Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: pass (nike.apache.org: domain of tsaloranta@gmail.com designates
 209.85.160.44 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=ICxMbkUkOZrCeCwDnapmPMpZrJgAePSd8cMgWi16CdynjtN7+pGmdF4ARPKMj6anhH
         b76WbS7hvTpOQxzlp2crNXudNnhMFnNUXtyKhhs9BE/dpYyoePPtX54LsopLJBi5lm1V
         8hrcug41Z1rlxBJyRWCMETSTqq77CZZsDvJHY=
MIME-Version: 1.0
In-Reply-To: <j2t1cb725391004051346ja8a24100rb7660be72b7db69c@mail.gmail.com>
References: <l2i1cb725391004041247nde9119afieb2e954e0711dc76@mail.gmail.com>
	 <4BB98AC5.3040607@fourkitchens.com>
	 <i2y1cb725391004050047jefc1249fucd1bf9d8f60a742@mail.gmail.com>
	 <4BB99933.6030708@fourkitchens.com>
	 <q2q22dabfc71004050529x7e5e786dvcbc584a1b8936e7e@mail.gmail.com>
	 <w2g1cb725391004051008u15d8f6e7mba250d6aec9e2a8c@mail.gmail.com>
	 <p2g10e230a81004051045v7e83d42bw36628085eb6088da@mail.gmail.com>
	 <w2s1cb725391004051106va1a792d5jae1f55d83b62999@mail.gmail.com>
	 <r2q10e230a81004051335y4c363a5clf76b3fc735af05a0@mail.gmail.com>
	 <j2t1cb725391004051346ja8a24100rb7660be72b7db69c@mail.gmail.com>
Date: Mon, 5 Apr 2010 16:48:50 -0700
Message-ID: <l2m5f7770581004051648u649db36u462fbecc47441294@mail.gmail.com>
Subject: Re: Memcached protocol?
From: Tatu Saloranta <tsaloranta@gmail.com>
To: user@cassandra.apache.org
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Apr 5, 2010 at 1:46 PM, Paul Prescod <paul@ayogo.com> wrote:
> On Mon, Apr 5, 2010 at 1:35 PM, Mike Malone <mike@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 +-