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