基礎
DynamoDB を列のあるスプレッドシートのようにモデル化してから、スキーマも
ALTER TABLE もなく、プライマリキーがディスク上の住所だと気づく。あとで
スケッチするアクセスパターンは、どれもその住所に収まるか、それと戦うかだ。
このセクションは型付き値モデル、1 つのパーティションキーの下でアイテムが コレクションにまとまる仕組み、そして一貫性の選択がなぜどの読み取り API にも 出てくるか。SQL の癖はここで捨てる。属性はアイテムごとに任意で、型は API 境界で重要であり、複合キーはメタデータではなく — データの物理的なソート順だ。
読み終えたらできること
- 任意の DynamoDB アイテムを見て、JSON から推測せずに各属性の型を言える。
- なぜ
Queryが 1 つのアイテムコレクションを返すのか、パーティションキーと ソートキーがディスク上で実際に何を制御するかを説明できる。 - 非正規化の前にアイテムサイズを見積もり、400 KB の硬上限がいつ書き込みを 拒否するかを知っている。
- 読み取りで強整合と結果整合のどちらを選ぶか決め、古いデータが UI で何を 犠牲にするか予測できる。
読む順番
次の順でガイドを進める。各ステップは前のものを前提にする。
- いつ DynamoDB を使うか — キーバリュー設計に ストレージと移行コストを投じる前の、向き／不向きの判断。
- データ型 —
S、N、B、セット、リスト、 マップ。すべての API 呼び出しが守るべき型タグ。 - JSON マーシャリング — 素の JSON が 型付き DynamoDB 属性になる経路と、黙った型変換が刺さる場所。
- アイテムサイズ上限 — 400 KB の上限、 何がカウントされるか、子をインラインに詰めると超えるパターン。
- アイテムベースの操作 — すべての操作は アイテム全体が対象。部分更新は式であり、列書き込みではない。
- アイテムコレクション — 同じ
パーティションキーを共有する全アイテム。1 回の
Queryがソート順で辿れる単位。 - 複合プライマリキー — パーティション + ソートキーとしての物理配置。DynamoDB の「プライマリキー」がスカラーではなく 範囲である理由。
- 一貫性 — ベーステーブルでの強整合と結果整合。 GSI に対して要求できること／できないこと。
USER#123 上の複合キーにソートキー PROFILE、ORDER#… があれば、1 回の
Query でユーザーのプロフィールと直近の注文を時刻順に返せる。アイテム
コレクションを誤解すると、テーブルを Scan するか、各行を GetItem で
取るか — どちらもスケールが悪く、どちらも請求に出る。
DynoTable で手を動かす
DynoTable でライブテーブルを開き、グリッドでキーを確認する。 テーブルの概要はパーティションキーとソートキーの名前に加え、すべての GSI を 示すので、クエリを書く前にアイテムのまとまり方が見える。サンプルアイテムを 無料の アイテムサイズ計算機 に貼ると、400 KB 上限に向けたバイト数が測れる。子レコードを 3 つ非正規化すると、読み取り／ 書き込みキャパシティユニットの切り上げが始まる 1 KB の線を越えがちだ。
ビジュアルなフィルタービルダーは型対応の演算子でハッシュキーとレンジキーの
条件を足せるので、JSON を手書きせず、実コレクションに対する Query を練習できる。
無料の読み取り専用アクセスはクエリ、PartiQL SELECT、エクスポートをカバーする。
書き込みには有料トライアルまたはライセンスが必要。
DynoTable をダウンロードして、読み進めながら自分のテーブルで これらのプリミティブを動かそう。