[
https://issues.apache.org/jira/browse/CASSANDRA-1072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12896693#action_12896693
]
Kelvin Kakugawa commented on CASSANDRA-1072:
--------------------------------------------
I took a look at Cages. It's interesting as a platform for transactions on top
of Cassandra.
Unfortunately, that's not amenable to high performance counts. ZK clusters
only have one leader--i.e. only one node can be written to, at any given time.
It's not feasible to:
1) acquire a ZK lock
2) perform a quorum read
3) perform a quorum write, then
4) release the ZK lock
for every increment. I've heard of the aftermath of such an approach (ZK locks
to coordinate high performance counts on top of Cassandra) and it was not
pretty. Even this blog post:
http://ria101.wordpress.com/2010/05/12/locking-and-transactions-over-cassandra-using-cages/
mentions that to scale the locks, you'll have to start sharding the ZK
clusters. I completely understand this service for more complicated operations
on top of Cassandra, but not for high performance counters.
The distributed counter code allows increments to be written straight into a
cass cluster. (No reads or locks are required.) And, each replica aggregates
all of the deltas that were originally written to it, plus idempotently repairs
the increments written to the other replicas (to eventually learn the total
counts for a given key).
Granted, a CL.ONE read may be inconsistent to a certain degree. However,
eventually, each replica will learn all the increments written to all replicas.
If you need to know the exact count for a given key, then you will have to pay
for a CL.ALL read. However, this is true for any use case where writes aren't
CL.QUORUM.
Please review Helland's Building on Quicksand paper (sections 5 & 6) for a more
academic understanding of the approach implemented by #1072.
> 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, 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.
