どんな場面で検討するか
JSON等のドキュメントを、アプリのアクセスキーに沿って保存し、変動負荷や複数地域への配信を設計したい場合。トランザクション、整合性、APIは必要条件に合わせて選ぶ。
組織で使う条件
パーティションごとのRU消費と429を監視し、SDKの再試行と冪等化を組み合わせる。権限/ネットワークとバックアップを設計し、整合性レベルをアプリの要件で確認する。
採用前に試すこと
- 代表的な検索/更新からパーティションキー案を作り、合成ドキュメントを投入する。
- 点読取・索引検索・パーティションをまたぐ検索を実行し、RU・遅延・429を記録する。
- 同じ更新を再送して重複を検出し、バックアップ/復旧方式と料金方式を比較する。
合格と判断する条件
- 期待する検索結果と更新結果が一致し、429時に記録・制限付き再試行で回復する。
- キーの偏りとクエリ別RUを説明し、採用APIと課金方式を特定できる。
見落としたくない点
- 多くの表を自由に結合する業務集計ならリレーショナルDBと比較する。偏ったキーのままRUを増やすだけの対処や、全APIで同じ制約/料金と思う選定は避ける。
- 多くの表を自由に結合する業務集計ならリレーショナルDBと比較する。偏ったキーのままRUを増やすだけの対処や、全APIで同じ制約/料金と思う選定は避ける。