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:44:30 GMT
I should add that although you can do full 2 way replication, I believe
replication can also have filters applied allow for subsets of the data to
be replicated to different nodes.

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

> 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
>



-- 
“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