Meaning of eventual consistency in Cassandra?

What is the meaning of eventual consistency in Cassandra when nodes in a single cluster do not contain the copies of开发者_StackOverflow中文版 same data but data is distributed among nodes. Now since a single peice of data is recorded at a single place (node). Why wouldn't Cassandra return the recent value from that single place of record? How do multiple copies arise in this situation?

Cassandra's consistency is tunable. What can be tuned?
* Number of nodes needed to agree on the data for reads.. call it R * Number of nodes needed to agree on the data for writes.. call it W
In case of 3 nodes, if we chose 2R and 2W.. then during a read, if 2 nodes agree on a value, that is the true value. The 3rd may or may not have the same value.
In case of write, if 2W is chosen, then if data is written to 2 nodes, it is considered enough. This model IS consistent.
If R + w <= N where N is number of nodes, it will be eventually consistent.
Cassandra maintains a timestamp with each column and each field of column to eventually become consistent. There is a mechanism in background to reach a consistent state.
But like I said, if R + W > N, then it is consistent solid. That is why consistency is considered tunable in Cassandra.

Its up to the client to decide the appropriate consistency level (zero, any, one, quoram or all). (The consistency level controls both read and write behavior based on your replicationfactor.) In a single node cluster the consistency levels any, one, quorom and all are equivalent.

Even with replication factor = 1, consistency is not necessarily immediate because writes are buffered on the node that you send them to and hence don't necessarily immediately get sent to the node responsible for that key.

But it depends on what consistency level you choose.

Mostly the use-case for Cassandra is with replication factor > 1, which is where consistency becomes more of an issue. RF=3 seems to be a common setting (as it allows Quorum reads/writes with one node unavailable)

Here is a nice explain about eventually consistent: http://www.allthingsdistributed.com/2008/12/eventually_consistent.html

Cassandra tends to compromise latency and consistency for availability. It’s “eventually consistent,” a model for NoSQL database consistency that’s used with distributed setups. Rather than maintain strict consistency that could really slow things down at scale, eventual consistency enables high availability—just at the cost of every instance of your data not being synced up across all servers right away.