DynamoDBのアトミックカウンターの信頼性
Amazon DynamoDB をアプリケーションで使用することを検討していたところ、 アトミックカウンター の信頼性について質問があります。
concurrently、およびconsistentlyを必要とする分散アプリケーションを構築しています、Dynamoの属性に保存されているカウンターをインクリメント/デクリメントします。同時実行レベルが非常に高い（たとえば、平均ヒット率が20kの同時ヒットであるとしましょう）ダイナモのアトミックカウンターの信頼性はどうでしょうか。 /月あたりの減少）。
カウンターは非常に信頼性が高く、決してヒットしない必要があります。このような重要な環境で誰かがDynamoDBをテストしましたか？
ありがとう
DynamoDBは、複数のサーバー間でキーを分割することにより、スケーリングプロパティを取得します。これは、CassandraやHBaseスケールなどの他の分散データベースと同様です。データを複数のサーバーに移動するだけのDynamoDBでスループットを向上させることができますが、各サーバーは合計同時接続/数を処理できます。最大スループットを達成する方法の説明については、サーバーの FAQで を参照してください。
Q：プロビジョニングしたスループットのレベルを常に達成できますか？
Amazon DynamoDBは、すべての主キーにわたって比較的ランダムなアクセスパターンを想定しています。リクエストの結果、主キー全体にトラフィックがかなり均等に分散されるように、データモデルを設定する必要があります。非常に不均一または偏ったアクセスパターンがある場合、プロビジョニングされたスループットのレベルを達成できない場合があります。
データを保存するとき、Amazon DynamoDBはテーブルを複数のパーティションに分割し、主キーのハッシュキー要素に基づいてデータを分散します。テーブルに関連付けられているプロビジョニングされたスループットもパーティション間で分割されます。各パーティションのスループットは、割り当てられた割り当てに基づいて個別に管理されます。パーティション間でプロビジョニングされたスループットの共有はありません。その結果、Amazon DynamoDBのテーブルは、ワークロードがハッシュキー値全体にかなり均一に分散されている場合、プロビジョニングされたスループットレベルを満たすのに最適です。ハッシュキー値全体にリクエストを分散すると、パーティション全体にリクエストが分散され、プロビジョニングされたスループットレベルを完全に達成するのに役立ちます。
主キー間でワークロードパターンが不均一であり、プロビジョニングされたスループットレベルを達成できない場合は、プロビジョニングされたスループットレベルをさらに上げることでスループットのニーズを満たすことができ、各パーティションのスループットが向上します。ただし、主キー全体で比較的ランダムなアクセスパターンを実現するために、要求パターンまたはデータモデルの変更を検討することをお勧めします。
つまり、直接インクリメントされる1つのキーが1つのサーバーに存在する必要があるため、そのキーはスケーリングされません。この問題を処理する方法は他にもあります。たとえば、DynamoDBへのフラッシュ増分（これには信頼性の問題がある可能性があります）または分割されたカウンターが複数のキーに分散され、シャード内のすべてのキーをプルすることによって読み戻されるシャードカウンターなどがあります。カウンター（ http://whynosql.com/scaling-distributed-counters/ ）。
スケーラビリティに関するgigqの回答に加えて、DynamoDBのアトミックインクリメントはべき等ではないため、信頼性がありません。UpdateItemADDリクエストを発行した後に接続が切断されると、追加がコミットされたかどうかを知る方法がありません。再試行する必要があるかどうかはわかりません。
DynamoDB条件付き更新はこれを修正しますが、エラーがなくても、属性への2つの変更が同時に試行されるたびに再試行する必要があるため、システムのスケーラビリティがさらに低下します。
単一のダイナモdbキーを書き込む場合、ホットパーティションの問題が発生します。ホットパーティションの問題は、インデックスあたり約300 TPSから始まります。したがって、テーブルに5つのインデックスがある場合、ホットパーティションの問題が約300/5〜60 TPSになる可能性があります。
それ以外の場合、dynamo dbは、ユースケースに応じて、約10〜40K TPSまで拡張可能です。