cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kelvin Kakugawa (JIRA)" <>
Subject [jira] Commented: (CASSANDRA-580) vector clock support
Date Tue, 01 Dec 2009 22:51:20 GMT


Kelvin Kakugawa commented on CASSANDRA-580:

Ah, I see what you were going after.  That's a more concise interface change.

My understanding about including a timestamp along w/ the logical clock is to limit the potential
growth of the vector.  Basically, whenever a new node updates a value, the vector size grows
by one.  However, the problem is that if many different nodes happen to update a given value
(for various reasons--failure scenarios, etc.), the potential size of a vector could grow
to an unmanageable length and it would keep that length forever.  So, the Dynamo authors chose
to tag each update with a timestamp, so they could truncate the vector to only the last 10
nodes to update the value.  There is a possibility that an inconsistency could arise, because
of the truncation.  However, the paper said in practice, it was a non-issue.

In summary, the timestamp is not there to help resolve consistency problems, it's there to
make the vector more manageable.

> vector clock support
> --------------------
>                 Key: CASSANDRA-580
>                 URL:
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: Core
>         Environment: N/A
>            Reporter: Kelvin Kakugawa
>            Assignee: Kelvin Kakugawa
>         Attachments: 580-interface-1-add-vector-clock.diff, 580-interface-2-add-vector-clock.diff,
>   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.

View raw message