cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Yeschenko (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-4775) Counters 2.0
Date Thu, 19 Dec 2013 02:20:11 GMT


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.
and the comments following it (plus

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

View raw message