# DynamoDB のセカンダリインデックスの一般的なガイドライン
Amazon DynamoDB では、次の 2 種類のセカンダリインデックスをサポートしています。
+ **グローバルセカンダリインデックス (GSI) —** パーティションキーおよびソートキーを持つインデックス。ベーステーブルのものとは異なる場合があります。このインデックスに関するクエリがすべてのパーティションにまたがり、ベーステーブル内のすべてのデータを対象とする可能性があるため、グローバルセカンダリインデックスは「グローバル」と見なされます。グローバルセカンダリインデックスにはサイズの制限はなく、読み込みアクティビティと書き込みアクティビティ用にプロビジョニングされた独自のスループット設定がテーブルのものとは異なります。
+ **ローカルセカンダリインデックス (LSI) -** パーティションキーはベーステーブルと同じですが、ソートキーが異なるインデックスです。ローカルセカンダリインデックスは、ローカルセカンダリインデックスのすべてのパーティションの範囲が同じパーティションキーバリューを持つベーステーブルのパーティションに限定されるという意味で「ローカル」です。その結果、任意の 1 つのパーティションキーバリューに対してインデックスが作成された項目の合計サイズが、10 GB を超えることはありません。また、ローカルセカンダリインデックスでは、読み込みアクティビティおよび書き込みアクティビティのプロビジョニングされたスループット設定が、インデックス作成中のテーブルと共有されます。
DynamoDB の各テーブルには、最大で 20 のグローバルセカンダリインデックス (デフォルトのクォータ) と 5 つのローカルセカンダリインデックスを持つことができます。
多くの場合、グローバルセカンダリインデックスはローカルセカンダリインデックスよりも便利です。どのタイプのインデックスを使用するかの決定は、アプリケーションの要件によっても異なります。グローバルセカンダリインデックスとローカルセカンダリインデックスの比較および、どちらを選ぶかの詳細については、「[DynamoDB でのセカンダリインデックスを使用したデータアクセス性の向上](SecondaryIndexes.md)」を参照してください。
DynamoDB でインデックスを作成する際に留意すべき一般的な原則と設計パターンは次のとおりです。
**Topics**
+ [インデックスを効率的に使用する](#bp-indexes-general-efficiency)
+ [計画を慎重に選択する](#bp-indexes-general-projections)
+ [フェッチを回避するための頻繁なクエリの最適化](#bp-indexes-general-fetches)
+ [ローカルセカンダリインデックス作成時に項目コレクションのサイズ制限に注意する](#bp-indexes-general-expanding-collections)
## インデックスを効率的に使用する
**インデックス数は最小限に抑えます。**頻繁にクエリを行わない属性では、セカンダリインデックスを作成しないようにします。ほとんど使用されていないインデックスは、ストレージおよび I/O のコスト増大の一因になり、アプリケーションのパフォーマンスには効果がありません。
## 計画を慎重に選択する
セカンダリインデックスはストレージとプロビジョニング済みのスループットを消費するため、インデックスのサイズは可能な限り小さくすべきです。また、インデックスが小さいほど、テーブル全体に対してクエリを行うのに比べてパフォーマンスが向上します。使用するクエリが属性の一部しか返さないことが多く、それらの属性のサイズを合計しても項目全体より大幅に小さい場合には、頻繁にリクエストを行う属性だけを対象とするようにします。
読み込みに比べて、テーブルでの書き込みアクティビティが多くなることが予想される場合には、次のベストプラクティスに従います。
+ インデックスに書き込まれる項目のサイズが最小になるように、計画される属性が少なくなるようにします。ただし、計画される属性のサイズが単一の書き込み容量ユニット (1 KB) より大きい場合にのみ適用されます。例えば、インデックスエントリのサイズが 200 バイトである場合、DynamoDB ではこれが 1 KB に切り上げられます。言い換えれば、インデックス項目のサイズが小さい間は、追加コストが発生することなく、より多くの属性を計画することができます。
+ クエリではほとんど必要にならないことが分かっている属性は計画しないでください。インデックスで計画されている属性を更新する度に、インデックス更新による追加コストが発生します。プロビジョニングされたスループットの高いコストでは、`Query` では計画されない属性を引き続き検索できますが、クエリのコストは頻繁にインデックスを更新するコストよりも大幅に低くなる可能性があります。
+ `ALL` は、異なるソートキーによってソートされるテーブル項目全体を返るようにする場合にのみ指定します。すべての属性を計画することでテーブルをフェッチする必要がなくなりますが、ほとんどの場合、ストレージおよび書き込みアクティビティに要するコストが倍加します。
次のセクションで説明するように、フェッチを最小限に抑える必要性に応じて、インデックスをできるだけ小さくします。
## フェッチを回避するための頻繁なクエリの最適化
レイテンシーを可能な限り小さくしてクエリを最速にするには、クエリによって返ることが予想されるすべての属性を計画します。特に、計画されていない属性のローカルセカンダリインデックスにクエリを実行すると、DynamoDB は自動的にテーブルからこれらの属性を取得します。そのため、項目全体をテーブルから読み取る必要があります。これにより、レイテンシーと不要な I/O オペレーションを減らすことができます。
「不定期な」クエリは、「必須」のクエリに変化することがあります。不定期にのみ、クエリを実行することが予想されるために計画しない属性がある場合は、状況が変わる可能性があるかどうかを検討します。
テーブルのフェッチの詳細については、「[ローカルセカンダリインデックスに対するプロビジョニングされたスループットに関する考慮事項](LSI.md#LSI.ThroughputConsiderations)」を参照してください。
## ローカルセカンダリインデックス作成時に項目コレクションのサイズ制限に注意する
*項目コレクション*とは、テーブルとそのローカルセカンダリインデックス内で、同じパーティションキーを持つすべての項目を意味します。10 GB を超えることができる項目コレクションはないため、パーティションキーバリューによっては容量が不足する可能性があります。
テーブル項目を追加または更新すると、DynamoDB は影響を受けるローカルセカンダリインデックスをすべて更新します。インデックスが付けられた属性がテーブル内で定義されている場合は、ローカルセカンダリインデックスも増加します。
ローカルセカンダリインデックスを作成する場合は、インデックスに書き込まれるデータの量と、および同じパーティションキーバリューを含むデータ項目数を考慮します。特定のパーティションキーバリューに対するテーブルおよびインデックス項目の合計が 10 GB を超えると予想される場合は、そのインデックスの作成を回避できないかどうかを検討してください。
ローカルセカンダリインデックスの作成を回避できない場合は、項目コレクションのサイズ制限を超える前に対処する必要があります。ベストプラクティスとして、10 GB のサイズ制限に近づいたアイテムコレクションのサイズを監視して警告するアイテムを書き込む際は、[https://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/dynamodbv2/model/ReturnItemCollectionMetrics.html](https://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/dynamodbv2/model/ReturnItemCollectionMetrics.html) パラメータを使用します。アイテムコレクションの最大サイズを超えると、書き込みが失敗します。アプリケーションに影響が出る前にアイテムコレクションのサイズを監視してアラートを出すことで、アイテムコレクションのサイズに関する問題を軽減できます。
**注記**
ローカルセカンダリインデックスは、一度作成すると削除できません。
制限の範囲内での作業と是正措置のための方法については、「[項目コレクションのサイズ制限](LSI.md#LSI.ItemCollections.SizeLimit)」を参照してください。