From user-return-36921-apmail-cassandra-user-archive=cassandra.apache.org@cassandra.apache.org Wed Oct 2 09:48:08 2013 Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 28D3610877 for ; Wed, 2 Oct 2013 09:48:08 +0000 (UTC) Received: (qmail 33487 invoked by uid 500); 2 Oct 2013 09:48:04 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 33311 invoked by uid 500); 2 Oct 2013 09:47:57 -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 33253 invoked by uid 99); 2 Oct 2013 09:47:55 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 Oct 2013 09:47:55 +0000 X-ASF-Spam-Status: No, hits=1.7 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of 0x6e6562@gmail.com designates 209.85.212.178 as permitted sender) Received: from [209.85.212.178] (HELO mail-wi0-f178.google.com) (209.85.212.178) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 Oct 2013 09:47:51 +0000 Received: by mail-wi0-f178.google.com with SMTP id hn9so603080wib.11 for ; Wed, 02 Oct 2013 02:47:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :content-type; bh=ktjDGP6rq+o8i6Gx3bjbg4p+KEvxAiigBG8iIGD9nVE=; b=beu4D4JevPKepGZnb+62jYAO5oS3HRlU9oBkbJdHeoOEaiqdS44Go3NWeiFvQU1bkW KxNpN4Rzo3pA9mnQIGDlo/M11ZuNrqGa1yxpALi5poHLYH/BKAHgp0+srHKnzH1ujHMr Vw4C788dbFvVKGJM4kr2fTvY05sIGODEiXZjFJnR069LyNcFnKOOwOWrmpvVbl+nsLYe bFsCgpwUkHvp6dwtocy+9EE1rWtE9iW78ElIjC2pGBQZhWb9YGjL2CCBfw634qmQOfCK m252xj29CDnipXOkIwh2O5KfB3eGnJzzJQuruWm6nUzv4732FDBETLw/EyJPke/LVH7Y qvXw== X-Received: by 10.180.99.3 with SMTP id em3mr22887671wib.4.1380707250245; Wed, 02 Oct 2013 02:47:30 -0700 (PDT) Received: from backd8 (host238.lshift.net. [195.172.218.238]) by mx.google.com with ESMTPSA id ev4sm14779644wib.7.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Oct 2013 02:47:29 -0700 (PDT) Date: Wed, 2 Oct 2013 10:47:23 +0100 From: Ben Hood <0x6e6562@gmail.com> To: Haithem Jarraya , user@cassandra.apache.org Message-ID: In-Reply-To: References: Subject: Re: Maintaining counter column consistency X-Mailer: Airmail Beta (205) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="524bebab_19495cff_10c96" X-Virus-Checked: Checked by ClamAV on apache.org --524bebab_19495cff_10c96 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Haithem, I might have phrased my question wrongly - I wasn't referring to the cons= iderations of consistency level or replication factors - I was referring = to fact that I want to insert a row and increment a counter in the same o= peration. I was concerned about the inconsistency that could arise if the= counter increment failed, after the underlying record on which the incre= ment was based succeeded. So I wasn't talking about the consistency betwe= en Cassandra nodes, rather the consistency between an idempotent base rec= ord and an non-idempotent summary counter. Cheers, Ben On October 2, 2013 at 10:09:40 AM, Haithem Jarraya (a-hjarraya=40expedia.= com) wrote: Hi Ben, If you make sure R + W > N you should be fine. Have a read of this=C2=A0http://www.slideshare.net/benjaminblack/introduc= tion-to-cassandra-replication-and-consistency Thanks, H On 1 Oct 2013, at 18:29, Ben Hood <0x6e6562=40gmail.com> wrote: Hi, We're maintaining a bunch of application specific counters that are incremented on a per event basis just after the event has been inserted. Given the fact that they can get of sync, we were wondering if there are any best practices or just plain real world experience for handling the consistency of these counters=3F The application could tolerate an inconsistency for a while, so I'm not sure that the cost of any full-on ACID semantics (should they actually be possible in Cassandra) would be justified. So the first inclination was to issue the increment after the insert and hope for the best. Then at some later point, we would run a reconciliation on the underlying data in the column family and compare this with the counter values. Obviously you can only do this once a counter column has gone cold - i.e. it wouldn't make sense to reconcile something that could still get incremented. Does it make sense to put the insert and increment in a CQL batch=3F Does anybody have any high level advice for this design deliberation=3F Cheers, Ben --524bebab_19495cff_10c96 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Haithem,

I might have phrased my question wrongly - I wasn't ref= erring to the considerations of consistency level or replication factors = - I was referring to fact that I want to insert a row and increment a cou= nter in the same operation. I was concerned about the inconsistency that = could arise if the counter increment failed, after the underlying record = on which the increment was based succeeded. So I wasn't talking about the= consistency between Cassandra nodes, rather the consistency between an i= dempotent base record and an non-idempotent summary counter.

=
Cheers,

Ben

On October 2, 2013 at 10:09:40 AM, Haithem Jarraya (a-hjarraya=40expedia.com) wro= te:

Hi Ben,

If you make sure R + W > N you should be fine.

Thanks,

H
On 1 Oct 2013, at 18:29, Ben Hood <0x6e6562=40gmail.com> wrote:

Hi,

We're maintaining a bunch of application specific counters that are
incremented on a per event basis just after the event has been
inserted.

Given the fact that they can get of sync, we were wondering if there
are any best practices or just plain real world experience for
handling the consistency of these counters=3F

The application could tolerate an inconsistency for a while, so I'm
not sure that the cost of any full-on ACID semantics (should they
actually be possible in Cassandra) would be justified.

So the first inclination was to issue the increment after the insert
and hope for the best. Then at some later point, we would run a
reconciliation on the underlying data in the column family and compare
this with the counter values. Obviously you can only do this once a
counter column has gone cold - i.e. it wouldn't make sense to
reconcile something that could still get incremented.

Does it make sense to put the insert and increment in a CQL batch=3F

Does anybody have any high level advice for this design deliberation=3F

Cheers,

Ben

--524bebab_19495cff_10c96--