[ 
https://issues.apache.org/jira/browse/CASSANDRA-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12915712#action_12915712
 ] 

zhu han commented on CASSANDRA-1546:
------------------------------------

{quote}
So, to answer the question about serializing the writes, there is no need (and
I believe it's a good thing performance-wise). When a leader receives an
update, it doesn't read-then-write. It writes-then-read. 
{quote}

I agree. "Write-then-read" fits better with current code base than 
"read-then-write".
But CounterMutation#readLocalCounterColumn() needs to read all present 
LocalCounterColumns, merge
them together and get the latest value of LocalCounterColumn. This may hurt the 
performance because
it may trigger disk IO for each counter update.

Can we add a "CounterCache" option to Counter column family? 
CounterMutation#applyUpdateLocally() applies 
the delta value to  cached counter atomatically if the cache is hit. If it's 
missed, it just gives up.
CounterMutation#readLocalCounterColumn() fetch the counter value from the cache 
if it's hit, otherwise,
goes to the current slow path implementation, and update the cache with the 
value returned by the slow path.

But special care should be taken, as the execution of slow path and insertion 
to the cache is not atomic. Fortunately,
we can use the timestamp of cached LocalCounterColumn to detect the race, and 
discard the stale value silently.

We can implement it as a simple N-way associate counter column cache, backed by 
a fixed-size plain array. Of course,
N should be configurable. So that the memory footprint of the cache is very 
dense, and the performance overhead is very lightweight. 
If the collision rate of Java hashCode() implementation is not good,  crc32 or 
other fast hash method can be used to distribute
the LocalCounterColumn to the cache, depends on their row key.

I think some workload which maintains counter which are frequently updated, can 
benifit a lot from this simple cache.

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

Reply via email to