incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dwight Merriman <dwi...@10gen.com>
Subject Re: serialized vector clock as global counter?
Date Sun, 14 Mar 2010 23:37:42 GMT
yes - take a look at this app engine blog post:

http://googleappengine.blogspot.com/2009/09/migration-to-better-datastore.html

if i read this correctly, app engine data store is pretty much in the
"strongly consistent" camp while cassandra is more eventually consistent --
so really quite different.  you would get higher availability on an EC
system but atomic updates become quite hard (at least when fully
generalized)

On Sun, Mar 14, 2010 at 6:29 PM, Fred Wulff <frew@stanford.edu> wrote:

> Hey Toby,
>
> I'm not an expert on Cassandra's infrastructure, but I believe the
> thing the AppEngine datastore has that Cassandra doesn't is a
> transaction between the read and write of a sharded counter. That
> means that while the read of the various counters may be inconsistent,
> the actual update of the shard is always consistent and the read of
> that shard is always consistent with the previous write.
>
> -Fred
>
> On Sun, Mar 14, 2010 at 9:46 AM, Toby DiPasquale <toby@cbcg.net> 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:
> http://code.google.com/appengine/articles/sharding_counters.html.
> > 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
> >
>

Mime
View raw message