Hacker News Reader

Comment by jmix | Hacker News Reader

False -- if there are nodes being added or deleted from the system, Cassandra provides no guarantee of consistency. Two nodes might disagree on quorum membership and thus quorum accesses may fail to overlap, leading to inconsistency.

The consistency claims are overblown.

View on HN

Cassandra uses a technique known as consistent hashing to allow each node to independently determine what nodes are replicas for a given row. The process really just involves hashing the row key and then comparing the result to the token of each node in the cluster. If the hash falls in between a node's token and the token of the previous node in the ring, then that node is a replica for that row. There's not really any way that nodes can disagree on this.

Given that nodes cannot disagree on the set of replicas for a row, quorums must (by definition, and the pigeon hole principal) overlap by at least one replica.

Imagine two nodes, both initiating updates to the same row. One has observed a number of node additions and deletions. The other has not. They will perform their updates on disjoint sets.

> There's not really any way that nodes can disagree on this.

Atomic, dynamic updates to a ring are a difficult thing to do. If I'm missing some additional mechanism that ensures agreement on ring membership, please explain.

Please enlighten us with a cluster database that enables guaranteed consistency with dynamic node membership. They all have quirks handling membership (unless you're looking at a shared disk setup).

Checkout HyperDex. We just released a new version, and it is indeed consistent as nodes join and fail.

It's all about the tradeoffs you are taking. Cassandra favors availability over consistency. For many workloads that is desired for others it is not.

HBase for example is always consistent, but if you lose a node unexpectedly some data is not available for some time.

HBase.

Reply on news.ycombinator.com