incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Copenhaver <sean.copenha...@gmail.com>
Subject Re: CouchDB's advantages over MongoDB
Date Thu, 14 Apr 2011 14:11:41 GMT
Oh I meant ports on a test machine. As in you had a machine trying to produce load. 


On Apr 14, 2011, at 10:05 AM, Sean Copenhaver <sean.copenhaver@gmail.com> wrote:

> 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 simplify 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í <itaborai83@gmail.com>
> I'm trying to come up with some of CouchDB's advantages over MongoDB. Mongo
> seems to have some advantages on easier "queriability" and overall speed
> (this is really an understatement, but I´m looking forward for the snappy
> 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 as
>   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 feel
> that for the uninitiated, it is hard to fully understand the strengths and
> weaknesses of both products, as well as the operational implications of
> each. Couch's weaknesses, unfortunately, seems to be a bit more evident at
> 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.
> 
> 
> 
> -- 
> “The limits of language are the limits of one's world. “ -Ludwig von Wittgenstein

Mime
  • Unnamed multipart/alternative (inline, 7-Bit, 0 bytes)
View raw message