You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Craig Hansen (JIRA)" <ji...@apache.org> on 2013/09/20 19:43:59 UTC

[jira] [Commented] (CASSANDRA-4775) Counters 2.0

    [ 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