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 sean.copenhaver@gmail.com
 designates 209.85.212.52 as permitted sender)
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=rjsanq4eNZ87NOzy+BOaZz8xBfLmiPu2aUjyAVggzhXodJOvZFH9vz1LoUmC83PQ1o
         V0vvHWjp6Jx7TwqFw/SjvLg3lJtt/MoVMRWrLIbturzkJCY/R6bwd+rvx5i80N3lwayy
         +N3C2CDHIbN/O0sqPnoYStorKtWh6TsuffL+k=
MIME-Version: 1.0
In-Reply-To: <BANLkTikV7p_CDszrmSwz_QOjaeiqPEDcww@mail.gmail.com>
References: <BANLkTikV7p_CDszrmSwz_QOjaeiqPEDcww@mail.gmail.com>
Date: Thu, 14 Apr 2011 10:05:15 -0400
Message-ID: <BANLkTikhZ4-S5aTKF5+ucunsACi88dKD0A@mail.gmail.com>
Subject: Re: CouchDB's advantages over MongoDB
From: Sean Copenhaver <sean.copenhaver@gmail.com>
To: user@couchdb.apache.org
Content-Type: multipart/alternative; boundary=20cf307c9c3c1feca104a0e16ad5

--20cf307c9c3c1feca104a0e16ad5
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

>From my understanding, some advantages I see of CouchDB are:

Easy horizontal scale path:

It's HTTP. Guess what there are already a lot of and well understood? HTTP
load balancers and caching systems. It has master-master replication built
in. Your database logic is in a design document, which is just another
document that can be replicated across nodes.

Vertical scaling:

With support for Android and iOS you can now take the same database and use
the built in replication to take it up and down from mobile, desktop, and
server. Awesome.

HTTP JSON:

Anything can talk to it. You don't have to have a middleware piece to talk
to it for your for many web application scenarios. This can greatly simplif=
y
things.

Changes API:

You can have a lot of systems monitoring for changes and apply filters to
get just what you want.

Concurrent at it's core:

Thanks to Erlang and the ideas of MVCC you can have many connections to the
database with no worries. I think I have read that some test cases found
that you would run out of IO bandwidth and ports before CouchDB would stop
responding. It might be slow (probably have time outs), but it's up and
talking. Write speed is limited since it's serialized on a node, but in
either case you could load balance that.

2011/4/14 Daniel Itabora=ED <itaborai83@gmail.com>

> I'm trying to come up with some of CouchDB's advantages over MongoDB. Mon=
go
> seems to have some advantages on easier "queriability" and overall speed
> (this is really an understatement, but I=B4m looking forward for the snap=
py
> compression and the NIF interface stuff).
>
>
> So far, I've come up with the following:
>
>   -
>
>   Crash Proof durability (not having to replicate to achieve durability a=
s
>   a best practice)
>   -
>
>   Changes feed (for doing real time analytics, for example)
>   -
>
>   Incremental map/reduce
>   -
>
>   Concurrent reads during writes (no global server write lock, even if it
>   is a fast one)
>   -
>
>   Unlimited document size
>   -
>
>   Linked Documents in views
>   -
>
>   Server side programmability (shows, lists, update handlers, validation
>   functions).
>
>   - Atomic Bulk Operations
>
>
>
> I'd love to hear some more or even be corrected when necessary, but I fee=
l
> that for the uninitiated, it is hard to fully understand the strengths an=
d
> weaknesses of both products, as well as the operational implications of
> each. Couch's weaknesses, unfortunately, seems to be a bit more evident a=
t
> first, despite it being a rock solid technology.
>
>
> Thanks,
>
> Daniel
>
>
> ps:. I had posted this to r/couchdb over at reddit, but that seems like a
> wasteland these days.
>


--=20
=93The limits of language are the limits of one's world. =93 -Ludwig von
Wittgenstein

--20cf307c9c3c1feca104a0e16ad5--