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

21–30 of 126 posts

Re: Cassandra is not row level consistent

#21

Post by convolvatron »

helper wrote: 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…

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

Re: Cassandra is not row level consistent

#23

Post by AznHisoka »

helper wrote: 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…

what about using redis for distributed locks? (assuming you are not using redis cluster)

Re: Cassandra is not row level consistent

#24

Post by helper »

AznHisoka wrote: post #23
helper wrote: 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…

what about using redis for distributed locks? (assuming you are not using redis cluster)

I personally wouldn't use redis for anything besides a cache.

Re: Cassandra is not row level consistent

#25

Post by parenthephobia »

zzzcpan wrote: post #8

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's timestamps can be specified by the client: it's possible to use any integer as your timestamp, such as Lamport timestamps, or even atomic distributed counters (possibly using Cassandra's own counters).

Vector clocks are still out, though.

Edit: Actually, you can't do Lamport timestamps because you can't query the current value of a timestamp.

Re-edit: That's wrong. I shouldn't believe any old blog I find. (I'm leaving it in the comment because it was quoted in a reply.)

Re: Cassandra is not row level consistent

#26

Post by sigy »

zzzcpan wrote: post #18
supergirl wrote: post #11

Earlier quoted context omitted.

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.

No matter what scheme you use, it is still a rule. Lamport timestamps, whatever are just different ways of resolving a conflict. In general, the fact that you have designed your system to have this conflict in the first place is an easier problem to solve than having users understand more complex resolution methods -- especially those that push a callback into the app design rather than actually just solving the basic problem in a pragmatic way.

Re: Cassandra is not row level consistent

#27

Post by chillaxtian »

parenthephobia wrote: post #25
zzzcpan wrote: post #8

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's timestamps can be specified by the client: it's possible to use any integer as your timestamp, such as Lamport timestamps, or even atomic distributed counters (possibly using Cassandra's own counters). Vector clocks are still out, though. Edit: Actually, you can't do Lamport timestamps because you can't query the current value of a timestamp. Re-edit: That's wrong. I shouldn't believe any old blog I find.…

> Edit: Actually, you can't do Lamport timestamps because you can't query the current value of a timestamp.

you can get the timestamp of each column back as part of a SELECT.

is that not enough?

Re: Cassandra is not row level consistent

#28

Post by craz »

AznHisoka wrote: post #23
helper wrote: 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…

what about using redis for distributed locks? (assuming you are not using redis cluster)

You'll want to use a library that implements Redlock: http://redis.io/topics/distlock

Re: Cassandra is not row level consistent

#30

Post by siculars »

helper wrote: 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 distributed. As in a "C" system vs a "non-C" system, where "C" is consistency.

Disclaimer, I work for Basho, makers of Riak.

Post reply on HN