cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Smith (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-6123) Break timestamp ties consistently for a given user requests
Date Sat, 21 Dec 2013 09:00:16 GMT


Christopher Smith commented on CASSANDRA-6123:

I mentioned this in the other bug, but repeating it here as it is relevant to having a "definitive"

Rather than adding a server ID to the timestamp (and a static one at that), why not instead
change how Cassandra resolves field updates with the same timestamp? The current logic is
to have the version with the lowest *value* discarded, which seems broken and not useful.
If instead the was that the version from the "lowest server" is discarded, we can ensure that
competing writes to different servers will always be resolved with row-level isolation (eventual
consistency always resolves to *all* of the fields from one of the writes overwriting the
other updates).

Defining which server is "lower" could be done with ID's, but since it really doesn't matter
which server is deemed lower so long as it is consistently deemed lower, I think just using
metadata that already uniquely identifies a server is sufficient. Why not simply resolve based
on org.apache.cassandra.db.SystemKeyspace.getLocalHostId()?

Advantages to this approach:

1) No extra space need be consumed for each field value.
2) No change in the SSTable file format.
3) Ensures row-level isolation regardless of whether you are using client or server side timestamps.
4) The resolution of timestamps stops being much of a concern.
5) Scales to an effectively infinite number of nodes. (If we have UUID collisions we have
so many more problems in Cassandra than timestamp ties.)

> Break timestamp ties consistently for a given user requests
> -----------------------------------------------------------
>                 Key: CASSANDRA-6123
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Sylvain Lebresne
>            Assignee: Sylvain Lebresne
>             Fix For: 2.1
> The basic goal of this issue is to fix the fact that if 2 different clients issue "simultaneously"
the 2 following updates:
> {noformat}
> INSERT INTO foo(k, v1, v2) VALUES (0, 1, -1); // client1
> INSERT INTO foo(k, v1, v2) VALUES (0, -1, 1); // client2
> {noformat}
> then, if both updates get the same timestamp, then currently, we don't guarantee that
at the end the sum of {{v1}} and {{v2}} will be 0 (it won't be in that case).
> The idea to solves this is to make sure 2 updates *never* get the same "timestamp" by
making the timestamp be the sum of the current time (and we can relatively easily make sur
no 2 update coordinated by the same node have the same current time) and a small ID unique
to each server node. We can generate this small unique server id thanks to CAS (see CASSANDRA-6108).
> Let's note that this solution is only for server-side generated timestamps.  Client provided
timestamp will still be allowed, but in that case it will be the job of the client to synchronize
to not generate 2 identical timestamp if they care about this behavior.
> Note: see CASSANDRA-6106 for some related discussion on this issue.

This message was sent by Atlassian JIRA

View raw message