Hacker News Reader

Comment by _benedict | Hacker News Reader

No, you wrote that you have to write and wait several minutes for data to replicate. This is straight-up false.

Yes, if you mix consistency levels incorrectly you will do it wrong and maybe get stale data, but that is a different criticism. I agree that it is easy for unsophisticated users to incorrectly use consistency levels in complex topologies, and I hope we will introduce mechanisms to prevent users making such mistakes in future. But that was not your claim, and in my experience users do understand consistency levels just fine.

There are lots of valid criticisms to point at various use cases with Cassandra, but this was just incorrect.

View on HN

it’s worse than waiting actually. Because client A might write value « 1 » and after client B write value « 2 ». Then client C can read Value 2 for 5 minute and then cassandra internal read-repair eventually put value 1 on all replica and value 2 is lost forever.

No, that is literally impossible.

If value 2 is newer than value 1, value 1 will never overwrite value 2. If a client reads value 2 at QUORUM then it will always be seen by all future queries.

Client À write value 1 on 2 of 3 node with timestamp=3

then later client B write value 2 on 2 of the 3 node with timestamp=1

then read repair happen and (value=1 timestamp=3) is written to all 3 nodes.

this is only one of many scenarios where this stupid design fail.

Client B’s write will only be successfully read from 1 of the nodes it wrote to, and read-repair only runs on QUORUM reads. So, no, it will not be possible to read value 2 for 5m - it will never be visible to operations at QUORUM.

This would have been a valid criticism of LWW (and there are other more contrived examples), but I think (or hope) this is an explicit trade off made by anyone using Cassandra in eventual consistency mode. There are strategies to prevent this being a problem for workloads where it matters, some discussed elsewhere in the thread.

Since "client B write" was successfully written on 2 of the 3 nodes. Any read request that read only from 2 of the 3 nodes instead of using quorum read, will be able to see what Client B wrote until it magically disappears.

Quorum Read-repair is only one reason for why the value would randomly disappear. Another one is periodic anti Entropy repair!

No, it won’t. Successfully written does not mean what you think it means. If there is “newer” (by timestamp) data on disk or in memtable then it will not be returned to a client, regardless of which order that data arrived. It is unlikely even to be written to disk (except the commit log).

Since at least one of those nodes has the “newer” value, only one node can serve this “older” value

Reply on news.ycombinator.com