Live data from Hacker News

Cassandra is not row level consistent

datanerds.io

91–100 of 126 posts

Re: Cassandra is not row level consistent

#91
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…

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 query that forces it to run second. So the reordering of the queries that he's observing is legal, and can be simply avoided with "UPDATE ... IF revision = :last-rev".

Re: Cassandra is not row level consistent

#92
post #87
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…

> Don't take shortcuts and you won't get burned. I'm sorry that the user did something unexpected and then posted about it in a way that made your application look bad. I know that must be frustrating. However... Calling the user out as doing something wrong when your application is failing because of a use case you can't handle properly just looks bad. You serve your users, not the other way around. Don't forget tha…

There is no "one size" fits all database or distributed system in existence. To say that there is is to say that MySQL is equally as well suited to all use cases as Cassandra or Redis. They all store and serve data, right?

Cassandra makes no claims to be such a holy grail. Read their documentation, and you can see the use cases it is good for and those it is not.

The author of this blog post chose one it is not good for.

Put another way, "I'm sorry that the Lamborghini you bought broke when you attempted to go off-roading with it. Perhaps you should have bought a Jeep instead?"

Re: Cassandra is not row level consistent

#93
post #87
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…

> Don't take shortcuts and you won't get burned. I'm sorry that the user did something unexpected and then posted about it in a way that made your application look bad. I know that must be frustrating. However... Calling the user out as doing something wrong when your application is failing because of a use case you can't handle properly just looks bad. You serve your users, not the other way around. Don't forget tha…

The high-handedness doesn't improve your argument. Consider forgoing it next time.

Re: Cassandra is not row level consistent

#94
post #89

Earlier quoted context omitted.

> I can't think of any way in which Cassandra would be better than using {Zookeeper,etcd,consul} This is the correct answer. Zookeeper & Curator make it nearly foolproof to implement a distributed lock correctly, whereas with Cassandra, its the other way round.

> Zookeeper & Curator make it nearly foolproof to implement a distributed lock correctly, whereas with Cassandra, its the other way round. Cassandra makes it nearly distributed to implement a foolproof lock correctly?

Yes, nearly! But not quite.

Re: Cassandra is not row level consistent

#95
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 would be a more sympathetic response if Cassandra did less to tempt devs not intimately familiar with it into doing things which will hose them later on. I've worked with it very successfully in the past and contributed to one of its client libraries, but I hesitate to recommend it because that trait makes it unnecessarily dangerous to use.

Re: Cassandra is not row level consistent

#96

Earlier quoted context omitted.

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

Agreed. If Writes >> Reads and TPS > 1M Maybe Cassandra :-)

Re: Cassandra is not row level consistent

#97
post #87
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…

> Don't take shortcuts and you won't get burned. I'm sorry that the user did something unexpected and then posted about it in a way that made your application look bad. I know that must be frustrating. However... Calling the user out as doing something wrong when your application is failing because of a use case you can't handle properly just looks bad. You serve your users, not the other way around. Don't forget tha…

It's not possible to detect whether the user wants CP. You can assume they want CP, but the entire point of Cassandra is that it doesn't make that assumption.

Cassandra is AP with opt-in CP. This is an explicit tradeoff. You're giving up the assumption (which enables error checking) that everything is CP in order to get AP performance. This tradeoff is one of the main use cases for which Cassandra exists.

The vast majority of the time, error checking is way more valuable than AP performance, so your approach to handling the error makes sense, but if that's your situation you shouldn't be using Cassandra. There are a wide variety of ACID-compliant relational databases that do what you want.

TL;DR: Using Cassandra and expecting CP error checking is like using a hammer and expecting screwdriver behavior.

Re: Cassandra is not row level consistent

#98
post #52
post #35

Earlier quoted context omitted.

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.

I recall several people on twitter (I follow a lot of distributed systems people / cs professors as it is part of my job to build these things) who agreed with Martin's analysis.

Re: Cassandra is not row level consistent

#99
post #87

Earlier quoted context omitted.

> Don't take shortcuts and you won't get burned. I'm sorry that the user did something unexpected and then posted about it in a way that made your application look bad. I know that must be frustrating. However... Calling the user out as doing something wrong when your application is failing because of a use case you can't handle properly just looks bad. You serve your users, not the other way around. Don't forget tha…

The high-handedness doesn't improve your argument. Consider forgoing it next time.

[deleted]

Re: Cassandra is not row level consistent

#100
post #87

Earlier quoted context omitted.

> Don't take shortcuts and you won't get burned. I'm sorry that the user did something unexpected and then posted about it in a way that made your application look bad. I know that must be frustrating. However... Calling the user out as doing something wrong when your application is failing because of a use case you can't handle properly just looks bad. You serve your users, not the other way around. Don't forget tha…

There is no "one size" fits all database or distributed system in existence. To say that there is is to say that MySQL is equally as well suited to all use cases as Cassandra or Redis. They all store and serve data, right? Cassandra makes no claims to be such a holy grail. Read their documentation, and you can see the use cases it is good for and those it is not. The author of this blog post chose one it is not good…

[deleted]
Post reply on HN