[
https://issues.apache.org/jira/browse/CASSANDRA-4775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13701215#comment-13701215
]
Jonathan Ellis commented on CASSANDRA-4775:
-------------------------------------------
Going back to the Sylvain's comments on the existing counters implementation:
bq. I believe that "implementation detail" is responsible for a fair amount of
the pain counters are... We could change that "implementation detail". Instead
we could stop distinguishing the merge rules for local shard, and when a
replica need to increment his hard, he would read/increment/write while holding
a lock to ensure atomicity.
On the one hand, the idea of applying a band aid instead of a rewrite is very
appealing from a risk management perspective, and the merge code has pained me
ever since we added it. On the other hand, I have two problems with counters
1.0 that are not addressed by this:
# read-before-write is inherent in the 1.0 design [although for the record I
think its original authors did not realize that], which means counters offer
very different [worse] performance from "normal" Cassandra updates. We see
this confuse people fairly regularly today, and we saw the same confusion with
indexes before we fixed it there.
# I don't care a whole lot about replayability from a client perspective, but
idempotence internally is very handy (CASSANDRA-5549).
> 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
