I searched for an explanation on how Couchbase achieves strong consistency inside a cluster. Is all of this as a result of using membase?
-
What do you mean by "strong consistency"? – Ari Apr 03 '13 at 15:44
-
I mean immediately consistent in case of a write. In this official Riak comparison it sais it's fully consistent http://docs.basho.com/riak/1.2.1/references/appendices/comparisons/Riak-Compared-to-Couchbase/ – ftraian Apr 03 '13 at 16:03
3 Answers
Couchbase IS membase btw. Couchbase is a product and a company, the company is a merge of NorthScale (Membase) and the CouchDB founders, and the resulting name for both company and product was Couchbase.
Update operations (replace and [forced] set) update RAM cache first, and subsequent reads are the new value, this is the consistency model.
Couchbase is an "eventually persisted" (EP) architecture, where CRUD operations update RAM cache first and are inserted into the EP queue for disk i/o. At the same time, when replicas are configured, they go into replica queues and are transferred to the other nodes. The EP architecture is what allows for immediate consistency and super high throughput as disk i/o is the slowest component of all systems.
As WiredPrairie mentioned, a single node is responsible/active for a given key. The key is hashed and the result of the hash is a particular partition it should live in. The partition->couchbase-node map, which the sdk's maintain, allows them to go directly to the active node for each partition. Again, this reduces latency because it doesn't have to go through a load balancer, (it's load balanced by the architecture itself), nor does it go through a "master" node, each node is a master, nor does it go through a "shard master" whose job is to redirect clients to a particular shard. By bypassing all those, latency is reduced to a minimum.

- 1,273
- 6
- 7
-
How can you call something "eventually persisted" if there's a potential data loss? Also views are eventually consistent and not immediate. – Yosi Dahari Aug 19 '16 at 08:37
Couchbase guarantees strong consistency by enforcing that all reads for a particular piece of data go to a single node in a cluster. You cannot read from a replica. If you could, you might end up with inconsistent data.
When using the 2.0 XDCR, Couchbase provides only eventual consistency.
I wouldn't say it's a "result" of anything other than a specific design requirement they had for their software.
There's some additional information in this blog post.

- 58,954
- 17
- 116
- 143
I don't think it is strong consistency, since if one node with active vbucket reboot, data has not been replicated or not persisted yet, it will lose the data ; strong consistency need W+R>N, and R=1 here, so we need W=N which means all replicas should be ACID; we could call it fake strong consistency

- 109
- 8