プロビジョニングされた読み取り容量ユニットが1つしかないのに、DynamoDBスキャンが非常に高速なのはなぜですか？
1346個のアイテムでテーブルを作成しました。各アイテムのサイズは4KB未満です。読み取り容量ユニットを1つプロビジョニングしたので、1秒あたり平均1つのアイテムの読み取りが期待されます。ただし、1346個のアイテムすべてを単純にスキャンすると、ほぼすぐに返されます。
ここで何が欠けていますか？
回答
これは、バースト可能なアクション（テーブル全体のスキャンなど）に使用するために300秒の期間にわたって容量を取得するバースト容量にまで低下する可能性があります。
これは、これらのクレジットをすべて使用した場合、利用できる十分な容量がないため、他のインタラクションが影響を受けることを意味します。
消費されたWCU / RCUの量は、CloudWatchメトリクスまたはDynamoDBインターフェース自体（[メトリクス]タブを介して）で確認できます。
「各アイテムが4KB未満である」と言う以外は、エントリのサイズを指定しません。どれくらい少ないですか？
1 RCUは、最大4KBのアイテムの1秒あたり2つの結果整合性読み取りをサポートします。
言い換えると、1つのRCUと結果整合性のある読み取りにより、1秒あたり8KBのデータを読み取ることができます。
レコードが4KBの場合、2レコード/秒
1KB、8 /秒
512B、16 /秒
256B、32 /秒を取得します
したがって、すでに述べた「バースト」機能により、55RCUを使用できました。ただし、レコードのサイズが小さいため、55RCUは「ほぼ即座に」データを返すことができました。
ここで有利に機能することが2つあります。1つは、Scan操作に必要なRCUが、小さなアイテムの場合と思っていたよりも大幅に少ないことです。もう1つは「バースト容量」です。私は両方を説明しようとします：
DynamoDBの価格設定ページには、「アップサイズは4キロバイトの項目については、1つのRCUは毎秒2つの最終的に一貫性のある読み取り要求を実行することができます。」と述べています。これは、アイテムのサイズが10バイトであっても、結果整合性を持って読み取るにはRCUの半分のコストがかかることを示しています。ただし、これについてはどこにも記載されていませんが、このコストは、単一のアイテムを取得する操作にのみ当てはまりGetItemます。ではScanまたはQuery、それはあなたが、個々の項目に別々に払っていないことが判明します。代わりに、これらの操作はディスクに保存されているデータを順番にスキャンし、読み取ったデータの量に対して料金を支払います。あなたの1000の小さな項目とした場合の合計DynamoDBのは、ディスクから読み取る必要があったというサイズが80キロバイトだった、あなたは、80キロバイト/ 4キロバイト/ 2、または10件のRCUを支払うことになるではない500件のRCU。
これは、1346項目を読み取り、1346/2 = 673ではなく、55RCUのみを測定した理由を説明しています。
2つ目は、DynamoDBに「バースト容量」機能があることです。ここで説明します。
DynamoDBは現在、最大5分（300秒）の未使用の読み取りおよび書き込み容量を保持しています。読み取りまたは書き込みアクティビティがときどきバーストするときに、これらの追加の容量ユニットはすぐに消費される可能性があります。テーブルに定義した1秒あたりのプロビジョニングされたスループット容量よりもさらに高速です。
そのため、リクエストの前にデータベースが5分間存在していた場合、DynamoDBは300 RCUを保存しました。これは、すぐに使い切ることができます。300 RCUはスキャンに必要な量よりもはるかに多いため（55）、スキャンはスロットルなしで非常に迅速に実行されました。
クエリを実行すると、RCUカウントは、読み取られたアイテムの数を考慮せずに、読み取られたデータの量に適用されます。したがって、アイテムが小さい場合、たとえばそれぞれ数バイトの場合、単一の4KBRCU内で簡単にクエリできます。
これは、DynamoDBから多くのアイテムを読み取るときにも特に役立ちます。多くの小さなアイテムをクエリする方が、BatchGettingよりもはるかに安価で効率的であることはすぐにはわかりません。