[
https://issues.apache.org/jira/browse/CASSANDRA-6504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeremy Hanna updated CASSANDRA-6504:
------------------------------------
Labels: counters (was: )
> counters++
> ----------
>
> Key: CASSANDRA-6504
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6504
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Priority: Major
> Labels: counters
> Fix For: 2.1 beta1
>
>
> Continuing CASSANDRA-4775 here.
> We are changing counter write path to explicitly
> lock-read-modify-unlock-replicate, thus getting rid of the previously used
> 'local' (deltas) and 'remote' shards distinction. Unfortunately, we can't
> simply start using 'remote' shards exclusively, since shard merge rules
> prioritize the 'local' shards. Which is why we are introducing the third
> shard type - 'global', the only shard type to be used in 2.1+.
> The updated merge rules are going to look like this:
> global + global = keep the shard with the highest logical clock
> global + local or remote = keep the global one
> local + local = sum counts (and logical clock)
> local + remote = keep the local one
> remote + remote = keep the shard with highest logical clock
> This is required for backward compatibility with pre-2.1 counters. To make
> 2.0-2.1 live upgrade possible, 'global' shard merge logic will have to be
> back ported to 2.0. 2.0 will not produce them, but will be able to understand
> the global shards coming from the 2.1 nodes during the live upgrade. See
> CASSANDRA-6505.
> Other changes introduced in this issue:
> 1. replicate_on_write is gone. From now on we only avoid replication at RF 1.
> 2. REPLICATE_ON_WRITE stage is gone
> 3. counter mutations are running in their own COUNTER_MUTATION stage now
> 4. counter mutations have a separate counter_write_request_timeout setting
> 5. mergeAndRemoveOldShards() code is gone, for now, until/unless a better
> solution is found
> 6. we only replicate the fresh global shard now, not the complete
> (potentially quite large) counter context
> 7. to help with concurrency and reduce lock contention, we cache node's
> global shards in a new counter cache ({cf id, partition key, cell name} ->
> {count, clock}). The cache is only used by counter writes, to help with 'hot'
> counters being simultaneously updated.
> Improvements to be handled by separate JIRA issues:
> 1. Split counter context into separate cells - one shard per cell. See
> CASSANDRA-6506. This goes into either 2.1 or 3.0.
> Potential improvements still being debated:
> 1. Coalesce the mutations in COUNTER_MUTATION stage if they share the same
> partition key, and apply them together, to improve the locking situation when
> updating different counter cells in one partition. See CASSANDRA-6508. Will
> to into 2.1 or 3.0, if deemed beneficial.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
