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:40:04 GMT
Simple that you can have 2 way continuous replication to keep multiple nodes
in sync with the full data set. So all nodes could be used for all activity.

Usually with the slave configuration the slaves are only for reading so a
single node could keep everything in sync. Since couchdb has a deterministic
algorithm for picking conflict winners even with multple writes to multiple
databases your nodes will be consistent once replication occurs. You'll
still have the conflict but you can resolve that with a separate system
knowing that everyone will see the same data.

On Thu, Apr 14, 2011 at 10:17 AM, Nebu Pookins <nebupookins@gmail.com>wrote:

> Can you clarify this? What exactly is it here that couchdb let's you do
> that mongo doesn't? Is "master" merely a conceptual label, or do you
> actually configure couch differently when it acts as a "slave"?
>
> Sent from my iPhone
>
> On 2011-04-14, at 9:59 AM, Cory Zue <czue@dimagi.com> wrote:
>
> > Master - Master replication
> >
> > On Thu, Apr 14, 2011 at 6:51 AM, Robert Newson <robert.newson@gmail.com
> >wrote:
> >
> >> 'Unlimited document size" - Not true.
> >> "Atomic Bulk Operations" -- Not in the sense you probably mean.
> >>
> >> B.
> >>
> >> 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, None, 0 bytes)
View raw message