[
https://issues.apache.org/jira/browse/CASSANDRA-4775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13701847#comment-13701847
]
Sylvain Lebresne commented on CASSANDRA-4775:
---------------------------------------------
bq. read-before-write is inherent in the 1.0 design
That's true, and that's annoying. That being said, I think the fact that today
CL.ONE lies about doing a read-before-write is probably a good part of what end
up surprising people. Besides, I'll admit that I remain to be convinced about
the performance of doing one column per write with on-read merging (as as been
suggested for a replacement). It will clearly be faster on writes, but
performance on read remains to be seen (I'm particularly afraid of "everything
run fines in testing, but I go in production, some counters gets more load than
expected and now the read performance on those goes through the roof"). But
yes, read-before-write is a PITA and somewhat "anti-Cassandra".
bq. but idempotence internally is very handy
I couldn't agree more, and that's my biggest problem with the current
implementation (and as always be really). But just in case that wasn't clear,
the whole goal of the "band aid" (as you call it) I'm mentioning would to
restore internal idempotence. So that problem is *not* inherent to counters 1.0.
> 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
