cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Telford <>
Subject Re: Facebook messaging and choice of HBase over Cassandra - what can we learn?
Date Mon, 22 Nov 2010 13:03:31 GMT
Provided at least one node receives the write, it will eventually be written
to all replicas. A failure to meet the requested ConsistencyLevel is just
that; not a failure to write the data itself. Once the write is received by
a node, it will eventually reach all replicas, there is no roll back.

This is the source of a fair bit of confusion, as most people are used to
the binary behaviour of "success or failure". It's important that clients
are able to distinguish between a failure for a write to reach the cluster
and a failure to meet the requested ConsistencyLevel in order to provide
Durability guarantees for application data.

On 22 November 2010 12:31, David Boxenhorn <> wrote:

> Yes, but the value is supposed to be 11, since the write failed.
> On Mon, Nov 22, 2010 at 2:27 PM, André Fiedler <
>> wrote:
>> Doesn´t sync Cassandra all nodes if the network is up again? I think this
>> was one of the reasons, storing a timestamp at every key/value pair?
>> So i think the response will only temporary be 11. If all nodes have synct
>> it should be 12? Or isn´t that so?
>> greetings André
>> 2010/11/22 Samuel Carrière <>
>> >Cassandra can work in a consistent way, see some of this discussion and
>>> the Consistency section here
>>> >
>>> >If you always read and write with CL.Quorum (or the other way discussed)
>>> you will have consistency. Even if some of the replicas are temporarily
>>> inconsistent, or off line or whatever. Your reads will >be consistent, i.e.
>>> every client will get the same value or the read will not work. If you want
>>> to work at a lower or higher consistency you can.
>>> >
>>> >Eventually all replicas of a value will become consistent.
>>> >
>>> >There are a number of reasons why cassandra may not be a good fit, and I
>>> would guess something else would be a problem before the consistency model.
>>> >
>>> >Hope that helps.
>>> >Aaron
>>> Hello,
>>> I like cassandra a lot and I'm sure it can be used in many use cases,
>>> but I'm not sure we can say that we have strong consistency,
>>> even if we read and write with CL.Quorum.
>>> Firstly, we can only expect consistency at the column level. Reading
>>> and writing with CL.Quorum gives you most of the time
>>> a consistent value for each individual column, but it does not mean if
>>> gives you a consistent view of your data.
>>> (Because cassandra gives you no isolation and no transactions, your
>>> application has to deal with data inconsistencies).
>>> Secondly, I may be wrong, but I'm not sure consistency at the column
>>> level is guaranteed. Here is an example, with a replication
>>> factor of 3.
>>> Imagine that the current value of col1 is 11. Your application tries
>>> to write "col1 = 12" with CL.Quorum.
>>> Imagine the write arrives to node 1, but that the new value is not
>>> transmitted to nodes 2 and 3 because of network failures. So
>>> the write fails (this is the expected behaviour), but node 1 still has
>>> the new value (there is no rollback).
>>> Then, imagine that the network is back to normal, and that another
>>> client asked for the value of col1, with CL.Quorum. Here,
>>> the value of the response is not guaranteed. If the client asks for
>>> the value to node 2 and node 3, the response will be 11, but
>>> if he asks to node 1 and node 2 or 3, the response will be 12.
>>> Am I missing something ?
>>> Samuel

View raw message