cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kelvin Kakugawa (JIRA)" <>
Subject [jira] Commented: (CASSANDRA-1546) (Yet another) approach to counting
Date Mon, 11 Oct 2010 16:39:34 GMT


Kelvin Kakugawa commented on CASSANDRA-1546:


(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:
>             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,
> 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.

View raw message