[jira] Issue Comment Edited: (CASSANDRA-580) vector clock support

["Stu Hood (JIRA)" <ji...@apache.org>]

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

Stu Hood edited comment on CASSANDRA-580 at 11/25/09 2:06 AM:
--------------------------------------------------------------

One important difference between Cassandra and some other systems utilizing vector clocks is that in Cassandra, writes do not read from disk any old versions of the value that is being written to. This means that conflict resolution currently happens in 3 different places:
 1. At read time - Two nodes have different versions,
 2. At write time - The version being written is older than the version a node has in a Memtable,
 3. At compaction time - Versions of values persisted to different SSTables disagree.

NB: For the purposes of this ticket, I think that all resolution should be handled server side, deterministically, and that one of the following options should be implemented as part of a separate ticket.

But before too much progress is made, we will probably want to decide whether we want to support:
 a) Client side conflict resolution (logic implemented on the client side),
 b) Server side resolution (pluggable logic on the server),
 c) A hybrid (pluggable resolution, which can optionally sends the versions to the client at resolution time #1 or #2)

If we decide to implement client-side resolution (a), then we will need to remove resolution at steps #2 and #3 (or make it optional for option (c)), and keep more copies of the data. For #2, a Memtable could store conflicting versions in memory until they are resolved by a read or flushed to disk. For #3, SSTables will need to be able to store multiple versions of a row/cf until they are resolved by a read.

      was (Author: stuhood):
    One important difference between Cassandra and some other systems utilizing vector clocks is that in Cassandra, writes do not read from disk any old versions of the value that is being written to. This means that conflict resolution currently happens in 3 different places:
 1. At read time - Two nodes have different versions,
 2. At write time - The version being written is older than the version a node has in a Memtable,
 3. At compaction time - Versions of values persisted to different SSTables disagree.

NB: For the purposes of this ticket, I think that all resolution should be handled server side, deterministically, and that one of the following options should be implemented as part of a separate ticket.

But before too much progress is made, we will probably want to decide whether we want to support:
 a) Client side conflict resolution (logic implemented on the client side),
 b) Server side resolution (pluggable logic on the server),
 c) A hybrid (pluggable resolution, which can optionally sends the versions to the client at resolution time #1 or #2)

If we decide to implement client-side resolution (a), then we will need to remove resolution at steps #2 and #3 (or make it optional for option (c)), and keep more copies of the data. For #3, a Memtable could store conflicting versions in memory until they are resolved by a read or flushed to disk. For #2, SSTables will need to be able to store multiple versions of a row/cf until they are resolved by a read.
  
> vector clock support
> --------------------
>
>                 Key: CASSANDRA-580
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-580
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: Core
>         Environment: N/A
>            Reporter: Kelvin Kakugawa
>            Assignee: Kelvin Kakugawa
>   Original Estimate: 672h
>  Remaining Estimate: 672h
>
> Allow a ColumnFamily to be versioned via vector clocks, instead of long timestamps.  Purpose: enable incr/decr; flexible conflict resolution.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.