On Mon, Apr 5, 2010 at 1:46 PM, Paul Prescod <p...@ayogo.com> wrote: > On Mon, Apr 5, 2010 at 1:35 PM, Mike Malone <m...@simplegeo.com> wrote: >>> That's useful information Mike. I am a bit curious about what the most >>> common use cases are for atomic increment/decrement. I'm familiar with >>> atomic add as a sort of locking mechanism. >> >> They're useful for caching denormalized counts of things. Especially things >> that change rapidly. Instead of invalidating the counter whenever an event >> occurs that would incr/decr the counter, you can incr/decr the cached count >> too. > > Do you think that a future cassandra increment/decrement would be > incompatible with those use cases? > > It seems to me that in that use case, an eventually consistent counter > is as useful as any other eventually consistent datum. In other words, > there is no problem incrementing from 12 to 13 and getting back 15 as > the return value (due to coinciding increments). 15 is the current > correct value. It's arguably more correct then a memcached value which > other processes are trying to update but cannot because of locking. > Benjamin seemed to think that there were applications that depended on > the result always being 13.
I would think that there is also possibility of losing some increments, or perhaps getting duplicate increments? It is not just isolation but also correctness that is hard to maintain but correctness also. This can be more easily worked around in cases where there is additional data that can be used to resolve potentially ambiguous changes (like inferring which of shopping cart additions are real, which duplicates). With more work I am sure it is possible to get things mostly working, it's just question of cost/benefit for specific use cases. I think distributed counters are useful, but difficulty depends on what are expected levels of concurrency/correctness/isolation. There are many use cases where "about right" (or at least only losing additions, or only getting extra ones) is enough. For example, when calculating charges for usage, it is probably ok to lose some usage charges, but not add bogus ones. If mostly consistent result can be achieved cheaply, there is no point in implementing more complex system to get minor increment (prevent loss of, say, 2% of uncounted-for requests). -+ Tatu +-
