問題タブ [eventual-consistency]

e コマース アプリケーションを想像してみてください。

Node cluster N1, N2, N3.3 つ持っていて、一貫性レベル (CL) が弱いとしましょう。

Read CL = N/2+1 = 2 (in this case), Write CL = Any (alteast 1)

次のような製品テーブルがあります

これは、3 つのノード間で同期されている初期データです。

1. クライアント A は N1 から情報を読み取り、クライアント B は N2 から情報を読み取ります。

   クライアント 1 は、1 台のコンピューターが使用可能であることを確認します

   クライアント 2 は、1 台のコンピューターが使用可能であることを確認します

2. クライアント A が最初に注文します。したがって、N1 の場合、テーブルは次のようになります。

   product_info : {'computer':0}

3. クライアント 2 が注文を行うため、N2 ではテーブルは次のようになります。

   product_info : {'computer':0}

   しかし実際には、クライアント 2 の注文は処理されていないはずです。

4. クライアント C は N3 経由でアクセスします。ここで、N1 で読み取りが行われ、0 が返されます。(クォーラムは少なくとも 2 つのノードが応答する必要があるため) N3 の値は 1 ですが、そのタイムスタンプは古くなっています。その値を更新し、利用可能なコンピューターがないことをクライアントに示します。これはいい

   この例では、最初の product_info がクライアント A と B によってロードされた時点でデータが同期されているため、弱い一貫性レベルと強い一貫性レベルの両方が間違った結果につながります。これを Cassandra でどのように処理できますか?

私は App Engine のデータストアのこの機能に出くわしました。それは、GAE で動作の一貫性を保つために永続化されたルート エンティティを実際に持つ必要がないということです。計算されたキーを使用して、子エンティティを格納およびロードできます。私の質問は次のとおりです。これは良い習慣ですか、それともデータストアの実装の癖に頼りすぎていますか?

Python を使用した例を次に示します。この慣用句は Java でも機能するはずです。

子エンティティがあるとしましょう:

CustomerReports は、実際のエンティティ タイプ Customer に基づいて生成されます。ただし、次のように存在しない親エンティティの祖先キーを計算することで、このレポート エンティティを強い整合性で保存できます。

そのようです：

これは、キーを計算するだけで再度取得できます。

ありがとうございました。

RavenDB を使用するアプリケーションの起動時に、特定のタイプのドキュメントの完全なコレクションをロードし、それらをループ処理する必要があります。ドキュメントの数は常に少なくする必要があります (< 1000)。

私はこれを行うことができます：

しかし、私が得ている結果がすぐに一貫していることを確認したい.

このケースは aLoad()と a の間にあるようですQuery()。(私が思うに) クエリは最終的に一貫性を保つことを意図しており、負荷はすぐに一貫性を保つことを意図しているのでしょうか?

しかし、この場合、関連するインデックスはありません (フィルター処理や並べ替えはありません) Query()。

現在のプロジェクトで noSQL ソリューションを検討していますが、これらのデータベースの多くにある「結果整合性」条項については躊躇しています。結果整合性は、レプリケーションが遅れる mySQL データベースを扱う場合とは異なりますか? 過去に遅延レプリケーションで使用した 1 つの解決策は、データの一貫性がすぐに必要な場合にマスターから読み取ることです。

しかし、リレーショナル データベースが強力なデータ整合性を主張する理由について、私は混乱しています。トランザクションを使用する必要があると思います。これにより、強い一貫性が得られます。では、mySQL のレプリケーションが遅れる可能性があると想定してアプリケーションを作成することは良い方法でしょうか?

データ ストア エントリの作成時にクライアントの再試行を処理するための戦略を考え出す必要があります。

• クライアントは、データベースに新しいエントリを作成する要求を送信します
• サーバーはエントリの作成を実行し、成功応答を準備します
• リクエストが処理されなかったとクライアントに信じ込ませる何らかのエラーが発生します (パケット損失など)。
• クライアントは、データベースに新しいエントリを作成するために同じ要求を再度送信します
• サーバーは再試行を検出し、別のデータストア エントリを作成せずに元の応答を再作成して送信します
• クライアントが返信を受け取る
• 誰もが満足し、データベースには 1 つのエントリしか作成されませんでした

制限が 1 つあります。サーバーはステートレスです。クライアントにセッション情報はありません。

私の現在の考えは次のとおりです。

• すべての create-request に、保証されたグローバルに一意の ID をタグ付けします (質問にはあまり関係ありませんが、作成方法は次のとおりです)。
  • データ ストア (および memcache) を使用して、サーバー インスタンスが読み込まれると、単調に増加する一意の ID をすべてのサーバー インスタンスに割り当てます (これをSIと呼びましょう) 。
  • クライアントが開始ページを要求すると、要求を処理したインスタンスは、単調に増加する一意のページ ロード ID ( PL ) を生成し、 SI.PLをページ コンテンツと共にクライアントに送信します。
  • create-request ごとに、クライアントは単調に増加する一意の request-id ( RI ) を生成し、create-request とともにSI.PL.RIを送信します。
• create-request ごとに、サーバーは最初に create-tag を認識しているかどうかを確認します。
• そうでない場合は、新しいエントリを作成し、何らかの形で create-tag を一緒に保存します。
• タグがわかっている場合は、それを使用して最初に作成されたエントリを見つけ、対応する応答を再作成します。

現在考えている実装オプションとその問題点は次のとおりです。

1. create-tag をエントリ内のインデックス付きプロパティとして保存します。
   • サーバーがリクエストを受け取ると、クエリを使用して既存のエントリを見つける必要があります
   • 問題: AppEngine のクエリは結果整合性しかないため、エントリを見逃す可能性があります
2. create-tag をエントリのキーとして使用します。
   • 数値がラップされない場合は一意であることが保証されているため、問題ありません (long の場合はそうではありません)。
   • マイナーな不便: 将来の使用でエントリのキーの長さが増加します (不要なオーバーヘッド)。
   • 重大な問題: これにより、データストアに連続したエントリ キーが生成されます。これは、格納されたデータにホット スポットが作成され、パフォーマンスに大きな影響を与える可能性があるため、絶対に回避する必要があります。

オプション 2 について私が考えている解決策の 1 つは、ホットスポットを排除する代わりに、連番を取得し、それらを一意で決定論的だがランダムに見えるシーケンスに再マッピングする何らかの式を使用することです。そのような式がどのように見えるかについてのアイデアはありますか?

それとも、全体的により良いアプローチがありますか？