cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-6880) counters++ lock on cells, not partitions
Date Tue, 18 Mar 2014 17:29:46 GMT


Jonathan Ellis commented on CASSANDRA-6880:

I think you're right that doing it per-cell is the least-surprising behavior for upgrading.
 We can always evaluate switching to partition-level locking later if it turns out batch updates
are the scenario we want to optimize for.

> counters++ lock on cells, not partitions
> ----------------------------------------
>                 Key: CASSANDRA-6880
>                 URL:
>             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

View raw message