Re:Cassandra is not row level consistent
by lucian1900 on Friday November 25, 2016 @04:51AM
(#13035501)
Minor nitpick: distributed systems can be consistent too. Your comment implies all distributed systems choose availability over consistency.
Re:Cassandra is not row level consistent
by joncrocks on Friday November 25, 2016 @06:52AM
(#13036064)
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
by pkolaczk on Friday November 25, 2016 @07:05AM
(#13036114)
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
by crypto5 on Thursday November 24, 2016 @10:02PM
(#13034139)
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
by pkolaczk on Friday November 25, 2016 @07:46AM
(#13036328)
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.
Right. Cassandra crawled at 20 TPS when we sent IF cql statements. One thing to note is that Cassandra txns can never be rolled back - they can only be committed/ retrried and so on.
Re:Cassandra is not row level consistent
by im_down_w_otp on Thursday November 24, 2016 @11:27PM
(#13034409)
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
by pkolaczk on Friday November 25, 2016 @07:52AM
(#13036360)
Quorum reads + writes and applying non-destructive updates only are enough to get linearizabile consistency in Cassandra, even if clocks are not perfectly synchronized.
Re:Cassandra is not row level consistent
by im_down_w_otp on Friday November 25, 2016 @09:53PM
(#13041433)
If you're applying non-destructive updates then you don't even need quorum to achieve consistency. You're just writing immutable data.
Re:Cassandra is not row level consistent
by pkolaczk on Saturday November 26, 2016 @04:30AM
(#13042694)
If you're applying non-destructive updates without quorum, you would not get monotonic read consistency, because stale reads would be possible. You could write a row, immediately read it back from another replica and find out the row is not there, because that replica didn't get it yet. You'd have only eventual consistency.
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 distributed. As in a "C" system vs a "non-C" system, where "C" is consistency.
Disclaimer, I work for Basho, makers of Riak.