問題タブ [eventual-consistency]

プロジェクトの 1 つに Dynamodb を使用しようとして、dynamodb の強整合性モデルについて疑問があります。よくある質問から

強力な一貫性のある読み取り — Amazon DynamoDB は、結果整合性に加えて、アプリケーションまたはアプリケーションの要素が必要とする場合に、強力な一貫性のある読み取りをリクエストする柔軟性と制御も提供します。強整合性読み取りは、読み取りの前に成功応答を受け取ったすべての書き込みを反映する結果を返します。

上記の定義から、強力な一貫性のある読み取りは最新の書き込み値を返すことがわかります。

例を挙げると、Client1 がキー K1 で書き込みコマンドを発行して、値を V0 から V1 に更新するとします。数ミリ秒後、クライアント 2 がキー K1 の読み取りコマンドを発行すると、強力な整合性の場合は常に V1 が返されますが、結果整合性の場合は V1 または V0 が返される場合があります。私の理解は正しいですか？

そうである場合、書き込み操作が成功を返したが、データがすべてのレプリカに更新されておらず、強力な一貫性のある読み取りを発行した場合、この場合、最新の書き込み値を確実に返すにはどうすればよいでしょうか?

次のリンク AWS DynamoDB read after write一貫性 - 理論的にはどのように機能しますか? この背後にあるアーキテクチャを説明しようとしていますが、これが実際にどのように機能するかわかりませんか? このリンクをたどった後に頭に浮かぶ次の質問は、DynamoDb はシングル マスター、マルチ スレーブ アーキテクチャに基づいており、書き込みと強力な整合性のある読み取りはマスター レプリカを介して行われ、通常の読み取りは他のレプリカを介して行われるかということです。

Google App Engine で実行される RESTful Web サービスがあり、JPA を使用してエンティティを GAE データ ストアに格納します。

新しいエンティティは、POST 要求を使用して作成されます (サーバーがエンティティ ID を生成するため)。

ただし、GAE DS は結果整合性があるため、どのステータス コードを返すのが最適かはわかりません。私は次のことを検討しました：

• 200 OK: RFC は、応答本文に「アクションの結果を記述または含むエンティティ」を含める必要があると述べています。これは、エンティティが DS に永続化されるときに生成された ID で更新されるため、実現可能です。したがって、更新されたエンティティをすぐにシリアル化して返すことができます。ただし、すべてのノードがまだ整合性に達していない可能性があるため、ID によるそのエンティティに対する後続の GET 要求は失敗する可能性があります (これは、私のクライアント アプリケーションの実際の問題として観察されています)。
• 201 Created: 上記のように、一貫性がまだ達成されていない場合、新しいエンティティの URI を返すと、クライアントの問題が発生する可能性があります。
• 202 Accepted: 上記の問題は解消されますが、新しいエンティティの ID をクライアントに通知することはできません。

このシナリオでベスト プラクティスと見なされるのはどれですか?

バックグラウンド

私たちのプロジェクトでは、クライアントがアップロードしたファイルのストレージとしてAmazon S3を使用しています。

技術的な理由により、ファイルを一時的な名前で S3 にアップロードし、その内容を処理して、処理後にファイルの名前を変更します。

問題

名前を変更するファイルは正常にアップロードされましたが、「名前の変更」操作はエラーで何度も失敗します。404 (key not found)

Amazonのドキュメントでは、この問題について言及しています：

Amazon S3 は、Amazon のデータ センター内の複数のサーバー間でデータを複製することにより、高可用性を実現します。PUT リクエストが成功すると、データは安全に保存されます。ただし、変更に関する情報は Amazon S3 全体にレプリケートする必要があり、これには時間がかかる場合があるため、次のような動作が見られる場合があります。

回避策として一種のポーリングを実装しました。成功するまで「名前の変更」操作を再試行してください。
ポーリングは 20 秒後に停止します。

この回避策はほとんどの場合に機能します。ファイルは数秒以内に複製されます。
しかし、非常にまれですが、20 秒では不十分な場合もあります。S3 でのレプリケーションにはさらに時間がかかります。

質問

• PUT オペレーションが成功してから Amazon S3 でのレプリケーションが完了するまでに観測された最大時間はどれくらいですか?

• Amazon S3 はレプリケーションを「バイパス」する方法を提供していますか? ('master' を直接クエリしますか?)

結果整合性によって同時実行を処理する方法は? または、結果整合性によってデータの整合性を確保する方法を尋ねることができますか?

CQRS とイベント ソーシングによって、結果整合性とは、ドメイン イベントをキューに入れ、プロジェクションであるイベント ハンドラーを設定することを意味します。これらのプロジェクションは、非同期の方法で読み取りキャッシュを更新します。その読み取りキャッシュを使用して検証すると、検証の基にした情報がまだ有効であることを確認できなくなります。コマンドを送信すると、未処理 (または未投影?) のドメイン イベントがキューに存在する可能性があり、これにより検証の結果が変わる可能性があります。つまり、これは単なる別のタイプの同時実行です...これらのまれな同時実行の問題をどのように処理すると思いますか? ドメイン イベントは既にストレージに保存されているため、何もすることはできません。イベント ストレージから削除することはできません (書き込みは 1 回だけであることが想定されているため)。私たちは決心し、あなたのリクエストをキャンセルしました。それともできますか？

アップデート：

イベントストレージによる同時実行を処理するための可能な解決策:

書き込みモデル別

読み取りモデル別

投影による

既存の RavenDB セッションで次のクエリを実行すると:

RavenDB はどのインデックスを待機しますか? 私の仮定では、クエリの時点ですべてのインデックスが最新になるのを待つということです。ただし、動的インデックスが 1 つしかなく、Location他のテーブルに 20 個のインデックスがある場合、常に 21 個のインデックスが更新されるのを待っているということでしょうか?

または、メソッドの機能を誤解していますか?