Return-Path: Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: (qmail 83478 invoked from network); 14 May 2010 08:17:18 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 14 May 2010 08:17:18 -0000 Received: (qmail 86709 invoked by uid 500); 14 May 2010 08:17:17 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 86691 invoked by uid 500); 14 May 2010 08:17:17 -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 86683 invoked by uid 99); 14 May 2010 08:17:16 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 14 May 2010 08:17:16 +0000 X-ASF-Spam-Status: No, hits=2.5 required=10.0 tests=AWL,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of yen.pai@gmail.com designates 74.125.83.172 as permitted sender) Received: from [74.125.83.172] (HELO mail-pv0-f172.google.com) (74.125.83.172) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 14 May 2010 08:17:10 +0000 Received: by pvg11 with SMTP id 11so330348pvg.31 for ; Fri, 14 May 2010 01:16:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=ehsYIb23drgmWRIGcdGLdI5wPmdSLzCVnQs9QPCrxjY=; b=MZ/86O/cenlZEeanj8iCBx9n6WRHPjKKOkmtohA0uHvsMvZAXbOTdu41lGyKCAeajA wBBPi97HwDUkQcwK6z//7g4ECU7AEIGhIHpyo+7kZGjIPN7jnoKk1Tb8i0LsMeMiw1FQ mnuww6cWjgnLjzjBzfxtRdVQcSbvc/KeY1W/s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=QcS6Cuid8iIQ4+pH3iWvSOw+9Ac3LaTcfMBGu60v2tQaXQP7xAXLowRjtWMRcGYBl9 SjEsfPQQn8D601jVxA9rpy/WSPiHGYbRNcMZSFY3lXuTxfmofxiQ5K1Qc/lE5ZOavDQM Zjhcrd1Ek8wC1ckwyrjM7mfGyiSn0kv/cBBTk= MIME-Version: 1.0 Received: by 10.143.85.7 with SMTP id n7mr489908wfl.239.1273825010252; Fri, 14 May 2010 01:16:50 -0700 (PDT) Sender: yen.pai@gmail.com Received: by 10.142.199.7 with HTTP; Fri, 14 May 2010 01:16:50 -0700 (PDT) In-Reply-To: References: Date: Fri, 14 May 2010 01:16:50 -0700 X-Google-Sender-Auth: 6coblZh4JDZrwn-0NU1pRzsC5Z8 Message-ID: Subject: Re: how does cassandra compare with mongodb? From: ypai To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=000e0cd5cd523dfd3a0486897f3c --000e0cd5cd523dfd3a0486897f3c Content-Type: text/plain; charset=ISO-8859-1 Not sure if this was mentioned, but MongoDB is strongly consistent while Cassandra is eventually consistent -- at least about a month ago when I looked at it in more detail, though with vector clocks in 0.7, this may be less of an issue. As for "schema-less" and coupling of database/application, etc.: Using solutions like iBatis/Hibernate allow the application to be abstracted from the database in theory, but in practice, it is very rare that a schema will undergo changes without corresponding changes in the ORM layer. MongoDB's flexibility in regards to schema does allow the application developer more freedom/control but even though MongoDB doesn't enforce a schema in the traditional sense, a logical schema still exists: applications still need to know what Mongo "collections" (analogous to tables) to reference, what keys to use, what fields to retrieves -- just like a typical "enterprise" Java application needs to know what tables, keys, and columns to retrieve. It's just that with MongoDB, if a column/field name is wrong in the application, it is likely to fail silently, rather then throw an exception. In any case, the term "schema-less" is a little deceptive -- one still has to think carefully about how to structure and store one's data in order to leverage the strengths of a particular datastore. Also, I would say that a MongoDB document (think JSON) in a collection called "user" such as: { "_id": "primaryKeyEquivalent", "addresses": [ {"address1"}, {"address2"}, {"address3"} ] } is about as self-documenting as a table "user" and a table "user_addresses" with a one to many FK relationship. On Thu, May 13, 2010 at 7:31 PM, Steve Lihn wrote: > Not sure how to comment on this concept. I guess it infers that the > database and application are no longer loosely coupled, but now strongly > coupled. > I guess too, that java developers will vote yes, while database architect > and DBA will vote no. > > In the "traditional" sense, enterprise data is the soul of a business. Data > has to stand by itself with reasonable information (primary key and foreign > key) to interpret itself. But it appears now with the Mongo approach, the > data store (I won't even call it database) is a byproduct of the mapping > class. Without reading the mapping classes, one can barely understand the > data. How is this going to be accepted by large enterprises? I put a big > question mark on it. > > On top of it, if you follow Hibernate's suggestion of using numeric as > primary keys, your data will be as cryptic as hell. > > > > On Thu, May 13, 2010 at 8:10 PM, philip andrew wrote: > >> MongoDB encourages you to define your schema in your application code by >> using mapping classes. This logically infers that it makes no sense to >> define the schema twice, in the database and in your application code. >> >> --000e0cd5cd523dfd3a0486897f3c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Not sure if this was mentioned, but MongoDB is strongly consistent while Ca= ssandra is eventually consistent -- at least about a month ago when I looke= d at it in more detail, though with vector clocks in 0.7, this may be less = of an issue.

As for "schema-less" and coupling of database/application, et= c.:

Using solutions like iBatis/Hibernate allow the application to b= e abstracted from the database in theory, but in practice, it is very rare = that a schema will undergo changes without corresponding changes in the ORM= layer.

MongoDB's flexibility in regards to schema does allow the applicati= on developer more freedom/control but even though MongoDB doesn't enfor= ce a schema in the traditional sense, a logical schema still exists:=A0 app= lications still need to know what Mongo "collections" (analogous = to tables) to reference, what keys to use, what fields to retrieves -- just= like a typical "enterprise" Java application needs to know what = tables, keys, and columns to retrieve.=A0 It's just that with MongoDB, = if a column/field name is wrong in the application, it is likely to fail si= lently, rather then throw an exception.=A0 In any case, the term "sche= ma-less" is a little deceptive -- one still has to think carefully abo= ut how to structure and store one's data in order to leverage the stren= gths of a particular datastore.

Also, I would say that a MongoDB document (think JSON) in a collection = called "user" such as:
{=A0 "_id": "primaryKeyEquivalent",
= =A0=A0 "addresses": [ {"address1"}, {"address2&quo= t;}, {"address3"} ]
}

is about as self-documenting as a table "user" an= d a table "user_addresses" with a one to many FK relationship.



On Thu, May 13, 2010 at 7:31 PM= , Steve Lihn <s= tevelihn@gmail.com> wrote:
Not sure how to c= omment on this concept. I guess it infers that the database and application= are no longer loosely coupled, but now strongly coupled.
I guess too, that java developers will vote yes, while database architect a= nd DBA will vote no.

In the "traditional" sense, enterprise data is the soul of a busi= ness. Data has to stand by itself with reasonable information (primary key = and foreign key) to interpret itself. But it appears now with the Mongo app= roach, the data store (I won't even call it database) is a byproduct of= the mapping class. Without reading the mapping classes, one can barely und= erstand the data. How is this going to be accepted by large enterprises? I = put a big question mark on it.

On top of it, if you follow Hibernate's suggestion of using numeric= as primary keys, your data will be as cryptic as hell.



On Thu, May 13, 2010 a= t 8:10 PM, philip andrew <philip142au@gmail.com> wrote:<= br>
MongoDB encourages you to define your schema in your application code by us= ing mapping classes. This logically infers that it makes no sense to define= the schema twice, in the database and in your application code.


--000e0cd5cd523dfd3a0486897f3c--