Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cassandra is not row level consistent

datanerds.io

Post reply on HN
Print view View original

101–110 of 126 posts

Re: Cassandra is not row level consistent

#101

Post by isoap »

ncw33 wrote: post #91
jbellis wrote: 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 quer…

> the second query (the UPDATE) is being partially applied before the first query (the INSERT) - and that's OK

"Partially applied" is ok with a database?

The description of Cassandra on it's site is "Linear scalability and proven fault-tolerance on commodity hardware or cloud infrastructure make it the perfect platform for mission-critical data."

If it's mission-critical data, I wouldn't do arbitrary things with it for conflict resolution that can corrupt data.

Re: Cassandra is not row level consistent

#102

Post by isoap »

pkolaczk wrote: post #83
convolvatron wrote: post #21

Earlier quoted context omitted.

cassandra never claimed to be a consistent distributed database. its really quite sad that someone had to find that out the hard way.

It is optionally consistent if you know how to use it and you know its limitations. Their use of Cassandra was obviously wrong. Mixing LWT and non-LWT is like having only half of your shared data protected by mutexes - this isn't going to work correctly.

In such a situation though, shouldn't it raise an error? At least that way, the user could have a chance to recover.

Why should it make an arbitrary decision that unknowingly corrupts data for some users?

Re: Cassandra is not row level consistent

#103

Post by hamax »

isoap wrote: post #102
pkolaczk wrote: post #83

Earlier quoted context omitted.

It is optionally consistent if you know how to use it and you know its limitations. Their use of Cassandra was obviously wrong. Mixing LWT and non-LWT is like having only half of your shared data protected by mutexes - this isn't going to work correctly.

In such a situation though, shouldn't it raise an error? At least that way, the user could have a chance to recover. Why should it make an arbitrary decision that unknowingly corrupts data for some users?

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.

Re: Cassandra is not row level consistent

#104

Post by brianwawok »

isoap wrote: post #101
ncw33 wrote: post #91

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…

> the second query (the UPDATE) is being partially applied before the first query (the INSERT) - and that's OK "Partially applied" is ok with a database? The description of Cassandra on it's site is "Linear scalability and proven fault-tolerance on commodity hardware or cloud infrastructure make it the perfect platform for mission-critical data." If it's mission-critical data, I wouldn't do arbitrary things with it f…

This is not arbitrary. It may be not intuitive coming from a rdbms background, but it isn't arbitrary.

As Johnathon pointed out, it's like properly using synchronized or volatile half the time. I don't call it sometimes not working as arbitrary. I call it expected for not following the rules of the system.

Re: Cassandra is not row level consistent

#105

Post by brianwawok »

isoap wrote: post #102
pkolaczk wrote: post #83

Earlier quoted context omitted.

It is optionally consistent if you know how to use it and you know its limitations. Their use of Cassandra was obviously wrong. Mixing LWT and non-LWT is like having only half of your shared data protected by mutexes - this isn't going to work correctly.

In such a situation though, shouldn't it raise an error? At least that way, the user could have a chance to recover. Why should it make an arbitrary decision that unknowingly corrupts data for some users?

Right does Java throw an exception if you forget a lock around a shared variable?

Re: Cassandra is not row level consistent

#106

Post by isoap »

brianwawok wrote: post #104
isoap wrote: post #101

Earlier quoted context omitted.

> the second query (the UPDATE) is being partially applied before the first query (the INSERT) - and that's OK "Partially applied" is ok with a database? The description of Cassandra on it's site is "Linear scalability and proven fault-tolerance on commodity hardware or cloud infrastructure make it the perfect platform for mission-critical data." If it's mission-critical data, I wouldn't do arbitrary things with it f…

This is not arbitrary. It may be not intuitive coming from a rdbms background, but it isn't arbitrary. As Johnathon pointed out, it's like properly using synchronized or volatile half the time. I don't call it sometimes not working as arbitrary. I call it expected for not following the rules of the system.

Let's pretend I'm leading a blind child by telling them which direction they should go, and if they don't step carefully, they could be hurt.

If I can't see the child, should I continue to give them direction, or tell them to stop?

In this use case, the database makes changes to data without knowing what is correct and what is harmful. That is not the user's fault. It's a code choice.

Re: Cassandra is not row level consistent

#107

Post by tremon »

brianwawok wrote: post #104
isoap wrote: post #101

Earlier quoted context omitted.

> the second query (the UPDATE) is being partially applied before the first query (the INSERT) - and that's OK "Partially applied" is ok with a database? The description of Cassandra on it's site is "Linear scalability and proven fault-tolerance on commodity hardware or cloud infrastructure make it the perfect platform for mission-critical data." If it's mission-critical data, I wouldn't do arbitrary things with it f…

This is not arbitrary. It may be not intuitive coming from a rdbms background, but it isn't arbitrary. As Johnathon pointed out, it's like properly using synchronized or volatile half the time. I don't call it sometimes not working as arbitrary. I call it expected for not following the rules of the system.

If I follow your argument correctly, it is basically the same argument as "your C compiler is correct, what you've written is invalid and the standard allows undefined behaviour here".

Which may be a technically valid argument against the compiler/database system, but it's not a valid argument for defending the system as a whole: if a standard allows arbitrary execution instead of bailing out on non-standard (ambiguous) input, it is unreliable.

Re: Cassandra is not row level consistent

#108

Post by hamax »

isoap wrote: post #106
brianwawok wrote: post #104

Earlier quoted context omitted.

This is not arbitrary. It may be not intuitive coming from a rdbms background, but it isn't arbitrary. As Johnathon pointed out, it's like properly using synchronized or volatile half the time. I don't call it sometimes not working as arbitrary. I call it expected for not following the rules of the system.

Let's pretend I'm leading a blind child by telling them which direction they should go, and if they don't step carefully, they could be hurt. If I can't see the child, should I continue to give them direction, or tell them to stop? In this use case, the database makes changes to data without knowing what is correct and what is harmful. That is not the user's fault. It's a code choice.

No, it's a users choice to use a DB that has this tradeoff.

Like it was said a couple of time already, all of your complaints about C* would work just as well for locking mechanisms in most popular languages.

Re: Cassandra is not row level consistent

#109

Post by cowardlydragon »

4ad wrote: post #77
jbellis wrote: 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.

Read the CAP theorem, or stick to your single node.

Re: Cassandra is not row level consistent

#110

Post by hamax »

tremon wrote: post #107
brianwawok wrote: post #104

Earlier quoted context omitted.

This is not arbitrary. It may be not intuitive coming from a rdbms background, but it isn't arbitrary. As Johnathon pointed out, it's like properly using synchronized or volatile half the time. I don't call it sometimes not working as arbitrary. I call it expected for not following the rules of the system.

If I follow your argument correctly, it is basically the same argument as "your C compiler is correct, what you've written is invalid and the standard allows undefined behaviour here". Which may be a technically valid argument against the compiler/database system, but it's not a valid argument for defending the system as a whole: if a standard allows arbitrary execution instead of bailing out on non-standard (ambiguo…

Is variable assignment in c/java/... unreliable? It behaves very similar to what C* does. Concurrent access and modification will produce undefined behaviour if you don't explicitly protect it.
Post reply on HN