メニュー
Amazon DynamoDB
開発者ガイド (API Version 2012-08-10)

ローカルセカンダリインデックス

ベーステーブルのプライマリキーを使用してデータのクエリを実行する必要があるのは、一部のアプリケーションだけですが、代替のソートキーが役に立つ場合があります。アプリケーションにソートキーという選択肢を提供するために、テーブルに 1 つ以上のlocal secondary indexを作成して、それらのインデックスに対して Query または Scan リクエストを実行できます。

たとえば、テーブルの作成とサンプルデータのロード で定義した Thread テーブルがあります。このテーブルは、AWS フォーラムのようなアプリケーションで役立ちます。次の図は、テーブル内の項目の構成を示しています。一部表示されていない属性もあります。

DynamoDB には、同じパーティションキー値を持つすべての項目が隣接して保存されます。この例では、特定の ForumName を指定すると、Query オペレーションはそのフォーラムのすべてのスレッドをすばやく見つけることができます。同じパーティションキー値を持つ項目のグループでは、項目がソートキーの値によって並べ替えられます。クエリにソートキー (Subject) も指定した場合、DynamoDB では、返された結果をすばやく絞り込むことができます。たとえば、"S3" フォーラムの中から、Subject の先頭が文字 "a" であるすべてのスレッドを返すことができます。

リクエストによっては、より複雑なデータアクセスパターンが要求される場合があります。(例:

  • ビューと返信の数が最も多いのはどのフォーラムか?

  • 特定のフォーラムでメッセージ数が最も多いのはどのスレッドか?

  • 特定の期間中に特定のフォーラムに投稿されたスレッド数は?

これらの質問に答えるには、Query アクションでは十分ではありません。代わりに、テーブル全体の Scan を実行する必要があります。膨大な数の項目があるテーブルでは、これにより、プロビジョニングされた読み込みスループットが大量に消費されることになり、完了するまでに長時間かかります。

ただし、RepliesLastPostDateTime などの非キー属性に 1 つ以上のlocal secondary indexを指定することができます。

local secondary index は特定のパーティションキー値の代替ソートキーを維持します。またlocal secondary indexでは、そのベーステーブルの一部またはすべての属性のコピーが保持されます。テーブルを作成する際に、local secondary indexに射影する属性を指定します。local secondary indexのデータは、ベーステーブルと同じパーティションキーと、異なるソートキーで構成されます。これにより、この異なるディメンションにわたってデータ項目に効率的にアクセスできます。クエリまたはスキャンの柔軟性を向上するために、テーブルごとに最大 5 つのlocal secondary indexを作成できます。

たとえば、あるアプリケーションで過去 3 か月以内に投稿されたすべてのスレッドを検索する必要があるとします。local secondary index がない場合は、アプリケーションでは Thread テーブル全体の Scan を実行して、指定された時間枠から外れた投稿を破棄する必要があります。local secondary indexがあれば、Query オペレーションでは LastPostDateTime をソートキーとして使用して、データをすばやく特定することができます。

次の図は、LastPostIndex という名前の local secondary index を示しています。パーティションキーは Thread テーブルのパーティションキーと同じですが、ソートキーは LastPostDateTime です。

local secondary index は、すべて次の条件を満たす必要があります。

  • パーティションキーはそのベーステーブルのパーティションキーと同じである。

  • ソートキーは完全に 1 つのスカラー属性で構成されている。

  • ベーステーブルのソートキーがインデックスに射影され、非キー属性として機能する。

この例では、パーティションキーは ForumName で、local secondary indexのソートキーは LastPostDateTime です。さらに、ベーステーブルのソートキーの値 (この例では Subject) がインデックスに射影されますが、その値はインデックスキーの一部ではありません。アプリケーションが ForumNameLastPostDateTime に基づくリストを必要とする場合は、LastPostIndex に対して Query リクエストを実行できます。クエリ結果は LastPostDateTime によって並べ替えられ、昇順または降順で返すことができます。このクエリは、特定の時間枠内に LastPostDateTime がある項目だけを返すなどのキー条件を適用することもできます。

すべてのlocal secondary indexには、そのベーステーブルからのパーティションキーとソートキーが自動的に格納されます。必要に応じて、非キー属性をインデックスに射影できます。インデックスのクエリを行うと、DynamoDB ではこれらの射影された属性を効率的に取り出すことができます。local secondary index のクエリを行うと、クエリでは、インデックスに射影されていない属性も取り出すことができます。DynamoDB では、これらの属性をベーステーブルから自動的にフェッチしますが、レイテンシーが大きくなり、プロビジョニングされたスループットコストが高くなります。

任意のlocal secondary indexについて、異なるパーティションキーの値ごとに最大 10 GB のデータを保存できます。この数字には、ベーステーブル内のすべての項目に加えて、同じパーティションキーの値を持つインデックス内のすべての項目も含まれています。詳細については、「項目コレクション」を参照してください。

属性の射影

LastPostIndex があるので、アプリケーションは、ForumName と LastPostDateTime をクエリ基準として使用できますが、追加の属性を取り出すには、DynamoDB は、Thread テーブルに対して追加の読み込みオペレーションを実行する必要があります。このような追加の読み込みをフェッチと言い、それによってクエリにプロビジョニングするスループットの合計量が増加することがあります。

ウェブページに "S3" 内のすべてのスレッドと各スレッドの返信のリストを表示し、最新の返信の最後の返信日時で並べ替えるとします。このリストに入力するには、次の属性が必要になります。

  • 件名

  • Replies

  • LastPostDateTime

このデータのクエリを最も効率的に行い、フェッチオペレーションを回避するには、次の図に示すように、local secondary indexにテーブルからの Replies 属性を射影します。

射影は、テーブルからセカンダリインデックスにコピーされる属性セットです。テーブルのパーティションキーとソートキーは必ずインデックスに射影されます。アプリケーションのクエリ要件をサポートするために、他の属性を射影することができます。インデックスのクエリを行うと、Amazon DynamoDB は射影内の属性に、それらの属性が独立したテーブル内にあるかのようにアクセスできます。

セカンダリインデックス を作成する場合は、インデックスに射影される属性を指定する必要があります。DynamoDB にはこのための 3 つのオプションが用意されています。

  • KEYS_ONLY – インデックスの各項目は、テーブルのパーティションキーとソートキー値、およびインデックスキー値のみで構成されます。KEYS_ONLY オプションを使用すると、セカンダリインデックス は最小になります。

  • INCLUDEKEYS_ONLY の属性に加えて、セカンダリインデックス にその他の非キー属性が含まれるように指定できます。

  • ALL – セカンダリインデックス にソーステーブルのすべての属性が含まれます。テーブルの全データがインデックスで複製されるため、ALL の射影により、セカンダリインデックス は最大になります。

前の図では、非キー属性の RepliesLastPostIndex に射影されています。アプリケーションでは Thread テーブル全体ではなく LastPostIndex に対するクエリを実行し、ウェブページに SubjectRepliesLastPostDateTime を表示することができます。他の非キー属性がリクエストされた場合には、DynamoDB はそれらの属性を Thread テーブルからフェッチする必要があります。

アプリケーションの観点から見ると、ベーステーブルから追加の属性をフェッチする処理は、自動的で透過的なので、アプリケーションロジックを書き直す必要はありません。ただし、このようなフェッチによって、local secondary index を使用することで得られるパフォーマンスの利点が大幅に小さくなる可能性があります。

local secondary index に射影する属性を選択する場合には、プロビジョニングされるスループットコストとストレージコストのトレードオフを考慮する必要があります。

  • ごく一部の属性だけに最小のレイテンシーでアクセスする必要がある場合は、それらの属性だけを local secondary index に射影することを検討してください。インデックスが小さいほど少ないコストで格納でき、書き込みコストも低くなります。まれにしかフェッチされない属性がある場合には、それらの属性を格納するコストよりも、プロビジョニングされるスループットのコストのほうが長期的に大きくなる可能性があります。

  • アプリケーションが非キー属性に頻繁にアクセスする場合には、それらの属性を local secondary index に射影すると効果的です。local secondary index の追加のストレージコストは、頻繁なテーブルスキャンを実行するコストを相殺します。

  • ほとんどの非キー属性に頻繁にアクセスする場合は、それらの属性、さらにはベーステーブル全体をlocal secondary indexに射影することができます。それによってフェッチが不要になるため、柔軟性が最大になり、プロビジョニングされるスループットが最小限になります。ただしストレージコストが増加し、すべての属性を射影する場合には 2 倍にまで増大します。

  • アプリケーションでテーブルのクエリを頻繁に行う必要がなく、テーブル内のデータに対する書き込みや更新が多数になる場合は、KEYS_ONLY を射影することを検討してください。local secondary index のサイズは最小になりますが、クエリに必要なサイズは確保されます。

ローカルセカンダリインデックス の作成

テーブルで 1 つ以上の local secondary index を作成するには、CreateTable オペレーションの LocalSecondaryIndexes パラメータを使用します。テーブルの ローカルセカンダリインデックス は、テーブルが作成された時点で作成されます。テーブルを削除すると、そのテーブルにある local secondary index も削除されます。

local secondary indexのソートキーにとなる 1 つの非キー属性を指定する必要があります。選択した属性は、スカラー文字列、数値、またはバイナリである必要があります。他のスカラー型、ドキュメント型、およびセット型は使用できません。データ型の詳細なリストについては、「データ型」を参照してください。

重要

local secondary indexがあるテーブルには、パーティションキーの値ごとに 10 GB のサイズ制限があります。local secondary indexがあるテーブルには、1 つのパーティションキー値の合計サイズが 10 GB を超えない限り、任意の数の項目を保存できます。詳細については、「項目コレクションのサイズ制限」を参照してください。

local secondary index には、任意のデータ型の属性を射影できます。これには、スカラー、ドキュメント、およびセットが含まれます。データ型の詳細なリストについては、「データ型」を参照してください。

ローカルセカンダリインデックス のクエリ

DynamoDB テーブルでは、各項目のパーティションキーとソートキーを結合した値が一意である必要があります。ただし、local secondary indexでは、ソートキーの値は、特定のパーティションキーの値に対して一意である必要がありません。local secondary indexにソートキーの値が同じである複数の項目がある場合、Query オペレーションは、同じパーティションキーの値を持つすべての項目を返します。レスポンスでは、一致する項目は特定の順序で返されません。

結果整合性のある読み込みまたは強力な整合性のある読み込みを使用して、local secondary index のクエリを行うことができます。必要な整合性のタイプを指定するには、Query オペレーションの ConsistentRead パラメータを使用します。local secondary index からの強力な整合性のある読み込みでは、常に最新の更新された値が返されます。クエリがベーステーブルからさらに属性をフェッチする必要がある場合、それらの属性はインデックスについて整合性があることになります。

特定のフォーラムのディスカッションスレッドにあるデータをリクエストする Query から返される次のデータを考えてみます。

Copy
{ "TableName": "Thread", "IndexName": "LastPostIndex", "ConsistentRead": false, "ProjectionExpression": "Subject, LastPostDateTime, Replies, Tags", "KeyConditionExpression": "ForumName = :v_forum and LastPostDateTime between :v_start and :v_end", "ExpressionAttributeValues": { ":v_start": {"S": "2015-08-31T00:00:00.000Z"}, ":v_end": {"S": "2015-11-31T00:00:00.000Z"}, ":v_forum": {"S": "EC2"} } }

このクエリでは次のようになっています。

  • DynamoDB が ForumName パーティションキーを使用して LastPostIndex にアクセスし、「EC2」のインデックス項目を特定します。このキーを持つすべてのインデックス項目が、すばやく取り出せるように隣り合わせに格納されます。

  • このフォーラム内で、DynamoDB はインデックスを使用して、指定された LastPostDateTime 条件に一致するキーを検索します。

  • Replies 属性はインデックスに射影されているため、DynamoDB は追加でプロビジョニングされたスループットを消費することなく、この属性を取り出すことができます。

  • Tags 属性はインデックスに射影されていないため、DynamoDB は Thread テーブルにアクセスしてこの属性をフェッチする必要があります。

  • 結果が、LastPostDateTime によって並べ替えられ、返されます。インデックスのエントリはまずパーティションキーの値によって、次にソートキーの値によって並べ替えられ、保存される順序で Query から返されます(ScanIndexForward パラメータを使用すると、結果が降順で返されます)。

local secondary indexには Tags 属性が射影されていないため、DynamoDB は、読み込みキャパシティーユニットをさらに消費して、ベーステーブルからこの属性をフェッチする必要があります。このクエリを頻繁に実行する必要がある場合は、Tags 属性を LastPostIndex に射影して、ベーステーブルからフェッチされないようにする必要があります。ただし、Tags 属性をまれにしか使用しない場合は、Tags 属性をインデックスに射影するためにストレージを追加することが有効でない可能性があります。

ローカルセカンダリインデックスの実行

Scan を使用して、local secondary index からすべてのデータを取得できます。 リクエストにはベーステーブル名とインデックス名を指定する必要があります。Scan では、DynamoDB はインデックスのすべてのデータを読み取り、それをアプリケーションに返します。また、データの一部のみを返し、残りのデータを破棄するようにリクエストすることもできます。これを行うには、Scan API の FilterExpression パラメータを使用します。詳細については、「Scan のフィルタ式」を参照してください。

項目の書き込みと ローカルセカンダリインデックス

DynamoDB によって、すべてのlocal secondary indexがそれぞれのベーステーブルと自動的に同期されます。アプリケーションがインデックスに直接書き込むことはありません。ただし、DynamoDB でこれらのインデックスがどのように維持されるかを理解することは重要です。

local secondary indexを作成する場合は、インデックスのソートキーになる属性を指定します。その属性のデータ型も指定します。つまり、ベーステーブルに項目を書き込むとき、その項目にインデックスキー属性が定義されている場合は、その型がインデックスキースキーマのデータ型に一致する必要があります。LastPostIndex の場合、インデックス内の LastPostDateTime ソートキーは、文字列データ型として定義されています。Thread テーブルに項目を追加するときに、LastPostDateTime に対して別のデータ型 (数値など) を指定すると、データ型の不一致により DynamoDB によって ValidationException が返されます。

テーブルに項目を書き込む場合には、local secondary indexソートキーに対して属性を指定する必要はありません。LastPostIndex を例にとると、Thread テーブルに新しい項目を書き込むために、LastPostDateTime 属性の値を指定する必要はありません。その場合、DynamoDB はこの特定の項目のインデックスにデータを書き込むことはありません。

ベーステーブル内の項目とlocal secondary index内の項目を 1 対 1 の関係にする必要はありません。この振る舞いは、多くのアプリケーションにとってメリットになります。詳細については、「スパースなインデックスの利用」を参照してください。

多数の local secondary index があるテーブルは、インデックス数が少ないテーブルに比べて書き込みアクティビティに多くのコストを要します。詳細については、「ローカルセカンダリインデックス におけるプロビジョニングされたスループットに関する考慮事項」を参照してください。

重要

local secondary indexがあるテーブルには、パーティションキーの値ごとに 10 GB のサイズ制限があります。local secondary indexがあるテーブルには、1 つのパーティションキー値の合計サイズが 10 GB を超えない限り、任意の数の項目を保存できます。詳細については、「項目コレクションのサイズ制限」を参照してください。

ローカルセカンダリインデックス におけるプロビジョニングされたスループットに関する考慮事項

DynamoDB でテーブルを作成する場合には、テーブルで予想されるワークロードに応じた読み込みおよび書き込みキャパシティーユニットをプロビジョニングします。このワークロードには、テーブルの local secondary index の読み込みおよび書き込みアクティビティが含まれます。

プロビジョンドスループット性能の現在の料金を確認するには、https://aws.amazon.com/dynamodb/pricing を参照してください。

読み込みキャパシティーユニット

local secondary index に対してクエリを実行する場合には、消費される読み込みキャパシティーユニットの数は、データのアクセス方法によって異なります。

テーブルに対するクエリと同様に、インデックスクエリでは ConsistentRead の値に応じて、結果整合性のある読み込みまたは強力な整合性のある読み込みを実行できます。1 回の強力な整合性のある読み込みでは、1 つの読み込みキャパシティーユニットが消費され、結果整合性のある読み込みではその半分が消費されます。したがって結果整合性のある読み込みを選択することで、読み込みキャパシティーユニットのコストを削減できます。

インデックスキーと射影された属性だけをリクエストするインデックスクエリの場合、DynamoDB はテーブルに対するクエリの場合と同じ計算方法で、プロビジョニングされた読み込みアクティビティを計算します。唯一の違いは、ベーステーブル内の項目のサイズではなくインデックスエントリのサイズに基づいて計算が行われることです。読み込みキャパシティーユニットの数は、返されたすべての項目について射影されたすべての属性のサイズの合計です。結果は、次の 4 KB 境界まで切り上げられます。DynamoDB がプロビジョニング済みスループットの利用率を計算する方法の詳細については、「読み取りと書き込みのスループット設定」を参照してください。

local secondary indexに射影されていない属性を読み取るインデックスクエリの場合、DynamoDB は射影された属性をインデックスから読み取るのに加えて、それらの属性をベーステーブルからフェッチする必要があります。これらのフェッチは、Query オペレーションの Select または ProjectionExpression パラメータに、射影されていない属性を含めた場合に実行されます。フェッチによってクエリ応答のレイテンシーが増加し、プロビジョニングされるスループットのコストも増加します。前述のlocal secondary indexからの読み込みに加えて、フェッチされるベーステーブル項目それぞれについて、読み込みキャパシティーユニットの料金がかかります。この料金は、リクエストした属性だけでなく、項目全体をテーブルから読み取るために発生するものです。

Query オペレーションによって返される結果の最大サイズは、1 MB です。これには、返されるすべての項目にわたる、すべての属性の名前と値のサイズが含まれます。ただし、local secondary indexに対するクエリによって、DynamoDB がテーブルから項目の属性をフェッチする場合には、結果で示されるデータの最大サイズが小さくなる可能性があります。この場合、結果のサイズは次の合計になります。

  • インデックス内で一致する項目のサイズ(次の 4 KB に切り上げ)

  • ベーステーブル内で一致する各項目のサイズ (項目ごとに次の 4 KB に切り上げ)

この式を使用すると、クエリオペレーションによって返される結果の最大サイズは依然として 1 MB になります。

たとえば、各項目のサイズが 300 バイトであるテーブルがあるとします。そのテーブルには local secondary index がありますが、各項目のうち 200 バイトだけがインデックスに射影されます。このインデックスに対して Query を行うときに各項目についてテーブルのフェッチが必要で、クエリによって 4 つの項目が返されるとします。DynamoDB では次のように合計されます。

  • インデックス内で一致する項目のサイズは 200 バイト × 4 項目 = 800 バイトになり、それが 4 KB に切り上げられます。

  • ベーステーブル内で一致する項目のサイズ: (300 バイト、4 KB に切り上げ) × 4 項目 = 16 KB。

それによって、結果データの合計サイズは 20 KB になります。

書き込みキャパシティーユニット

テーブル内の項目が追加、更新、または削除された場合に local secondary index を更新すると、テーブルにプロビジョニングされた書き込みキャパシティーユニットが消費されます。書き込み用にプロビジョニングされたスループットの合計コストは、テーブルに対する書き込みと、local secondary index の更新で消費された書き込みキャパシティーユニットの合計になります。

local secondary index に項目を書き込むコストは、いくつかの要因によって異なります。

  • インデックス付き属性が定義されたテーブルに新しい項目を書き込む場合、または既存の項目を更新して未定義のインデックス付き属性を定義する場合には、インデックスへの項目の挿入に 1 回の書き込みオペレーションが必要です。

  • テーブルに対する更新によってインデックス付きキー属性の値が(A から B に)変更された場合には、インデックスから既存の項目を削除し、インデックスに新しい項目を挿入するために、2 回の書き込みが必要です。 

  • インデックス内に既存の項目があって、テーブルに対する書き込みによってインデックス付き属性が削除された場合は、インデックスから古い項目の射影を削除するために、1 回の書き込みが必要です。

  • 項目の更新の前後にインデックス内に項目が存在しない場合は、インデックスで追加の書き込みコストは発生しません。

これらすべての要因は、インデックス内の各項目のサイズが 1 KB 以下であるという前提で書き込みキャパシティーユニット数を算出します。インデックスエントリがそれよりも大きい場合は、書き込みキャパシティーユニットを追加する必要があります。クエリが返す必要がある属性を特定し、それらの属性だけをインデックスに射影することで、書き込みコストは最小になります。

ローカルセカンダリインデックス のストレージに関する考慮事項

アプリケーションがテーブルに項目を書き込むと、DynamoDB では正しい属性のサブセットが、それらの属性を表示する必要がある local secondary index に自動的にコピーされます。AWS アカウントでは、テーブル内の項目のストレージと、そのベーステーブルのlocal secondary indexにある属性のストレージに対して課金されます。

インデックス項目が使用するスペースの量は、次の量の合計になります。

  • ベーステーブルのプライマリキー (パーティションキーとソートキー) のサイズのバイト数

  • インデックスキー属性のサイズのバイト数

  • 射影された属性(存在する場合)のサイズのバイト数

  • インデックス項目あたり 100 bytes のオーバーヘッド

local secondary indexのストレージ要件の見積もりは、インデックス内の 1 項目の平均サイズの見積もり値にベーステーブルの項目数を掛けて算出します。

特定の属性が定義された項目がテーブルに含まれておらず、その属性がインデックスソートキーとして定義されている場合、DynamoDB はその項目に関連するデータをインデックスに書き込みません。この動作の詳細については、「スパースなインデックスの利用」を参照してください。

項目コレクション

注記

次のセクションは、local secondary index があるテーブルだけに関係します。

DynamoDB では、項目コレクションとは、テーブルおよびテーブルのlocal secondary index全体で同じパーティションキーの値を持つ任意の項目グループです。このセクションで使用する例では、Thread テーブルのパーティションキーは ForumName で、LastPostIndex のパーティションキーも ForumName です。同じ ForumName を持つテーブルとインデックス項目は、すべて同じ項目コレクションの一部です。たとえば Thread テーブルと LastPostIndex local secondary index には、フォーラム EC2 用の項目コレクションと、フォーラム RDS 用の別の項目コレクションがあります。

次の図は、フォーラム S3 の項目コレクションを示しています。

この図では、項目コレクションは、ForumName パーティションキーの値が「S3」である Thread および LastPostIndex 内のすべての項目で構成されています。テーブルにその他のlocal secondary indexがあった場合には、ForumName が「S3」であるそれらのインデックス内の項目も、項目コレクションの一部になります。

DynamoDB では次のオペレーションのいずれかを使用して、項目コレクションに関する情報を得ることができます。

  • BatchWriteItem

  • DeleteItem

  • PutItem

  • UpdateItem

これらのオペレーションでは、それぞれ ReturnItemCollectionMetrics パラメータがサポートされています。このパラメータを SIZE に設定すると、インデックス内の各項目コレクションのサイズに関する情報が表示されます。

UpdateItemThread テーブルでの オペレーションの出力に含まれる スニペットを示します。ReturnItemCollectionMetricsSIZE に設定されています。更新された項目には ForumName 値「EC2」があったため、出力にはその項目コレクションに関する情報が含まれています。

Copy
{ ItemCollectionMetrics: { ItemCollectionKey: { ForumName: "EC2" }, SizeEstimateRangeGB: [0.0, 1.0] } }

SizeEstimateRangeGB オブジェクトは、項目コレクションのサイズが 0~1 GB の間であることを示します。DynamoDB ではこのサイズ見積りが定期的に更新されるため、項目を次に変更したときには数字が異なる場合があります。

項目コレクションのサイズ制限

1 つの項目コレクションのサイズは最大 10 GB までです。この制限は、local secondary index を含まないテーブルには適用されません。1 つ以上の local secondary index を含むテーブルのみに影響します。

項目コレクションが 10 GB を超えると、DynamoDB は ItemCollectionSizeLimitExceededException を返します。こうなると、その項目コレクションに項目を追加することも、項目サイズを大きくすることもできません。(項目コレクションのサイズを小さくする読み込みおよび書き込みオペレーションは、引き続き実行できます)。その他の項目コレクションには項目を追加することができます。

項目コレクションのサイズを小さくするには、次のいずれかを実行します。

  • 問題になっているパーティションキーの値を持つ不要な項目を削除します。ベーステーブルからこれらの項目を削除すると、DynamoDB では同じパーティションキーの値を持つインデックスエントリも削除されます。

  • 属性を削除するか属性のサイズを小さくすることで、項目を更新します。これらの属性が local secondary index に射影されている場合には、DynamoDB では対応するインデックスエントリのサイズも小さくなります。

  • 同じパーティションキーおよびソートキーを使用して新しいテーブルを作成し、古いテーブルから新しいテーブルに項目を移動します。これは、頻繁にアクセスされない履歴データがテーブルに含まれている場合に適した方法です。この履歴データを Amazon Simple Storage Service(Amazon S3)にアーカイブすることもできます。

項目コレクションの合計サイズが 10 GB 未満になると、再び同じパーティションキーの値を使用して項目を追加できるようになります。

項目コレクションのサイズを監視するようにアプリケーションを設定することをお勧めします。1 つの方法としては、BatchWriteItemDeleteItemPutItem、または UpdateItem を使用する場合に、ReturnItemCollectionMetrics パラメータを SIZE に設定するというものがあります。アプリケーションで出力内の ReturnItemCollectionMetrics オブジェクトを調査し、項目コレクションがユーザー定義の制限(たとえば 8 GB)を超えた場合にエラーメッセージを記録するようにします。制限を 10 GB より低く設定すれば早期警告システムになり、項目コレクションが上限に達する前に余裕をもって何らかの対処をとることができます。

項目コレクションおよびパーティション

各項目コレクションのテーブルおよびインデックスデータは、単一のパーティションに格納されます。Thread テーブルの例では、同じ ForumName 属性を持つすべてのベーステーブルとインデックス項目が、同じパーティション内に格納されます。「S3」項目コレクションが 1 つのパーティションに格納され、「EC2」が別のパーティションに格納され、「RDS」が 3 つ目のパーティションに格納されます。

アプリケーションを設計する場合は、テーブルデータが異なるパーティションキー値に均一に分配されるようにする必要があります。local secondary index を持つテーブルについては、単一のパーティション内の単一の項目コレクションに読み込みおよび書き込みアクティビティの「ホットスポット」が作られないように、アプリケーションを設計します。