データモデリング

SQL が教えた癖でエンティティごとに 1 テーブルへ正規化し、それからフル Scan なしではクエリできない DynamoDB テーブルを出荷する。移行コストはプロダクトが 本番に出てから降りかかる。

DynamoDB のモデリングはアクセスパターンから始まる。機能が必要とする読み書きを 列挙し、それを満たすキーと GSI を設計する。シングルテーブル設計は、パターンが 重なるときに多くのエンティティ型を 1 テーブルに詰める。それはトレードオフであり、 宗教ではない。このセクションはそのパターンと、複数テーブルの方が安く作れて 運用できるケースの両方を教える。

読み終えたらできること

• キーより先にアクセスパターンを書き出し、各パターンを Query か正当化された Scan に対応づけられる。
• エンティティ接頭辞、オーバーロードされたキー、ホットな部分集合向けのスパース GSI を備えたシングルテーブルレイアウトを設計できる。
• 別テーブル、キャッシュ、またはリレーショナルなサイドカーが 1 テーブルの 複雑さに勝つときを見分けられる。
• type 属性と非正規化フィールドを、冪等な書き込みを壊さずに使える。

読む順番

1. シングルテーブル設計 — メンタルモデル。 1 テーブル、多数のエンティティ型、同居のためのキー選択。
2. データのモデル化方法 — ワークシート。 アクセスパターンを入れ、キー設計と GSI を出す。
3. シングルテーブルにしないとき — 境界づけられたコンテキスト、重なりの薄さ、1 レイアウトに運用税を払うチーム。
4. type 属性 — 曖昧な属性形なしに、1 つの コレクション内でエンティティ種別を区別する。
5. 非正規化 — 2 ホップを避けるために フィールドを複製する。更新で何を失うかを知る。
6. シングルトンアイテム — カウンター、設定、 親の隣に置かなければならないメタデータ向けの、パーティションあたり 1 行。

シングルテーブル設計が輝くのは、1 回の Query が親とその子を返すとき — 例えば PK = ORDER#K4 がヘッダー、明細、出荷イベントをソート順で返すときだ。 2 つのサービスが無関係なドメインを所有し、新機能のたびに別のオーバーロード GSI が要るときは失敗する。このセクションの 3 本目のガイドは、重なりが薄いときに 複数テーブルを使う許可証だ。

非正規化は表示用フィールドを親行へ複製し、ダッシュボードが 2 ホップを要しない ようにする。トレードオフは書き込みのファンアウト。顧客の表示名を変えると、 それをキャッシュしたすべての注文アイテムに触れることがある。シングルトン アイテム（PK = CONFIG、SK = APP）は、別の設定ストアなしにグローバルト カウンターや機能フラグをテナントデータの隣に置く。テナントパーティションへの Query が無関係な設定のメガバイトを誤って返さないよう、明示的にモデル化する。

DynoTable で試す

AWS に触る前にキーをスケッチする。無料の シングルテーブル設計プランナー は アクセスパターンの一覧を PK/SK 配置、GSI 提案、サンプルアイテム、CreateTable JSON に変える。出力を DynoTable に貼り、アイテムが実際にどうコレクションへ 着地するかを眺める。

キーが満たさないパターンには、SQL Workbench が 境界づけられた読み取りの上でクライアント側に JOIN と集約を走らせる — 正直な救済であり、モデリングの言い訳ではない。有料プランはエディタでアイテム形を 試作するときの書き込みステージングを追加する。

DynoTable をダウンロードして、ライブテーブルに対してこれらの レイアウトをモデル化し、閲覧しよう。