DynamoDB ユーザー用の Bigtable

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

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

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

コントロールプレーン

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

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

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

地理的レプリケーション

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

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

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

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

次の表では、レプリケーションのコンセプトを一覧表示して、DynamoDB と Bigtable での可用性について説明します。

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

データプレーン

次の表は、DynamoDB と Bigtable のデータモデルのコンセプトを比較したものです。表の各行は、類似する機能を示しています。たとえば、DynamoDB のアイテムは Bigtable の行に似ています。

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

運用

データプレーンオペレーションを使用すると、テーブル内のデータに対して作成、読み取り、更新、削除（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 つは、ソートキーの先頭にバージョン番号の接頭辞 0（v0_ など）が付いたコピー、もう 1 つは、バージョン番号の接頭辞 1（v1_ など）が付いたコピーです。アイテムが更新されるたびに、更新されたバージョンの並べ替えキーで次に高いバージョンプレフィックスを使用し、バージョンプレフィックスが 0 のアイテムに更新されたコンテンツをコピーします。これにより、任意のアイテムの最新バージョンをゼロ接頭辞を使用して特定できるようにします。この戦略では、アプリケーション側のロジックを維持する必要があるだけでなく、データの書き込みに非常に多くの費用と時間がかかります。これは、各書き込みで前の値の読み取りと 2 回の書き込みが必要になるためです。

複数行トランザクションと大きい行の容量

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

大きな値の格納

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

スキーマ変換の例

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

基本的なスキーマの移行

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

主キー		属性
パーティションキー	ソートキー	説明	料金	サムネイル
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 行キーに変換します。同じ一連の列を含む列ファミリー（SKU）を 1 つ作成します。

	SKU
行キー	説明	料金	サムネイル
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 でそのまま複製できます。ただし、プロセスでスキーマの問題に対処することをおすすめします。

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

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

主キー		属性
パーティションキー	ソートキー	UploadDate	形式
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 列を使用する必要も、新しい順のタイムスタンプを計算して並べ替えキーにする必要もありません。これによりスキーマが大幅に簡素化され、動画が削除された場合は、単一のリクエストで、すべてのコメントを含む動画の行をトランザクションで削除できます。

最後に、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 を確認する。