[
https://issues.apache.org/jira/browse/CASSANDRA-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12919892#action_12919892
]
Kelvin Kakugawa commented on CASSANDRA-1546:
--------------------------------------------
zhu,
(1), maintain a local cache, is the currently recommended deployment strategy.
(2) would limit the scalability of #1072, because a cache miss would be
severely penalized.
(3) may be possible; however, it would require a lot of bookkeeping between the
replicas. An interesting approach would be to require all updates on a given
partition to have increasing timestamps. So, when an update is propagated to
the other replicas via read repair, the timeframe of the MT / SST of the update
would be included. This would allow partial timeframes (represented by the MT
/ SST) to be repaired. The real win would be that it would make a
repair-on-write code path cheaper. However, it would make the read paths
(read, read repair) more expensive.
> (Yet another) approach to counting
> ----------------------------------
>
> Key: CASSANDRA-1546
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1546
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Sylvain Lebresne
> Assignee: Sylvain Lebresne
> Fix For: 0.7.0
>
> Attachments: 0001-Remove-IClock-from-internals.patch,
> 0001-v2-Remove-IClock-from-internals.patch,
> 0001-v3-Remove-IClock-from-internals.txt, 0002-Counters.patch,
> 0002-v2-Counters.patch, 0002-v3-Counters.txt,
> 0003-Generated-thrift-files-changes.patch, 0003-v2-Thrift-changes.patch,
> 0003-v3-Thrift-changes.txt, marker_idea.txt
>
>
> This could be described as a mix between CASSANDRA-1072 without clocks and
> CASSANDRA-1421.
> More details in the comment below.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
