Orders DynamoDB テーブルは、パーティションキーとして OrderID (ソートキーなし) を使用し、100,000 を超える項目を含んでいます。OrderSource 属性が「MobileApp」と等しいすべての注文を効率的に取得する必要があります。ユーザーエクスペリエンスを向上させるための最も効率的な設計は何ですか？

正解は、OrderSource をパーティションキーとしてグローバルセカンダリインデックス (GSI) を作成し、MobileApp をキーとして GSI を Query することです。GSIは、元のテーブルとは異なるパーティションキーとソートキーを持つインデックスで、特定の属性に基づいて効率的にデータを検索するために使用されます。この場合、OrderSourceをGSIのパーティションキーにすることで、「MobileApp」に一致するすべての項目をQuery操作で直接、かつ効率的に取得できます。 Scan操作はテーブル全体をスキャンするため、項目数が多い場合に非効率的でコストも高くなります。ローカルセカンダリインデックス (LSI) は、ベーステーブルと同じパーティションキーを持つ必要があります。したがって、OrderSourceをLSIのパーティションキーにすることはできません。OrderSourceをソートキーとするGSIを作成した場合、OrderSourceの値で直接クエリすることはできないため、効率的ではありません。