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 DB224C746 for ; Fri, 7 Jun 2013 15:55:00 +0000 (UTC) Received: (qmail 88791 invoked by uid 500); 7 Jun 2013 15:54:58 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 88722 invoked by uid 500); 7 Jun 2013 15:54:53 -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 88705 invoked by uid 99); 7 Jun 2013 15:54:51 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 07 Jun 2013 15:54:51 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW X-Spam-Check-By: apache.org Received-SPF: error (athena.apache.org: local policy) Received: from [209.85.220.178] (HELO mail-vc0-f178.google.com) (209.85.220.178) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 07 Jun 2013 15:54:47 +0000 Received: by mail-vc0-f178.google.com with SMTP id id13so2900309vcb.9 for ; Fri, 07 Jun 2013 08:54:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=uS2srkni0c+f6hL19VUsZM2g31lUstjo4yfEZ0rshVU=; b=ekbzpP32nN5bWQYAKa1w6UEpAgWSAG6pUlEINm0WtBRqqrIzUzMIJB8gcDiCNilU4G kIaHaWuavmAbz5cHo081PFY8MSuQPmoxfygIsB9/1p8/3WWLhJFY45V01LBSKCqUW7nw CTH8DFQJseYFNjqKyB5JBAA68OTSii+EoeQ0m4SIHPgZNdFr4rNqa7cb7W/QZB8hr9bC n8wIaZP+HHQHKgRVG+HohwNxXPWKMd/jWv8DyYLebvxhbhbj0W7/d58ym12Sw1Njc+jk S98hKPinKBwHIubALAIW2H0GRrcamRrxqlcUvSxoEkCKpvDlm58VGxZeK2lL8tFi+Lyo C/Iw== MIME-Version: 1.0 X-Received: by 10.52.23.136 with SMTP id m8mr8143293vdf.27.1370620446177; Fri, 07 Jun 2013 08:54:06 -0700 (PDT) Received: by 10.58.245.73 with HTTP; Fri, 7 Jun 2013 08:54:06 -0700 (PDT) In-Reply-To: References: <1370542999.95424.YahooMailNeo@web162002.mail.bf1.yahoo.com> <1370557558.14800.YahooMailNeo@web162004.mail.bf1.yahoo.com> Date: Fri, 7 Jun 2013 17:54:06 +0200 Message-ID: Subject: Re: [Cassandra] Conflict resolution in Cassandra From: Theo Hultberg To: user@cassandra.apache.org Cc: Emalayan Vairavanathan Content-Type: multipart/alternative; boundary=20cf307ac81fd1270e04de92706c X-Gm-Message-State: ALoCoQnSPxqjrpANH2dOcnCR7jcAZ6Xl43YA4AoutyDMQaxAPUOzxkyti1vL+K98yX/g1aM9S4Ju X-Virus-Checked: Checked by ClamAV on apache.org --20cf307ac81fd1270e04de92706c Content-Type: text/plain; charset=ISO-8859-1 Like Edward says Cassandra's conflict resolution strategy is LWW (last write wins). This may seem simplistic, but Cassandra's Big Query-esque data model makes it less of an issue than in a pure key/value-store like Riak, for example. When all you have is an opaque value for a key you want to be able to do things like keeping conflicting writes so that you can resolve them later. Since Cassandra's rows aren't opaque, but more like a sorted map LWW is almost always enough. With Cassandra you can add new columns/cells to a row from multiple clients without having to worry about conflicts. It's only when multiple clients write to the same column/cell that there is an issue, but in that case you usually can (and you probably should) model your way around that. T# On Fri, Jun 7, 2013 at 4:51 PM, Edward Capriolo wrote: > Conflicts are managed at the column level. > 1) If two columns have the same name the column with the highest timestamp > wins. > 2) If two columns have the same column name and the same timestamp the > value of the column is compared and the highest* wins. > > Someone correct me if I am wrong about the *. I know the algorithm is > deterministic, I do not remember if it is highest or lowest. > > > On Thu, Jun 6, 2013 at 6:25 PM, Emalayan Vairavanathan < > svemalayan@yahoo.com> wrote: > >> I tried google and found conflicting answers. Thats why wanted to double >> check with user forum. >> >> Thanks >> >> ------------------------------ >> *From:* Bryan Talbot >> *To:* user@cassandra.apache.org; Emalayan Vairavanathan < >> svemalayan@yahoo.com> >> *Sent:* Thursday, 6 June 2013 3:19 PM >> *Subject:* Re: [Cassandra] Conflict resolution in Cassandra >> >> For generic questions like this, google is your friend: >> http://lmgtfy.com/?q=cassandra+conflict+resolution >> >> -Bryan >> >> >> On Thu, Jun 6, 2013 at 11:23 AM, Emalayan Vairavanathan < >> svemalayan@yahoo.com> wrote: >> >> Hi All, >> >> Can someone tell me about the conflict resolution mechanisms provided by >> Cassandra? >> >> More specifically does Cassandra provides a way to define application >> specific conflict resolution mechanisms (per row basis / column basis)? >> or >> Does it automatically manage the conflicts based on some synchronization >> algorithms ? >> >> >> Thank you >> Emalayan >> >> >> >> >> >> > --20cf307ac81fd1270e04de92706c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Like Edward says Cassandra's conflict resolution strat= egy is LWW (last write wins). This may seem simplistic, but Cassandra's= Big Query-esque data model makes it less of an issue than in a pure key/va= lue-store like Riak, for example. When all you have is an opaque value for = a key you want to be able to do things like keeping conflicting writes so t= hat you can resolve them later. Since Cassandra's rows aren't opaqu= e, but more like a sorted map LWW is almost always enough. With Cassandra y= ou can add new columns/cells to a row from multiple clients without having = to worry about conflicts. It's only when multiple clients write to the = same column/cell that there is an issue, but in that case you usually can (= and you probably should) model your way around that.

T#


On Fri, Jun 7, 2013 at 4:51 PM, Edward Capriolo <edl= inuxguru@gmail.com> wrote:
Conflicts are managed = at the column level.
1) If two columns have the same name the co= lumn with the highest timestamp wins.=A0
2) If two columns have the same column name and the same timestamp the= value of the column is compared and the highest* wins.

Someone correct me if I am wrong about the *. I k= now the algorithm is deterministic, I do not remember if it is highest or l= owest.


On Thu, Jun 6, 2013 at 6:25 PM, Emalayan Vairavanathan &l= t;svemalayan@yaho= o.com> wrote:
I tried google and found conflicting answers. Thats why wante= d to double check with user forum.=A0

Thanks

From: Bryan Talbot <btalbot@aeriagames.com>
To: user@cassandra.apache.org; Emalaya= n Vairavanathan <svemalayan@yahoo.com>
Sent: Thursday, 6 June 2013= 3:19 PM
Subject: Re: [C= assandra] Conflict resolution in Cassandra

For generic questions like this, google is your friend:=A0= http://lmgtfy.com/?q=3Dcassandra+conflict+resoluti= on

-Bryan


On Thu, Jun 6, 2013 at 11:23 AM, Emalayan Vairavana= than <svemalayan@yahoo.com> wrote:
Hi All,

Can someone tell me about the conflict resolution mechanisms provided by Ca= ssandra?

More specifically does Cassandra provides a way to define appli= cation specific conflict resolution mechanisms (per row basis =A0/ column b= asis)?=A0
=A0 =A0 =A0 =A0 =A0 =A0or=A0
Does it automatically manage the conflicts based on some synchronization al= gorithms ?


Thank you
Emalayan







--20cf307ac81fd1270e04de92706c--