2.1標準
顧客・注文・注文履歴を、顧客IDと注文IDから低レイテンシで取得する。
JOINを使わず、アクセスパターンを先に定義して単一テーブルへ格納する。
最も適切なデータストアはどれか。
× 不正解
DynamoDB単一テーブル設計ではアクセスパターンを基準にPK・SKを設計し、関連エンティティを同じアイテムコレクションへ置く。
詳細解説
正しいDynamoDBの単一テーブル設計と複合キー
PK・SKの組み合わせとアイテムコレクションで、定義したアクセスパターンを1回のQueryで取得できる。
PK・SKの組み合わせとアイテムコレクションで、定義したアクセスパターンを1回のQueryで取得できる。
誤りRDSで毎回3テーブルをJOINする
柔軟な関係クエリには向くが、ミリ秒のキーアクセスと大規模なスケール要件では別設計が必要になる。
柔軟な関係クエリには向くが、ミリ秒のキーアクセスと大規模なスケール要件では別設計が必要になる。
誤りS3のファイル名に顧客と注文を連結する
ファイル名だけでは条件付き更新・低レイテンシQuery・同時実行制御を提供しない。
ファイル名だけでは条件付き更新・低レイテンシQuery・同時実行制御を提供しない。
誤りAthenaで毎回全S3ファイルを検索する
バッチ分析向けで、単一顧客の低レイテンシ取得には向かない。
バッチ分析向けで、単一顧客の低レイテンシ取得には向かない。
実際に確かめる
一時的な検証環境で実行できる例です。
DynamoDB single-table design、Query、partition key・sort keyの公式説明を確認する。期待される結果
RDSの柔軟なJOINとDynamoDBのアクセスパターン設計を比較できる。理解のポイント
- DynamoDB
- 単一テーブル
- PK・SK
- アクセスパターン
確認時の注意
- 確認環境: AWS公式DEA-C01試験ガイドと各サービスの公式ドキュメントの確認
- AWS公式DEA-C01 Domain 2・Task 2.1と各サービスの公式ドキュメントを確認する。
基礎のおさらい
クエリ形状
必要な取得条件・並び順・ページングをキー設計へ反映する。
非正規化
読み取りを速くする代わりに重複・更新整合性・アイテムサイズを管理する。
問題IDAWS-DEA-113
確認環境AWS公式DEA-C01試験ガイドと各サービスの公式ドキュメントの確認
最終技術確認2026-08-20
誤り・権利侵害を報告