TomoMemo.devDynamo DBの設計に際し、役立った視点をメモ。
意図（Intent：利用目的）
- 誰が、何を、どれくらいの速さで取得したいのかを明確にする
- DynamoDB設計の出発点は「アクセスパターン（データの取得要求）」の理解にある
- どの問い合わせに即答したいのか？
- アクセスパターンの核（最も頻出し、即答したい質問群）を定義すること
形（Shape：データ構造の形状）
- 問い合わせに最短で答えるために、データはどんなキー構造（Primary Key/Sort Key）と粒度（データの分割単位）にすべきかを決める
- DynamoDBはスキーマレス（柔軟な構造を許容するデータモデル）だが、クエリ主導設計（取得要件を起点とした設計）が基本となる
- Query一発で取れる形か？サイズは小さいか？
- データ取得が最小コストで完結する形を追求すること
流れ（Flow：データライフサイクルの流れ）
- データはどのように投入（ETL：Extract Transform Load）され、更新（Upsert/PutItem）され、削除（TTL：Time To Live）されるのかを定義する
- 冪等性（べきとうせい）（Idempotency：同じ操作を繰り返しても結果が変わらない性質）や再試行設計（Retry Handling）も含める
- 壊れない書き込みと、詰まらない取り込みになってるのか？
- データの流れにおける「耐障害性（Fault Tolerance）」を担保すること
限界（Limits：物理的・論理的制約）
- Dynamo DBには「物理法則」が存在する
- スループット制限（Read/Write Capacity Units）
- 分散要件（パーティションキー分布）
- アイテムサイズ上限（400KB）
- コスト制約（課金モデル）
- 整合性レベル（Consistency Model）
- どこが詰まる？どう監視・スケールするのか？
- ホットパーティション（特定キーへの過集中アクセス）やクォータ制限（サービス上限値）を予測し、設計段階で回避すること
進化（Evolution & Governance：進化と統治）
- 将来の要件変化や検索軸の追加、セキュリティポリシーの変更、運用体制の拡張に対して、小さく安全に適応できるか
- DynamoDB設計は「一度作ったら終わり」ではなく、スキーマ進化（Schema Evolution）と運用統治（Governance）の両立が重要