Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cassandra is not row level consistent

datanerds.io

Post reply on HN
Print view View original

81–90 of 126 posts

Re: Cassandra is not row level consistent

#81

Post by joncrocks »

lucian1900 wrote: post #75
siculars wrote: post #30

Earlier quoted context omitted.

Seconded. Don't use an AP system for distributed lock management. As with most things, use the right tool for the right job. When I speak to developers about Riak I tell them the biggest difference between systems like Riak (including Cassandra) and traditional relational systems is not the data model, ie. relational vs non-relations (or structured vs unstructured) but rather the architecture, ie. distributed vs not…

Minor nitpick: distributed systems can be consistent too. Your comment implies all distributed systems choose availability over consistency.

While they don't all pick one over another, there are limitations on how available and consistent you can make systems, for the same level of partition tolerance - https://en.wikipedia.org/wiki/CAP_theorem

Re: Cassandra is not row level consistent

#82

Post by pkolaczk »

joncrocks wrote: post #81
lucian1900 wrote: post #75

Earlier quoted context omitted.

Minor nitpick: distributed systems can be consistent too. Your comment implies all distributed systems choose availability over consistency.

While they don't all pick one over another, there are limitations on how available and consistent you can make systems, for the same level of partition tolerance - https://en.wikipedia.org/wiki/CAP_theorem

While technically you're right, the CAP theorem uses a very strict definition of availability, which is often not needed to consider the system available in real-life. Also the consistency in CAP theorem is defined as linearizability, and this is just one of very many kinds of consistency. Often the systems are ok with weaker types of consistency.

Therefore, I'd really like that everyone stopped labeling distributed databases as AP or CP, because this is an oversimplification and most of the time, just plain wrong.

Re: Cassandra is not row level consistent

#83

Post by pkolaczk »

convolvatron wrote: post #21
helper wrote: post #6

As a long time Cassandra user its easy to forget that some of Cassandra's semantics will be surprising to new users. That being said, if you are considering adopting an AP database it really is important for you to know the details about how write conflicts get resolved. This is perhaps the biggest difference between Cassandra other databases like Riak and ought to be part of your decision making process instead of a…

cassandra never claimed to be a consistent distributed database. its really quite sad that someone had to find that out the hard way.

It is optionally consistent if you know how to use it and you know its limitations. Their use of Cassandra was obviously wrong. Mixing LWT and non-LWT is like having only half of your shared data protected by mutexes - this isn't going to work correctly.

Re: Cassandra is not row level consistent

#84

Post by pkolaczk »

chungtg wrote: post #13
helper wrote: post #6

As a long time Cassandra user its easy to forget that some of Cassandra's semantics will be surprising to new users. That being said, if you are considering adopting an AP database it really is important for you to know the details about how write conflicts get resolved. This is perhaps the biggest difference between Cassandra other databases like Riak and ought to be part of your decision making process instead of a…

Datastax seems to think that it is a good idea: http://www.datastax.com/dev/blog/consensus-on-cassandra

Details matter. All updates in the Datastax post are protected by LWT. That code is correct. The OP's code was wrong, because he was mixing non-LWT updates.

Re: Cassandra is not row level consistent

#85

Post by pkolaczk »

vesak wrote: post #62
sigy wrote: post #9

Earlier quoted context omitted.

Some details besides ad-hominem might actually be helpful. When you make statements like this it just looks like trolling.

Cassandra is not a person, so that was not ad hominem.

Technically, Cassandra was a person in Greek mythology. So still ad hominem.

Re: Cassandra is not row level consistent

#86

Post by pkolaczk »

webmaven wrote: post #70
jbellis wrote: post #59

Cassandra developer here. Lots of comments here about how Cassandra is AP so of course you get inconsistent (non-serializable) results. This is true, to a point. I'm firmly convinced that AP is a better way to build distributed systems for fault tolerance, performance, and simplicity. But it's incredibly useful to be able to "opt in" to CP for pieces of the application as needed. That's what Cassandra's lightweight t…

So, since their use of UPDATE is problematic, what is the correct way to release the locks?

DELETE ... IF EXISTS

DELETE ... IF

UPDATE ... IF

Re: Cassandra is not row level consistent

#87

Post by isoap »

jbellis wrote: post #59

Cassandra developer here. Lots of comments here about how Cassandra is AP so of course you get inconsistent (non-serializable) results. This is true, to a point. I'm firmly convinced that AP is a better way to build distributed systems for fault tolerance, performance, and simplicity. But it's incredibly useful to be able to "opt in" to CP for pieces of the application as needed. That's what Cassandra's lightweight t…

> Don't take shortcuts and you won't get burned.

I'm sorry that the user did something unexpected and then posted about it in a way that made your application look bad. I know that must be frustrating. However...

Calling the user out as doing something wrong when your application is failing because of a use case you can't handle properly just looks bad. You serve your users, not the other way around. Don't forget that.

If it were me and there were a case that my application couldn't handle properly, if I couldn't fix it, I'd raise an error, and then document clearly that they should not do this, such that when they search for that error, they'd find the answer. Then, I'd work to see if there were a way I could avoid the error altogether by not allowing that use case.

Re: Cassandra is not row level consistent

#88

Post by pkolaczk »

mdani wrote: post #53
crypto5 wrote: post #37

Earlier quoted context omitted.

I think you can make Cassandra "C" by using quorum reads and writes. Also they support some SERIAL consistency level, which uses PAXOS underneath, and supposedly achieves consistency as well.

The IF statement uses Paxos as underlying implementation and still it may result into an inconsistency if you are using two separate CQL statements. Cassandra does not provide begin ... end construction where everything is atomically committed or rolled back.

You can use Cassandra LWT as a building block for multi-partition transactions, in a similar way like CAS atomic operations are used to build locks, mutexes and monitors and then monitors are used to implement ACID transactions in RDBMS. However, noone says it would be easy or performant, therefore this is probably not a good idea.

Re: Cassandra is not row level consistent

#89

Post by PDoyle »

MrBuddyCasino wrote: post #68
helper wrote: post #6

As a long time Cassandra user its easy to forget that some of Cassandra's semantics will be surprising to new users. That being said, if you are considering adopting an AP database it really is important for you to know the details about how write conflicts get resolved. This is perhaps the biggest difference between Cassandra other databases like Riak and ought to be part of your decision making process instead of a…

> I can't think of any way in which Cassandra would be better than using {Zookeeper,etcd,consul} This is the correct answer. Zookeeper & Curator make it nearly foolproof to implement a distributed lock correctly, whereas with Cassandra, its the other way round.

> Zookeeper & Curator make it nearly foolproof to implement a distributed lock correctly, whereas with Cassandra, its the other way round.

Cassandra makes it nearly distributed to implement a foolproof lock correctly?

Re: Cassandra is not row level consistent

#90

Post by pkolaczk »

im_down_w_otp wrote: post #44
crypto5 wrote: post #37

Earlier quoted context omitted.

I think you can make Cassandra "C" by using quorum reads and writes. Also they support some SERIAL consistency level, which uses PAXOS underneath, and supposedly achieves consistency as well.

Quorum won't solve consistency problems like this unless you can also guarantee a serialized reader/writer for any given piece of data. The best you can do by pinning queries to primary replicas and enforcing R + W > N is RYOW consistency, and that depends on the aforementioned serialization point.

Quorum reads + writes and applying non-destructive updates only are enough to get linearizabile consistency in Cassandra, even if clocks are not perfectly synchronized.
Post reply on HN