[
https://issues.apache.org/jira/browse/CASSANDRA-1072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12899168#action_12899168
]
Kelvin Kakugawa commented on CASSANDRA-1072:
--------------------------------------------
Hi Jeff,
Helland's Building on Quicksand paper discusses the abstract strategy behind
our distributed counters. It would useful to review it:
http://blogs.msdn.com/b/pathelland/archive/2008/12/12/building-on-quicksand-paper-for-cidr-conference-on-innovative-database-research.aspx
The relevant sections are 5 and 6.
Briefly, Helland postulates that 3 useful properties of distributed commutative
operations are:
1) commutative operation,
2) partitioned work, and
3) idempotent repair.
I also go through #1072 in detail, here:
http://www.slideshare.net/kakugawa/distributed-counters-in-cassandra-cassandra-summit-2010
The important detail that we're missing from your example is the way the work
was partitioned. A given counter's value is actually constructed from the
incremental updates received by each replica. Let me clarify w/ an example.
Let's assume that all replicas start w/ this distributed counter vector:
[(A, 4), (B, 3), (C, 3)] = 10
Example (a):
initial value:
[(A, 4), (B, 3), (C, 3)] = 10
node B (+1):
[(A, 4), (B, 4), (C, 3)] = 11
node C (+1):
[(A, 4), (B, 3), (C, 5)] = 12
On reconciliation (between any node), we take the highest count for a remote
replica. So, if node A received a repair from both nodes B and C, the
resulting vector would be:
[(A, 4), (B, 4), (C, 5)] = 13
Example (b):
initial value:
[(A, 4), (B, 3), (C, 3)] = 10
node B (+1):
[(A, 4), (B, 4), (C, 3)] = 11
node C (after repair from B):
[(A, 4), (B, 4), (C, 3)] = 11
node C (+1):
[(A, 4), (B, 4), (C, 4)] = 12
Now, let's take the situation where node A receives a repair from C (and,
optionally, B), the resulting vector would be:
[(A, 4), (B, 4), (C, 4)] = 12
I did gloss over some details in the above. If you would like me to clarify, I
would be happy to do so.
> Increment counters
> ------------------
>
> Key: CASSANDRA-1072
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1072
> Project: Cassandra
> Issue Type: Sub-task
> Components: Core
> Reporter: Johan Oskarsson
> Assignee: Kelvin Kakugawa
> Attachments: CASSANDRA-1072-2.patch, CASSANDRA-1072.patch,
> Incrementcountersdesigndoc.pdf
>
>
> Break out the increment counters out of CASSANDRA-580. Classes are shared
> between the two features but without the plain version vector code the
> changeset becomes smaller and more manageable.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
