DynamoDB ユーザー用の Bigtable

このドキュメントは、データストアとして Bigtable を使用するために、アプリケーションの移行または設計を行う DynamoDB のデベロッパーとデータベース管理者を対象としています。このドキュメントを読む前に、Bigtable の概要をご覧ください。

Bigtable と DynamoDB は、1 秒あたり数百万の秒間クエリ数（QPS）をサポートできる分散 Key-Value ストアであり、ペタバイト規模のデータまでスケールアップできるストレージを提供します。また、ノードの障害を許容できます。

これらのデータベースサービスの機能セットは似ていますが、その根底にあるアーキテクチャと動作の細部は異なっており、移行を開始する前にそれを理解することが重要です。このドキュメントでは、2 つのデータベースシステムの類似点と相違点に焦点を当てて説明します。

コントロールプレーン

DynamoDB と Bigtable では、コントロールプレーンを使用して容量を構成し、リソースを設定および管理できます。DynamoDB はサーバーレスプロダクトで、DynamoDB とのインタラクションの最上位レベルはテーブルレベルです。プロビジョニングされた容量モードでは、読み取り / 書き込みリクエストユニットのプロビジョニング、リージョンとレプリケーションの選択、バックアップの管理が行われます。Bigtable はサーバーレスプロダクトではありません。1 つ以上のクラスタを持つインスタンスを作成する必要があります。容量は、クラスタに含まれるノードの数によって決まります。これらのリソースの詳細については、インスタンス、クラスタ、ノードをご覧ください。

次の表は、DynamoDB と Bigtable のコントロールプレーンリソースを比較したものです。

DynamoDB	Bigtable
テーブル: 定義された主キーを持つアイテムのコレクション。テーブルには、バックアップ、レプリケーション、容量の設定があります。	インスタンス: 異なる Google Cloud ゾーンやリージョンにある Bigtable クラスタのグループ。このクラスタ間では、レプリケーションや接続のルーティングが発生します。レプリケーションポリシーはインスタンスレベルで設定されます。クラスタ: 地理的に同じ Google Cloud ゾーン、理想的にはレイテンシとレプリケーションの問題に対応するためにアプリケーションサーバーに配置された、ノードのグループ。容量を管理するには、各クラスタのノード数を調整します。テーブル: 行キーによってインデックス付けされた値の論理構成。バックアップはテーブルレベルで制御されます。
読み取り容量単位（RCU）と書き込み容量単位（WCU）: 固定ペイロードサイズで 1 秒あたりの読み取りまたは書き込みを可能にする単位。ペイロードサイズが大きいオペレーションごとに、読み取りまたは書き込みユニットに対して課金されます。 `UpdateItem` オペレーションは、更新がアイテム属性のサブセットに関係する場合にも、更新された項目の最大サイズ（書き込み前または更新後）に使用された書き込み容量を消費します。	ノード: データの読み取りと書き込みを行う仮想コンピューティングリソース。クラスタで読み取り、書き込み、スキャンのスループットの上限に変換されるノードの数。ノードの数は、レイテンシの目標、リクエスト数、ペイロードサイズの組み合わせに応じて調整できます。 SSD ノードは RCU と WCU との大きな違いとは異なり、同じスループットで読み取りと書き込みを行います。詳細については、通常のワークロードでのパフォーマンスをご覧ください。
パーティション: ノードと同じ場所に配置されたソリッドステートドライブ（SSD）を基盤とする連続する行のブロック。各パーティションには、1,000 WCU、3,000 RCU、10 GB のハードリミットが適用されます。	タブレット: 選択したストレージメディア（SSD または HDD）を基盤とする連続する行のブロック。ワークロードに合わせて、テーブルがタブレットに分割されます。タブレットは Bigtable のノードではなく、Google の分散ファイルシステムに保存されます。これにより、スケーリング時にデータを迅速に再配布でき、複数のコピーを維持することで耐久性が向上します。
グローバルテーブル: データ変更を複数のリージョンに自動的に伝播することで、データの可用性と耐久性を向上する方法。	レプリケーション: データの変更を自動的に同じリージョンまたは複数のゾーンに分散させることで、データの可用性と耐久性を向上する方法。
該当なし	アプリケーションプロファイル: クライアント API 呼び出しをインスタンス内の適切なクラスタに転送する方法を Bigtable に指示する設定。また、アプリプロファイルをタグとして使用して、アトリビューションの指標をセグメント化することもできます。

地理的レプリケーション

レプリケーションは、次のお客様要件をサポートするために使用されます。

ゾーンまたはリージョンの障害が発生した場合のビジネスの継続性を実現する高可用性。
サービスデータをエンドユーザーの近くに配置し、世界中のどこからでも低レイテンシでサービスを提供できます。
1 つのクラスタにバッチワークロードを実装し、サービスを提供するクラスタへのレプリケーションに依存する必要がある場合のワークロードの隔離。

Bigtable は、Bigtable が利用可能な Google Cloud リージョンのうち最大 8 つのリージョンで使用可能な数のゾーンで複製クラスタをサポートします。ほとんどのリージョンには 3 つのゾーンがあります。Bigtable は、マルチプライマリトポロジ内のクラスタ間で自動的にデータを複製します。つまり、任意のクラスタに対する読み取りと書き込みが可能です。Bigtable のレプリケーションでは、結果整合性が保たれます。詳細については、レプリケーションの概要をご覧ください。

DynamoDB には、複数のリージョン間でのテーブルレプリケーションをサポートするグローバルテーブルがあります。グローバルテーブルはマルチプライマリであり、リージョン間で自動的に複製されます。レプリケーションには結果整合性があります。

次の表に、レプリケーションのコンセプトと、DynamoDB と Bigtable における可用性を示します。

プロパティ	DynamoDB	Bigtable
マルチプライマリレプリケーション	はい、できます。任意のグローバルテーブルへの読み書きが可能です。	はい、できます。任意の Bigtable クラスタに対する読み取りと書き込みが可能です。
整合性モデル	結果整合性グローバルテーブルのリージョンレベルでの書き込み / 書き込みの整合性。	結果整合性すべてのテーブルで、リージョンレベルでの read-your-writes の整合性。
レプリケーションレイテンシ	サービスレベル契約（SLA）なし。数秒	サービスレベル契約（SLA）なし数秒
構成の粒度	テーブルレベル	インスタンスレベルインスタンスには複数のテーブルを含めることができます。
実装	選択した各リージョンにテーブルレプリカがあるグローバルテーブルを作成します。地域単位。テーブルをグローバルテーブルに変換することで、レプリカ間の自動レプリケーションを実現します。テーブルでは、DynamoDB ストリームが有効で、ストリームにはアイテムの新しい画像と古いイメージの両方が含まれます。リージョンを削除して、そのリージョン内のグローバルテーブルを削除します。	複数のクラスタを持つインスタンスを作成します。レプリケーションは、そのインスタンスのクラスタ間で自動的に行われます。ゾーンレベル。 Bigtable インスタンスに対してクラスタを追加または削除する。
レプリケーションのオプション	テーブルごと。	インスタンス単位。
トラフィックのルーティングと可用性	最も近い地理的レプリカにルーティングされるトラフィック。障害が発生した場合は、カスタムビジネスロジックを適用して、リクエストを他のリージョンにリダイレクトするタイミングを決定します。	アプリケーションプロファイルを使用して、クラスタトラフィックルーティングポリシーを構成します。複数クラスタのルーティングを使用して、トラフィックを最も近い正常なクラスタに自動的にルーティングします。障害が発生した場合、Bigtable は HA のためにクラスタ間の自動フェイルオーバーをサポートします。
スケーリング	レプリケートされた書き込みリクエストユニット（R-WRU）の書き込み容量は、レプリカ間で同期されます。レプリケートされた読み取り容量単位（R-RCU）の読み取り容量は、レプリカあたりです。	必要に応じて、複製された各クラスタに対してノードを追加または削除して、クラスタを個別にスケーリングできます。
費用	R-WRU は通常の WRU よりも 50% コストがかかります。	各クラスタのノードとストレージごとに料金が発生します。ゾーン間のリージョンレプリケーションには、ネットワークレプリケーションの費用は発生しません。レプリケーションはリージョンまたは大陸間でのレプリケーションの際に発生します。
SLA	99.999%	99.999%

データプレーン

次の表は、DynamoDB と Bigtable のデータモデルのコンセプトを比較したものです。テーブルの各行は、類似の特徴を表します。たとえば、DynamoDB の項目は Bigtable の行に似ています。

DynamoDB	Bigtable
アイテム: 主キーによって他のすべてのアイテムの中で一意に識別可能な属性のグループ。最大許容サイズは 400 KB です。	Row: 行キーで識別される単一のエンティティ。許容される最大サイズは 256 MB です。
なし	列ファミリー: 列をグループ化するユーザー指定の名前空間。
属性: 名前と値のグループ。属性値は、スカラー、セット、ドキュメントタイプのいずれかです。属性のサイズ自体に明示的な制限はありません。ただし、各アイテムは 400 KB に制限されているため、属性が 1 つだけのアイテムの場合、属性は、最大 400 KB から属性名が占有するサイズを差し引いた値になります。	列修飾子: 列の列ファミリー内の一意の識別子。列の完全な識別子は、column-family:column-qualification として表されます。列修飾子は、列ファミリー内で辞書順に並べ替えられます。列修飾子の最大許容サイズは 16 KB です。セル:セルは、特定の行、列、タイムスタンプのデータを保持します。セルには 100 MB までの 1 つの値が含まれます。
主キー: テーブル内のアイテムの一意の識別子。パーティションキーまたは複合キーを指定できます。パーティションキー: 1 つの属性で構成される単純な主キー。これにより、アイテムが存在する物理パーティションが決まります。2 KB までのファイルを選択できます。並べ替えキー: パーティション内の行の順序を決定するキー。1 KB までのファイルを選択できます。複合キー: パーティションキーと並べ替えキーまたは範囲属性の 2 つのプロパティから構成される主キー。	行キー: テーブル内のアイテムの一意の識別子。通常は、値と区切り文字を連結して表します。最大許容サイズは 4 KB です。列修飾子を使用して、DynamoDB の並べ替えキーと同等の動作を実現できます。複合キーは、連結された行キーと列修飾子を使用して作成できます。詳しくは、このドキュメントのスキーマ設計のセクションをご覧ください。
有効期間: アイテムごとのタイムスタンプにより、アイテムが不要になるタイミングが決定されます。指定したタイムスタンプの日時を過ぎると、項目は書き込みスループットを消費せずにテーブルから削除されます。	ガベージコレクション: セルごとのタイムスタンプにより、項目が不要になるタイミングが決まります。ガベージコレクションは、コンパクションと呼ばれるバックグラウンドプロセス中に期限切れのアイテムを削除します。ガベージコレクションポリシーは列ファミリーレベルで設定され、経過時間だけでなく、ユーザーが保持するバージョン数に基づいてアイテムを削除することもできます。クラスタのサイズを設定するときに、コンパクション用の容量に対応する必要はありません。

Operations

データプレーンオペレーションを使用すると、テーブル内のデータに対して作成、読み取り、更新、削除（CRUD）アクションを実行できます。次の表は、DynamoDB と Bigtable の同様のデータプレーンオペレーションを比較したものです。

DynamoDB	Bigtable
`CreateTable`	`CreateTable`
`PutItem` `BatchWriteItem`	`MutateRow` `MutateRows` Bigtable は書き込みオペレーションを upsert として扱います。
`UpdateItem` 条件付き書き込みインクリメントとデクリメント	`CheckAndMutateRow` `ReadModifyWriteRow` Bigtable は書き込みオペレーションを upsert として扱います。
`GetItem` `BatchGetItem`, `Query`, `Scan`	``ReadRow`` ``ReadRows` `（範囲、プレフィックス、リバーススキャン） Bigtable では、行キー接頭辞、正規表現パターン、行キーの範囲を前方または逆方向に効率的にスキャンできます。

データの種類

Bigtable と DynamoDB はどちらもスキーマレスです。列は、テーブルの存在やデータ型に対してテーブル全体に適用されることなく、書き込み時に定義できます。同様に、特定の列または属性のデータ型は、行またはアイテムごとに異なる場合があります。ただし、DynamoDB API と Bigtable API では、データ型の処理方法が異なります。

各 DynamoDB 書き込みリクエストには、各属性のタイプ定義が含まれており、読み取りリクエストのレスポンスで返されます。

Bigtable はすべてをバイトとして扱い、クライアントがレスポンスを正しく解析できるように、クライアントコードが型とエンコードを認識すると想定します。例外は increment オペレーションです。この値は、64 ビットビッグエンディアン符号付き整数として値を解釈します。

次の表は、DynamoDB と Bigtable のデータ型の違いを比較したものです。

DynamoDB	Bigtable
スカラー型: サーバーレスポンスでデータ型記述子トークンとして返されます。	バイト: クライアントアプリケーション内の目的の型にバイトがキャストされます。 Increment は、値を 64 ビットビッグエンディアン符号付き整数として解釈します
セット: 並べ替えられた一意の要素のコレクション。	列ファミリー: 列修飾子をメンバー名として使用し、それぞれに 0 バイトをセル値として指定できます。セットメンバーは、列ファミリー内で辞書順に並べ替えられます。
マップ: 一意のキーを使用した Key-Value ペアの並べ替えなしのコレクション。	列ファミリー列修飾子をマップキーと値の値のセル値として使用します。マップキーは、辞書順に並べ替えられます。
リスト: 並べ替えられたアイテムのコレクション。	列修飾子 insert timestamp を使用して、list_append（insert timestamp for prepend の逆）と同等の動作を実現します。

スキーマの設計

スキーマの設計では、データの保存方法に関する重要な考慮事項があります。Bigtable と DynamoDB の主な違いは次のとおりです。

単一値の更新
データの並べ替え
データのバージョニング
大きな値のストレージ

単一値の更新

DynamoDB の UpdateItem オペレーションは、更新でアイテムの属性のサブセットが使用されている場合でも、「前」と「後」のアイテムサイズのうち大きい方の書き込み容量を消費します。つまり、DynamoDB では、論理的には他の列の場合と同様に同じ行に配置される場合でも、頻繁に更新される列が別々の行に配置されることがあります。

Bigtable では、セルが特定の行の唯一の列か数千の列の中の一つの列かにかかわらず、セルを効率的に更新できます。詳しくは、単純な書き込みをご覧ください。

データの並べ替え

DynamoDB はパーティションキーをハッシュしてランダムに分散しますが、Bigtable は行キーの辞書的順序で行を保存し、ハッシュはユーザーに委ねます。

ランダムキー分散は、すべてのアクセスパターンに対して最適とは限りません。これにより、ホット行範囲のリスクを軽減できますが、パーティションをまたぐスキャンを伴うアクセスパターンは高コストで非効率的になります。これらの制限なしスキャンは、特に時間ディメンションを持つユースケースで一般的です。

このタイプのアクセスパターンを処理する場合（パーティションの境界を越えてスキャンする場合）、DynamoDB のセカンダリインデックスが必要になりますが、Bigtable ではセカンダリインデックスが不要になります。同様に、DynamoDB では、クエリとスキャンのオペレーションが 1 MB のデータスキャンに制限され、この上限を超えるとページ分けが必要になります。Bigtable にはそのような制限はありません。

パーティションキーがランダムに分散されているにもかかわらず、選択したパーティションキーがスループットに悪影響を及ぼすトラフィックを均一に分散していない場合、DynamoDB にホットパーティションを持つ場合があります。この問題に対処するために、DynamoDB では、書き込みを複数の論理パーティションキー値にランダムに分割する書き込みシャーディングを提案しています。

この設計パターンを適用するには、固定セット（1 ～ 10 など）から乱数を作成してから、この数値を論理パーティションキーとして使用する必要があります。パーティションキーがランダム化されているため、テーブルへの書き込みはすべてのパーティションキー値に分散されます。

Bigtable ではこの手順をキーソルティングと呼んでいます。ホットタブレットを避けるには効果的な方法です。

データのバージョニング

各 Bigtable セルにはタイムスタンプがあります。最新のタイムスタンプは常に、特定の列のデフォルト値になります。タイムスタンプの一般的なユースケースはバージョニングです。タイムスタンプは、その行と列の以前のバージョンのデータと異なる新しいセルを列に書き込みます。

DynamoDB にはこのようなコンセプトがないため、バージョニングをサポートする複雑なスキーマ設計が必要です。このアプローチでは、各アイテムのコピーを 2 つ作成します。1 つはコピー番号に v0_ が付いたバージョン番号（例: 並べ替えキー）を使用し、もう 1 つのコピーにはバージョン番号を設定します。接頭辞の接頭辞（v1_ など）。アイテムが更新されるたびに、更新されたバージョンの並べ替えキーで次に上位のバージョンプレフィックスを使用し、更新されたコンテンツをバージョンプレフィックスのゼロの項目にコピーします。これにより、接頭辞 0 を使用して最新バージョンのアイテムを確実に配置できます。この戦略では、アプリケーション側のロジックを維持する必要がありますが、書き込みごとに前の値の読み取りと 2 回の書き込みを行う必要があるため、データの書き込みに非常にコストがかかります。

複数行トランザクションと大容量行の比較

Bigtable は複数行トランザクションをサポートしていません。ただし、DynamoDB に存在するアイテムよりもはるかに大きい行を保存できるため、多くの場合、共有行キーの下に関連するアイテムをグループ化するスキーマを設計することで、目的のトランザクション性を実現できます。このアプローチを示す例については、単一テーブル設計パターンをご覧ください。

大きな値の格納

Bigtable の行に似た DynamoDB アイテムは 400 KB に制限されているため、大きな値を格納するには、アイテムをアイテム間で分割するか、S3 のような他のメディアに保存する必要があります。どちらの方法も、アプリケーションに複雑性をもたらします。これに対して、Bigtable のセルは最大 100 MB まで保存でき、Bigtable の行は最大 256 MB をサポートできます。

スキーマ変換の例

このセクションの例では、重要なスキーマ設計の違いを考慮して、DynamoDB から Bigtable にスキーマを変換します。

基本スキーマの移行

商品カタログは、基本的な Key-Value パターンを示す良い例です。このようなスキーマは DynamoDB では次のようになります。

主キー		属性
パーティションキー	ソートキー	Description	料金	サムネイル
hats	fedoras#brandA	プレミアムウールから作られています。	30	https://storage…
hats	fedoras#brandB	耐久性の高い耐水キャンバス。	28	https://storage…
hats	newsboy#brandB	ヴィンテージの魅力を日常の印象に変えましょう。	25	https://storage…
shoes	sneakers#brandA	スタイリングと快適さで	40	https://storage…
shoes	sneakers#brandB	クラシックな機能に現代的な素材を使用	50	https://storage…

このテーブルでは、DynamoDB から Bigtable へのマッピングは簡単にできます。DynamoDB の複合主キーを複合 Bigtable 行キーに変換します。同じ列のセットを含む 1 つの列ファミリー（SKU）を作成します。

	SKU
行キー	Description	料金	サムネイル
hats#fedoras#brandA	プレミアムウールから作られています。	30	https://storage…
hats#fedoras#brandB	耐久性の高い耐水キャンバス。	28	https://storage…
hats#newsboy#brandB	ヴィンテージの魅力を日常の印象に変えましょう。	25	https://storage…
shoes#sneakers#brandA	スタイリングと快適さで	40	https://storage…
shoes#sneakers#brandB	クラシックな機能に現代的な素材を使用	50	https://storage…

単一のテーブル設計パターン

単一テーブルの設計パターンは、リレーショナルデータベースの複数のテーブルを DynamoDB の 1 つのテーブルにまとめます。前の例のアプローチを採用し、Bigtable でこのスキーマをそのまま複製できます。ただし、プロセスのスキーマの問題に対処することをおすすめします。

このスキーマでは、パーティションキーに動画の一意の ID が含まれているため、その動画に関連するすべての属性が同じ場所に配置され、アクセスが速くなります。DynamoDB のアイテムサイズの制限により、1 行にフリーコメントを無制限に入力することはできません。したがって、パターン VideoComment#reverse-timestamp の並べ替えキーを使用して、各コメントがパーティション内の個別の行を時系列の新しい順で並べ替えます。

この動画に 500 件のコメントがあり、所有者が動画を削除したとします。つまり、すべてのコメントと動画属性も削除する必要があります。DynamoDB でこれを行うには、このパーティション内のすべてのキーをスキャンし、複数の削除リクエストを発行して反復処理する必要があります。DynamoDB は複数行トランザクションをサポートしていますが、この削除リクエストは大きすぎて単一のトランザクションで実行することはできません。

主キー		属性
パーティションキー	ソートキー	アップロード日	形式
0123	動画	2023-09-10T15:21:48	{"480": "https://storage…", "720": "https://storage…", "1080p": "https://storage…"}
	VideoComment#98765481	コンテンツ
	VideoComment#98765481	これすごく好き特別な効果が素晴らしい。
	VideoComment#86751345	コンテンツ
	VideoComment#86751345	1:05 に音声の不具合があるようです。
	VideoStatsLikes	数
	VideoStatsLikes	3
	VideoStatsViews	数
	VideoStatsViews	156
0124	動画	2023-09-10T17:03:21	{"480": "https://storage…", "720": "https://storage…"}
	VideoComment#97531849	コンテンツ
	VideoComment#97531849	すべての友人と共有しました。
	VideoComment#87616471	コンテンツ
	VideoComment#87616471	このスタイルは映画監督を思い出させるものですが、それが誰かはっきりしません。
	VideoStats	ViewCount
	VideoStats	45

コードを簡素化しデータリクエストをより高速かつ低コストで行えるように、移行時にこのスキーマを変更します。Bigtable の行は DynamoDB の項目よりもはるかに大容量であり、多数のコメントを処理できます。動画に数百万件のコメントが寄せられる場合は、ガベージコレクションポリシーを設定して、最新のコメント数を決めてそれだけを保持するようにします。

カウンタは、行全体を更新するオーバーヘッドなしに更新できるため、分割する必要はありません。Bigtable のタイムスタンプでは、時系列の新しいコメントが自動的に取得されるため、UploadDate 列を使用する、または逆のタイムスタンプを計算して並べ替えキーを作成する必要はありません。これにより、スキーマが大幅に簡素化され、動画が削除されると、1 つのリクエストで動画の行（すべてのコメントを含む）をトランザクション的に削除できます。

最後に、Bigtable の列は辞書順に整理されているため、動画の読み込み時に単一の読み込みリクエストで高速の範囲スキャン（動画プロパティから最新の N 個のコメントまで）を行えるように列の名前を変更できます。その後、ビューアがスクロールしたときに残りのコメントをページ分割できます。

	属性
行キー	形式	高評価	ビュー	UserComments
0123	{"480": "https://storage…", "720": "https://storage…", "1080p": "https://storage…"} @2023-09-10T15:21:48	3	156	これすごく好き特別な効果が素晴らしい。@ 2023-09-10T19:01:15 There seems to be an audio glitch at 1:05. @ 2023-09-10T16:30:42
0124	{"480": "https://storage…", "720":"https://storage…"} @2023-09-10T17:03:21		45	このスタイルは映画監督を思い出させるものですが、それが誰かはっきりしません。@2023-10-12T07:08:51

隣接リスト設計パターン

この設計の少し異なるバージョンについて考えてみましょう。これは、DynamoDB では隣接リスト設計パターンとよく呼ばれます。

主キー		属性
パーティションキー	ソートキー	DateCreated	詳細
Invoice-0123	Invoice-0123	2023-09-10T15:21:48	{"discount": 0.10, "sales_tax_usd":"8", "due_date":"2023-10-03.."}
	Payment-0680	2023-09-10T15:21:40	{"amount_usd": 120, "bill_to":"John…", "address":"123 Abc St…"}
	Payment-0789	2023-09-10T15:21:31	{"amount_usd": 120, "bill_to":"Jane…", "address":"13 Xyz St…"}
Invoice-0124	Invoice-0124	2023-09-09T10:11:28	{"discount": 0.20, "sales_tax_usd":"11", "due_date":"2023-10-03.."}
	Payment-0327	2023-09-09T10:11:10	{"amount_usd": 180, "bill_to":"Bob…", "address":"321 Cba St…"}
	Payment-0275	2023-09-09T10:11:03	{"amount_usd": 70, "bill_to":"Kate…", "address":"21 Zyx St…"}

このテーブルでは、並べ替えキーは時間ではなく支払い ID に基づいているため、別のワイドカラムパターンを使用して、Bigtable でこれらの ID を別々の列にすることができるため上記と同様のメリットが得られます。

	請求書	支払い
行キー	詳細	0680	0789
0123	{"discount": 0.10, "sales_tax_usd":"8", "due_date":"2023-10-03.."} @ 2023-09-10T15:21:48	{"amount_usd": 120, "bill_to":"John…", "address":"123 Abc St…"} @ 2023-09-10T15:21:40	{"amount_usd": 120, "bill_to":"Jane…", "address":"13 Xyz St…"} @ 2023-09-10T15:21:31
行キー	詳細	0275	0327
0124	{"discount": 0.20, "sales_tax_usd":"11", "due_date":"2023-10-03.."} @ 2023-09-09T10:11:28	{"amount_usd": 70, "bill_to":"Kate…", "address":"21 Zyx St…"} @ 2023-09-09T10:11:03	{"amount_usd": 180, "bill_to":"Bob…", "address":"321 Cba St…"} @ 2023-09-09T10:11:10

前の例からわかるように、適切なスキーマ設計により、Bigtable のワイドカラム型モデルは非常に強力であり、高コストな複数行トランザクション、セカンダリインデキシング、または他のデータベースでの on-delete cascade 処理が必要な多くのユースケースに使用できます。

次のステップ

Bigtable のスキーマ設計について確認する。
Bigtable エミュレータについて確認する。
Google Cloud に関するリファレンスアーキテクチャ、図、ベストプラクティスを確認する。Cloud Architecture Center をご覧ください。