cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Halliday (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-4775) Counters 2.0
Date Tue, 26 Mar 2013 13:45:18 GMT


Jonathan Halliday commented on CASSANDRA-4775:

To my mind it's the read rather than the lock that's the problem.  The design pattern of 'blind
write to log the event on increment, read and replay the series of events to calculate the
current value on read' would seem more in keeping with the 'cassandra way'. Of course you
need to periodically squash the increment log down to a single point in time value to stop
it growing unbounded and that step does need locking of some form, but that batch operation
is less costly than a lock/read on each write.  In keeping with my earlier point re: making
the 'counters' mechanism as general/pluggable as possible, having a generic implementation
of the 'log a modification event stream, replay it on read' that could eventually be exposed
as a primitive on which users could build their own functionality would be a big win. It may
be a harder pattern to implement well, but it's ultimately a lot more powerful.
> Counters 2.0
> ------------
>                 Key: CASSANDRA-4775
>                 URL:
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: Core
>            Reporter: Arya Goudarzi
>              Labels: counters
>             Fix For: 2.0
> 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