[
https://issues.apache.org/jira/browse/CASSANDRA-4775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586715#comment-13586715
]
Jonathan Ellis commented on CASSANDRA-4775:
-------------------------------------------
To go back to implementation...
bq. merging counts becomes a local problem: you can say that each node merges
locally once the counter is older than gc_grace_seconds
There is a coordination problem here; if one node merges away the values
slightly before the others, it will give us counts that we can't reconcile at
the coordinator. So we'd need to do it more like "after gc_grace_seconds,
rounded up to the nearest hour" to prevent problems with clock drift.
Additional note: until we perma-merge the old data after gcgs, we'll want to
keep a "preliminary merge" (in a separate, hidden CF?) for read performance.
This could be a (merged count, md5) tuple; coordinator could read-repair using
the md5s.
> Counters 2.0
> ------------
>
> Key: CASSANDRA-4775
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4775
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Arya Goudarzi
> Labels: counters
> Fix For: 2.0
>
>
> The existing partitioned counters remain a source of frustration for most
> users almost two years after being introduced. The remaining problems are
> inherent in the design, not something that can be fixed given enough
> time/eyeballs.
> Ideally a solution would give us
> - similar performance
> - less special cases in the code
> - potential for a retry mechanism
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
