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 <[email protected] > 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 <[email protected]>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 <[email protected]> wrote: >> >> > Master - Master replication >> > >> > On Thu, Apr 14, 2011 at 6:51 AM, Robert Newson <[email protected] >> >wrote: >> > >> >> 'Unlimited document size" - Not true. >> >> "Atomic Bulk Operations" -- Not in the sense you probably mean. >> >> >> >> B. >> >> >> >> 2011/4/14 Daniel Itaboraí <[email protected]>: >> >>> 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
