[
https://issues.apache.org/jira/browse/CASSANDRA-1072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12894052#action_12894052
]
SoftwareProjects commented on CASSANDRA-1072:
---------------------------------------------
Kelvin, thank you for putting the document together. Much appreciated.
The one thing that is a big concern to us is the limitation of reads requiring
cl.ALL. With a large number of nodes, it sounds like this will render reads
not suitable for any real-time user-facing queries. There has to be a way
around this? Didn't the folks at Digg implement version-clocks with client
side resolution not requiring cl.ALL for reads?
Server side resolution is definitely the way to go. Just wondering if we can
have the aes/resolution take place "offline", not requiring cl.ALL for reads.
> Increment counters
> ------------------
>
> Key: CASSANDRA-1072
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1072
> Project: Cassandra
> Issue Type: Sub-task
> Components: Core
> Reporter: Johan Oskarsson
> Assignee: Kelvin Kakugawa
> Attachments: CASSANDRA-1072-2.patch, CASSANDRA-1072.patch,
> Incrementcountersdesigndoc.pdf
>
>
> Break out the increment counters out of CASSANDRA-580. Classes are shared
> between the two features but without the plain version vector code the
> changeset becomes smaller and more manageable.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
