Return-Path: Delivered-To: apmail-incubator-cassandra-user-archive@minotaur.apache.org Received: (qmail 91623 invoked from network); 4 Jul 2009 01:31:59 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 4 Jul 2009 01:31:59 -0000 Received: (qmail 71480 invoked by uid 500); 4 Jul 2009 01:32:09 -0000 Delivered-To: apmail-incubator-cassandra-user-archive@incubator.apache.org Received: (qmail 71449 invoked by uid 500); 4 Jul 2009 01:32:09 -0000 Mailing-List: contact cassandra-user-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: cassandra-user@incubator.apache.org Delivered-To: mailing list cassandra-user@incubator.apache.org Received: (qmail 71440 invoked by uid 99); 4 Jul 2009 01:32:09 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 04 Jul 2009 01:32:09 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of snacktime@gmail.com designates 209.85.222.184 as permitted sender) Received: from [209.85.222.184] (HELO mail-pz0-f184.google.com) (209.85.222.184) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 04 Jul 2009 01:32:01 +0000 Received: by pzk14 with SMTP id 14so871279pzk.32 for ; Fri, 03 Jul 2009 18:31:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=DkkJ1gFW/PKswONqCFJygznEd2J1TCkZm63aJdTL/mg=; b=aPiWKyAt7PlYL9h9cyPpxHkwzCImejsYJ0H1sPtxPu0PevnjB9kUNQojZGcCJn7TBg 9y4V4ZEUrDjrEEEvUi2xGfX7oP/BwwIZg0qTFJJIWwG21UL8hlnv5RLytMxffRYYjhBS ymlE/xAaBzewjl8j7YUm4PG5CSRyyYUq+gd2Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Yf0Ifd9xP0aq0K/YyrStjEdhX5hyaMXtAAp0RWf0Vrvej+kWrG4Z4MqL+v4u2sXn5C P7u8nZguin7p+ol4v3NtiygoktM0ZUQt7n4ICIxpRvoBt8G3t2FuK+PM+ZFbjLLe1DTS wbVBfMeaRUojI8yKlZFM4m2rPp1RHcbWe4dKs= MIME-Version: 1.0 Received: by 10.142.233.9 with SMTP id f9mr685085wfh.331.1246671101782; Fri, 03 Jul 2009 18:31:41 -0700 (PDT) Date: Fri, 3 Jul 2009 18:31:41 -0700 Message-ID: <1f060c4c0907031831g11c05819m53243d9701e2aacb@mail.gmail.com> Subject: eventual consistency and what that means in real world terms From: snacktime To: cassandra-user@incubator.apache.org Content-Type: multipart/alternative; boundary=000e0cd2e2f82c6d3b046dd73c34 X-Virus-Checked: Checked by ClamAV on apache.org --000e0cd2e2f82c6d3b046dd73c34 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I'm evaluating a number of options to an rdbms for some of our facebook games. A small, yet important number of queries require transactions. For example we have auctions, and buying/purchasing of items with limited quantities. Are there knobs you can tweak to enforce consistency on a per query basis? For example, I want to do a write that should not be visible until it's been written to all nodes in the cluster, is that possible? What kind of general time frames are we talking about to write data to 3 nodes? So basically what we want is high availability for 99.99% of queries, but high consistency for the remainder, across the same data. Is this currently possible? Chris --000e0cd2e2f82c6d3b046dd73c34 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm evaluating a number of options to an rdbms for some of our facebook= games. =A0A small, yet important number of queries require transactions. = =A0For example we have auctions, and buying/purchasing of items with limite= d quantities. =A0

Are there knobs you can tweak to enforce consistency on a pe= r query basis? =A0For example, I want to do a write that should not be visi= ble until it's been written to all nodes in the cluster, is that possib= le? =A0What=A0kind=A0of=A0general=A0time=A0frames=A0are=A0we=A0talking=A0ab= out=A0to=A0write=A0data=A0to=A03=A0nodes?

So basically what we want is high availability for 99.9= 9% of queries, but high consistency for the remainder, across the same data= . =A0Is this currently possible?

Chris
--000e0cd2e2f82c6d3b046dd73c34--