DynamoDBのローカルインデックスとグローバルインデックスの違い

これら2つのセカンダリインデックスとそれらの違いに興味があります。これがどのように見えるか想像するのは難しいです。そして、これは私よりも多くの人々を助けると思います。

ローカルセカンダリインデックスはまだ元のハッシュキーに依存しています。テーブルにハッシュ+範囲を指定する場合は、LSIをハッシュ+範囲1、ハッシュ+範囲2 ...ハッシュ+範囲6と考えてください。クエリする範囲属性がさらに5つあります。また、プロビジョニングされたスループットは1つだけです。

グローバルセカンダリインデックスは新しいパラダイムを定義します-インデックスごとに異なるハッシュ/範囲キー。
これにより、テーブルごとに1つのハッシュキーの元の使用法が破られます。これは、GSIを定義するときに、インデックスごとにプロビジョニングされたスループットを追加して支払う必要がある理由でもあります。

違いの詳細については、GSIの発表をご覧ください。

ドキュメントからの正式な定義は次のとおりです。

グローバルセカンダリインデックス —ハッシュと範囲キーを持つインデックスで、テーブル上のインデックスとは異なる場合があります。インデックスに対するクエリは、テーブル内のすべてのデータをすべてのパーティションにまたがることができるため、グローバルセカンダリインデックスは「グローバル」と見なされます。

ローカルセカンダリインデックス —テーブルと同じハッシュキーを持つが、範囲キーが異なるインデックス。ローカルセカンダリインデックスは、ローカルセカンダリインデックスのすべてのパーティションのスコープが、同じハッシュキーを持つテーブルパーティションに限定されるという意味で「ローカル」です。

ただし、その違いは、主要な定義という点での可能性をはるかに超えています。インデックスを維持するためのコストと労力に直接影響するいくつかの重要な要素を以下に示します。

• スループット：

ローカルセカンダリインデックスは、テーブルのスループットを消費します。ローカルインデックスを介してレコードをクエリすると、操作はテーブルからの読み取りキャパシティーユニットを消費します。ローカルインデックスを持つテーブルで書き込み操作（作成、更新、削除）を実行すると、2つの書き込み操作があり、1つはテーブルに対するもので、もう1つはインデックスに対するものです。どちらの操作でも、テーブルの書き込み容量ユニットが消費されます。

グローバルセカンダリインデックスには独自のプロビジョニングされたスループットがあります。インデックスにクエリを実行すると、操作はインデックスからの読み取り容量を消費します。グローバルインデックスを持つテーブルで書き込み操作（作成、更新、削除）を実行すると、2つになります。 1つはテーブルに対するもの、もう1つはインデックス*に対するものです。

*グローバルセカンダリインデックスのプロビジョニングされたスループットを定義するときは、次の要件に特に注意してください。

テーブルの書き込みを成功させるには、テーブルとそのすべてのグローバルセカンダリインデックスのプロビジョニングされたスループット設定に、書き込みに対応するのに十分な書き込み容量が必要です。それ以外の場合、テーブルへの書き込みは抑制されます。

• 管理：

ローカルセカンダリインデックスは、テーブルを作成するときにのみ作成できます。ローカルセカンダリインデックスを既存のテーブルに追加する方法はありません。また、一度作成したインデックスは削除できません。

テーブルを作成して既存のテーブルに追加すると、グローバルセカンダリインデックスを作成できます。既存のグローバルセカンダリインデックスを削除することもできます。

• 整合性を読む：

ローカルセカンダリインデックスは結果整合性または強力な整合性をサポートしますが、グローバルセカンダリインデックスは結果整合性のみをサポートします。

• 投影：

ローカルセカンダリインデックスを使用すると、インデックスに投影されない属性を取得できます（ただし、追加のコスト：パフォーマンスと消費容量ユニット）。グローバルセカンダリインデックスでは、インデックスに投影された属性のみを取得できます。

セカンダリインデックスに定義されたキーの一意性に関する特別な考慮事項：

ローカルセカンダリインデックスでは、範囲キー値は特定のハッシュキー値に対して一意である必要はありません。同じことがグローバルセカンダリインデックスに適用され、キー値（ハッシュと範囲）は一意である必要はありません。

出典：http : //docs.aws.amazon.com/amazondynamodb/latest/developerguide/SecondaryIndexes.html

これらはインデックスによる可能な検索です：

• ハッシュによる
• ハッシュ+範囲
• ハッシュ+ローカルインデックス
• グローバルインデックス別
• グローバルインデックス+範囲インデックス

テーブルのハッシュインデックスと範囲インデックス： これらは、Amazon AWS SDKの以前のバージョンの通常のインデックスです。

グローバルインデックスとローカルインデックス： これらは、テーブルの既存のハッシュインデックスと範囲インデックスに加えて、テーブルに作成される「追加の」インデックスです。 グローバルインデックスはハッシュに似ています。範囲インデックスは、テーブルのハッシュで使用される範囲インデックスと同様に動作します。コード内のエンティティモデルでは、ゲッターに次のように注釈を付ける必要があります。

• グローバルインデックスの場合：

  @DynamoDBIndexHashKey(globalSecondaryIndexName = INDEX_GLOBAL_RANGE_US_TS)
  @DynamoDBAttribute(attributeName = PROPERTY_USER)
  public String getUser() {
      return user;
  }
  

• グローバルインデックスに関連付けられた範囲インデックスの場合：

  @DynamoDBIndexRangeKey(globalSecondaryIndexName = INDEX_GLOBAL_RANGE_US_TS)
  @DynamoDBAttribute(attributeName = PROPERTY_TIMESTAMP)
  public String getTimestamp() {
      return timestamp;
  }
  

さらに、グローバルインデックスでテーブルを読み取る場合は、（一貫した読み取りではなく）最終的な読み取りである必要があります。

queryExpression.setConsistentRead(false);

それを置く1つの方法はこれです：

LSI-複数の異なる属性を使用してクエリを「フィルタリング」または制限しながら、単一のハッシュキーでクエリを実行できます。

GSI-テーブル内の複数のハッシュキーでクエリを実行できますが、結果としてスループットが余分にかかります。

以下に、テーブルタイプの詳細とその機能を示します。

ハッシュのみ

おそらくすでにご存じのとおり、すでに存在するハッシュキーに書き込むと既存のデータが上書きされるため、ハッシュキー自体は一意である必要があります。

ハッシュ+範囲

ハッシュキー+範囲キーを使用すると、範囲キーが異なる限り、同じである複数のハッシュキーを持つことができます。この場合、すでに存在するハッシュキーに書き込み、そのハッシュキーでまだ使用されていない範囲キーを使用すると、新しいアイテムが作成されますが、同じハッシュと範囲の組み合わせを持つアイテムの場合すでに存在する場合は、一致するアイテムを上書きします。

これを考えるもう1つの方法は、ある形式のファイルのようなものです。フォーマット（範囲）が異なる限り、同じフォルダー（テーブル）に、同じ名前（ハッシュ）のファイルを同じフォルダー（テーブル）に置くことができます。同様に、名前が異なる限り、同じ形式のファイルを複数持つことができます。

LSI

LSIは基本的にHash-Key + Range-Keyと同じであり、LSIの値も提供する必要があることを除いて、アイテムの作成時には同じ規則に従います。空のままにすることはできません。

LSIは、「レンジ・キー2」であると言うためには、あなたが（それ以前から私のファイル形式とのアナロジーを使用して）という名前のファイルを持つことができないよう完全に正しいではありません。file.format.lsiとfile.format.lsi2。ただし、file.format.lsiand file.format2.lsiまたはfile.format.lsiandおよびを使用できfile2.format.lsiます。

基本的に、LSIは単なる「フィルターキー」であり、実際の範囲キーではありません。ベースのハッシュと範囲の値の組み合わせは一意である必要がありますが、LSIの値は一意である必要はありません。それを見るより簡単な方法は、LSIをファイル内のデータと考えることです。に関係なく、 "PROJECT101"という名前のすべてのファイルを検索し、fileFormat内部のデータを読み取って、クエリに含める必要があるものと省略されるものを判別するコードを記述できます。これは、基本的にLSIの動作方法です（ファイルを開いて内容を読み取るためのオーバーヘッドが発生することはありません）。

GSI

GSIの場合、基本的にはGSIごとに別のテーブルを作成しますが、それらの間でデータをミラーリングする複数の個別のテーブルを維持する手間はかかりません。このため、スループットが高くなります。

したがって、GSIの場合はfileName、ベースハッシュキーfileFormatとして、およびベースレンジキーとして指定できます。その後、のハッシュキーfileName2と範囲キーを持つGSIを指定できますfileFormat2。次に、LSIとのみクエリを実行できるLSIとは異なり、fileName必要にfileName2応じてクエリを実行できますfileName。

主な利点は、2つではなく1つのテーブルを維持するだけでよく、プライマリハッシュ/範囲またはGSIハッシュ/範囲のいずれかに書き込みを行うと、その他も自動的に更新されることです。そのため、マルチテーブル設定でできるように、他のテーブルを更新することを「忘れる」ことはありません。また、マルチテーブルセットアップのように、一方を更新した後、もう一方を更新する前に、接続が失われる可能性はありません。

さらに、GSIは基本のハッシュ/範囲の組み合わせを「オーバーラップ」できます。あなたがテーブルを作りたかったのであればfileNameとfileFormatお使いのベースハッシュ/範囲としてfilePriorityおよびfileNameあなたのGSIとして、することができます。

最後に、GSIのハッシュと範囲の組み合わせは一意である必要はありませんが、基本のハッシュと範囲の組み合わせは一意である必要があります。これは、デュアル/マルチテーブルセットアップでは不可能ですが、GSIでは可能です。その結果、更新するときは、ベースとGSI Hash + Rangeの両方に値を指定する必要があります。これらの値を空/ nullにすることはできません。

説明の別の方法：LSIは、同じハッシュキーを持つアイテムに対して追加のクエリを実行するのに役立ちます。GSIは、「テーブル全体」のアイテムに対して同様のクエリを実行するのに役立ちます。とても便利です。

ユーザープロファイルテーブルがある場合：一意のID、名前、電子メール。ここで、名前、電子メールでテーブルをクエリ可能にする必要がある場合-唯一の方法は、それらをGSIにすることです（LSIは役に立ちません）。

このドキュメントはかなり良い説明を与えます：

https://aws.amazon.com/blogs/aws/now-available-global-secondary-indexes-for-amazon-dynamodb/

この質問にはコメントできませんでしたが、書き込みと読み取りのパフォーマンスの点で優れています。

（テーブルの読み取りおよび書き込みスループットが100のローカルインデックス）または（テーブルの読み取り/書き込みスループットが50である読み取り/書き込みスループットが50のグローバルインデックス）

ユースケースに個別のパーティションキーは必要ないため、必要な機能にはローカルインデックスで十分です。

GSIは、一貫した読み取りには使用できません。

LSIは一貫した読み取りに使用できますが、メインパーティションのサイズは10GBに制限されます。また、LSIはテーブル作成時にのみ作成できます。