DynamoDBに関する基本的な内容をまとめてみたものです。DynamoDBに関する、Web上にすでにある良識な解説コンテンツをまとめたサイトの抜粋です。
セカンダリインデックス
DynamoDBがサポートする2種類のセカンダリインデックス
テーブル内のデータに効率的にアクセスするため、DynamoDB はPrimary Key属性用にインデックスを作成して維持します。このため、アプリケーションはPrimary Keyの値を指定することで、迅速にデータを取得する ことができます。
しかし多くのアプリケーションでは、Primary Key以外の属性を使って、データに効率的にアクセスできるようにするセカンダリ（または代 替）キーを 1 つ以上設定することで、メリットが得られることがあります。これに対応するために、1 つのテーブルで 1 つ以上のセカンダリインデックスを作成して、それらのインデックスに対してクエリリクエストを実行することができます。
DynamoDB では、次の 2 種類のセカンダリインデックスをサポートしています。
グローバルセカンダリインデックス
テーブルとはパーティションキーまたはパーティション/ソートキーが異なるインデックスです。グローバルセカンダリインデックスは、インデックスに関する クエリが、すべてのパーティションにまたがり、表内のすべての項目を対象とする可能性があるため、「グローバル」と見なされます。
ローカルセカンダリインデックス
テーブルとパーティションキーは同じですが、ソートキーが異なるインデックスです。ローカルセカンダリインデックスは、ローカルセカンダリインデックスの すべてのパーティションの範囲が、同じパーティションキーを持つテーブルパーティションに限定されるという意味で “ローカル” です。
セカンダリインデックスは、スパース型オブジェクトとして、DynamoDB が自動的に保持します。
項目は、インデックスの定義元のテーブル内に存在する場合のみ、表示されます。このため、インデックスに対するクエリは非常に効率的に実行されます。これは、インデックス内の項目数が、大抵の場合、テーブル内の項目数と比べて非常に少ないためです。
グローバルセカンダリインデックス
グローバルセカンダリインデックスは、Hash keyの代わりとなります。
グローバルセカンダリインデックスは、多数の異なる値が存在する属性間の関係を追跡する場合に特に便利です。例えば、テーブルのプライマリパーティションキーとして CustomerID を、グローバルセカンダリインデックスのパーティションキーとして 郵便番号を持つ DynamoDB テーブルを作成することができます。
郵便番号は多数存在し、お客様の数も多数存在します。Primary keyを使用して、任意のお客様に対するデータ項目をすばやく取得することができます。グローバルセカンダリインデックスを使用すると、特定の郵便番号の地域内に住んでいるすべてのお客様に対して、効率的なクエリを 実行することができます。
1テーブル当たり、最大で５つのグローバルセカンダリインデックスを作成することができます。
ローカルセカンダリインデックス
ローカルセカンダリインデックスは、Range key以外の絞り込み検索におけるキーとして利用するものです。
ローカルセカンダリインデックスを使用しない 場合は、多数の項目を取得し、結果をフィルタリングする必要がありますが、ローカルセカンダリインデックスを使用すると、一般的なクエリを簡単にコスト効率のよい方法で実行できます。つまり、アプリケーションには、より幅広い属性をベースにした、より柔軟なクエリを行うことができます。
グローバルとローカルのセカンダリインデックスはどちらも、クエリの柔軟性を向上させます。
ローカルセカンダリインデックスが特定のパーティションキーの値に関連付けられるのに対して、グローバルセカンダリインデックスはすべてのパーティションキーの値が対象となります。パーティションキーの値が同じ項目は、DynamoDB の同じパーティションを共有しているため、”ローカル” セカンダリインデックスは (同じパーティションに) 一緒に保存される項目のみを対象とします。つまり ローカルセカンダリインデックスの目的は、パーティションキーの値が同じで、ソートキーの値が異なる項目に対してクエリを実行することです。
1テーブル当たり、最大で５つのローカルセカンダリインデックスを作成することができます。
セカンダリインデックスを使用する際の注意点
・グローバルセカンダリインデックス、ローカルセカンダリインデックスは、便利な機能ですが、スループットやストレージ容量を追加で必要とする
・特にインデックスの数が増えれば増えるほど、書き込みのコストが上がる
・セカンダリインデックスに強く依存するようなテーブル設計になるようであれば、そもそもRDBで要件を満たしたほうがよいのではないか、検討してみるのが望ましい