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 <f...@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 <t...@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 > > >
