「翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。」
データのクエリとスキャンのベストプラクティス
このセクションでは、Query
の Scan
および Amazon DynamoDB オペレーションを使用するためのベストプラクティスについて説明します。
スキャンのパフォーマンスに関する考慮事項
一般に、Scan
オペレーションは DynamoDB の他のオペレーションよりも効率が低くなります。オペレーションは常にテーブル全体またはScan
をスキャンします。セカンダリインデックス次に、値を除外して必要な結果を提供します。基本的に、結果セットからデータを削除する余分なステップが追加されます。
可能であれば、多くの結果を削除するフィルタを使用して、大きなテーブルまたはインデックスに対して Scan
オペレーションを使用することは避けてください。また、テーブルまたはインデックスが増加すると、Scan
オペレーションも低速になります。オペレーションでは、すべての項目でリクエストされた値がないかを調べ、1 回のオペレーションで、大規模なテーブルまたはインデックスに対してプロビジョニングされたスループットを使用できます。Scan
応答時間を短縮するには、アプリケーションが Query
の代わりに Scan
を使用できるように、テーブルとインデックスを設計します。 (テーブルの場合は、GetItem
および BatchGetItem
APIs.) の使用を検討することもできます。)
または、リクエスト率への影響を最小限に抑える方法で、Scan
オペレーションを使用するようにアプリケーションを設計します。
読み取りアクティビティでの突然のスパイクの回避
テーブルの作成時に、その読み込みおよび書き込みキャパシティーユニット要件を設定します。読み込みの場合、キャパシティーユニットは、1 秒あたりの強い整合性のある 4
KB データ読み込みリクエストの数として表されます。結果整合性のある読み込みの場合、読み込みキャパシティーユニットは、1 秒あたり 2 4 KB 読み込みリクエストです。オペレーションは、デフォルトでは結果整合性のある読み込みを実行し、最大
Scan
(1 ページ) のデータを返すことができます。1 MBしたがって、単一の Scan
リクエストで消費できるオペレーションは、(1 MB ページサイズ / 4 KB 項目サイズ) / 2 (結果的に整合性のある読み込み) = 128 です。代わりに強力な整合性のある読み込みをリクエストした場合、Scan
オペレーションはプロビジョニングされたスループットの 2 倍—256 読み込みオペレーションを消費します。
これは、テーブルの設定済み読み込みキャパシティーと比較して、急激な使用率の急増を表します。スキャンによるこのキャパシティーユニットの使用量により、同じテーブルに対する他の重要なリクエストが使用可能なキャパシティーユニットを使用することができなくなります。その結果、これらのリクエストに対して
ProvisionedThroughputExceeded
例外が発生することがあります。
問題の原因は、Scan
で使用するキャパシティーユニットが突然増加することではありません。スキャンは、同じパーティションにあるすべてのキャパシティーユニットを消費する可能性もあります。これは、スキャンリクエストがパーティションで互いに隣接する項目を読み取るためです。つまり、リクエストが同じパーティションを実行し、そのすべてのキャパシティーユニットが消費され、そのパーティションへの他のリクエストがスロットリングされることになります。データの読み取りリクエストが複数のパーティションにまたがっている場合、オペレーションは特定のパーティションを調整しません。
次の図は、Query
および Scan
オペレーションによるキャパシティーユニットの使用率の急激な上昇の影響と、同じテーブルに対する他のリクエストへの影響を示しています。

ここに示すように、使用率のスパイクは、テーブルのプロビジョニングされたスループットにさまざまな方法で影響する可能性があります。
-
良い: リクエストとサイズの均等な分散
-
好適ではありません。頻繁なリクエストのバースト
-
不良: いくつかのランダムな大きなリクエスト
-
不良: 大規模なスキャンオペレーション
大規模な Scan
オペレーションを使用する代わりに、以下の手法を使用して、テーブルのプロビジョニングされたスループットに対するスキャンの影響を最小限に抑えることができます。
-
ページサイズの縮小
スキャンオペレーションはページ全体を読み取るため (デフォルトでは 1 MB)、ページサイズを小さく設定することでスキャンオペレーションの影響を軽減できます。オペレーションには、リクエストのページサイズを設定するために使用できる
Scan
Limit パラメータが用意されています。ページサイズが小さい各Query
またはScan
リクエストでは、読み込みオペレーションが少なくなり、リクエスト間に "pause" が作成されます。たとえば、各項目が 4 KB であり、ページサイズを 40 項目に設定したとします。この場合、Query
リクエストで消費されるのは、結果的に整合性のある読み込みオペレーション 20 個または強い整合性のある読み込みオペレーション 40 個のみです。多数の小さいQuery
またはScan
オペレーションでは、スロットリングなしで他の重要なリクエストが成功できます。 -
分離スキャンオペレーション
DynamoDB は、簡単にスケーラビリティを実現できるように設計されています。その結果、アプリケーションは別の目的でテーブルを作成できます。複数のテーブル間でコンテンツが複製される場合もあります。「ミッションクリティカル」なトラフィックを受け取っていないテーブルに対してスキャンを実行します。一部のアプリケーションでは、2 つのテーブル間で 1 時間ごとにトラフィックをローテーションすることによって、この負荷を処理します — 1 つは重要なトラフィック用、もう 1 つはブックキーピング用です。その他のアプリケーションは、「ミッションクリティカル」テーブルと「シャドウ」テーブルの 2 つのテーブルですべての書き込みを実行することでこれを実行できます。
プロビジョニングされたスループットを超えたことを示すレスポンスコードを受け取るリクエストを再試行するようにアプリケーションを設定します。または、UpdateTable
オペレーションを使用して、テーブルのプロビジョニングされたスループットを増やします。ワークロードに一時的なスパイクがあり、スループットを超過する場合、プロビジョニングされたレベルを超えることがあります。必要に応じて、エクスポネンシャルバックオフを使用してリクエストを再試行します。エクスポネンシャルバックオフの実装の詳細については、「エラーの再試行とエクスポネンシャルバックオフ」を参照してください。
並列スキャンの利用
多くのアプリケーションは、シーケンシャルスキャンではなく、並列 Scan
オペレーションを使用することからメリットがあります。たとえば、履歴データの大きなテーブルを処理するアプリケーションは、シーケンシャルなテーブルよりもかなり高速に並列スキャンを実行できます。複数のワーカースレッドをバックグラウンドの「スピア」プロセスで使用し、本番稼働のトラフィックに影響を与えることなく、優先度の低いテーブルをスキャンできます。これらの各例では、プロビジョニングされたスループットリソースの他のアプリケーションをスタベーションしないように、並列
Scan
が使用されています。
並列スキャンは便利な場合がありますが、プロビジョニングされたスループットに高い需要を置くことができます。並列スキャンにより、アプリケーションには、すべてが同時に Scan
オペレーションを実行している複数のワーカーが存在します。これにより、テーブルのプロビジョニングされた読み込みキャパシティーのすべてをすばやく消費できます。その場合、テーブルにアクセスする必要のある他のアプリケーションがスロットリングされる可能性があります。
以下の条件が満たされている場合、並列スキャンは適切な選択肢となります。
-
テーブルサイズは 20 GB 以上です。
-
テーブルのプロビジョニングされた読み込みスループットが完全に使用されていません。
-
シーケンシャル
Scan
オペレーションは遅すぎます。
の選択TotalSegments
の最適な設定は、特定のデータ、テーブルのプロビジョニングされたスループット設定、およびパフォーマンス要件によって異なります。TotalSegments
これを正しく行うために、実験が必要になる場合があります。データの 2 GB ごとに 1 つのセグメントなど、単純な比率から始めることをお勧めします。たとえば、30
GB のテーブルでは、TotalSegments
を 15 (30 GB / 2 GB) に設定できます。アプリケーションは 15 人のワーカーを使用し、各ワーカーは異なるセグメントをスキャンします。
クライアントリソースに基づく TotalSegments
の値を選択することもできます。を 1 から 1000000 までの任意の数に設定でき、TotalSegments
によりそのセグメントの数をスキャンできます。DynamoDBたとえば、クライアントが同時に実行できるスレッドの数を制限している場合、アプリケーションで最高の TotalSegments
パフォーマンスが得られるまで Scan
を徐々に増やすことができます。
並列スキャンをモニタリングしてプロビジョニング済みスループットの使用率を最適化します。同時に、他のアプリケーションがリソースのスタベーションが発生しないようにします。プロビジョニングされたスループットを消費せずに、TotalSegments
リクエストでスロットリングが発生している場合は、Scan
の値を増やします。リクエストが使用する必要以上のプロビジョニングされたスループットを消費する場合は、TotalSegments
の値を減らします。Scan