cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benjamin>
Subject Re: serialized vector clock as global counter?
Date Mon, 15 Mar 2010 00:07:46 GMT
Whether or not it can be made to work, it seems a poor fit for
Cassandra.  Why not use Zookeeper?

On Sun, Mar 14, 2010 at 9:46 AM, Toby DiPasquale <> wrote:
> Hi all,
> I'm trying to write an application using Cassandra which requires the
> use of a global, monotonically-increasing counter. I've seen the
> previous threads on this subject which basically say that this can't
> be done in Cassandra as is, but I think I've come up with a method
> that might work. I wanted to get the list's feedback on whether or not
> this method is workable:
> * Each client maintains its own monotonically-increasing counter as a
> row in Cassandra
> * When a client wants to increment the counter, it will:
>  * increment its own counter key using a quorum write
>  * read all keys in the CF using a quorum read
>  * the sum of the values is then the value of the counter
> This method is robust against nodes coming and going (new nodes just
> get a new counter and dead nodes never increase their counter again).
> It also doesn't matter for my application if some possible values for
> the counter are skipped over, as long as every value is greater than
> the last. I believe this scheme to be commensurate to a vector clock,
> no?
> My question would be: assuming we're using both quorum reads and
> writes, is it possible that clients A and B could race in the
> following manner:
> * A updates its counter
> * B updates its counter
> * A reads the keys to get sum X
> * B reads the keys to get the same sum X
> ...thus violating the ever-increasing constraint?
> Google App Engine suggests a similar method for doing global counters
> on Datastore:
> I'm troubled by their implementation, though, because the reads on the
> list of counters are not transactional and are potentially subject to
> the same race that I've described above.
> Any thoughts/ideas?
> --
> Toby DiPasquale

View raw message