DynamoDBのテーブル設計

実はRDBよりもカッチリ設計する必要がある。　→ ウォーターフォール的

DynamoDBのQueryは条件を最大2つしか設定できない（Primary Key + Sort Key）ので、追加の要件に弱い。

RDBは正規化していればあとから要件が増えても対応できる。

鉄則

テーブル数はなるべく少なくする。（理想はシングルテーブル）

1. DynamoDBはテーブル単位課金なのでコストメリットがある
2. O11yの観点でも、単一テーブルへの監視設定で済む方が楽

手順

1. データモデリング。ER図を作る。
2. ユースケース（get◯◯by△△のようなクエリ条件）をリスト化する
3. スキーマ設計する
4. ユースケース表に対応するクエリを書き出す
   1. 対象が現実的なデータ量であれば、ScanやFilterを使っても良い
5. 満たせていなければ3からやり直し

テクニック

• GSIオーバローディング
  • PKとSKの属性に「特定の種類の項目を入れない」設計方法
  • 極端な例、PKを「PK」という項目名にしてしまう
    • ここにはUserIDが入ったり、BookIDが入ったり、とにかくエンティティのPKが入るという
  • GSIを複数設定しなくても、ひとつの属性でエンティティごとの検索ができるメリットがある
• 複合ソートキー
  • 1つのソートキーに2種類以上の値を入れる
  • 例えば、MessageID#created_at
  • こうすることで、ソートキーを検索条件に使いつつ末尾の作成日時でソートされてクエリ結果を返せる
    • begin_with句で前方一致がかけられるからこそなせる技