[jira] [Commented] (CASSANDRA-4775) Counters 2.0

["Aleksey Yeschenko (JIRA)" <ji...@apache.org>]

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

Aleksey Yeschenko commented on CASSANDRA-4775:
----------------------------------------------

So, this thread has become quite overloaded. Will summarize it shortly in this comment, and then move the actual work/discussion to CASSANDRA-6504.

The initial idea for the new design (a new cell for each increment/decrement, then summing up on reads) and its variations didn't work out, for one reason or another. The largest problems are the required coordination for collapsing the increment history and difficulty in making it backward compatible with the current implementation.

We decided to go for incremental improvements instead - namely, stop using 'local' shards altogether, and do explicit read-modify-write with just one shard type ('global') instead. See https://issues.apache.org/jira/browse/CASSANDRA-4775?focusedCommentId=13702042&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13702042 and the comments following it (plus https://issues.apache.org/jira/browse/CASSANDRA-4071?focusedCommentId=13483381&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13483381).

This will fix, *at minimum*, the over counting issue with commit log replay, CASSANDRA-4417, and CASSANDRA-4071, and, together with some related improvements, drastically simplify counters code in general.


> 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
>            Assignee: Aleksey Yeschenko
>              Labels: counters
>             Fix For: 2.1
>
>
> 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 was sent by Atlassian JIRA
(v6.1.4#6159)