Amazon DynamoDB
開発者ガイド (API バージョン 2012-08-10)

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

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

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

  • ローカルセカンダリインデックス — パーティションキーはベーステーブルと同じですが、ソートキーが異なるインデックスです。ローカルセカンダリインデックスは、ローカルセカンダリインデックスのすべてのパーティションの範囲が、同じパーティションキー値を持つベーステーブルのパーティションに限定されるという意味で「ローカル」です。その結果、任意の 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 を超えると予想される場合は、そのインデックスの作成を回避できないかどうかを検討してください。

ローカルセカンダリインデックスの作成を回避できない場合は、項目コレクションのサイズ制限を超える前に対処する必要があります。制限の範囲内での作業と是正措置のための戦略については、「項目コレクションのサイズ制限」を参照してください。