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

このセクションでは、を使用するためのベストプラクティスをいくつか紹介しますQueryおよびScanオペレーションを Amazon DynamoDB で作成します。

スキャンのパフォーマンスに関する考慮事項

一般的には、Scanオペレーションは、DynamoDB の他のオペレーションよりも効率が低くなります。AScanオペレーションは、常にテーブルまたはセカンダリインデックス全体をスキャンします。次に、値をフィルタリングして必要な結果を提供し、本質的に結果セットからデータを削除する余分なステップを追加します。

可能であれば、Scan操作は、多くの結果を削除するフィルタを使用して大きなテーブルまたはインデックスに対して行います。また、テーブルまたはインデックスが大きくなるにつれて、Scan操作が遅くなります。-Scanオペレーションは、すべての項目で要求された値を調べ、1 回のオペレーションで大きなテーブルまたはインデックスに対してプロビジョニングされたスループットを使い果たすことができます。応答時間を短縮するには、テーブルおよびインデックスを設計して、アプリケーションがQueryの代わりにScan。（テーブルの場合は、GetItemおよびBatchGetItemAPI。)

または、アプリケーションを設計してScan操作を、リクエスト率への影響を最小限に抑える方法で行うことができます。

読み取りアクティビティの突然のスパイクの回避

テーブルを作成する場合には、テーブルを作成する場合には、テーブルで読み込みおよび書き込みキャパシティーユニットの要件を設定します。読み取りの場合、キャパシティーユニットは、1 秒間に強い整合性のある 4 KB データ読み取り要求の数として表されます。結果整合性のある読み込みの場合、読み込みキャパシティーユニットは 1 秒あたり 2 回の 4 KB 読み込みリクエストです。AScanオペレーションは、デフォルトで結果整合性のある読み込みを実行し、最大 1 MB (1 ページ) のデータを返すことができます。したがって、単一のScanリクエストは、(1 MB ページサイズ/ 4 KB アイテムサイズ)/2 (結果整合性のある読み取り) = 128 の読み込み操作を使用できます。代わりに強力な整合性のある読み込みを要求すると、Scanオペレーションでは、プロビジョニングされたスループット（256 回の読み取り操作）が 2 倍消費されます。

これは、テーブルに設定されている読み込み容量と比較して、急に使用量が急増することを表します。スキャンによるキャパシティーユニットのこの使用により、同じテーブルに対する他の潜在的に重要なリクエストで利用可能なキャパシティーユニットが使用できなくなります。その結果、おそらくProvisionedThroughputExceeded例外です。

問題は、容量ユニットの急激な増加だけではありませんScanを使用します。スキャンは、パーティション上で隣り合うアイテムの読み取りを要求するため、同じパーティションからすべての容量ユニットを消費する可能性もあります。これは、要求が同じパーティションに到達し、そのすべての容量ユニットが消費され、そのパーティションへの他の要求を抑制することを意味します。データの読み取り要求が複数のパーティションに分散されている場合、オペレーションは特定のパーティションをスロットルしません。

次の図は、キャパシティ・ユニットの使用率が急増したことによる影響を示しています。QueryおよびScan操作、および同じテーブルに対する他のリクエストへの影響。

次の図に示すように、使用率の急増は、テーブルのプロビジョニングされたスループットにいくつかの点で影響する可能性があります。

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

2. それほど良くない: バーストでの頻繁な要求

3. 不得意な処理 いくつかのランダムな大きな要求

4. 不得意な処理 大規模なスキャンの操作

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

• ページサイズの削減

  スキャン操作はページ全体 (既定では 1 MB) を読み込むため、ページサイズを小さくすることで、スキャン操作の影響を軽減できます。-Scanオペレーションは、制限パラメーターで、リクエストのページサイズを設定するために使用できます。EAQueryまたはScanリクエストでは、使用する読み取り操作が少なくなり、各リクエストの間に「一時停止」が作成されます。たとえば、各項目が 4 KB で、ページサイズを 40 項目に設定するとします。AQueryリクエストは、結果整合性のある読み込み操作を 20 回しか消費せず、強く整合性のある読み込み操作を 40 回しか消費しません 小さいものの大きい数QueryまたはScan操作を使用すると、他の重要なリクエストはスロットリングなしで成功できます。

• スキャンの操作を分離する

  DynamoDB は、簡単に拡張できるように設計されています。その結果、アプリケーションは、異なる目的のためにテーブルを作成することができ、場合によっては複数のテーブル間でコンテンツを複製することさえできます。「ミッションクリティカルな」トラフィックを受けていないテーブルに対してスキャンを実行する場合 アプリケーションによっては、2 つのテーブル間でトラフィックを 1 時間ごとにローテーションすることで、この負荷を処理します。1 つは重要なトラフィック用で、もう 1 つは簿記用です。他のアプリケーションでは、「ミッションクリティカル」テーブルと「シャドウ」テーブルの 2 つのテーブルに対してすべての書き込みを実行することで、これを実行できます。

プロビジョニングされたスループットを超えたことを示すレスポンスコードを受信するすべてのリクエストを再試行するようにアプリケーションを設定します。または、テーブルのプロビジョニングされたスループットを増やすUpdateTableオペレーション. ワークロードの一時的なスパイクが発生して、スループットがプロビジョニングされたレベルを超えることがあります。場合によっては、指数関数的なバックオフを使用してリクエストを再試行します。指数バックオフの実装の詳細については、」エラーの再試行とエクスポネンシャルバックオフ。

並列スキャンの活用

多くのアプリケーションでは、パラレルを使用することでメリットを得られますScanシーケンシャルスキャンの代わりに、オペレーションを実行します。たとえば、履歴データの大きなテーブルを処理するアプリケーションは、シーケンシャルデータよりもはるかに高速に並列スキャンを実行できます。バックグラウンドの「sweeper」プロセスの複数のワーカースレッドは、本番トラフィックに影響を与えずに、低い優先度でテーブルをスキャンする可能性があります。これらの各例では、Scanは、プロビジョニングされたスループットリソースの他のアプリケーションが枯渇しないように使用されます。

並列スキャンは有益ですが、プロビジョニングされたスループットに大量の要求が発生する可能性があります。並列スキャンでは、アプリケーションには複数のワーカーがあり、Scanオペレーションを同時に実行します。これにより、テーブルでプロビジョニングされた読み込みキャパシティー。その場合、テーブルにアクセスする必要がある他のアプリケーションがスロットルされる可能性があります。

並列スキャンの場合は、次の条件が満たされている場合が考えられます。

• テーブルのサイズは 20 GB 以上です。

• テーブルのプロビジョニングされた読み込みスループットが完全に使用されていません。

• シーケンシャルScan操作が遅すぎます。

セグメント合計の選択

最適な設定TotalSegmentsは、特定のデータ、テーブルのプロビジョニングされたスループット設定、およびパフォーマンス要件によって異なります。それを正しくするには、実験が必要な場合があります。まず、2 GB のデータごとに 1 セグメントなど、単純な比率から始めることをお勧めします。たとえば、30 GB のテーブルでは、TotalSegmentsへ 15 (30 GB/2 GB). アプリケーションは 15 人のワーカーを使用し、各ワーカーは異なるセグメントをスキャンします。

または、[] を選択することもできます。TotalSegmentsクライアントリソースに基づいています。次の設定を行うことができますTotalSegmentsを 1 ～ 1000000 の任意の数に設定できます。DynamoDB では、その数のセグメントをスキャンできます。たとえば、クライアントが同時に実行できるスレッドの数を制限している場合、TotalSegments最高の取得までScanパフォーマンスをアプリケーションで使用します。

並列スキャンを監視して、プロビジョニングされたスループットの使用を最適化し、他のアプリケーションのリソースが不足していないことを確認します。の値を増やすTotalSegmentsでプロビジョニングされたスループットをすべて消費せず、Scanリクエスト。の値を減らすTotalSegmentsの場合Scanリクエストは、使用するよりも多くのプロビジョニングされたスループットを消費します。