問題タブ [eventual-consistency]

私は、GAEデータストアでの偶発性の一貫性と毎秒1書き込みの原則に頭を悩ませようとしています。シナリオと 2 つの質問があります。

質問:

1. 1 秒以内に同じ EntityGroup に 2 つの書き込み (user.put と comment.put) を行ったため、ここで例外が発生しますか? それを回避する簡単な方法はありますか？
2. parent=user(user_id) を削除すると、2 つのエンティティは同じ EntityGroup に属しなくなります。関数から返されたコメントのリストに、最後に追加されたコメントが含まれていない可能性があるということですか?
3. 私は本質的に間違ったことをしていますか？

エンティティ参照部分が間違っていることはわかっています。質問には関係ありません（または関係ありますか？）

次のシナリオがあります。

• 約 7000 万の機器が 3 ～ 5 分ごとにサーバーに信号を送信し、ID、ステータス (オンラインまたはオフライン)、IP、場所 (緯度と経度)、親ノード、およびその他の情報を送信します。

• 他の情報は標準形式ではない可能性があります (したがって、スキーマはありません) が、クエリを実行する必要があります。

• 機器は、その過程で信号を送信せずに、しばらくの間 (または永久に) 消える可能性があります。したがって、機器が過去 X 日間信号を送信していない場合、その機器を「忘れる」方法が必要です。また、新しい機器がいつでもオンラインになる可能性があります。

• このすべてのデータを照会する必要があります。特定の地域または IP 範囲でオフラインになっている機器の数を知ることと同様です。同時に実行されるクエリは多くありません。

• 一部のクエリは、データベースの更新と同時に高速 (クエリあたり 3 分未満) で実行する必要があります。そのため、主要な属性 (id、ステータス、IP、場所、および親ノード) のインデックスが必要です。クエリ結果は 100% 正確である必要はありません。クエリ結果に表示されるまでに時間がかかりすぎない限り (平均で 20 分以上)、結果整合性は問題ありません。

• しつこさは全くいらない、力が抜けたら全部失ってもいい。

これらすべてを考慮して、MapReduceとJavascriptの経験があるため、おそらくMongoDBまたはCouchDBのnoSQLアプローチを使用することを考えましたが、どちらが自分の問題に適しているかわかりません(私はCouchDBに引き寄せられています)、またはそれらがまったく適しているかどうかはわかりませんこの膨大なワークロードを処理するために。ディスクへの永続性は必要ないので、実際に「従来の」データベースが必要かどうかさえわかりませんが (メイン メモリのアプローチの方がよいのではないでしょうか?)、カスタム クエリを簡単に作成する方法が必要です。

私が検出した主な問題は次のとおりです。

• 大量のタプルを非常に高速に挿入/更新する必要があり、受信したシグナルが既にデータベースにあるかどうかを事前に知りません。ほとんどすべてのシグナルは前回と同じ状態になるので、id でクエリを実行して、タプルが更新された場合は何もしないかどうかを確認しますか?

• オフライン機器を忘れる。期限切れのタプルを削除する夜間に実行されるバッチ ジョブは、この問題を解決します。

• 同時に実行されるクエリは多くありませんが、高速に実行する必要があります。したがって、クラスターの複数のノードで単一のクエリを実行するクラスターが必要だと思います (CouchDB MapReduce はワークロードをクラスターの複数のノードに分割しますか?)。クラスターが必要かどうかはよくわかりませんが、より高価な 1 台のマシンですべての負荷を処理できますか?

• これまで noSQL システムを使用したことはありませんが、このテーマに関する理論的な知識は持っています。

CloudSearch の結果は最終的に一貫性があるだけです。

私のアプリケーションの 95% では、これが提供するパフォーマンスと冗長性のトレードオフとして許容できます。

ただし、最後の 5% では、新しい SDF ドキュメントを POST し、すぐに実行した POST を反映する必要があるクエリを実行していることに気付きました。

現在、POST の直後に結果が期待どおりになるまで CloudSearch をポーリングすることを含む、石畳のソリューションがあります。残念ながら、これには、余分な読み取りを行うことに関連するコスト ($) の増加から、複数のユーザーがいる場合の競合状態まで、さまざまな問題があります。

この状況に対処するためのベストプラクティスはありますか?

AWS フォーラムからの xpost: https://forums.aws.amazon.com/thread.jspa?messageID=470636⹬

編集:私の特定のユースケースに関する追加情報。

多数のブールクエリを使用して検索の結果を取得しています。クエリに表示されないように 1 つ以上のドキュメントを更新し、ビューを更新して結果を表示できるようにしたいと考えています。 .

具体的には、ブール値が「アーカイブ済み」としてマークされたドキュメントがたくさんあります

アーカイブされていないビューでそれらを見ているときに、それらをアーカイブ済みとしてマークすると、それらのアイテムを表示せずにビューを更新できるようにしたいと考えています。

また、ソート/フィルタリング/ページングに CloudSearch を使用しているため、ローカル コピーの挿入や変更が困難です

最終的に一貫性のあるデータベースに多数のエントリが格納されている場合、変更されたエントリを確実に見つけるための標準的な方法はありますか? もちろん、それらは「最終的に」しか見つかりませんが、それは問題ありませんが、決して見つからない可能性のあるシナリオは避けたいと思います。

これは非常に一般的な問題のように思われるため、標準的な処理方法がいくつかあると思います。しかし、残念なことに、私はそれについて有用なものを見つけるのにかなり苦労しています.

私が考えているアプローチは、単調に増加するバージョン番号 (タイムスタンプなど) ですべてのエントリにタグを付け、これまでに見た中で最も高いバージョン番号よりも大きいバージョン番号を持つすべてのエントリをデータベースに問い合わせることです。これに関する問題は、エントリが順不同でコミットされる (したがって、クエリで返される) 可能性があることです。したがって、後の更新が特定のクエリに「成功」​​し、以前の更新がそうでない場合、次のクエリでこれまでに見た最高のバージョン番号として後の更新のバージョン番号を使用することはできません。以前の更新が見つかりません。

バージョン番号が常に連続的に増加し、バージョンがスキップされないことが保証されている場合 (私の場合はこれを実現するのは困難ですが、実行可能である可能性があります)、変更ごとに 1 つのエントリを含む変更ログを保持し、クエリを実行するだけで済みます。 「x、y、z、... を除くすべてのバージョンを教えてください」。しかし、この変更ログと関連するクエリは巨大になる可能性があるため (一貫性を想定できる時間スケールに対する変更の速度によって異なります)、これは良い選択肢ではないと思います。

何かご意見は？

私はちょうど卒業論文を書いているところです。したがって、私は理論の最終的な一貫性と、Cassandra がこの理論をどのように適用するかに関心があります。私の問題を理解するには、次の一貫性の定義を考慮してください（私が理解している限り）：

• 因果の一貫性:

  因果関係がある可能性のあるメモリ操作がシステムのすべてのノードで同じ順序で見られる場合、システムは因果的一貫性を提供します。(ウィキペディア)

  したがって、プロセス A がデータ X を DB に書き込み、その後プロセス B がこのデータ X を読み取り、これを Y で上書きする場合、すべてのレプリカ (それぞれのノード) で A の後に B が X を取得すると、因果的一貫性が保証されると言います。 ）。

• 読み取りと書き込みの一貫性:

  これは、因果的一貫性の特殊なケースです。これにより、読み取りと書き込みは同じプロセス A で処理されます。このタイプの一貫性により、変更後に A が古いデータ オブジェクトを持つことはありません。

• セッションの一貫性:

  この場合、プロセス A はセッションで DB にアクセスします。このセッションが存在する限り、システムは読み取りと書き込みの一貫性を保証します

• 単調読み取りの一貫性:

  プロセスが読み取り後に特定のデータ オブジェクトを取得する場合、システムは、後続のすべての読み取りアクセスのプロセスが古いデータ オブジェクトを取得しないことを保証します。

• 単調な書き込みの一貫性:

  この場合、DB への書き込みオプションはシリアル化されます。これにより、書き込みオプションの順序によって、どのプロセスが最初に書き込みを行うかが決まります。

  これで、理論上、一部または 1 つが NoSQL システムに実装されている一貫性オプションがいくつかあります。しかし、私が何か間違ったことを理解した場合は、私を修正してください。

私の質問は、CASSANDRA が提供する一貫性の種類はどれですか? そして、これらの一貫性はルール「R+W>N」それぞれ「R+W<=N」にどのように関連していますか?

ほとんどの nosql ソリューションは結果整合性のみを使用します。DynamoDB がデータを 3 つのデータセンターにレプリケートする場合、書き込み後の整合性はどのように維持されるのでしょうか?

この種の問題に対する一般的なアプローチは何でしょうか? MySQLでもレプリケーションデータは非同期でレプリケートされるので面白いと思います。