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

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

Was looking into possible variations of the original idea - the first comment in this issue, and how we could implement it to allow true idempotent client-retriable counter updates, and came with this so far: https://gist.github.com/iamaleksey/fa36552409dc2aa70bee

Cons:
- has significant overhead per-cell - needs to store the timeuuid in the column name
- has the obvious overhead of having multiple cells per single counter
- requires either forcing QUORUM writes (so that merge could get away with QUORUM reads) or ALL reads for the merge. Now, this is probably true for any merge process for any variation of 'each update = new cell, with periodic merges'
- requires special-casing on the read path
- maintaining backward compatibility isn't going to be fun

Pros:
- updates are truly idempotent (within the configurable write window)
- allows counters to coexist with regular columns in regular tables
- allows including counters in (non-logged) batches
- requires a lot less overall special-casing
- easily supports min/max/avg/sum_sq functions

Not sure if this is viable considering that '"retryable" is at the very bottom of my priorities here' but maybe there is something useful in there anyway.
                
> 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 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