Anyone has experience around this on HBase, a CP database?
Cassandra is not row level consistent
51–60 of 126 posts
Re: Cassandra is not row level consistent
#52Earlier quoted context omitted.
You'll want to use a library that implements Redlock: http://redis.io/topics/distlock
You really don't want to use redlock: http://martin.kleppmann.com/2016/02/08/how-to-do-distributed... Antirez's rebuttle didn't really rebuke martin's overall theory that redlock is a very bad locking algorithm: http://antirez.com/news/101
Did anyone else ever publish a meaningful response? I thought Antirez's response was reasonable but I also recognize the inherent bias. I'd love to see responses from other experts, ideally written such that non-experts can reasonably understand.
Re: Cassandra is not row level consistent
#53Earlier 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.
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.
Re: Cassandra is not row level consistent
#54I guess I'm old or just not hip (most likely both) but I had to google WAT (I know WTF but WAT ... never seen it). Even now I'm still not sure but I presume WAT = what!
In case this is not the explanation you found: http://knowyourmeme.com/memes/wat
Re: Cassandra is not row level consistent
#55Earlier quoted context omitted.
Maybe your startup just sucked at Cassandra?
To be fair, it's easy to suck at Cassandra and most folks that use it used to suck at it.
To be fair, some starups are being trendy and using Cassandra when a traditional SQL database would better fit their needs.
One I worked at used a framework designed for SQL, wrote a Cassandra storage backend, didn't denormalize data at all (!) and then (badly) performed JOINs in software because the framework was built around the storage having relational operations (!!) topped off by their backend implementation not being aware of partitioning keys, and hence using unique values for them (!!!).
The first two I discovered when trying to diagnose why certain parts of our website/API were extremely slow. The third I discovered mid-import when suddenly the (staging) cluster stopped being able to process queries.
There wasn't any problem Cassandra was solving, our read volume was much higher than our write volume (like, 10x-100x), and we didn't even have that much data in the first place. Premature optimization (for a problem we were a long way from having) and being trendy.
I don't think Cassandra is particularly bad (and can be used in awesome ways for high-write, low-read immutable timeseries data) but you have to use Cassandra as Cassandra, not as a trendy MySQL.
Re: Cassandra is not row level consistent
#56Hazelcast has a distributed lock (see http://docs.hazelcast.org/docs/3.7/manual/html-single/index....) and I've used for more than a year to synchronize jobs across a cluster.
Re: Cassandra is not row level consistent
#57Earlier quoted context omitted.
You'll want to use a library that implements Redlock: http://redis.io/topics/distlock
You really don't want to use redlock: http://martin.kleppmann.com/2016/02/08/how-to-do-distributed... Antirez's rebuttle didn't really rebuke martin's overall theory that redlock is a very bad locking algorithm: http://antirez.com/news/101
Thanks, I learned the fencing token lock algorithm from this.
Re: Cassandra is not row level consistent
#58Re: Cassandra is not row level consistent
#59Cassandra 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 transactions (LWT) are for, and that's what the authors of this piece used.
However! Fundamentally, mixing serializable (LWT) and non-serializable (plain UPDATE) ops will produce unpredictable results and that's what bit them here.
Basically the same as if you marked half the accesses to a concurrently-updated Java variable with "synchronized" and left it off of the other half as an "optimization."
Don't take shortcuts and you won't get burned.
Re: Cassandra is not row level consistent
#60With the Oracle/PostgreSQL, readers never wait for writers and writers never wait for readers http://philip.greenspun.com/sql/your-own-rdbms.html
using underlying locking mechanism
http://www.beej.us/guide/bgipc/output/html/singlepage/bgipc....