[
https://issues.apache.org/jira/browse/CASSANDRA-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12915276#action_12915276
]
zhu han commented on CASSANDRA-1546:
------------------------------------
That's soooooo cool. Thank you. :-)
Does the lead replica has to iterate all SSTables, and get the latest value of
th counter before applying the decr/incr mutation? If so, the read path can
be a performance bottleneck. But we can leverage some tricks: only the counter
columns in the latest SSTable are valid and others in the old SSTable can be
ignored safely.
So, the frequently updated counter column can resides in memtable, and local
read-modify-write operation only brings negligible performance lost. The
counter update path is almost as fast as normal column update path.
I have no idea about the detail of the removal before incr/decr problem. But a
quick solution could be let the deletion operation snapshots the current value
of counter column, write it in another column. Just let the read path to merge
these columns, including different counter columns, and the deletion snapshot
column.
The deletion snapshot column are reconciled by the timestamp as usual. So if
the counter is deleted multiple times, only the latest snapshot is kept and
decreased from the merged counter value in read path.
> (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,
> 0002-Counters.patch, 0003-Generated-thrift-files-changes.patch
>
>
> 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.
