From user-return-3931-apmail-cassandra-user-archive=cassandra.apache.org@cassandra.apache.org Mon Apr 05 21:34:45 2010 Return-Path: Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: (qmail 20300 invoked from network); 5 Apr 2010 21:34:45 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 5 Apr 2010 21:34:45 -0000 Received: (qmail 92803 invoked by uid 500); 5 Apr 2010 21:34:44 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 92781 invoked by uid 500); 5 Apr 2010 21:34:44 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 92773 invoked by uid 99); 5 Apr 2010 21:34:44 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Apr 2010 21:34:44 +0000 X-ASF-Spam-Status: No, hits=2.9 required=10.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [209.85.160.44] (HELO mail-pw0-f44.google.com) (209.85.160.44) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Apr 2010 21:34:38 +0000 Received: by pwj2 with SMTP id 2so1987837pwj.31 for ; Mon, 05 Apr 2010 14:34:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.66.202 with HTTP; Mon, 5 Apr 2010 14:34:17 -0700 (PDT) In-Reply-To: References: <4BB98AC5.3040607@fourkitchens.com> <4BB99933.6030708@fourkitchens.com> Date: Mon, 5 Apr 2010 14:34:17 -0700 Received: by 10.141.4.8 with SMTP id g8mr4443059rvi.87.1270503257155; Mon, 05 Apr 2010 14:34:17 -0700 (PDT) Message-ID: Subject: Re: Memcached protocol? From: Mike Malone To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=000e0cd0eba25429620483841760 X-Virus-Checked: Checked by ClamAV on apache.org --000e0cd0eba25429620483841760 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 5, 2010 at 1:46 PM, Paul Prescod wrote: > On Mon, Apr 5, 2010 at 1:35 PM, Mike Malone 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. An eventually consistent count operation in Cassandra would be great, and it would satisfy all of the use cases I would typically use counts for in memcached. It's just a matter of reconciling inconsistencies with a more sophisticated operation than "latest write wins" (specifically, the reconciliation operation should apply all incr/decr ops). Mike --000e0cd0eba25429620483841760 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Apr 5, 2010 at 1:46 PM, Paul Pre= scod <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 famil= iar with
>> atomic add as a sort of locking mechanism.
>
> They're useful for caching denormalized counts of things. Especial= ly things
> that change rapidly. Instead of invalidating the counter whenever an e= vent
> 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.
=A0=
An eventually consistent count operation in Cassandra would be g= reat, and it would satisfy all of the use cases I would typically use count= s for in memcached. It's just a matter of reconciling inconsistencies w= ith a more sophisticated operation than "latest write wins" (spec= ifically, the reconciliation operation should apply all incr/decr ops).

Mike
--000e0cd0eba25429620483841760--