DVAAWSのサービスを使用した開発
eコマースアプリケーションでDynamoDBを使った注文管理テーブルを設計しています。現在のテーブルはorderId（パーティションキーのみ）を使用しており、「特定ユーザーの全注文一覧を取得する」クエリが頻繁に発生します。現状はTable Scanを使用しているためパフォーマンスとコストの問題が生じています。最も効率的な解決策はどれですか？
AテーブルのプライマリキーをorderId（パーティションキー）＋userId（ソートキー）に変更し、userIdでクエリする
プライマリキーをorderIdとuserIdに変更する方法は、orderIdとuserIdの複合アクセスには有効ですが、userIdのみでのQueryには別途GSIが必要です。
BuserIdをパーティションキーとしたGSI（グローバルセカンダリインデックス）を作成し、そのGSIに対してQueryを実行する
✓ 正解
DynamoDBでプライマリキー以外の属性に対して効率的なクエリを行うにはGSI（グローバルセカンダリインデックス）を使用します。userIdをパーティションキーとしたGSIを作成することで、フルスキャンなしに特定ユーザーの注文を効率よく取得できます。
C既存のScan呼び出しにFilterExpressionを追加してuserIdでフィルタリングする
FilterExpressionは、Scan後にデータを絞り込むだけであり、スキャン時に消費されるRCU（読み取りキャパシティユニット）自体は削減されないため非効率です。
DElastiCache for Redisを追加し、スキャン結果をキャッシュして再利用する
ElastiCacheの追加は、スキャン結果をキャッシュして再利用するものですが、根本的な問題解決にはなりません。
解説
DynamoDBでプライマリキー以外の属性に対して効率的なクエリを行うにはGSI（グローバルセカンダリインデックス）を使用します。userIdをパーティションキーとしたGSIを作成することで、フルスキャンなしに特定ユーザーの注文を効率よく取得できます。
選択肢AのプライマリキーをorderIdとuserIdに変更する方法は、orderIdとuserIdの複合アクセスには有効ですが、userIdのみでのQueryには別途GSIが必要です。
選択肢CのFilterExpressionは、Scan後にデータを絞り込むだけであり、スキャン時に消費されるRCU（読み取りキャパシティユニット）自体は削減されないため非効率です。
選択肢DのElastiCacheの追加は、スキャン結果をキャッシュして再利用するものですが、根本的な問題解決にはなりません。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでDVAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →