DynamoDBのキー設計・インデックス・キャパシティ（SAA）
パーティションキー／ソートキー、LSIとGSI、QueryとScan、RCU/WCU、キャパシティモード、条件付き書き込み、TTL、トランザクションの入口まで試験視点で厚く整理します。
このページの狙い
DynamoDB はキー設計とアクセスパターンがそのまま性能とコストになります。ここでは プライマリキー／セカンダリインデックス／API 選択／キャパシティ／よくある落とし穴を、誤答になりやすい言い回しとセットで厚くします。細かい数式やクォータは更新されるため、公式の Limits／Pricing を最終確認してください。
公式ドキュメント（入口）
データモデル（テーブル → アイテム → 属性）
DynamoDB は テーブルの下に アイテム（行相当）、その下に 属性（名前と値のペア）がぶら下がります。「スキーマレス」に見えても、本番ではアクセスパターンが固定されているほど設計が楽になります。試験では「とりあえずテーブル一つで全部解決」より、GSI を足す前にパーティションキーを見直す方が正解になりやすいです。
プライマリキー（パーティションキーとソートキー）
| キー | 役割 | 試験で効くポイント |
|---|---|---|
| パーティションキー（ハッシュキー） | データをどのパーティションに載せるかの入力 | カーディナリティが低いと偏りやすい |
| ソートキー（レンジキー） | 同一パーティション内の並び順・範囲取得 | begins_with や範囲条件と相性が良い |
複合キー（パーティション＋ソート）では、パーティションキー値が同じアイテム群の中でソートキーが並びます。ソートキー単体の重複は、パーティションキーが異なれば許容されます。
ホットパーティション（具体イメージ）
例: 人気イベントの eventId だけをパーティションキーにし、秒間数万回の書き込みが同一キーに集中する。DynamoDB はスケールしますが、設計としては危険信号です。対策の方向性は教材どおり キー空間の分割（ユーザーID を前置する、シャードサフィックスを付ける、書き込みをキューで平滑化する等）を検討します。試験では「スループットを上げれば設計不要」が誤答になりやすいです。
LSI と GSI（混同ポイントを深掘り）
| LSI（ローカルセカンダリインデックス） | GSI（グローバルセカンダリインデックス） | |
|---|---|---|
| パーティションキー | ベーステーブルと同じ | 別属性を指定できる |
| 作成タイミング | テーブル作成時のみ | 後から追加可能 |
| 用途のイメージ | 同じイベント内で「別の並べ替え軸」が欲しい | メールアドレス・外部ID など別次元で引きたい |
| 投影（Projection） | KEYS_ONLY / ALL / INCLUDE の話が出る | 同様。読み取りコストとサイズに影響 |
GSI は便利ですが、ベーステーブルへの書き込み1回が GSI 側にも伝播し、キャパシティ消費が増える点が試験に効きます。「検索要件が増えるたびに GSI を量産」は、コスト・運用の観点で誤答になりやすいです。
主要 API の使い分け（試験）
| 操作 | ざっくり | 落とし穴 |
|---|---|---|
GetItem |
単一アイテム取得 | キーが分からないと使えない |
Query |
パーティションキー等号＋ソートキー条件 | 効率的な本命。1リクエストあたりのデータ量上限に注意 |
Scan |
テーブル横断 | 本番の主パターンにするとコストと遅延が爆発しやすい |
BatchGetItem |
複数キーをまとめて取得 | 未処理キー・再試行設計が絡む |
BatchWriteItem |
まとめて Put/Delete | 順序保証はしない前提で設計 |
「全ユーザーの監査ログを毎回 Scan で洗い出す」より、パーティションキーを時刻やテナントで分割し Query が正解になりやすいです。
キャパシティの考え方（RCU / WCU のイメージ）
プロビジョンドモードでは、読み込みキャパシティユニット（RCU） と 書き込みキャパシティユニット（WCU） で上限を決めます。試験では「強一貫読み取りは通常読み取りより消費が増える」など、読み取りの種類で単価が変わる話が出ます（詳細は公式の読み取りキャパシティの説明に従う）。
スロットリングは、プロビジョンドの上限に達したときに ProvisionedThroughputExceededException として現れます。対策は キャパシティ増、指数バックオフでのリトライ、ホットキー緩和、オンデマンド／Auto Scaling などの文脈で比較されます。
キャパシティモード（意思決定）
| モード | 向き | 注意 |
|---|---|---|
| オンデマンド | トラフィックが読めない／急激なスパイク | 一定の高負荷が常時続く場合、プロビジョンド＋適切な上限の方が安くなる可能性を比較 |
| プロビジョンド | RCU/WCU を見積もれる | 上限超過でスロットリング。Application Auto Scaling で緩和 |
モード切替には制限時間があるため、設問に「今すぐ何度でも切替」と出たら公式の切替ルールで照合します。
条件付き書き込みと楽観ロック
ConditionExpression により「在庫がまだ残っているときだけ減算」のような compare-and-set が実現できます。試験では、バージョン番号属性を持たせて競合を検知するパターンとセットで語られます。
TTL（生存期間）
期限切れアイテムの自動削除に使います。試験では「TTL は即時削除を保証する」と絶対化する誘導に注意します。削除タイミングはベストエフォートという説明が公式にあります。
トランザクション（入口）
TransactWriteItems / TransactGetItems で、複数アイテムをまとめて All-or-nothing に近い操作ができます。RDB の広いトランザクション境界と同一視せず、対象アイテム数や制約は公式を参照してください。
レイテンシーと DAX
DynamoDB 単体でもミリ秒台を狙えますが、同一データへの読み取り集中（プロフィール、人気商品マスタ）なら DAX（DynamoDB Accelerator） が選択肢です。DAX は DynamoDB 互換 API を持ち、アプリ改修を抑えやすい点が試験の対比ポイントです（ElastiCache, DAX、Redis と Memcached の比較）。
整合性・ストリーム・グローバルテーブル・バックアップ
→ DynamoDB の整合性・ストリーム・グローバルテーブル・バックアップ（SAA）
関連トピック
重要ポイント
- ▸パーティションキーは分散の単位。偏りはホットパーティションとスロットリングの原因。カーディナリティとアクセス分布を設計に含める
- ▸LSIは同一パーティションキー内の別ソート軸でテーブル作成時のみ。GSIは別パーティションキーで横断するが書き込み増と課金増に注意
- ▸プロビジョンドはRCU/WCUの見積もりとスロットリング、オンデマンドは変動負荷向けだが常時高負荷では単価面を比較する
- ▸1アイテム最大400KB。巨大ペイロードはS3＋ポインタが定石。Scanはフルテーブル相当のコストになりやすい
- ▸DAXは読み取り集中のミクロ秒化。ElastiCacheとの差（DynamoDB互換API）は試験で対比される
このトピックの学習を完了しますか？
完了状態はいつでも切り替えられます
この試験ドメイン内で次の学習に進む
同じサービスの関連トピック
RDS / Aurora / ElastiCache に関連するトピックを続けて確認できます。