cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "zhu han (JIRA)" <>
Subject [jira] Commented: (CASSANDRA-1546) (Yet another) approach to counting
Date Mon, 27 Sep 2010 16:22:34 GMT


zhu han commented on CASSANDRA-1546:

Thank you for you detailed response.

During a write, after having apply the increment locally, there is a read a one column (the
one corresponding to the local count).
This is this value that is sent for replication (this thus integrate the fleshly written update).
This read is a normal read, so it hits as
many sstables as need be, if that's what you mean. 

Yep. What I mean is we don't need to read multiple sstables but the most fresh one to get
the latest value of the single column.  If the counter column is updated frequently, it should
reside in memtable. So, We can read it from memtable directly, even without touching on disk
sstables.  That is, we do not need any disk IO for the counter incr/decr mutation, just like
the normal column mutation. 

This can keep the update of counter still faster than read, which is the keen competitive
advantage of cassandra.

Ok, the problem is the following: suppose you issue one increment (+1), then you remove the
counter, then you increment again (+1).
Say the leader replicate is always the same one, but he receives the two increments first.
It will 'merge' those two increment, and
we'll end up with one column, whose count is 2 and whose timestamp is the one of the last
increment. Then it receives the delete.
But as far as he's concerned, this delete is obsolete and will be discarded. Even if we were
somehow able to detect that the delete
should have delete something, how can we know which parts of the now merged count should be
kept or not.
I see. What I said does not work here.

 What makes things more complicated, is commands from two clients does not have any total
order at all. For example, two clients, one issued increment, the other one issued deletion,
both at time t1. Whether the effect of increment left after execution of these two commands
are not deterministic.

So, I agree with you, this issue should not be blocker of this feature. Cassandra can not
provide atomic incr/decr, or delete, no matter how hard we try,  as long as CAP theorem is
right .  I even thought we should not solve this tricky problem. Let's expose this constraint
to the client application directly.

> (Yet another) approach to counting
> ----------------------------------
>                 Key: CASSANDRA-1546
>                 URL:
>             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.

View raw message