DynamoDB のセカンダリインデックスの一般的なガイドライン - Amazon DynamoDB

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

DynamoDB のセカンダリインデックスの一般的なガイドライン

Amazon DynamoDB では、次の 2 種類のセカンダリインデックスをサポートしています。

  • グローバルセカンダリインデックス (GSI) — パーティションキーおよびソートキーを持つインデックス。ベーステーブルのものとは異なる場合があります。このインデックスに関するクエリがすべてのパーティションにまたがり、ベーステーブル内のすべてのデータを対象とする可能性があるため、グローバルセカンダリインデックスは「グローバル」と見なされます。グローバルセカンダリインデックスにはサイズの制限はなく、読み込みアクティビティと書き込みアクティビティ用にプロビジョニングされた独自のスループット設定がテーブルのものとは異なります。

  • ローカルセカンダリインデックス (LSI) - パーティションキーはベーステーブルと同じですが、ソートキーが異なるインデックスです。ローカルセカンダリインデックスは、ローカルセカンダリインデックスのすべてのパーティションの範囲が同じパーティションキーバリューを持つベーステーブルのパーティションに限定されるという意味で「ローカル」です。その結果、任意の 1 つのパーティションキーバリューに対してインデックスが作成された項目の合計サイズが、10 GB を超えることはありません。また、ローカルセカンダリインデックスでは、読み込みアクティビティおよび書き込みアクティビティのプロビジョニングされたスループット設定が、インデックス作成中のテーブルと共有されます。

DynamoDB の各テーブルには、最大で 20 のグローバルセカンダリインデックス (デフォルトのクォータ) と 5 つのローカルセカンダリインデックスを持つことができます。

多くの場合、グローバルセカンダリインデックスはローカルセカンダリインデックスよりも便利です。どのタイプのインデックスを使用するかの決定は、アプリケーションの要件によっても異なります。グローバルセカンダリインデックスとローカルセカンダリインデックスの比較、およびそれらの選択方法の詳細については、「」を参照してくださいセカンダリインデックスを使用したデータアクセス性の向上

DynamoDB でインデックスを作成する際に留意すべき一般的な原則と設計パターンは次のとおりです。

インデックスを効率的に使用する

インデックス数は最小限に抑えます。頻繁にクエリを行わない属性では、セカンダリインデックスを作成しないようにします。ほとんど使用されていないインデックスは、ストレージおよび I/O のコスト増大の一因になり、アプリケーションのパフォーマンスには効果がありません。

計画を慎重に選択する

セカンダリインデックスはストレージとプロビジョニング済みのスループットを消費するため、インデックスのサイズは可能な限り小さくすべきです。また、インデックスが小さいほど、テーブル全体に対してクエリを行うのに比べてパフォーマンスが向上します。使用するクエリが属性の一部しか返さないことが多く、それらの属性のサイズを合計しても項目全体より大幅に小さい場合には、頻繁にリクエストを行う属性だけを対象とするようにします。

読み込みに比べて、テーブルでの書き込みアクティビティが多くなることが予想される場合には、次のベストプラクティスに従います。

  • インデックスに書き込まれる項目のサイズが最小になるように、計画される属性が少なくなるようにします。ただし、計画される属性のサイズが単一の書き込み容量ユニット (1 KB) より大きい場合にのみ適用されます。例えば、インデックスエントリのサイズが 200 バイトである場合、DynamoDB ではこれが 1 KB に切り上げられます。言い換えれば、インデックス項目のサイズが小さい間は、追加コストが発生することなく、より多くの属性を計画することができます。

  • クエリではほとんど必要にならないことが分かっている属性は計画しないでください。インデックスで計画されている属性を更新する度に、インデックス更新による追加コストが発生します。プロビジョニングされたスループットの高いコストでは、Query では計画されない属性を引き続き検索できますが、クエリのコストは頻繁にインデックスを更新するコストよりも大幅に低くなる可能性があります。

  • ALL は、異なるソートキーによってソートされるテーブル項目全体を返るようにする場合にのみ指定します。すべての属性を計画することでテーブルをフェッチする必要がなくなりますが、ほとんどの場合、ストレージおよび書き込みアクティビティに要するコストが倍加します。

次のセクションで説明するように、フェッチを最小限に抑える必要性に応じて、インデックスをできるだけ小さくします。

フェッチを回避するための頻繁なクエリの最適化

レイテンシーを可能な限り小さくしてクエリを最速にするには、クエリによって返ることが予想されるすべての属性を計画します。特に、計画されていない属性のローカルセカンダリインデックスにクエリを実行すると、DynamoDB は自動的にテーブルからこれらの属性を取得します。そのため、項目全体をテーブルから読み取る必要があります。これにより、レイテンシーと不要な I/O オペレーションを減らすことができます。

「不定期な」クエリは、「必須」のクエリに変化することがあります。不定期にのみ、クエリを実行することが予想されるために計画しない属性がある場合は、状況が変わる可能性があるかどうかを検討します。

テーブルのフェッチの詳細については、「ローカルセカンダリインデックスに対するプロビジョニングされたスループットに関する考慮事項」を参照してください。

ローカルセカンダリインデックス作成時に項目コレクションのサイズ制限に注意する

項目コレクションとは、テーブルとそのローカルセカンダリインデックス内で、同じパーティションキーを持つすべての項目を意味します。10 GB を超えることができる項目コレクションはないため、パーティションキーバリューによっては容量が不足する可能性があります。

テーブル項目を追加または更新すると、DynamoDB は影響を受けるローカルセカンダリインデックスをすべて更新します。インデックスが付けられた属性がテーブル内で定義されている場合は、ローカルセカンダリインデックスも増加します。

ローカルセカンダリインデックスを作成する場合は、インデックスに書き込まれるデータの量と、および同じパーティションキーバリューを含むデータ項目数を考慮します。特定のパーティションキーバリューに対するテーブルおよびインデックス項目の合計が 10 GB を超えると予想される場合は、そのインデックスの作成を回避できないかどうかを検討してください。

ローカルセカンダリインデックスの作成を回避できない場合は、項目コレクションのサイズ制限を超える前に対処する必要があります。ベストプラクティスとして、項目を記述するときに ReturnItemCollectionMetricsパラメータを使用して、10GB のサイズ制限に近づいている項目コレクションのサイズをモニタリングおよび警告する必要があります。項目コレクションの最大サイズを超えると、書き込みの試行が失敗します。項目コレクションのサイズ問題は、アプリケーションに影響を与える前に項目コレクションのサイズをモニタリングして警告することで軽減できます。

注記

一度作成したローカルセカンダリインデックスは削除できません。

制限の範囲内での作業と是正措置のための方法については、「項目コレクションのサイズ制限」を参照してください。