cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-4775) Counters 2.0
Date Sat, 06 Jul 2013 01:11:51 GMT


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:
>             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:

View raw message