4 ms·

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 dis

by zzzcpan 10y ago

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.

supergirl 10y ago
http://www.datastax.com/dev/blog/why-cassandra-doesnt-need-vector-clocks http://www.datastax.com/dev/blog/why-cassandra-doesnt-need-v...
- zzzcpan 10y ago
  "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.
  - sigy 10y ago
    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.
parenthephobia 10y ago
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.)
- chillaxtian 10y ago
  > 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?

by zzzcpan 10y ago

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.

supergirl 10y ago

http://www.datastax.com/dev/blog/why-cassandra-doesnt-need-vector-clocks http://www.datastax.com/dev/blog/why-cassandra-doesnt-need-v...

zzzcpan 10y ago
"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.
- sigy 10y ago
  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.

parenthephobia 10y ago

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.)

chillaxtian 10y ago
> 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?