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