2.4標準
顧客ごとにプロフィール、注文、支払い履歴を同じテーブルで取得する。
顧客ID単位のQueryを高速にし、項目種別も判別できるようにする。
最も適切な設計はどれか。
× 不正解
単一テーブル設計では、アクセスパターンに合わせてPK/SKを設計し、begins_withなどで種別をQueryする。
詳細解説
正しいPKをCUSTOMER#id、SKを種別と時刻の複合値にする
同一顧客の項目をitem collectionへまとめ、SKの順序でQueryできる。
同一顧客の項目をitem collectionへまとめ、SKの順序でQueryできる。
誤りすべてをパーティションキーなしで保存する
DynamoDB項目には主キーが必要で、目的のQueryも表現できない。
DynamoDB項目には主キーが必要で、目的のQueryも表現できない。
誤り顧客ごとに別テーブルを作る
テーブル数と運用が増え、アクセスパターンを一元管理しにくい。
テーブル数と運用が増え、アクセスパターンを一元管理しにくい。
誤りTTLを顧客IDへ設定する
TTLは期限削除用の時刻属性であり、関連項目のグループ化を行わない。
TTLは期限削除用の時刻属性であり、関連項目のグループ化を行わない。
実際に確かめる
一時的な検証環境で実行できる例です。
Amazon DynamoDB item collections、single-table design、Query key conditionの公式説明を確認する。期待される結果
PK共有によるitem collectionと、テーブル分割・Scan依存の違いを説明できる。理解のポイント
- Item collection
- PK/SK
- single-table design
- Query
確認時の注意
- 確認環境: AWS公式DEA-C01試験ガイドと各サービスの公式ドキュメントの確認
- AWS公式DEA-C01 Domain 2・Task 2.4と各サービスの公式ドキュメントを確認する。
基礎のおさらい
キーの表現
エンティティ種別をSKプレフィックスへ入れ、時刻やIDで並び替える。
上限と偏り
一つのPKへ集中するサイズ・スループットを測定し、必要なら分散キーを検討する。
問題IDAWS-DEA-171
確認環境AWS公式DEA-C01試験ガイドと各サービスの公式ドキュメントの確認
最終技術確認2026-08-20
誤り・権利侵害を報告