データのクエリとスキャンのベストプラクティス

このセクションでは、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 オペレーションによるキャパシティーユニットの使用率の急激な上昇の影響と、同じテーブルに対する他のリクエストへの影響を示しています。

ここに示すように、使用率のスパイクは、テーブルのプロビジョニングされたスループットにさまざまな方法で影響する可能性があります。

1. 良い: リクエストとサイズの均等な分散

2. 好適ではありません。頻繁なリクエストのバースト

3. 不良: いくつかのランダムな大きなリクエスト

4. 不良: 大規模なスキャンオペレーション

大規模な Scan オペレーションを使用する代わりに、以下の手法を使用して、テーブルのプロビジョニングされたスループットに対するスキャンの影響を最小限に抑えることができます。

• ページサイズの縮小

  スキャンオペレーションはページ全体を読み取るため (デフォルトでは 1 MB)、ページサイズを小さく設定することでスキャンオペレーションの影響を軽減できます。オペレーションには、リクエストのページサイズを設定するために使用できる ScanLimit パラメータが用意されています。ページサイズが小さい各 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