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

41–50 of 126 posts

Re: Cassandra is not row level consistent

#41

Post by chillaxtian »

Animats wrote: post #39

This: INSERT INTO locks (id, lock, revision) VALUES ('Tom', true, 1) IF NOT EXISTS USING TTL 20; looks like a race condition. The same problem comes up in SQL databases - you can't lock a row that doesn't exist yet. If you write, in SQL: BEGIN TRANSACTION SELECT FROM locks WHERE id = "Tom" AND lock = true AND revision = 1; -- if no records returned INSERT INTO LOCKS locks (id, lock, revision) VALUES ('Tom', true, 1)…

this is not a race in cassandra.

IF NOT EXISTS causes replicas to agree on the result using PAXOS, and only responds with success if a certain number of replicas concur + write the transaction to disk.

i believe it is a quorum for SERIAL consistency level, and local quorum (quorum of replicas in the local DC) for LOCAL_SERIAL.

Re: Cassandra is not row level consistent

#44

Post by im_down_w_otp »

crypto5 wrote: post #37
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…

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.

Re: Cassandra is not row level consistent

#46

Post by aartur »

And there's another surprise waiting to be discovered. The execution of a LWT is not guaranteed to return applied/not-applied response [1]. It can raise a WriteTimeout exception that means "I don't know if applied". It looks like in that case it can be worked around by inserting a UUID and in case of a WriteTimeout reading the UUID using SERIAL consistency and checking if it's the inserted UUID. But generally this limitation of LWTs makes implementing some algorithms impossible, e.g. you can't implement a 100% reliable counter.

[1] https://issues.apache.org/jira/browse/CASSANDRA-9328

Re: Cassandra is not row level consistent

#48

Post by late2part »

chillaxtian wrote: post #42
late2part wrote: post #38

Earlier quoted context omitted.

To be fair, it's easy to suck at Cassandra and most folks that use it used to suck at it.

agreed, cassandra is sharp edges all around.

If you or anyone else enjoys it - ping me via email, I might have a cool job for you.

Re: Cassandra is not row level consistent

#49

Post by angersock »

late2part wrote: post #48
chillaxtian wrote: post #42

Earlier quoted context omitted.

agreed, cassandra is sharp edges all around.

If you or anyone else enjoys it - ping me via email, I might have a cool job for you.

You should probably put your email in your profile then... ;)
Post reply on HN