DynamoDBのインデックスの仕組みについて、いつも分からなくなるので情報を整理するために纏めておきます。
公式マニュアルやDevelopersI/Oを参考にしています(ありがとう、クラスメソッド!!)。
セカンダリインデックスを使用したデータアクセス性の向上 - Amazon DynamoDB
コンセプトから学ぶAmazon DynamoDB【LSI篇】 | DevelopersIO
コンセプトから学ぶAmazon DynamoDB【GSI篇】 | DevelopersIO
- Key
- いわゆるPrimary Key
- Partition(HASH) Keyのみのものと、Partition KeyとSort(Range) keyを組み合わせたものの2種類がある
- 作成すると、暗黙的にインデックスが作成されている
- Grobal Secondary Index
- Grobal Secondary Index
- ベーステーブルと異なるPartition KeyとSort Keyを持つインデックス
- インデックスのPrimary Keyは、Partion KeyまたはPartion & Sort Keyとなる
- サイズ制限なし
- テーブル作成後に、追加/削除可能
- 結果整合性のみサポート
- 読み込み/書き込み処理に独自のスループット設定を可能
- Capacity Unitはベーステーブルでなく、Grobal Secondary Indexのものを消費する
- インデックスに射影されたものだけフェッチする
- Local Secondaary Index
- ベーステーブルと同じPartion Keyと異なるSort Keyを持つインデックス
- インデックスのPrimary Keyは、Partion & Sort Keyとなる
- 10GB以下
- テーブル作成と同時に作成
- 結果整合性と強整合性をサポート
- 読み込み/書き込み処理はベーステーブルのスループットによる
- 当然、Capacity Unitはベーステーブルのものを消費する
- インデックスに射影されていない属性もフェッチする
以下もメモ
- DyanamoDBにおけるパーティショニング数の算出方法
- 1パーティションあたりの読み込み/書き込みキャパシティユニット数、および1パーティションあたりのデータサイズは決まっており、どちらかの考え方で必要パーティショニング数が大きいほうを採用する
- https://www.slideshare.net/AmazonWebServicesJapan/20170809-black-belt-dynamodb#38
- 結果整合性
- 読み込みスループットを最大化する
- 最新書き込み結果が反映されない可能性あり(DynamoDBにおけるデータ全コピーの整合性は1秒ほどかかる)
- 強整合性
- 最新書き込みが反映されている