[jira] [Commented] (CASSANDRA-6123) Break timestamp ties consistently for a given user requests

["Christopher Smith (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-6123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13854824#comment-13854824 ] 

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" solution.

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: https://issues.apache.org/jira/browse/CASSANDRA-6123
>             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
(v6.1.4#6159)