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 >
