2.4標準
注文と注文項目を、顧客IDで一覧し、注文IDで詳細取得する。
読み取りを単一キー中心にし、複数のScanを避けたい。
最も適切な設計はどれか。
× 不正解
DynamoDBはアクセスパターンを先に定義する。顧客IDをPK、注文時刻や注文IDをSKにするなど、Queryで取得できるモデルにする。
詳細解説
正しいPK/SKを顧客・注文の階層にし、必要なGSIを定義する
アクセスパターンからキーを設計し、Queryで顧客の注文と注文項目を取得できる。
アクセスパターンからキーを設計し、Queryで顧客の注文と注文項目を取得できる。
誤り全項目を1行の巨大JSONへ詰める
更新競合や項目サイズ制限、部分取得の難しさが増える。
更新競合や項目サイズ制限、部分取得の難しさが増える。
誤りすべての検索をScanで実行する
全項目を読むため、データ量に比例してコストと遅延が増える。
全項目を読むため、データ量に比例してコストと遅延が増える。
誤り顧客IDをTTL属性にする
TTLは期限削除属性であり、顧客の検索キーにならない。
TTLは期限削除属性であり、顧客の検索キーにならない。
実際に確かめる
一時的な検証環境で実行できる例です。
Amazon DynamoDB single-table design、Query、Scan、GSIの公式説明を確認する。期待される結果
Query中心のキー設計とScan依存の違いを説明できる。理解のポイント
- アクセスパターン
- PK/SK
- GSI
- Query
確認時の注意
- 確認環境: AWS公式DEA-C01試験ガイドと各サービスの公式ドキュメントの確認
- AWS公式DEA-C01 Domain 2・Task 2.4と各サービスの公式ドキュメントを確認する。
基礎のおさらい
非正規化
読み取り要件を満たすため、同じ情報を複数項目へ複製することがある。
変更耐性
将来の検索条件をGSIや複合SKで表現できるか、書き込みコストも含めて確認する。
問題IDAWS-DEA-165
確認環境AWS公式DEA-C01試験ガイドと各サービスの公式ドキュメントの確認
最終技術確認2026-08-20
誤り・権利侵害を報告