Shouldn't Cassandra be using Lamport timestamps or even vector clocks there? Relying on timer and its resolution sounds strange for a database, especially a distributed one.
Cassandra is not row level consistent
11–20 of 126 posts
Re: Cassandra is not row level consistent
#12I see this as a basic misunderstanding of how LWT works. If you want to ensure serializable operations, then you need to use LWT with preconditions that ensure serializable operations.
Even better, stop trying to emulate the old and tired distributed lock methods that have been proven over and over again to be insufficient.
Re: Cassandra is not row level consistent
#13As 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
Re: Cassandra is not row level consistent
#14As 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
That piece was written in 2014, which was a different time ;)
Plus, if we were to take the vendor words at face value, we'd all be using Docker and MongoDB in production.
Re: Cassandra is not row level consistent
#15Cassandra 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.
100,000 nodes on Apple and 2,500 nodes on Netflix would like to have a word with you.
Re: Cassandra is not row level consistent
#16Cassandra 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.
100,000 nodes on Apple and 2,500 nodes on Netflix would like to have a word with you.
Apple no longer uses Cassandra.
Re: Cassandra is not row level consistent
#17Re: Cassandra is not row level consistent
#18Shouldn't Cassandra be using Lamport timestamps or even vector clocks there? Relying on timer and its resolution sounds strange for a database, especially a distributed one.
http://www.datastax.com/dev/blog/why-cassandra-doesnt-need-v...
"Conversely, if there are concurrent changes to a single field, only one will be retained, which is also what we want."
They are wrong though. As HN submission illustrates, people want some order and eventual consistency, not a rule to select a single field during concurrent changes. And this is where a Lamport timestamp could help.
Re: Cassandra is not row level consistent
#19Cassandra 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.
I second other people's responses that you should clean this up and add a lot of substance.
Often the best comments start off exactly like yours: it's clear you feel very strongly about the issue, so edit it and say how/why!! list the points that irked you.