2010/4/22 Даниел Симеонов <dsimeo...@gmail.com>: > Hi Paul, > Thank you for your answer, about the first question, I wondered if it is > possible to workaround this issue but relaxing some consistency, as I > understand you it should be possible to implement this compareAndSet > operation with the presence of vector clocks, then the client is going to > reconcile the data.
I believe that the proposed implementation of vector clocks in Cassandra allows the servers to do the reconciliation through "plugins". So you'd do a "compareAndSet" "plugin", or Cassandra might ship with one out of the box (there are several obvious ones that should probably be right in the box). > Regarding the second question I understood that without again the vector > clocks and client reconciliation then there is this causality problem > currently in Cassandra. In general, Cassandra 0.6 has little protection against overlapping and conflicting writes. > About the third question, isn't it the same as if the writes and reads both > use QUORUMs? I think that you can use Consistency.ALL on write, and Consistency.ONE on read, to optimize for read-speed, and the opposite to optimize for write speed. > What about implementation of counters, currently it seems it is not > implementable in 'Cassandra', will the vector clocks help here? Do you have > experiences with counters in Cassandra? Counters are the "classic" example of why you need vector clocks. The description for CASSANDRA-580 is "Allow a ColumnFamily to be versioned via vector clocks, instead of long timestamps. Purpose: enable incr/decr; flexible conflict resolution." https://issues.apache.org/jira/browse/CASSANDRA-580 Paul Prescod
