From user-return-36920-apmail-cassandra-user-archive=cassandra.apache.org@cassandra.apache.org Wed Oct 2 09:09:59 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 7DD3310742 for ; Wed, 2 Oct 2013 09:09:59 +0000 (UTC) Received: (qmail 57075 invoked by uid 500); 2 Oct 2013 09:06:25 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 56234 invoked by uid 500); 2 Oct 2013 09:04:00 -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 56126 invoked by uid 99); 2 Oct 2013 09:03:37 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 Oct 2013 09:03:37 +0000 X-ASF-Spam-Status: No, hits=-2.8 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_HI,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of prvs=980380028=a-hjarraya@expedia.com designates 216.251.112.223 as permitted sender) Received: from [216.251.112.223] (HELO mx1b.expedia.com) (216.251.112.223) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 Oct 2013 09:03:31 +0000 X-SRBS: None X-HAT: Sender Group RELAYLIST, Policy $RELAYED applied. X-MailPolicy: Default Outgoing Mail Policy Received: from unknown (HELO CHC-EXCHNA02.SEA.CORP.EXPECN.COM) ([10.184.69.26]) by mx1b.sea.corp.expecn.com with ESMTP; 02 Oct 2013 02:03:09 -0700 Received: from CHCXEXCHMBX006.SEA.CORP.EXPECN.com (10.184.69.10) by CHC-EXCHNA02.SEA.CORP.EXPECN.COM (10.184.69.26) with Microsoft SMTP Server (TLS) id 8.3.298.1; Wed, 2 Oct 2013 02:03:09 -0700 Received: from DBCXEXCHHUB002.SEA.CORP.EXPECN.COM (10.128.48.75) by CHCXEXCHMBX006.SEA.CORP.EXPECN.com (10.184.69.10) with Microsoft SMTP Server (TLS) id 15.0.712.24; Wed, 2 Oct 2013 02:03:08 -0700 Received: from DBCXCCR01.SEA.CORP.EXPECN.COM ([10.128.48.135]) by DBCXEXCHHUB002.SEA.CORP.EXPECN.COM ([10.128.48.75]) with mapi; Wed, 2 Oct 2013 10:02:46 +0100 From: Haithem Jarraya To: "user@cassandra.apache.org" Date: Wed, 2 Oct 2013 10:02:42 +0100 Subject: Re: Maintaining counter column consistency Thread-Topic: Maintaining counter column consistency Thread-Index: Ac6/TiiVjcF8ZkL1SQ+qw8XBzOHf+w== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F866F4645EA94B1B99859C57DD3E08CEexpediacom_" MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org --_000_F866F4645EA94B1B99859C57DD3E08CEexpediacom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ben, If you make sure R + W > N you should be fine. Have a read of this http://www.slideshare.net/benjaminblack/introduction-to= -cassandra-replication-and-consistency Thanks, H On 1 Oct 2013, at 18:29, Ben Hood <0x6e6562@gmail.com> wr= ote: 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? 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? Does anybody have any high level advice for this design deliberation? Cheers, Ben --_000_F866F4645EA94B1B99859C57DD3E08CEexpediacom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ben,

<= div>If you make sure R + W > N you should be fine.
Thanks,

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

Hi,

We're maintaining a bunch of application specific c= ounters that are
incremented on a per event basis just after the event h= as been
inserted.

Given the fact that they can get of sync, we we= re wondering if there
are any best practices or just plain real world ex= perience for
handling the consistency of these counters?

The appl= ication could tolerate an inconsistency for a while, so I'm
not sure tha= t the cost of any full-on ACID semantics (should they
actually be possib= le in Cassandra) would be justified.

So the first inclination was to= issue the increment after the insert
and hope for the best. Then at som= e later point, we would run a
reconciliation on the underlying data in t= he 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?
<= br>Does anybody have any high level advice for this design deliberation?
Cheers,

Ben

= --_000_F866F4645EA94B1B99859C57DD3E08CEexpediacom_--