[
https://issues.apache.org/jira/browse/CASSANDRA-4775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13773230#comment-13773230
]
Craig Hansen commented on CASSANDRA-4775:
-----------------------------------------
I hate to pollute such a scholarly thread with this comment. But I've been
researching all of the potential issues with cassandra counters for several
days now, and I have to say I'm not too encouraged by everything I'm reading. I
love how they work in development, however - just brilliant. While there is a
lot of information relating to potential problems, there seems to be very
little consensus regarding potential solutions.
In my case, I'm just trying to figure out if they are "good enough" for my use
cases, and whether or not there is any way to configure a cassandra cluster
specifically to mitigate some of the risks of using counters. I'd be willing to
create a specialized cluster for counter column families if the risks could be
mitigated through configuration, various write consistency levels, etc.
So at this point we're looking at using redis sets or cassandra counters
intra-day just for speed, and summarizing transactional data to cassandra
integer columns periodically for durability and historical accuracy. Any links
to resources for such solutions would be greatly appreciated. Also any
practical information relating to just how fragile they have proven to be would
be helpful.
The main thing is strategic: It would really help if I could get a sense of
whether resolving counter issues is on the roadmap, or if they will remain in
the "OK use them, but it's gonna be dumb" category.
> 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
