Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of john.tigernassau@gmail.com
 designates 209.85.218.52 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=PRUaNJVPS6T+/tdBi/HDSCkUGWWytvSlXnJvm2LstamZ7bcXuPEZZv09I5+YwCrox/
         6bcJximEv/ABy6VQ7HAk359zHpsu+SYb7H3ib6m9NT3Rr9p4S+26Mlhw1Ub1O4OfueAA
         a2da5kKu5a53bvNZUsF9fpwYyqIYkw0mgF4rc=
Message-ID: <4DA85D4E.2080806@gmail.com>
Date: Fri, 15 Apr 2011 08:59:26 -0600
From: John Taber <john.tigernassau@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8
MIME-Version: 1.0
To: user@couchdb.apache.org
Subject: Re: CouchDB's advantages over MongoDB
References: <BANLkTikV7p_CDszrmSwz_QOjaeiqPEDcww@mail.gmail.com>
	<BANLkTi=Xs+qTciVB1hig5=Yh3QP1ax044g@mail.gmail.com>
	<BANLkTintwPQun9QCRXW6jTqYJO9BLFqdsw@mail.gmail.com>
	<D7FDA6BF-9443-45A6-87E8-18D6395EB634@gmail.com>
	<BANLkTin5cXXR=su_1xZ9Wz-he42i9Y0Dzg@mail.gmail.com>
	<BANLkTi=JPMkv7o65GY1No9frpF6QqLyOrw@mail.gmail.com>
	<BANLkTimbsp_V-PpTzbY9vLujWQjpZVXA3A@mail.gmail.com>
	<4DA750E5.7050709@gmail.com>
	<BANLkTim-1=EC0dbuE6e4vyYPMA3EqNoCNw@mail.gmail.com>
	<BANLkTimgkMaNnSOj+ZRnodoOJhcKKGszow@mail.gmail.com>
 <BANLkTimmD5-pG-YVwxMsz_E3ugyEo+YOCA@mail.gmail.com>
In-Reply-To: <BANLkTimmD5-pG-YVwxMsz_E3ugyEo+YOCA@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

On 04/15/2011 07:04 AM, Sean Copenhaver wrote:
> CouchDB tries to make sure everything you do allows it to continue to scale
> with good performance. So all the database functions are pretty much
> isolated and can have no side effects. Easy example of the benefits of this
> is the incremental map and reduce. I would be curious to know how MongoDB's
> performance goes once you use a dynamic query on a data set that does not
> fit into memory.

Mongo sometimes crashing during development (and then, reading other 
comments on the web) was why I thought Couch was worth exploring myself 
- and in my limited experiments, Couch never had a hiccup.   And yes, 
the REST api is really nice (cries out for a cool Sammy client, Node 
backend design) and makes Rails or LAMP seem so outdated.  My tests 
never scaled it up big enough to compare performance at huge data levels 
and so far, haven't run into that problem with Mongo.

But I found the Couch built-in Auth process limiting and confusing and 
then became bogged down trying to get good map-reduce queries, and then 
didn't really get the node-backend concept working  - I simply had to 
cut the time bleeding.    Whatever documentation, forum queries, etc I 
found seems split between server and couchapps - I found this really 
confusing.   Couchapp is nice, just not something on our radar.

btw - I view Futon or Mongo command line as simply nice ways for 
developers to either see, check, or debug something and not a good 
systematic way to manage - scripts are much more trackable.  Mongo's 
command line is nice and I found simpler than using a GUI (again YMMV).

So for me, it was a decision of not enough time and budget for us to 
play around with Couch and instead, get things out with Mongo and hope 
any stability issues work themselves out.  YMMV.    And I post this with 
the hope that someone who has figured out some of these issues using 
Couch gets inspired to write up some good blogs/posts/gists  (or we can 
get enough development funds to work out issues ourselves) to enable us 
using Couch more in the future.

Meanwhile, I really, really like the JSON / NoSQL approach that both 
Couch and Mongo offer over the traditional SQL world.

> I will say that you have to mix the book and the wiki at the least to get a
> good picture of everything.
>
> Also for time to market that's really going to depend on how you need to use
> the database. MongoDB could also be slower to market then PostgreSQL if I
> picked it for the wrong reasons.
>
> CouchDB running as your web server, database, and middle tier is crazy
> awesome. Your  mileage will vary, but thanks to it's simple API over HTTP
> and the availability of the _changes API you have many options available to
> you.
>
> Now I do not have a lot of exposure to MongoDB (mostly just read about it a
> year ago). I would be interested in it's advantages over CouchDB.
>
> On Fri, Apr 15, 2011 at 3:24 AM, Dirkjan Ochtman<dirkjan@ochtman.nl>  wrote:
>
>> On Fri, Apr 15, 2011 at 06:03, Kinley Dorji<kinleyd@gmail.com>  wrote:
>>> @John Taber: I agree on one point that I know of - MongoDB has a very
>>> accessible database shell.
>>>
>>> For example, entering something like demonstrates the full query
>>> support it has over all fields, not just the keyed field:
>>>
>>>> db.things.find({name:"mongo"}).forEach(printjson);
>>> That kind of support does make it engaging for new users. Here, like
>>> in some of the other areas you mentioned, CouchDB has a steeper curve.
>> I suppose you've seen Futon? Seems like a rather accessible UI to me.
>>
>> Cheers,
>>
>> Dirkjan
>>
>
>