Dynamodb読み取りおよび書き込みユニット
私はAmazon DynamoDBでさまざまな記事を読んでいますが、これらがどのように使用されるかについての読み書きユニットについてはまだ少し混乱しています。たとえば、無料版を使用すると、1秒あたり5つの書き込み単位と10個の読み取り単位があり、各単位は1kbのデータを表します。しかし、これはどういう意味ですか？
これは、1秒あたり最大10件の読み取り要求を実行できることを意味しますか、または1秒あたり最大10kbのデータを要求できることを意味しますか（10または100の要求があるかどうかに関係なく）？この側面は私にははっきりしないからです。したがって、自分のWebサイトのページに同時にアクセスするユーザーが20人いる場合（データを取得するために20のクエリが実行される結果になります）、どうなりますか？そのうちの10人はデータをすぐに表示しますが、他の10人は1秒後にデータを表示しますか？または、要求されたデータ（20倍）が10 kb未満の場合、すべてのユーザーがすぐにデータを表示しますか？
また、読み取り単位が不十分で、100人のユーザーがそれぞれ1 kbのデータを同時に要求する場合、すべての要求が完了するまでに10秒かかることを意味しますか？
また、価格が予約または消費されたユニットに対して支払われているかどうかがわからないので、価格設定は少し混乱していますか？したがって、たとえば、価格は「書き込みスループット：書き込み容量10ユニットごとに1時間あたり0.00735ドル」と言います。これは、1日の間に書き込み要求が行われなくても、（0.00735 * 24 = 0.176ドル）支払うことを意味しますか？
容量は読み取り/書き込みされるオブジェクトのサイズに密接にバインドされているという点で正しいです。
2016年2月の更新
AWSはスループットの計算方法を更新し、計算のためにオブジェクトを1 KBから4 KBに増やしました。以下の議論はまだ有効ですが、特定の計算は現在異なります。
スループットの計算方法に関する最新情報と例については、最新のDynamoDBドキュメントを常に参照してください。
古いドキュメント
AWS DynamoDBのドキュメントから（1/8/14現在）：
書き込みに必要な容量の単位= 1秒あたりの項目書き込み数x項目サイズ（最も近いKBに切り上げ）
読み取りに必要な容量の単位* = 1秒あたりの項目読み取り数x項目サイズ（最も近いKBに切り上げ）
- 最終的に整合性のある読み取りを使用すると、1秒あたりの読み取り数で2倍のスループットが得られます。
例の質問に従って、1秒あたり10KBのデータを読み取りたい場合は、10個の読み取りユニットをプロビジョニングする必要があります。 1 KBのデータに対して10個のリクエストを作成する場合も、10 KBのデータに対して単一のリクエストを作成する場合も、問題ではありません。 10KB /秒に制限されています。
必要な読み取り容量の単位数は、API呼び出しの数ではなく、1秒あたりに読み取られるアイテムの数によって決まります。たとえば、テーブルから毎秒500アイテムを読み取る必要があり、アイテムが1KB以下の場合、500ユニットの読み取り容量が必要です。 500個の個別のGetItem呼び出しまたは50個のBatchGetItem呼び出しを実行して、それぞれが10項目を返すかどうかは関係ありません。
20ユーザーの例では、データは最も近いKBに切り上げられることに注意してください。したがって、20人のユーザーが0.5 KBのデータを要求したとしても、それらすべてを一度に処理するには20個の読み取りユニットが必要になります。読み取りユニットが10個しかない場合、他の10個のリクエストは抑制されます。 Amazon DynamoDBライブラリを使用する場合、自動再試行ロジックが組み込まれてリクエストを再試行するため、最終的にサービスを受ける必要があります。
100ユーザーについての質問では、これらのリクエストの一部が単に抑制され、再試行ロジックが最終的に失敗する可能性があります（コードは試行を停止する前に何度もリクエストを再試行するだけです）。したがって、400応答を処理する準備ができている必要があります。 DynamoDBからのコードとそれに応じて反応します。 DynamoDBを使用する場合はアプリケーションを監視し、アプリの重要なトランザクションが抑制されないようにすることが非常に重要です。
料金設定に関する最後の質問です。予約したものに対して1時間ごとに支払います。 1000の読み取りユニットを予約していて、サイトにまったくトラフィックがない場合、ひどい場合でも、それらの1000の読み取りユニットに対して1時間ごとに支払います。
完全を期すために、スループットはPER TABLEのプロビジョニングであることを覚えておいてください。したがって、ユーザー、写真、友達の3つのDynamoDBテーブルがある場合は、各テーブルに容量をプロビジョニングする必要があり、各テーブルに適切なものを決定する必要があります。この簡単な例では、アプリでの写真へのアクセス頻度が低いため、Usersテーブルと比較して低いスループットをプロビジョニングできます。
最終的に一貫性のある読み取りはコスト削減に最適ですが、アプリはそれを処理するように設計する必要があります。最終的に一貫した読み取りとは、データを更新し、すぐに新しい値を読み取ろうとした場合、新しい値を取得できず、以前の値が返されることを意味します。最終的には、十分な時間をかけて、新しい値を取得します。最新のデータを読み取ることが保証されていないため、支払い額は少なくなりますが、適切に設計すれば問題はありません。
それをパイプの直径と考えてください。1秒あたりの可能なデータスループットに対して料金を支払います。リクエストの数は関係ありません。
さらに、10の読み取りユニットを要求すると、実際のトラフィックに関係なく、実際に10ユニットの料金が発生します。
トラフィックが制限を超えると、最初に警告が表示されます（プロビジョニングされたスループットの80％としましょう）。その後、リクエストに時間がかかり始めます。それでもかなりの時間制限を超えている場合は、新しい接続が数分間拒否されることがあります。
それが役に立てば幸い
•アイテムの追加と更新は書き込みスループットを消費し、リクエスト/クエリアイテムはdynamo dbの読み取りスループットを消費します。 DynamoDBテーブル内の単一のアイテムの最大サイズは400 kbであり、アイテムが大きいほど、より多くのスループットを消費し、コストが高くなります。キーを使用してDynamoDBで検索している場合、テーブルスキャンは発生せず、アイテムサイズと同等のスループットが必要です。たとえば、アイテムサイズが4 KBの場合、1つの読み取り容量ユニットが必要です（1ユニットは4KB /秒に相当）。 1秒あたり40KBのデータを読み取りたい場合は、10個の読み取りユニットをプロビジョニングする必要があります。 4 KBのデータに対して10個のリクエストを作成する場合も、40 KBのデータに対して1回のリクエストを作成する場合も問題ありません。 40KB /秒に制限されています。ただし、キーとは別に検索している場合、DynamoDBはテーブルから完全なデータをスキャンしますが、データベースのデータが高い場合、dbのスキャンはプロビジョニングされたスループットの制限を超えます。スキャン中に必要な最大値までテーブルのスループットを増やすことができますが、コストがかかり、ほとんどの場合、データベースは完全にアイドル状態になります。
この記事を読んでください、すべての詳細があります：
通常、アイテムごとに支払いを行います。各アイテムのサイズは、書き込み/読み取り操作のために次の1KB/4KBに丸められます。
このルールの唯一の例外は、クエリ/スキャン呼び出しを行う場合です。
返されたすべてのアイテムは単一の読み取りオペレーションとして扱われ、DynamoDBはすべてのアイテムの合計サイズを計算してから、次の4 KB境界に切り上げます。クエリがそれぞれ64バイトの1500アイテムを返す場合、累積サイズは96 KBです。