グローバルセカンダリインデックスの管理 - Amazon DynamoDB

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

グローバルセカンダリインデックスの管理

このセクションでは、Amazon DynamoDB でグローバルセカンダリインデックスを作成、変更、削除する方法について説明します。

グローバルセカンダリインデックスを持つテーブルの作成

1 つ以上のグローバルセカンダリインデックスを持つテーブルを作成するには、CreateTable パラメータを指定して GlobalSecondaryIndexes オペレーションを使用します。最大限のクエリの柔軟性を得るために、テーブルごとに最大 20 個のグローバルセカンダリインデックス (デフォルトのクォータ) を作成できます。

インデックスパーティションキーとして機能する 1 つの属性を指定する必要があります。必要に応じて、インデックスソートキーに別の属性を指定できます。これらのキー属性のいずれかがテーブルのキー属性と同じである必要はありません。たとえば、GameScores テーブル (「DynamoDB のグローバルセカンダリインデックスの使用」を参照) で、TopScoreTopScoreDateTime のいずれもキー属性ではありません。は、パーティションキー グローバルセカンダリインデックス とソートキー TopScore を使用して作成できます。TopScoreDateTime このようなインデックスを使用して、ハイスコアとゲームが再生される時刻との間に相関があるかどうかを判断できます。

各インデックスキー属性は、型が StringNumber、または Binary のスカラー型である必要があります。 (ドキュメントまたはセットにすることはできません)。 には、任意のデータ型の属性を射影できます。グローバルセカンダリインデックスこれには、スカラー、ドキュメント、およびセットが含まれます。データ型の詳細なリストについては、「データ型」を参照してください。

プロビジョニングモードを使用している場合は、ProvisionedThroughput および ReadCapacityUnits で構成されるインデックスの WriteCapacityUnits 設定を指定する必要があります。 これらのプロビジョニングされたスループット設定は、テーブルの設定とは異なりますが、動作方法は似ています。詳細については、「グローバルセカンダリインデックスに対するプロビジョニング済みスループットに関する考慮事項」を参照してください。

グローバルセカンダリーインデックスは、基本テーブルから読み取り/書き込みキャパシティーモードを継承します。詳細については、「読み取り/書き込みキャパシティーモードの変更時の考慮事項」を参照してください。

テーブルのグローバルセカンダリインデックスについて説明する

テーブルのすべてのグローバルセカンダリインデックスのステータスを表示するには、DescribeTable オペレーションを使用します。レスポンスの GlobalSecondaryIndexes 部分には、テーブルのすべてのインデックスと、各インデックスの現在のステータス (IndexStatus) が表示されます。

IndexStatus は、次のいずれかになります。グローバルセカンダリインデックス

  • CREATING — インデックスは現在作成中であり、まだ使用することはできません。

  • ACTIVE — インデックスは使用可能で、アプリケーションはインデックスに対して Query オペレーションを実行できます。

  • UPDATING — インデックスのプロビジョニングされたスループット設定を変更中です。

  • DELETING — インデックスは現在削除中であり、使用できなくなりました。

が DynamoDB の構築を完了すると、インデックスのステータスが グローバルセカンダリインデックス から CREATING に変わります。ACTIVE

既存のテーブルに グローバルセカンダリインデックス を追加する

既存のテーブルに グローバルセカンダリインデックス を追加するには、UpdateTable パラメータを指定して GlobalSecondaryIndexUpdates オペレーションを使用します。以下を指定する必要があります。

  • インデックス名。名前は、テーブルのすべてのインデックスで一意である必要があります。

  • インデックスのキースキーマ。インデックスパーティションキーの属性を 1 つ指定する必要があります。オプションで、インデックスソートキーの別の属性を指定できます。これらのキー属性のいずれかがテーブルのキー属性と同じである必要はありません。各スキーマ属性のデータ型はスカラー型である必要があります。StringNumber、または Binary

  • テーブルからインデックスに射影される属性:

    • KEYS_ONLY インデックスの各項目は、テーブルのパーティションキーとソートキーの値、およびインデックスキーの値で構成されます。—

    • INCLUDE「—」で説明されている属性に加えて、セカンダリインデックスには指定する他の非キー属性が含まれます。KEYS_ONLY

    • ALL このインデックスには、ソーステーブルからのすべての属性が含まれます。—

  • インデックスのプロビジョニングされたスループット設定。ReadCapacityUnitsWriteCapacityUnits で構成されます。 これらのプロビジョニングされたスループット設定は、テーブルの設定とは異なります。

オペレーションごとに 1 つの グローバルセカンダリインデックス のみ作成できますUpdateTable

インデックス作成のフェーズ

既存のテーブルに新しい グローバルセカンダリインデックス を追加すると、インデックスの作成中もテーブルを引き続き利用できます。ただし、新しいインデックスは、そのステータスが 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

注記

に関連する CloudWatch メトリクスの詳細については、「DynamoDB」を参照してください。DynamoDB メトリクス

インデックスのプロビジョニングされた書き込みスループット設定が低すぎる場合、インデックスの作成が完了するまでに時間がかかります。新しい グローバルセカンダリインデックス の構築にかかる時間を短縮するために、プロビジョニングされた書き込みキャパシティーを一時的に増やすことができます。

注記

一般的なルールとして、インデックスのプロビジョニングされた書き込みキャパシティーは、テーブルの書き込みキャパシティーの 1.5 倍に設定することをお勧めします。これは、多くのユースケースに適しています。ただし、実際の要件はそれよりも高くなっている場合があります。

インデックスがバックフィルされている間、DynamoDB は内部システム容量を使用してテーブルから読み取ります。これは、インデックス作成の影響を最小限に抑えることと、テーブルの読み込みキャパシティーが不足しないようにすることです。

ただし、受信書き込みアクティビティのボリュームが、インデックスのプロビジョニングされた書き込みキャパシティーを超える可能性があります。これはボトルネックとなるシナリオです。インデックスの作成にはインデックスへの書き込みアクティビティがスロットリングされるため、このシナリオではインデックスの作成に時間がかかります。インデックスの構築中、インデックスの Amazon CloudWatch メトリクスをモニタリングして、消費された書き込みキャパシティーがプロビジョニングされたキャパシティーを超えているかどうかを判断することをお勧めします。ボトルネックのシナリオでは、バックフィルフェーズで書き込みスロットリングを回避するために、インデックスでプロビジョニングされた書き込み容量を増やす必要があります。

インデックスが作成されたら、アプリケーションの通常の使用状況を反映するように、そのプロビジョニングされた書き込みキャパシティーを設定する必要があります。

グローバルセカンダリインデックス の削除

が不要になった場合は、グローバルセカンダリインデックス オペレーションを使用して削除できます。UpdateTable

オペレーションごとに削除できる グローバルセカンダリインデックス は 1 つだけです。UpdateTable

の削除中、親テーブルの読み取りまたは書き込みアクティビティには影響しません。グローバルセカンダリインデックス削除が進行中の間も、他のインデックスのプロビジョニングされたスループットを変更できます。

注記

アクションを使用してテーブルを削除すると、そのテーブルのすべてのグローバルセカンダリインデックスも削除されます。DeleteTable

作成中の グローバルセカンダリインデックス の変更

インデックスの構築中に、DescribeTable オペレーションを使用してそのフェーズを決定できます。インデックスの説明にはブール属性 Backfilling が含まれており、DynamoDB が現在テーブルから項目を持つインデックスをロードしているかどうかを示しています。が true の場合、リソース割り当てフェーズが完了し、インデックスがバックフィルされます。Backfilling

バックフィルの進行中に、インデックスのプロビジョニングされたスループットパラメータを更新できます。インデックスビルドを高速化するために、これを行う場合があります。インデックスの構築中にインデックスの書き込みキャパシティーを増やし、後で減らすことができます。インデックスのプロビジョニングされたスループット設定を変更するには、UpdateTable オペレーションを使用します。インデックスのステータスは UPDATING に変わり、インデックスが使用できるようになるまで Backfilling は true になります。

バックフィリングフェーズ中に、作成中のインデックスを削除できます。このフェーズでは、テーブルの他のインデックスを追加または削除することはできません。

注記

オペレーションの一部として作成されたインデックスの場合、CreateTable 属性は Backfilling 出力に表示されません。DescribeTable詳細については、「インデックス作成のフェーズ」を参照してください。