Related question: Is it a good idea to specify ConsistencyLevels on a per-operation basis? For example: Read ONE Write ALL would deliver consistent read results, just like Read ALL Write ONE. However, if you specify Read ONE Write QUORUM you cannot give such guarantees anymore. Should there be (is there) a programming abstraction on top of ConsistencyLevel that takes care of these things and makes them explicit to the application developer?
On Fri, Feb 18, 2011 at 2:04 PM, Anthony John <chirayit...@gmail.com> wrote: > At Quorum - if 2 of 3 nodes are down, a read should not be returned, right ? > But yes - if single node READs are opted for, it will go through. > The original question was - "Why is Cassandra called eventually consistent > data store?" > Because at write time, there is not a guarantee that all replicas are > consistent. But they eventually will be! > At Quorum write and Read - you will not get inconsistent results and your > read will force consistency, if such a state has not yet been arrived at for > the particular piece of data. > But you have the option of or writing and reading at a lower standard, which > could result in inconsistencies. > HTH, > -JA > On Fri, Feb 18, 2011 at 12:00 AM, Stu Hood <stuh...@gmail.com> wrote: >> >> 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. >> > >
