121–126 of 126 posts
Cassandra is a piece of shit. Negative that comment how you wants, this never change the initial info. I used that BS on a startup on data science on the crawling info level and was on the worst experiences with db I had. CASSANDRA IS JUST PAIN.
Earlier quoted context omitted.
I agree, Cassandra is doing here exactly what I (as a user) would expect. When using a DB like C*, you always have to ask yourself, "does this update happen before or after this one - have I done anything to ensure that's the case?" In this example, the second query (the UPDATE) is being partially applied before the first query (the INSERT) - and that's OK, because there's no ordering or dependency in the second quer…
My biggest complaint about C : SQL-like interface. These seems like a terrible decision to me. If you are used to relational databases and SQL, it's a real struggle to get your head in the right place. Some of the gotchas: Cell level vs row level consistency/locking (as stated in this article) * Grouping / counting isn't really a thing. * WHERE statements are actually used for identifying the key/value pair you want…
It makes getting standard, and understanding what's going on a breeze.
Earlier quoted context omitted.
Quorum reads + writes and applying non-destructive updates only are enough to get linearizabile consistency in Cassandra, even if clocks are not perfectly synchronized.
If you're applying non-destructive updates then you don't even need quorum to achieve consistency. You're just writing immutable data.
Earlier quoted context omitted.
The only way for C* to know that it should raise an error is if it would implicitly protect all writes with LWT and this is not what most users want. Following the parent's example, if you don't protect memory access with a lock, you can't know that somebody else locked it.
"Must be consistent" is a property of the data, not of a particular transaction. Data on which inconsistent transactions are ever allowed should be declared, preferably with big hazard signs.
Great discussion around the CAP theorem but it misses the point. AP vs CP / Cassandra being AP is not relevant to this particular problem:
1) This is not a distributed systems corner case. You will run into this if you are running Cassandra on a single node. A node should be able to guarantee consistency internally during normal operation. If it is not able to do that, there is something wrong with the system.
2) This is a case where queries are being send from the same process/thread and go to exactly the same nodes. Attach a simple, monotonically increasing query counter to each call and you can easily serialize it on the other side.
Earlier quoted context omitted.
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.