Live data from Hacker News

Cassandra is not row level consistent

datanerds.io

71–80 of 126 posts

Re: Cassandra is not row level consistent

#71
post #50
post #47

I 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!

It is a particular form of "what" that is used when dumbstruck.

Closely related is WUT, particularly the popular variant LOLWUT: http://knowyourmeme.com/memes/lolwut

Re: Cassandra is not row level consistent

#74

Earlier quoted context omitted.

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.

I work for a large company that used docker in production. A lot of companies are. There are a lot of big names using Kubernetes, Mesos or some other container orchestration system.

Just like many companies use mongodb and nanoservices.

Re: Cassandra is not row level consistent

#75
post #6

As 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…

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…

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

#76
post #59

Cassandra 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 t…

haha, I was just going to ask you what you thought of this, and I'm glad to see you responded already! Yes! :)

Re: Cassandra is not row level consistent

#77
post #59

Cassandra 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 t…

This is too subtle. Incompatible operations should be rejected. Reliance on the programmer to correctly use systems that don't enforce consistency to write consistent transactions is a bad strategy.

Re: Cassandra is not row level consistent

#78
post #13

Earlier quoted context omitted.

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.

:) My last client (very, very big client) for the past year ran nearly all their production systems with Docker and MongoDb...

Never had any problems with Docker. MongoDB on the other hand... Suffice to say it is really fragile when spread across multiple datacentres, which is probably not a surprise to HN.

Re: Cassandra is not row level consistent

#79
post #77
post #59

Cassandra 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 t…

This is too subtle. Incompatible operations should be rejected. Reliance on the programmer to correctly use systems that don't enforce consistency to write consistent transactions is a bad strategy.

This kind of nannying can be really expensive to do correctly when trying to build high performance systems -- to the point where it doesn't make sense to punish everyone just because someone who didn't read the manual MIGHT misuse the product. It's not at all unreasonable to mix transactions with different guarantees if they never touch the same data, and tracking that accurately enough without pissing off your customers with performance needs seems like a fool's errand.
Post reply on HN