But, the reason that it isn't safe to say that we are a strongly consistent store is that if 2 of your 3 replicas were to die and come back with no data, QUORUM might return the wrong result.
A requirement of a strongly consistent store is that replicas cannot begin answering queries until they are consistent: this is not a requirement in Cassandra, althought arguably should be an option at some point in the distant future. On Thu, Feb 17, 2011 at 5:26 PM, Aaron Morton <aa...@thelastpickle.com>wrote: > For background... > > http://wiki.apache.org/cassandra/ArchitectureOverview > (There is a section on consistency in there) > > For deep background... > http://www.allthingsdistributed.com/2008/12/eventually_consistent.html > > http://s3.amazonaws.com/AllThingsDistributed/sosp/amazon-dynamo-sosp2007.pdf > > In short, yes (for all your questions) if you read and write at Quorum you > have consistency behavior for your operations. Even though some nodes > may have an inconsistent view of the data, e.g. one node is partitioned by > a broken network or is overloaded and does not respond. > > Aaron > > On 18 Feb, 2011,at 02:11 PM, mcasandra <mohitanch...@gmail.com> wrote: > > > Why is Cassandra called eventually consistent data store? Wouldn't it be > consistent if QUORAM is used? > > Another question is when I specify replication factor of 3 and write with > factor of 2 and read with factor of 2 then what happens? > > 1. When write occurs cassandra will return to the client only when the > writes go to commit log on 2 nodes successfully? > > 2. When read happens cassandra will return only when it is able to read > from > 2 nodes and determine that it has consistent copy? > -- > View this message in context: > http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Understand-eventually-consistent-tp6038330p6038330.html > Sent from the cassandra-u...@incubator.apache.org mailing list archive at > Nabble.com. > >
