cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Yeschenko (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-6880) counters++ lock on cells, not partitions
Date Wed, 02 Apr 2014 20:09:15 GMT

     [ https://issues.apache.org/jira/browse/CASSANDRA-6880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Aleksey Yeschenko updated CASSANDRA-6880:
-----------------------------------------

    Reviewer: Benedict  (was: Jonathan Ellis)

> 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)

Mime
View raw message