グローバルセカンダリインデックスを使用して、テーブルの結果整合性レプリカを作成できます。レプリカを作成すると、次のことが可能になります。
-
リーダーごとに異なるプロビジョニングされた読み込み容量を設定する。例えば、優先順位の高いクエリを処理し、最高レベルの読み込みパフォーマンスを必要とするアプリケーションと読み込みアクティビティのスロットリングを許容できる優先順位の低いクエリを処理するアプリケーションの 2 つのアプリケーションがあるとします。
これらのアプリケーションが同じテーブルから読み込むと、優先順位の低いアプリケーションからの読み込み負荷が高くなると、テーブルで使用可能な読み込み容量がすべて消費される可能性があります。これにより、優先度の高いアプリケーションの読み込みアクティビティが抑制されます。
代わりに、テーブル自体の読み込み容量とは別に設定できるグローバルセカンダリインデックスを通じてレプリカを作成できます。その後、テーブルの代わりに、優先度の低いアプリでレプリカにクエリすることができます。
テーブルからの読み込みを完全に排除する。例えば、Web サイトから大量のクリックストリームアクティビティをキャプチャするアプリケーションがある場合、読み込みが妨げられる危険性はありません。このテーブルを分離し、グローバルセカンダリインデックスを使用して作成されたレプリカを他のアプリケーションに読み取らせながら、他のアプリケーションによる読み込みを防止することができます (「詳細に設定されたアクセスコントロールのための IAM ポリシー条件の使用」を参照)。
レプリカを作成するには、親テーブルと同じキースキーマを持つグローバルセカンダリインデックスを設定します。このインデックスには、キー以外の属性の一部またはすべてが入力されます。アプリケーションでは、一部またはすべての読み込みアクティビティを親テーブルではなく、このグローバルセカンダリインデックスに送信できます。その後、親テーブルのプロビジョニングされた読み込み容量を変更せずに、グローバルセカンダリインデックスのプロビジョニングされた読み込み容量を調整して、これらの読み込みを処理できます。
親テーブルへの書き込みから、書き込みデータがインデックスに表示されるまでの間には、常に短い伝播遅延があります。つまり、アプリケーションでは、グローバルセカンダリインデックスレプリカの結果整合性は親テーブルのものであるということを考慮に入れる必要があります。
複数のグローバルセカンダリインデックスレプリカを作成して、異なる読み込みパターンをサポートできます。レプリカを作成するときは、各読み込みパターンが実際に必要とする属性のみを計画します。これにより、アプリケーションは、親テーブルから項目を読み取る必要はなく、必要なデータだけを取得するために、プロビジョニングされた読み込み容量を少なくすることができます。この最適化により、長期的には大幅なコスト削減を実現できます。
