1

次のケースは、Cassandra では論理的に正しいかもしれませんが、ユーザーにとっては難しいものです。まあ言ってみれば:

Cassandra 整合性レベル: すべて書き込み、1 つ読み取り replication_factor:3

1 レコードの場合、rowkey:001、column:status

  1. クライアント 1、行キー 001 の挿入値、ステータス:True、タイムスタンプ 11:00:05
  2. クライアント 2 スライス クエリ、行キー 001 の値 True を取得、@11:00:00
  3. クライアント 2、行キー 001 の更新値、ステータス:False、タイムスタンプ 11:00:02

したがって、クライアントの更新シーケンスは True から False になりますが、更新要求は異なるノードからのものですが、シーケンスは論理的に順序付けられています。

しかし、結果は rowkey:001, column:status, value: Trueです

では、なぜ Cassandra はクライアントの現地時間に依存するのでしょうか? クライアントのローカル時間の代わりにサーバーのローカル時間を使用しないのはなぜですか?

一貫性レベル write all と replication_factor:3 を使用しているため、3 つのノードすべてで更新シーケンスが正しく (True -> False)、正しい最終結果が得られます。

何らかの理由で、操作のタイムスタンプに強く依存する必要があり、クエリ操作にもタイムスタンプが必要な場合、クライアント 2 は値 True を認識しません。これは「将来」に発生します。

したがって、サーバーのタイムスタンプを使用するか、クエリにタイムスタンプを要求するか (つまり、データが「未来」にあるため、2 番目のステップのクエリでは結果が表示されません)、より一貫性が高くなります。

それ以外の場合、Cassandra の一貫性は非常に弱く、R + W > N ですらあります。

4

2 に答える 2

4

簡単に言えば、CQL は実際にはデフォルトでサーバー提供のタイムスタンプを使用するということです。

より長い回答として、 http: //www.datastax.com/dev/blog/why-cassandra-doesnt-need-vector-clocks で、競合解決におけるタイムスタンプの役割に関する投稿を書きました。

于 2013-10-09T21:23:15.350 に答える
0

CQL はサーバー側のタイムスタンプを使用しますが、従来の Thrift インターフェイスはクライアントのタイムスタンプを使用します。

すべての応答は書き込み後に互いに一貫性があるため、説明する内容は一貫性の問題ではないことに注意してください。因果律違反だけど。サーバー側のタイムスタンプを使用しても、同じ列への同時書き込みで問題が発生する場合があります。

いくつかの問題についての議論はこちら: http://aphyr.com/posts/294-call-me-maybe-cassandra

于 2013-10-08T10:02:18.927 に答える