Return-Path: Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: (qmail 89493 invoked from network); 16 Feb 2011 19:51:37 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 16 Feb 2011 19:51:37 -0000 Received: (qmail 38368 invoked by uid 500); 16 Feb 2011 19:51:35 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 38323 invoked by uid 500); 16 Feb 2011 19:51:33 -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 38315 invoked by uid 99); 16 Feb 2011 19:51:33 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 16 Feb 2011 19:51:33 +0000 X-ASF-Spam-Status: No, hits=2.8 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL,URI_HEX X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of chirayithaj@gmail.com designates 209.85.161.44 as permitted sender) Received: from [209.85.161.44] (HELO mail-fx0-f44.google.com) (209.85.161.44) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 16 Feb 2011 19:51:28 +0000 Received: by fxm9 with SMTP id 9so1894897fxm.31 for ; Wed, 16 Feb 2011 11:51:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=HY35G5ZwC8tT7tKwBJRkYR1NVOHRkvT2JUYAe3c8Vvk=; b=LSVfhZf+Becze+lhXYj5/Z6GawlqETS9ybWPHg+l1seM9w031GDzBLJO3jKaWkR2mj lxp03/Q2G4Bb4xjjPzcKjbRs5Fisu0ZDyNqLhFkGFhxQrBELtsoT9wpTPfZx8IAOvsF7 FO3IMocJ3NDM6DDqtqNk5il+6lM0OPVGBftQU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=SAMwOj1EYWI42OViq2TwxL5j6lLF4fV4sJ4FU+Gtt3vNQDVe4nP23+MBSNY2gr2X16 gUci5FopHLyVR11/6nHDJLMz/OkNIC//1K4gWMLvUFyouceJCoNzHYHNrde7MOovCro3 Jrdx4cl6tTayd1SuCll7r2slhj1AgoMSu7b+4= MIME-Version: 1.0 Received: by 10.223.111.137 with SMTP id s9mr1246115fap.98.1297885867362; Wed, 16 Feb 2011 11:51:07 -0800 (PST) Received: by 10.223.86.144 with HTTP; Wed, 16 Feb 2011 11:51:07 -0800 (PST) In-Reply-To: References: <1297883949310-6033138.post@n2.nabble.com> Date: Wed, 16 Feb 2011 13:51:07 -0600 Message-ID: Subject: Re: Patterns for writing enterprise applications on cassandra From: Anthony John To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=001636e0a749154d10049c6b9abd --001636e0a749154d10049c6b9abd Content-Type: text/plain; charset=ISO-8859-1 Ritesh, The gist of Dave's contention is that Casandra adds value in spite of the lack of transactions. However, that need not mean that it can be used for Enterprise applications. Transaction semantics needs to be re-imagined within the capabilities of this new kind of database infrastructure, which addresses some key challenges in scaling. In some sense - RDBMSs have spoiled us to expect ACID transactions in the database. Remember, transaction processing is older than RDBMSs - it was done on COBOL/mainframes and a bulk of banking transactions - even today - do not go through ACID supporting database platforms. They still live on the mainframe. So it can be done and frameworks like CAGES are showing a way forward. At the heart of it, there will need to be a Two-Phase commit type protocol coordinator that sits in front of Cassandra. Of which - one can be sure - there will be many implementations / best practices in the coming months. HTH, -JA On Wed, Feb 16, 2011 at 1:31 PM, Dave Revell wrote: > Ritesh, > > There don't seem to be any common best practices to do this. I think the > reason is that by adding transaction semantics on top of Cassandra you're > throwing away the most important properties of Cassandra. The effects of a > transaction/locking layer: > > - A centralized performance bottleneck that won't scale linearly > - Complex failure detection and recovery > - Reduced availability/partition tolerance (CAP: C prevents simultaneous A > and P) > - High latency for geographically remote clients > - Lower throughput due to enforced serial ordering of transactions > > There are probably other reasons that didn't occur to me. Cassandra's great > at doing what it does, but it's certainly not a general purpose > transactional database for all use cases. > > -Dave > > On Wed, Feb 16, 2011 at 11:19 AM, tijoriwala.ritesh < > tijoriwala.ritesh@gmail.com> wrote: > >> >> Hi Gaurav, >> Thanks for the reply...I did look at the cages framework and I see that it >> provides some functionality for locking and atomic writes for multiple >> keys. >> My question was that do people rely on these kind of frameworks - if so, >> is >> cages the only one or are there others as well...and if not, what do they >> do >> to solve these kind of problems... >> >> Thanks, >> Ritesh >> -- >> View this message in context: >> http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Patterns-for-writing-enterprise-applications-on-cassandra-tp6030077p6033138.html >> Sent from the cassandra-user@incubator.apache.org mailing list archive at >> Nabble.com. >> > > --001636e0a749154d10049c6b9abd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ritesh,

The gist of Dave's contention is that Casand= ra adds value in spite of the lack of transactions. However, that need not = mean that it can be used for Enterprise applications. Transaction semantics= needs to be re-imagined within the capabilities of this new kind of databa= se infrastructure, which addresses some key challenges in scaling.

In some sense - RDBMSs have spoiled us to expect ACID t= ransactions in the database. Remember, transaction processing is older than= RDBMSs - it was done on COBOL/mainframes and a bulk of banking transaction= s - even today - do not go through ACID supporting database platforms. They= still live on the mainframe.=A0

So it can be done and frameworks like CAGES are showing= a way forward. At the heart of it, there will need to be a Two-Phase commi= t type protocol coordinator that sits in front of Cassandra. Of which - one= can be sure - there will be many implementations / best practices in the c= oming months.

HTH,

-JA

On Wed, Feb 16, 2011 at 1:31 PM, Dave Revell <dave@meebo-inc.com> wrote:
Ritesh,

There don't = seem to be any common best practices to do this. I think the reason is that= by adding transaction semantics on top of Cassandra you're throwing aw= ay the most important properties of Cassandra. The effects of a transaction= /locking layer:

- A centralized performance bottleneck that won't s= cale linearly
- Complex failure detection and recovery
= - Reduced availability/partition tolerance (CAP: C prevents simultaneous A = and P)
- High latency for geographically remote clients
- Lower thr= oughput due to enforced serial ordering of transactions

There are probably other reasons that didn't occur to me. Cassand= ra's great at doing what it does, but it's certainly not a general = purpose transactional database for all use cases.

-Dave

--001636e0a749154d10049c6b9abd--