グローバルセカンダリインデックスの管理
このセクションでは、グローバルセカンダリインデックスを作成、変更、および削除する方法について説明します。
トピック
テーブルとグローバルセカンダリインデックスの作成
1 つ以上の グローバルセカンダリインデックス があるテーブルを作成するには、GlobalSecondaryIndexes オペレーションを CreateTable パラメータと共に使用します。最大限のクエリの柔軟性を得るために、テーブルごとに最大 5 個の グローバルセカンダリインデックス を作成できます。
インデックスパーティションキーとなる 1 つの属性を指定する必要があります。必要に応じて、インデックスソートキーに別の属性を指定できます。これらのキー属性は、テーブルのキー属性と同じである必要はありません。たとえば、GameScores テーブル (「グローバルセカンダリインデックス」を参照) で、TopScore も TopScoreDateTime もキー属性ではありませんが、パーティションキーに TopScore を使用し、ソートキーに TopScoreDateTime を使用して、グローバルセカンダリインデックスを作成できます。このようなインデックスを使用して、高いスコアとゲームをプレイする時間帯の間に相関関係があるかどうかを判断できます。
各インデックスキー属性は、文字列型、数値型、またはバイナリ型である必要があります(ドキュメントまたはセットにすることはできません)。 任意のデータ型の属性をグローバルセカンダリインデックスに射影できます。これには、スカラー、ドキュメント、およびセットが含まれます。データ型の詳細なリストについては、「データ型」を参照してください。
プロビジョニングモードを使用している場合、ReadCapacityUnits および ProvisionedThroughput で構成される、インデックス用の WriteCapacityUnits 設定を指定する必要があります。このプロビジョニングされたスループット設定は、テーブルに対するその設定から独立していますが、同じように動作します。詳細については、「グローバルセカンダリインデックス におけるプロビジョニングされたスループットに関する考慮事項」を参照してください。
グローバルセキュリティインデックスは、基本テーブルから読み取り/書き込みキャパシティーモードを継承します。詳細については、「読み取り/書き込みキャパシティーモードの変更時の考慮事項」を参照してください。
テーブルでのグローバルセカンダリインデックスの説明
テーブルのすべての グローバルセカンダリインデックス のステータスを表示するには、DescribeTable オペレーションを使用します。応答の GlobalSecondaryIndexes 部分は、それぞれの現在のステータス（IndexStatus）と共に、テーブルのすべてのインデックスを示します。
グローバルセカンダリインデックス の IndexStatus は次のいずれかになります。
-
CREATING— インデックスは現在作成中で、まだ使用することはできません。 -
ACTIVE— インデックスは使用する準備が整っていて、アプリケーションはインデックスでQueryオペレーションを実行できます。 -
UPDATING— インデックスのプロビジョニングされたスループット設定を変更中です。 -
DELETING— インデックスは現在削除中で、使用できなくなりました。
DynamoDB が グローバルセカンダリインデックス の作成を終了すると、インデックスのステータスは CREATING から ACTIVE に変わります。
既存のテーブルへのグローバルセカンダリインデックスの追加
既存のテーブルに グローバルセカンダリインデックス を追加するには、UpdateTable オペレーションを GlobalSecondaryIndexUpdates パラメータと共に使用します。以下を指定する必要があります。
-
インデックス名。名前は、テーブルのすべてのインデックス間で一意である必要があります。
-
インデックスのキースキーマ。インデックスパーティションキー用の 1 つの属性を指定する必要があります。必要に応じて、インデックスソートキーに別の属性を指定できます。これらのキー属性は、テーブルのキー属性と同じである必要はありません。各スキーマ属性のデータ型はスカラー（文字列、数値、またはバイナリ）である必要があります。
-
テーブルからインデックスに射影する属性:
-
KEYS_ONLY– インデックスの各項目は、テーブルのパーティションキーとソートキー値、およびインデックスキー値のみで構成されます。 -
INCLUDE-KEYS_ONLYの属性に加えて、セカンダリインデックスにその他の非キー属性が含まれるように指定できます。 -
ALL- インデックスにソーステーブルのすべての属性が含まれます。
-
-
ReadCapacityUnitsおよびWriteCapacityUnitsで構成される、インデックスのプロビジョニングされたスループット設定。これらのプロビジョニングされたスループット設定は、テーブルの設定から独立しています。
UpdateTable オペレーションごとに、1 つの グローバルセカンダリインデックス のみを作成できます。
注記
処理中のグローバルセカンダリインデックスの作成をキャンセルすることはできません。
インデックス作成のフェーズ
既存のテーブルに新しいグローバルセカンダリインデックスを追加すると、テーブルはインデックスの作成中も引き続き使用可能になります。ただし、Query オペレーションの新しいインデックスは、そのステータスが
CREATING から ACTIVE に変わるまで使用できません。
バックグラウンドでは、DynamoDB が次の 2 つの段階でインデックスを作成します。
- リソースの割り当て
-
DynamoDB はインデックスの作成に必要なコンピューティングリソースおよびストレージリソースを割り当てます。
リソースの割り当てフェーズ中は、
IndexStatus属性はCREATINGになり、Backfilling属性は false になります。テーブルのステータスとそのすべての セカンダリインデックス を取得するには、DescribeTableオペレーションを使用します。インデックスがリソースの割り当てフェーズにあるときは、その親テーブルを削除したり、インデックスまたはテーブルのプロビジョニングされたスループットを変更したりすることはできません。テーブルの他のインデックスを追加または削除することはできませんが、これらの他のインデックスのプロビジョニングされたスループットを変更することができます。
- バックフィリング
-
テーブルの各項目については、DynamoDB は、射影 (
KEYS_ONLY、INCLUDE、またはALL) に基づいて、インデックスに書き込む一連の属性を決定します。次に、これらの属性をインデックスに書き込みます。DynamoDB はバックフィルフェーズ中に、テーブルで追加、削除、または更新中の項目を追跡します。また、これらの項目の属性は、必要に応じてインデックスで追加、削除、または更新されます。バックフィリングフェーズ中に、
IndexStatus属性はCREATINGになり、Backfilling属性は true になります。テーブルのステータスとそのすべての セカンダリインデックス を取得するには、DescribeTableオペレーションを使用します。インデックスのバックフィリング中に親テーブルを削除することはできません。ただし、テーブルと任意のグローバルセカンダリインデックスのプロビジョニングされたスループットを変更することはできます。
注記
バックフィリングフェーズ中に、違反のある項目の書き込みは、成功するものと、拒否されるものがあります。バックフィリング後に、新しいインデックスのキースキーマに違反する、項目へのすべての書き込みは拒否されます。バックフィリングフェーズが完了したら、Violation Detector ツールを実行して、発生した可能性のあるキーの違反を検出し、解決することをお勧めします。詳細については、「インデックスキー違反の検出と修正」を参照してください。
リソースの割り当てフェーズとバックフィリングフェーズの進行中は、インデックスは CREATING 状態になります。この間、DynamoDB はテーブルで読み取りオペレーションを実行します。この読み取りオペレーションには課金されません。
インデックスの作成が完了すると、そのステータスは ACTIVE に変わります。状態が Query になるまで、インデックスに対して Scan や ACTIVE を実行することはできません。
注記
場合によっては、DynamoDB は、インデックスキーの違反のため、テーブルからインデックスにデータを書き込めない場合があります。これは、属性値のデータ型がインデックスキースキーマのデータ型と一致しない場合や、属性のサイズがインデックスキー属性の最大長を超える場合に発生することがあります。インデックスキーの違反によって、グローバルセカンダリインデックス
の作成に影響はありません。ただし、インデックスが ACTIVE になると、違反のあるキーはインデックスに存在しません。
DynamoDB には、これらの問題を見つけて解決するためのスタンドアロンツールが用意されています。詳細については、「インデックスキー違反の検出と修正」を参照してください。
大きなテーブルへのグローバルセカンダリインデックスの追加
グローバルセカンダリインデックスの作成に必要な時間は、次のようないくつかの要因によって異なります。
-
テーブルのサイズ
-
インデックスへの組み込みの対象になるテーブルの項目数
-
インデックスに射影される属性の数
-
インデックスのプロビジョニングされた書き込みキャパシティー
-
インデックス作成中のメインテーブルでの書き込みアクティビティ
非常に大きなテーブルにグローバルセカンダリインデックスを追加する場合、作成プロセスが完了するまでに長い時間がかかることがあります。進捗状況を監視し、インデックスに十分な書き込みキャパシティーがあるかどうか判断するには、次の Amazon CloudWatch メトリクスを確認します。
-
OnlineIndexPercentageProgress -
OnlineIndexConsumedWriteCapacity -
OnlineIndexThrottleEvents
注記
DynamoDB に関連した CloudWatch メトリクスに関する詳細は、「DynamoDB メトリクス」を参照してください。
インデックスでプロビジョニングされた書き込みスループット設定が低すぎる場合、インデックスの作成にはより多くの時間がかかります。新しいグローバルセカンダリインデックスの作成に要する時間を短くするため、プロビジョニングされる書き込みキャパシティーを一時的に増やすことができます。
注記
一般的なルールとして、インデックスのプロビジョニングされる書き込みキャパシティーを、テーブルの書き込みキャパシティーの 1.5 倍に設定することをお勧めします。これは多くのユースケースに適した設定ですが、実際の要件はこれ以上またはこれ以下である可能性があります。
DynamoDB は、インデックスのバックフィリング中に内部的なシステムキャパシティーを使用してテーブルからの読み取りを行います。これは、インデックス作成の影響を最小化し、テーブルの読み取りキャパシティーが不足しないようにするためです。
ただし、受信書き込みアクティビティのボリュームが、インデックスのプロビジョニングされた書き込みキャパシティーを超える可能性があります。これは、インデックスへの書き込みアクティビティが調整されているため、インデックス作成により多くの時間がかかるボトルネックのシナリオです。インデックスの作成中に、インデックスの Amazon CloudWatch のメトリクスを監視して、消費された書き込みキャパシティーが、プロビジョニングされたキャパシティーを超えているかどうか判断することをお勧めします。ボトルネックのシナリオでは、インデックスでプロビジョニングされた書き込みキャパシティーを増やし、バックフィルフェーズ中の書き込み調整を避ける必要があります。
インデックスが作成されたら、アプリケーションの通常の使用を反映するように、プロビジョニングされた書き込みキャパシティーを設定します。
インデックス作成の変更
インデックスの作成中に、DescribeTable オペレーションを使用して、そのフェーズを判断できます。インデックスの説明には、現在、DynamoDB がテーブルから項目と共にインデックスを読み込んでいるかどうかを示すためのブール属性
Backfilling が含まれます。Backfilling が true の場合、リソースの割り当てフェーズは完了していて、インデックスはバックフィル中です。
バックフィルの進行中は、インデックス用にプロビジョニングされたスループットパラメータを更新できます。インデックス作成を高速化するために、これを行うことがあります。作成中にインデックスの書き込みキャパシティーを増やし、その後で減らすことができます。インデックスのプロビジョニングされたスループット設定を変更するには、UpdateTable オペレーションを使用します。インデックスのステータスは UPDATING に変わり、Backfilling はインデックスの使用準備ができるまで true になります。
バックフィリングフェーズ中は、テーブルの他のインデックスを追加または削除することはできません。
注記
CreateTable オペレーションの一部として作成されたインデックスについて、Backfilling 属性は DescribeTable 出力に表示されません。詳細については、「インデックス作成のフェーズ」を参照してください。
テーブルからのグローバルセカンダリインデックスの削除
グローバルセカンダリインデックス が不要になった場合は、UpdateTable オペレーションを使用して削除することができます。
UpdateTable オペレーションごとに、1 つの グローバルセカンダリインデックス のみを削除できます。
グローバルセカンダリインデックスの削除中に、親テーブルの読み取りアクティビティまたは書き込みアクティビティに影響はありません。削除が進行中でも、その他のインデックスでプロビジョニングされたスループットを変更できます。
注記
DeleteTable アクションを使用してテーブルを削除すると、そのテーブルのすべての グローバルセカンダリインデックス も削除されます。
