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

テーブルのベストプラクティス

このセクションでは、模範的なテーブルの操作方法について説明します。

テーブル内のすべての項目に対して均一なデータアクセスを実現する設計

テーブルのプロビジョニングされたスループットを最適に使用するには、次の要因が影響します。

  • プライマリキーの選択

  • 個々の項目に対するワークロードパターン.

プライマリキーは、テーブルの各項目を一意に識別します。プライマリキーはシンプル (パーティションキー) または複合 (パーティションキーとソートキー) とすることができます。

データを保存するとき、DynamoDB はテーブルの項目を複数のパーティションに分割し、主にパーティションキー値に基づいて、データを分散します。そのため、テーブルにプロビジョニング済みの十分な量のリクエストスループットを得るには、ワークロードをパーティションキー値全体に均一に分散します。パーティションキー値全体にリクエストを分散すると、パーティション全体にリクエストが分散されます。

たとえば、1 つのテーブルに、頻繁にアクセスされるパーティションキー値がごく少数含まれる場合 (非常に頻繁に使用されるパーティションキー値が 1 つだけの場合もあります)、少数のパーティション (場合によっては 1 つのパーティションだけ) にリクエストトラフィックが集中します。1 つまたは一部のパーティションに偏ってしまうなど、ワークロードのバランスが極端に悪いと、リクエストでは、プロビジョニングされたスループットの全体的なレベルが達成されません。DynamoDB のスループットを最大限に活用するには、テーブルを作成するときに、パーティションキーに個別の値が多数含まれ、できるだけランダムかつ均一に値がリクエストされるようにします。

この操作によって、スループットレベルを達成するために、すべてのパーティションキー値にアクセスする必要があるというわけではありません。また、アクセスされるパーティションキー値の割合を高くする必要があるというわけでもありません。ただし、より明確に区別できるパーティションキー値にワークロードがアクセスするとき、それらのリクエストは、割り当てられたスループットレベルを十分に活用する方法で、分割されたスペース全体に展開されることに注意してください。一般的に、テーブルのパーティションキー値の合計数に対する、アクセスされたパーティションキー値の割合が大きくなるほど、スループットをより効率的に活用することができます。

パーティションキーの選択

一般的なパーティションキースキーマをいくつか比較し、プロビジョニングされたスループットの効率について次の表に示します。

パーティションキーの値 均一性

ユーザー ID(アプリケーションに多くのユーザーがある場合)

良い

ステータスコード(可能性のあるステータスコードが少しだけある場合) 不良
項目の作成日(直近の期間(日、時、分など)に切り上げられます) 不良
デバイス ID(各デバイスが比較的類似した間隔でデータにアクセスする場合) 良い
デバイス ID(追跡中のデバイスが大量にある場合でも、1 つのデバイスが他のすべてのデバイスよりもずっと人気がある場合) 不良

単一のテーブル内にあるパーティションキー値の数が非常に少ない場合は、より明確に区別できるパーティションキー値全体を対象として、書き込みオペレーションを分散するように検討してください。つまり、"ホット" パーティションキー値 (何度もリクエストされるパーティションキー値) を回避するように、プライマリキー要素を構築してください。このようなパーティションキー値が原因で、全体のパフォーマンス速度が低下する場合があります。

たとえば、複合プライマリキーを持つテーブルがあるとします。パーティションキーは項目の作成日を表します (直近の日付に切り上げられます)。ソートキーは項目の識別子を表します。特定の日付 (2014-07-09 など) で、すべての新しい項目が同じパーティションキー値として書き込まれます。

テーブル全体が単一のパーティションに収まり(時間の経過に伴うデータの増加を考慮します)、アプリケーションで必要となる読み込みスループットと書き込みスループットが単一のパーティションにおける読み込みと書き込みの容量を超過しない場合は、パーティション分割をしても、アプリケーションが予想外の制限を受けることはありません。

ただし、テーブル全体が単一のパーティションには収まらないことが予想される場合は、テーブルの完全にプロビジョニングされたスループットをより多く使用できるように、アプリケーションを設計する必要があります。

複数のパーティションキー値を対象としたランダム化

アプリケーションの書き込みスループットを向上させる方法の 1 つとして、複数のパーティションキー値を対象とした書き込みをランダム化する方法があります。固定された数値のセット(たとえば、1200)からランダムな数値を選択し、その数値をサフィックスとして日付に連結します。これにより、2014-07-09.12014-07-09.2 などのパーティションキー値が生成されます。この場合、最大のパーティションキー値は 2014-07-09.200 になります。パーティションキーをランダム化するため、毎日行われるテーブルへの書き込みは、すべてのパーティションキー値に均一に分散されます。これにより、並列処理が向上し、全体的なスループットが高まります。

特定の日付についてすべての項目を読み込むには、各サフィックスのすべての項目を取得する必要があります。たとえば、最初にパーティションキー値 2014-07-09.1 に対する Query リクエストを発行し、次に 2014-07-09.2 に対する Query を発行します。この処理を 2014-07-09.200 まで繰り返します。最終的には、アプリケーションですべての Query リクエストの結果をマージする必要があります。

算出された値の使用

ランダム化の方法によって、書き込みスループットを大幅に向上させることができます。ただし、特定の項目を読み込むことは難しくなります。これは、項目を書き込むときにどのサフィックスが使用されたかを把握できないためです。個々の項目を簡単に読み込むことができるようにするには、別の方法を使用します。ランダムな数値を使用して項目をパーティションに分散するのではなく、項目が持つ固有の情報に基づいて算出できる数値を使用します。

これまでの例を引き続き使用します。ここでは、各項目に OrderId があるとします。アプリケーションで項目をテーブルに書き込む前に、この OrderId に基づいてパーティションキーのサフィックスを計算します。この計算では、1~200 の範囲の数値が算出される必要があります。これらの各数値は、指定の名前のセット(またはユーザー ID のセット)を対象として、完全に均一に分散されます。

この計算はシンプルな計算で十分です (OrderId の各文字の UTF-8 コードポイント値を乗算して、それを 200 + 1 で割った余りなど)。 パーティションキー値は、日付に計算結果がサフィックスとして連結された値になります。この方法を使用すると、書き込みがパーティションキー値全体に均一に分散され、パーティション全体にも均一に分散されます。これで、GetItem オペレーションを実行して、特定の項目を簡単に読み込むことができます。これは、特定の OrderId 値を取得するときに、必要となるパーティションキー値を計算できるためです。

特定の日付についてすべての項目を読み込むには、2014-07-09.N キー(N は 1~200 の数値)に対する Query を発行し、アプリケーションですべての結果をマージする必要があります。ただし、すべてのワークロードを利用する単一の "ホット" パーティションキー値の使用は回避してください。

パーティションの動作について

DynamoDB によって自動的にテーブルパーティションが管理され、必要に応じて新しいパーティションが追加されます。また、パーティション間で均等にプロビジョンドスループット性能が分散されます。

テーブルに対して DynamoDB で最初に割り当てられるパーティションの数を予測することができます。また、その予測と、使用する規模およびアクセスパターンを比較することもできます。また、増えたストレージまたはプロビジョニングされたスループット要件に応じて、DynamoDB で割り当てられる追加のパーティションの数を見積もることもできます。これらの予測は、アプリケーションのニーズに最適なテーブル設計を決める場合に役立ちます。

注記

パーティションサイズとスループットに関する以下の詳細は、変更される場合があります。

パーティションの最初の割り当て

新しいテーブルを作成するときに、DynamoDB は指定のプロビジョニングされたスループット設定に従ってテーブルのパーティションを割り当てます。

1 つのパーティションは、最大 3,000 個の読み込みキャパシティーユニットまたは 1,000 個の書き込みキャパシティーユニットをサポートできます。新しいテーブルを作成するときに、パーティションの初期値は次のように表すことができます。

Copy
( readCapacityUnits / 3,000 ) + ( writeCapacityUnits / 1,000 ) = initialPartitions (rounded up)

たとえば、1,000 個の読み込みキャパシティーユニットと 500 個の書き込みキャパシティーユニットを使用してテーブルを作成したとします。この場合、パーティションの初期数は次のようになります。

Copy
( 1,000 / 3,000 ) + ( 500 / 1,000 ) = 0.8333 --> 1

このため、単一のパーティションで、テーブルのすべてのプロビジョニングされたスループット要件に対応できます。

ただし、1,000 個の読み込みユニットと 1,000 個の書き込みユニットがあるテーブルを作成した場合、1 つのパーティションは指定されたスループット容量をサポートすることができません。

Copy
( 1,000 / 3,000 ) + ( 1,000 / 1,000 ) = 1.333 --> 2

この場合、テーブルでは 2 つのパーティションが必要になり、各パーティションは 500 個の読み込みキャパシティーユニットと 500 個の書き込みキャパシティーユニットを保持します。

パーティションのその後の割り当て

1 つのパーティションに約 10 GB 個のデータを保持でき、最大 3,000 個の読み込みキャパシティーユニットまたは 1,000 個の書き込みキャパシティーユニット数をサポートできます。

DynamoDB は、必要に応じて既存のパーティションを分割することによって、テーブルに追加のパーティションを割り当てることができます。テーブルのパーティションの 1 つ (P) が、ストレージの制限 (10 GB) を超えたとします。この場合、DynamoDB は次のようにパーティションを分割します。

  1. 2 つの新しいパーティション (P1 および P2) を割り当てます。

  2. P からのデータを P1P2 の間で均等に分散します。

  3. テーブルから P を割り当て解除します。

次の図は、DynamoDB がパーティション分割を実行する方法を示しています。大きな四角形はパーティションを示し、小さい四角形はテーブルのデータ項目を表します。

パーティションの分割中に、DynamoDB は古いパーティションからのデータを 2 つの新しいパーティションに均等に分散します (他のパーティションのデータは影響を受けません)。古いパーティションのプロビジョンドスループット性能は二つの新しいパーティション間で、均等に分散されます (パーティションあたりのスループット容量 を参照)。

DynamoDB はバックグラウンドでパーティションの分割を自動的に実行することに注意してください。テーブルは、指定されたスループットレベルで、読み込みおよび書き込みアクティビティに対して完全に使用可能な状態のままになります。

パーティション分割は、以下に応じて発生します。

  • プロビジョニングされたスループット設定の引き上げ

  • ストレージ要件の引き上げ

プロビジョニングされたスループット設定の引き上げ

テーブルのプロビジョンドされたスループットを引き上げ、テーブルの現在のパーティショニングスキームが新しい要件に対応できない場合、DynamoDB はパーティションの現在の数を 2 倍にします。

たとえば、5,000 個の読み込みキャパシティーユニットと 2,000 個の書き込みキャパシティーユニットを使用して新しいテーブルを作成したとします。パーティションの最初の割り当て の情報を使用して、この新しいテーブルで 4 つのパーティションを必要とすることを決定できます。

Copy
( 5,000 / 3,000 ) + ( 2,000 / 1,000 ) = 3.6667 --> 4

4 つの各パーティションは、1 秒あたり 1,250 個の読み込み (5,000 読み込みキャパティシーユニット / 4 パーティション) および 1 秒あたり 500 個の書き込み (2,000 書き込みキャパティシーユニット / 4 パーティション) に対応できます。

ここで、テーブルの読み込みキャパシティーユニットを 5,000 から 8,000 に引き上げたとします。既存の 4 つのパーティションは、この要件をサポートできません。応答 (「パーティションのその後の割り当て」を参照) で、DynamoDB はパーティション数を 2 倍の 8 にします (4 * 2 = 8)。結果の各パーティションは、1 秒あたり 1,000 個の読み込み (8,000 読み込みキャパティシーユニット / 8 パーティション) および 1 秒あたり 250 個の書き込み (2,000 書き込みキャパティシーユニット / 8 パーティション) に対応できます。

次の図は、テーブルの元の 4 つのパーティションと、DynamoDB によってパーティション数が 2 倍になった後のパーティションスキームを示します。大きな四角形はパーティションを示し、小さい四角形はテーブルのデータ項目を表します。

ストレージ要件の引き上げ

既存のパーティションがデータでいっぱいになると、DynamoDB によってそのパーティションが分割されます。結果は 2 つのパーティションになり、古いパーティションからのデータは新しいパーティション間で均等に分割されます。

プロビジョニングされたスループット設定の引き上げ」で説明するテーブルには 8 個のパーティションがあるため、最大容量は、次に示すように約 80 GB になります。

Copy
8 partitions * 10 GB = 80 GB

これらのパーティションで容量がいっぱいになる場合、DynamoDB によってそのパーティションが分割されます。その結果、次に示すように合計 9 個のパーティションになり、容量全体は 90 GB になります。

Copy
9 partitions * 10 GB = 90 GB

次の図は、容量がいっぱいになった元のパーティションの 1 つと、DynamoDB によってそのパーティションが分割された後のパーティションスキームを示します。大きな四角形はパーティションを示し、小さい四角形はテーブルのデータ項目を表します。

パーティションあたりのスループット容量

テーブルのパーティション数を予測すると、パーティションごとの概算のスループット容量を判断することができます。5,000 個の読み込みキャパシティーユニットと 2,000 個の書き込みキャパシティーユニットを使用してテーブルを作成するとします。DynamoDB により、新しいテーブルに 4 個のパーティションが割り当てられます。

Copy
( 5,000 / 3,000 ) + ( 2,000 / 1,000 ) = 3.6667 --> 4

次のようにして、パーティションごとの読み込みキャパシティーと書き込みキャパシティーの量を判断できます。

Copy
5,000 read capacity units / 4 partitions = 1,250 read capacity units per partition 2,000 write capacity units / 4 partitions = 500 write capacity units per partition

ここで、これら 4 つのパーティションの 1 つの容量がいっぱいになるとします。DynamoDB はそのパーティションを分割し、それによりテーブルに 5 つのパーティションが割り当てられます。次に、パーティションごとの読み込みキャパシティーと書き込みキャパシティーは次のように分散されます。

Copy
1,250 read capacity units / 2 partitions = 625 read capacity units per child partition 500 write capacity units / 2 partitions = 250 write capacity units per child partition

上の結果 :

  • 5 つのパーティションのうち 3 つは、それぞれ読み込み容量 1,250 ユニットと書き込み容量 500 ユニットとなります。

  • 残りの 2 つのパーティションは、それぞれ読み込み容量 625 ユニットと書き込み容量 250 ユニットとなります。

テーブルのパーティションの数が増えると、各パーティションで利用できる読み込みキャパシティーと書き込みキャパシティーユニットの数が減ります。ただし、テーブルのプロビジョニングされたスループットの合計は同じままです。

急激に増大するキャパシティーは控えめに使用する

DynamoDB によって、パーティションごとのスループットを柔軟にプロビジョニングすることができます。 パーティションのスループットを十分に活用していない場合、後でスループットの利用率が急激に増加した場合に備えて、DynamoDB では未使用のキャパシティーの一部を保持します。現在 DynamoDB は、未使用の読み込みおよび書き込みキャパシティーについて、最大 5 分 (300 秒) を保持します。読み込みや書き込みのアクティビティの急激な増加が頻繁に発生しないときは、これらの追加のキャパシティーユニットはすぐに消費されます (テーブルに対して定義した 1 秒あたりのプロビジョンドスループット性能よりも速く消費されます)。ただし、急激に増大するキャパシティーが常に使用可能であることを前提としてアプリケーションを設計しないでください。DynamoDB は、急激に増大するキャパシティーをバックグラウンドでのメンテナンスや他のタスクで使用します。このとき、事前の通知はありません。

注記

今後、急激に増大するキャパシティーに関する上記の仕様は、変更される可能性があります。

データアップロード時に書き込みアクティビティを分散する

他のデータソースから DynamoDB にデータをロードする場合があります。一般に、DynamoDB はテーブルデータを複数のサーバーに分配します。データをテーブルにアップロードする場合は、配分されたサーバーすべてに同時にデータをアップロードすると、パフォーマンスが向上します。たとえば、ユーザーメッセージを DynamoDB テーブルにアップロードするとします。UserID がパーティションキーで、MessageID がソートキーである複合プライマリキーを使用するテーブルを設計するとします。ソースからのデータをアップロードするときは、特定のユーザーのすべてのメッセージ項目を読み込み、DynamoDB にアップロードしてしまいがちです。以下のテーブルのシーケンスを参照してください。

UserId MessageID

U1

1

U1 2
U1 ...
U1 ... 最大 100

U2

1

U2 2
U2 ...
U2 ... 最大 200

この場合の問題は、DynamoDB への書き込みリクエストをパーティションキー値全体に分散していないことです。一度に 1 つのパーティションキー値を使用し、そのすべての項目をアップロードしてから、次のパーティションキー値に移動し、同じ処理を実行します。バックグラウンドでは、DynamoDB によって複数のサーバーのテーブルにデータが分配されています。テーブル用にプロビジョニングされたすべてのスループット容量を十分に活用するには、パーティションキー値全体にワークロードを分散する必要があります。この場合、不均一のアップロード作業量が、同じパーティションキー値を持つ項目に向けられています。このため、DynamoDB によってテーブル用にプロビジョニングされたリソースすべてを十分に活用できない可能性があります。アップロード作業は、最初に各パーティションキーの値から 1 つの項目をアップロードすることで分散できます。次に、以下のテーブルのアップロードシーケンスの例に示すすべてのデータをアップロードするまで、すべての項目について、次のセットのソートキー値に対応するパターンを繰り返します。

UserId MessageID

U1

1

U2 1
U3 1
... ....

U1

2

U2 2
U3 2
... ...

このシーケンスのすべてのアップロードでは、異なるパーティションキー値が使用され、より多くの DynamoDB サーバーが同時にビジー状態になり、スループットパフォーマンスが向上します。

時系列データへのアクセスパターンを理解する

作成する各テーブルに対して、スループット要件を指定します。DynamoDB はリソースの割り当てを行い、持続性のある低レイテンシーを実現することで、スループット要件に対応します。 アプリケーションおよびテーブルの設計時には、テーブルのリソースを最も効率よく活用するためにアプリケーションのアクセスパターンを考慮する必要があります。

拠点での顧客の行動(URL のクリックなど)を追跡するテーブルを設計するとします。Customer ID をパーティションキー、日付/時刻をソートキーとして構成される複合プライマリキーを持つテーブルを設計するとします。このアプリケーションでは、顧客データが時間とともに無制限に大きくなります。ただし、アプリケーションは、テーブル内のすべての項目にわたって不均一のアクセスパターンを示す可能性があります。この場合、最新の顧客データのほうが適切であり、アプリケーションは最新の項目に頻繁にアクセスできます。時間の経過とともに、これらの項目へのアクセスは減少し、結果的に古い項目はほとんどアクセスされなくなります。これが既知のアクセスパターンである場合は、テーブルスキーマの設計時に考慮することができます。すべての項目を単一のテーブルに格納する代わりに、複数のテーブルに格納できます。たとえば、月単位のデータまたは週単位のデータを格納するテーブルを作成できます。最新の月または週のデータを格納するテーブルの場合、データアクセス率は高く、より高いスループットが要求されます。これに対し、古いデータを格納するテーブルについては、スループットの調整が可能であり、リソースを節約できます。

"ホット" な項目を高いスループットが設定された 1 つのテーブルに格納し、"コールド" な項目を低いスループットが設定された他のテーブルに格納することによって、リソースを節約できます。古い項目を削除するには、単純にテーブルを削除します。これらのテーブルは、Amazon Simple Storage Service(Amazon S3)など、他のストレージオプションに任意にバックアップできます。テーブル全体を削除するほうが、項目を 1 つずつ削除するよりもはるかに効率的です。これにより、削除オペレーションを置換オペレーションと同じくらいの回数実行するときに、書き込みスループットは基本的に 2 倍になります。

人気の高い項目をキャッシュに格納する

テーブル内の一部の項目が他の項目よりも人気が高い場合があります。たとえば、「テーブルの作成とサンプルデータのロード」で説明している ProductCatalog テーブルの場合を考えます。このテーブルに数百万点のさまざまな商品が格納されているとします。一部の商品が顧客の間で非常に人気が高い場合があり、したがってそれらの項目は他の項目よりも一貫してアクセス数が多くなります。その結果、ProductCatalog に対する読み込みアクティビティの分布は、これらの人気の高い項目に大きく偏ったものになります。

1 つの解決策は、アプリケーション層でこれらの読み込みをキャッシュに格納することです。キャッシュはスループットの高い多くのアプリケーションに使用されている手法であり、アクセス数の多い項目に対する読み込みアクティビティをデータベースではなくキャッシュにオフロードします。アプリケーションはメモリ内の最も人気の高い項目をキャッシュに格納できます。または、同様の処理に ElastiCache のような製品を使用できます。

引き続き ProductCatalog の例で、顧客がそのテーブルに項目をリクエストすると、アプリケーションはまずキャッシュに問い合わせて、キャッシュにその項目のコピーが存在するかどうかを確認します。存在する場合は、キャッシュヒットです。それ以外の場合は、キャッシュミスです。キャッシュミスがあると、アプリケーションは DynamoDB から項目を読み込み、その項目のコピーをキャッシュに格納する必要があります。時間の経過と共に、キャッシュが人気の高い項目で満たされるため、キャッシュミスは減ります。つまり、アプリケーションはこれらの項目に探して DynamoDB にアクセスする必要はなくなります。

キャッシュによる解決策により、読み込みアクティビティの分布で人気の高い項目への偏りを小さくできます。さらに、テーブルに対する読み込みアクティビティの量が減るため、キャッシュは DynamoDB 使用の全体的なコストを削減するために役立ちます。

プロビジョニングされたスループットを調整するときにワークロードの均一性を考慮する

テーブルのデータ量が増加したり、追加の読み込みおよび書き込みキャパシティーをプロビジョニングしたりするときに、DynamoDB によって、データが複数のパーティション全体に自動的に分散されます。アプリケーションでそれほど多くのスループットを必要としない場合、UpdateTable オペレーションを使用してスループットを減らし、プロビジョニングしたスループットに対してのみお支払いいただくことができます。

均一なワークロードで使用するように設計されたアプリケーションでは、DynamoDB のパーティション割り当てアクティビティによる目立った効果を確認することはできません。通常、ワークロードの一時的な不均一性は、「急激に増大するキャパシティーは控えめに使用する」で説明されているように、急激に増大するキャパシティーに対応した機能によって緩和されます。ただし、アプリケーションで不均一なワークロードに定期的に対応する必要がある場合、DynamoDB でのパーティション分割の動作(「パーティションの動作について」を参照)を考慮して、テーブルを設計してください。また、そのテーブルに対してプロビジョニングされるスループットを増減させるタイミングにも留意してください。

テーブルのプロビジョニングされたスループットの量を減らしても、DynamoDB はパーティションの数を減らしません。アプリケーションで実際に必要となるよりも多くのプロビジョニングされたスループットを使用して、テーブルを作成し、その後で、プロビジョニングされたスループットの量を減らしたとします。このシナリオでは、パーティションごとのプロビジョニングされたスループットの量は、初めから少ない量のスループットを使用してテーブルを作成した場合のパーティションごとのスループットの量と比べると、少なくなります。

たとえば、2,000 万個の項目を DynamoDB テーブルにバルクロードする必要がある状況を考えてみましょう。各項目のサイズを 1 KB と仮定した場合、このバルクロードにおけるデータのサイズは 20 GB になります。このバルクロードタスクでは、合計 2,000 万個の書き込みキャパシティーユニットが必要になります。このデータロードを 30 分以内に実行するには、テーブルのプロビジョニングされた書き込みスループットを 11,000 個の書き込みキャパシティーユニットに設定する必要があります。

パーティションの最大書き込みスループットは、1,000 個の書き込みキャパシティーユニットになります (「パーティションの動作について」を参照)。このため、DynamoDB では 11 個のパーティションが作成され、各パーティションには 1,000 個のプロビジョニングされた書き込みキャパシティーユニットが割り当てられます。

データをバルクロードした後、安定した状態の書き込みスループットの要件では、書き込みキャパシティーユニットの量はかなり少なくなります。たとえば、アプリケーションで 1 秒あたり 200 回の書き込みが必要になるとします。テーブルのプロビジョニングされたスループットをこのレベルに減らす場合、11 個のパーティションそれぞれについて、1 秒あたり約 20 個のキャパティーユニットがプロビジョニングされます。パーティションごとのプロビジョニングされたスループットがこのレベルに減少しても、DynamoDB の急激に増大するキャパシティーに対応した動作と組み合わされて、アプリケーションに十分に対応したスループットとなります。

ただし、アプリケーションで、パーティションごとに 1 秒あたり 20 回の書き込みを超える持続的な書き込みスループットが必要になる場合、次のいずれかを行う必要があります。(a) パーティションキー値ごとの 1 秒あたりの書き込み数がより少なくても対応できるスキーマを設計します。(b) より遅いペースで実行され、初期スループット要件が少なくなるようにデータのバルクロードを設計します。たとえば、30 分ちょうどではなく3 時間を超える一括インポートの実行が許可されていたとします。このシナリオでは、11,000 個ではなく、1 秒あたり 1,900 個の書き込みキャパシティーユニットのみをプロビジョニングする必要があります。その結果、DynamoDB ではテーブルに対して 2 つのパーティションのみが作成されます。

大規模環境でのアプリケーションのテスト

多くのテーブルでは、最初に格納されているデータ量は少量です。その後、アプリケーションでの書き込みアクティビティの実行に伴って、データ量は多くなっていきます。このデータ量の増加は段階的に発生する場合があり、テーブルに対して定義したプロビジョニングされたスループット設定を超えることはありません。テーブルが大きくなると、DynamoDB では、より多くのパーティションにデータを分散することで、テーブルを自動的に拡張します。こうした処理が実行されると、作成される各パーティションに割り当てられるプロビジョニングされたスループットは、元のパーティションに割り当てられるスループットよりも少なくなります。

アプリケーションでは、すべてのパーティションキー値に分散されているテーブルのデータにアクセスするが、不均一な方法でアクセスするとします (少数のパーティションキー値にのみ頻繁にアクセスする)。テーブルに十分な量のデータがなくても、アプリケーションは適切に動作する場合があります。ただし、テーブルが大きくなると、パーティションが増加し、パーティションごとのスループットは減少します。過去に動作したものと同じ不均一なアクセスパターンがアプリケーションで使用されると、アプリケーションが制限されることに気付くことがあります。

テーブルが大きくなった場合の "ホット" なキーに関連する問題を回避するには、大規模環境でアプリケーション設計をテストしてください。大規模環境で実行する場合のスループットに対するストレージの比率、および DynamoDB でパーティションをテーブルに割り当てる方法を検討します。(詳しくは、パーティションの動作について を参照してください)。

大量のテストデータを生成できない場合は、非常に高いスループット設定にプロビジョニングされたテーブルを作成できます。これにより、多くのパーティションを持つテーブルが作成されます。その後で、UpdateTable を使用して設定値を減らすことができます。ただし、大規模環境でアプリケーションを実行する場合に決定した、スループットに対するストレージの比率は維持してください。これで、テーブルの拡張後に必要となるパーティションごとのスループットの割合を備えたテーブルが作成されます。実際のワークロードを使用し、このテーブルに対してアプリケーションをテストしてください。

時系列データが格納されるテーブルは、際限なく大きくなる可能性があります。このようなテーブルが原因となって、アプリケーションのパフォーマンスが時間の経過に伴って低下する場合があります。時系列データを使用する場合、通常、アプリケーションはテーブルに格納されている以前の項目よりも最新の項目を頻繁に読み書きします。リアルタイムテーブルから以前の時系列データを削除し、そのデータを他の場所にアーカイブできる場合は、パーティションごとのスループットの割合を高い値に維持できます。

時系列データを使用したベストプラクティスについては、「時系列データへのアクセスパターンを理解する」を参照してください。