[jira] [Commented] (CASSANDRA-6880) counters++ lock on cells, not partitions

["Benedict (JIRA)" <ji...@apache.org>]

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

Benedict commented on CASSANDRA-6880:
-------------------------------------

+1

Pushed a [slightly modified version|https://github.com/belliottsmith/cassandra/tree/6880]

I've changed wrapCounterCells: renamed it to make it clearer what it's for from the name alone, and instead of writing our own Iterable/Iterator/Object, use Guava transformations. Also don't allocate a special object with a specialised hashCode(), simply let the hashCode() get boxed into an Integer, which is functionally equivalent but a bit neater in my book.

Don't feel super strongly about the changes if you still prefer your approach though.


> counters++ lock on cells, not partitions
> ----------------------------------------
>
>                 Key: CASSANDRA-6880
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6880
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Aleksey Yeschenko
>            Assignee: Aleksey Yeschenko
>             Fix For: 2.1 beta2
>
>
> I'm starting to think that we should switch to locking by cells, not by partitions, when updating counters.
> With the current 2.1 counters, if nothing changes, the new recommendation would become "use smaller partitions, batch updates to the same partition", and that goes against what we usually recommend:
> 1. Prefer wide partitions to narrow partitions
> 2. Don't batch counter updates (because you risk to exaggerate undercounting/overcounting in case of a timeout)
> Locking on cells would cause C* to have to grab more locks for batch counter updates, but would give us generally more predictable performance (independent of partition wideness), and won't force people to remodel their data model if they have often concurrently-updated counters in the same few wide partitions.
> (It's a small change, code-wise)



--
This message was sent by Atlassian JIRA
(v6.2#6252)