You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Daniel Itaboraí <it...@gmail.com> on 2011/04/14 15:47:41 UTC
CouchDB's advantages over MongoDB
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.
Re: CouchDB's advantages over MongoDB
Posted by Sean Copenhaver <se...@gmail.com>.
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 <ne...@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 <cz...@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í <it...@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
Re: CouchDB's advantages over MongoDB
Posted by Kinley Dorji <ki...@gmail.com>.
And to go a little further off topic (but perhaps closer to the truth):
Po (Kung Fu Panda): "There is no charge for awesomeness... or attractiveness."
Could well apply to CouchDB. :)
On Sat, Apr 16, 2011 at 6:52 PM, Jan Lehnardt <ja...@apache.org> wrote:
> Just a quick, kinda off-topic note,
>
> I'd like to thank everyone for a fair and balanced discussion. This
> could turn into sticky discussion but you all kept it civilised.
>
> Personally, I'm biased towards CouchDB, no surprise here, but it is
> no surprise either that other people are enthusiastic about others,
> especially MongoDB and I'm happy that we all get along :)
>
> Keep up the good chatting :)
>
> Cheers
> Jan
> --
>
>
>
> On 15 Apr 2011, at 16:59, John Taber wrote:
>
>> On 04/15/2011 07:04 AM, Sean Copenhaver wrote:
>>> CouchDB tries to make sure everything you do allows it to continue to scale
>>> with good performance. So all the database functions are pretty much
>>> isolated and can have no side effects. Easy example of the benefits of this
>>> is the incremental map and reduce. I would be curious to know how MongoDB's
>>> performance goes once you use a dynamic query on a data set that does not
>>> fit into memory.
>>
>> Mongo sometimes crashing during development (and then, reading other comments on the web) was why I thought Couch was worth exploring myself - and in my limited experiments, Couch never had a hiccup. And yes, the REST api is really nice (cries out for a cool Sammy client, Node backend design) and makes Rails or LAMP seem so outdated. My tests never scaled it up big enough to compare performance at huge data levels and so far, haven't run into that problem with Mongo.
>>
>> But I found the Couch built-in Auth process limiting and confusing and then became bogged down trying to get good map-reduce queries, and then didn't really get the node-backend concept working - I simply had to cut the time bleeding. Whatever documentation, forum queries, etc I found seems split between server and couchapps - I found this really confusing. Couchapp is nice, just not something on our radar.
>>
>> btw - I view Futon or Mongo command line as simply nice ways for developers to either see, check, or debug something and not a good systematic way to manage - scripts are much more trackable. Mongo's command line is nice and I found simpler than using a GUI (again YMMV).
>>
>> So for me, it was a decision of not enough time and budget for us to play around with Couch and instead, get things out with Mongo and hope any stability issues work themselves out. YMMV. And I post this with the hope that someone who has figured out some of these issues using Couch gets inspired to write up some good blogs/posts/gists (or we can get enough development funds to work out issues ourselves) to enable us using Couch more in the future.
>>
>> Meanwhile, I really, really like the JSON / NoSQL approach that both Couch and Mongo offer over the traditional SQL world.
>>
>>> I will say that you have to mix the book and the wiki at the least to get a
>>> good picture of everything.
>>>
>>> Also for time to market that's really going to depend on how you need to use
>>> the database. MongoDB could also be slower to market then PostgreSQL if I
>>> picked it for the wrong reasons.
>>>
>>> CouchDB running as your web server, database, and middle tier is crazy
>>> awesome. Your mileage will vary, but thanks to it's simple API over HTTP
>>> and the availability of the _changes API you have many options available to
>>> you.
>>>
>>> Now I do not have a lot of exposure to MongoDB (mostly just read about it a
>>> year ago). I would be interested in it's advantages over CouchDB.
>>>
>>> On Fri, Apr 15, 2011 at 3:24 AM, Dirkjan Ochtman<di...@ochtman.nl> wrote:
>>>
>>>> On Fri, Apr 15, 2011 at 06:03, Kinley Dorji<ki...@gmail.com> wrote:
>>>>> @John Taber: I agree on one point that I know of - MongoDB has a very
>>>>> accessible database shell.
>>>>>
>>>>> For example, entering something like demonstrates the full query
>>>>> support it has over all fields, not just the keyed field:
>>>>>
>>>>>> db.things.find({name:"mongo"}).forEach(printjson);
>>>>> That kind of support does make it engaging for new users. Here, like
>>>>> in some of the other areas you mentioned, CouchDB has a steeper curve.
>>>> I suppose you've seen Futon? Seems like a rather accessible UI to me.
>>>>
>>>> Cheers,
>>>>
>>>> Dirkjan
>>>>
>>>
>>>
>>
>
>
Re: CouchDB's advantages over MongoDB
Posted by Jan Lehnardt <ja...@apache.org>.
Just a quick, kinda off-topic note,
I'd like to thank everyone for a fair and balanced discussion. This
could turn into sticky discussion but you all kept it civilised.
Personally, I'm biased towards CouchDB, no surprise here, but it is
no surprise either that other people are enthusiastic about others,
especially MongoDB and I'm happy that we all get along :)
Keep up the good chatting :)
Cheers
Jan
--
On 15 Apr 2011, at 16:59, John Taber wrote:
> On 04/15/2011 07:04 AM, Sean Copenhaver wrote:
>> CouchDB tries to make sure everything you do allows it to continue to scale
>> with good performance. So all the database functions are pretty much
>> isolated and can have no side effects. Easy example of the benefits of this
>> is the incremental map and reduce. I would be curious to know how MongoDB's
>> performance goes once you use a dynamic query on a data set that does not
>> fit into memory.
>
> Mongo sometimes crashing during development (and then, reading other comments on the web) was why I thought Couch was worth exploring myself - and in my limited experiments, Couch never had a hiccup. And yes, the REST api is really nice (cries out for a cool Sammy client, Node backend design) and makes Rails or LAMP seem so outdated. My tests never scaled it up big enough to compare performance at huge data levels and so far, haven't run into that problem with Mongo.
>
> But I found the Couch built-in Auth process limiting and confusing and then became bogged down trying to get good map-reduce queries, and then didn't really get the node-backend concept working - I simply had to cut the time bleeding. Whatever documentation, forum queries, etc I found seems split between server and couchapps - I found this really confusing. Couchapp is nice, just not something on our radar.
>
> btw - I view Futon or Mongo command line as simply nice ways for developers to either see, check, or debug something and not a good systematic way to manage - scripts are much more trackable. Mongo's command line is nice and I found simpler than using a GUI (again YMMV).
>
> So for me, it was a decision of not enough time and budget for us to play around with Couch and instead, get things out with Mongo and hope any stability issues work themselves out. YMMV. And I post this with the hope that someone who has figured out some of these issues using Couch gets inspired to write up some good blogs/posts/gists (or we can get enough development funds to work out issues ourselves) to enable us using Couch more in the future.
>
> Meanwhile, I really, really like the JSON / NoSQL approach that both Couch and Mongo offer over the traditional SQL world.
>
>> I will say that you have to mix the book and the wiki at the least to get a
>> good picture of everything.
>>
>> Also for time to market that's really going to depend on how you need to use
>> the database. MongoDB could also be slower to market then PostgreSQL if I
>> picked it for the wrong reasons.
>>
>> CouchDB running as your web server, database, and middle tier is crazy
>> awesome. Your mileage will vary, but thanks to it's simple API over HTTP
>> and the availability of the _changes API you have many options available to
>> you.
>>
>> Now I do not have a lot of exposure to MongoDB (mostly just read about it a
>> year ago). I would be interested in it's advantages over CouchDB.
>>
>> On Fri, Apr 15, 2011 at 3:24 AM, Dirkjan Ochtman<di...@ochtman.nl> wrote:
>>
>>> On Fri, Apr 15, 2011 at 06:03, Kinley Dorji<ki...@gmail.com> wrote:
>>>> @John Taber: I agree on one point that I know of - MongoDB has a very
>>>> accessible database shell.
>>>>
>>>> For example, entering something like demonstrates the full query
>>>> support it has over all fields, not just the keyed field:
>>>>
>>>>> db.things.find({name:"mongo"}).forEach(printjson);
>>>> That kind of support does make it engaging for new users. Here, like
>>>> in some of the other areas you mentioned, CouchDB has a steeper curve.
>>> I suppose you've seen Futon? Seems like a rather accessible UI to me.
>>>
>>> Cheers,
>>>
>>> Dirkjan
>>>
>>
>>
>
Re: CouchDB's advantages over MongoDB
Posted by John Taber <jo...@gmail.com>.
On 04/15/2011 07:04 AM, Sean Copenhaver wrote:
> CouchDB tries to make sure everything you do allows it to continue to scale
> with good performance. So all the database functions are pretty much
> isolated and can have no side effects. Easy example of the benefits of this
> is the incremental map and reduce. I would be curious to know how MongoDB's
> performance goes once you use a dynamic query on a data set that does not
> fit into memory.
Mongo sometimes crashing during development (and then, reading other
comments on the web) was why I thought Couch was worth exploring myself
- and in my limited experiments, Couch never had a hiccup. And yes,
the REST api is really nice (cries out for a cool Sammy client, Node
backend design) and makes Rails or LAMP seem so outdated. My tests
never scaled it up big enough to compare performance at huge data levels
and so far, haven't run into that problem with Mongo.
But I found the Couch built-in Auth process limiting and confusing and
then became bogged down trying to get good map-reduce queries, and then
didn't really get the node-backend concept working - I simply had to
cut the time bleeding. Whatever documentation, forum queries, etc I
found seems split between server and couchapps - I found this really
confusing. Couchapp is nice, just not something on our radar.
btw - I view Futon or Mongo command line as simply nice ways for
developers to either see, check, or debug something and not a good
systematic way to manage - scripts are much more trackable. Mongo's
command line is nice and I found simpler than using a GUI (again YMMV).
So for me, it was a decision of not enough time and budget for us to
play around with Couch and instead, get things out with Mongo and hope
any stability issues work themselves out. YMMV. And I post this with
the hope that someone who has figured out some of these issues using
Couch gets inspired to write up some good blogs/posts/gists (or we can
get enough development funds to work out issues ourselves) to enable us
using Couch more in the future.
Meanwhile, I really, really like the JSON / NoSQL approach that both
Couch and Mongo offer over the traditional SQL world.
> I will say that you have to mix the book and the wiki at the least to get a
> good picture of everything.
>
> Also for time to market that's really going to depend on how you need to use
> the database. MongoDB could also be slower to market then PostgreSQL if I
> picked it for the wrong reasons.
>
> CouchDB running as your web server, database, and middle tier is crazy
> awesome. Your mileage will vary, but thanks to it's simple API over HTTP
> and the availability of the _changes API you have many options available to
> you.
>
> Now I do not have a lot of exposure to MongoDB (mostly just read about it a
> year ago). I would be interested in it's advantages over CouchDB.
>
> On Fri, Apr 15, 2011 at 3:24 AM, Dirkjan Ochtman<di...@ochtman.nl> wrote:
>
>> On Fri, Apr 15, 2011 at 06:03, Kinley Dorji<ki...@gmail.com> wrote:
>>> @John Taber: I agree on one point that I know of - MongoDB has a very
>>> accessible database shell.
>>>
>>> For example, entering something like demonstrates the full query
>>> support it has over all fields, not just the keyed field:
>>>
>>>> db.things.find({name:"mongo"}).forEach(printjson);
>>> That kind of support does make it engaging for new users. Here, like
>>> in some of the other areas you mentioned, CouchDB has a steeper curve.
>> I suppose you've seen Futon? Seems like a rather accessible UI to me.
>>
>> Cheers,
>>
>> Dirkjan
>>
>
>
Re: CouchDB's advantages over MongoDB
Posted by Sean Copenhaver <se...@gmail.com>.
CouchDB tries to make sure everything you do allows it to continue to scale
with good performance. So all the database functions are pretty much
isolated and can have no side effects. Easy example of the benefits of this
is the incremental map and reduce. I would be curious to know how MongoDB's
performance goes once you use a dynamic query on a data set that does not
fit into memory.
I will say that you have to mix the book and the wiki at the least to get a
good picture of everything.
Also for time to market that's really going to depend on how you need to use
the database. MongoDB could also be slower to market then PostgreSQL if I
picked it for the wrong reasons.
CouchDB running as your web server, database, and middle tier is crazy
awesome. Your mileage will vary, but thanks to it's simple API over HTTP
and the availability of the _changes API you have many options available to
you.
Now I do not have a lot of exposure to MongoDB (mostly just read about it a
year ago). I would be interested in it's advantages over CouchDB.
On Fri, Apr 15, 2011 at 3:24 AM, Dirkjan Ochtman <di...@ochtman.nl> wrote:
> On Fri, Apr 15, 2011 at 06:03, Kinley Dorji <ki...@gmail.com> wrote:
> > @John Taber: I agree on one point that I know of - MongoDB has a very
> > accessible database shell.
> >
> > For example, entering something like demonstrates the full query
> > support it has over all fields, not just the keyed field:
> >
> >> db.things.find({name:"mongo"}).forEach(printjson);
> >
> > That kind of support does make it engaging for new users. Here, like
> > in some of the other areas you mentioned, CouchDB has a steeper curve.
>
> I suppose you've seen Futon? Seems like a rather accessible UI to me.
>
> Cheers,
>
> Dirkjan
>
--
“The limits of language are the limits of one's world. “ -Ludwig von
Wittgenstein
Re: CouchDB's advantages over MongoDB
Posted by Dirkjan Ochtman <di...@ochtman.nl>.
On Fri, Apr 15, 2011 at 06:03, Kinley Dorji <ki...@gmail.com> wrote:
> @John Taber: I agree on one point that I know of - MongoDB has a very
> accessible database shell.
>
> For example, entering something like demonstrates the full query
> support it has over all fields, not just the keyed field:
>
>> db.things.find({name:"mongo"}).forEach(printjson);
>
> That kind of support does make it engaging for new users. Here, like
> in some of the other areas you mentioned, CouchDB has a steeper curve.
I suppose you've seen Futon? Seems like a rather accessible UI to me.
Cheers,
Dirkjan
Re: CouchDB's advantages over MongoDB
Posted by Kinley Dorji <ki...@gmail.com>.
@John Taber: I agree on one point that I know of - MongoDB has a very
accessible database shell.
For example, entering something like demonstrates the full query
support it has over all fields, not just the keyed field:
> db.things.find({name:"mongo"}).forEach(printjson);
That kind of support does make it engaging for new users. Here, like
in some of the other areas you mentioned, CouchDB has a steeper curve.
Still, once I started using tools like Benoit's excellent couchapp and
couchdbkit (I'm a Python guy), CouchDB's inherent support for two-tier
architecture (browser::CouchDB) became very, very compelling for me.
Awesomeness comes to mind again, especially given the huge
improvements in browser technology led by the folks at Chrome/Chromium
and Firefox.
IMHO, I found the online book CouchDB - The Definitive Guide to
provide an excellent intro to CouchDB. Of course there are parts where
I'd prefer more details but I guess that would be better suited for a
book like CouchDB Cookbook or CouchDB Recipes - I hope someone will
write it.
Regards,
On Fri, Apr 15, 2011 at 1:54 AM, John Taber <jo...@gmail.com> wrote:
> On 04/14/2011 09:56 AM, Kinley Dorji wrote:
>>
>> @Sean: Thanks for a great summary of CouchDB's awesomeness. :)
>
> Yes, but the discussion lacks the disadvantages, some are:
> 1) really poor how-to use case documentation, especially around map-reduce,
> auth (logins), syncing between mobile, servers,
> using nodejs to apply back-end logic, .......
> 2) db security
>
> Mongo is very easy to use and get projects going - at the moment, it is a
> huge winner for time-to-market.
>
>
>
>> On Thu, Apr 14, 2011 at 9:01 PM, Nebu Pookins<ne...@gmail.com>
>> wrote:
>>>
>>> On Thu, Apr 14, 2011 at 10:40 AM, Sean Copenhaver
>>> <se...@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.
>>>
>>> Thanks Sean, that makes sense. I've just now read another message by
>>> Luciano Ramalho, where Luciano essentially writes the same in the
>>> paper at http://journal.code4lib.org/articles/4893
>>>
>>> CouchDB was influenced by Lotus Notes, a networked, collaborative
>>> application suite designed to support users who are often off-line.
>>> So, CouchDB allows master-master replication, that is, synchronization
>>> between peer nodes which have received inserts and updates
>>> independently. MongoDB supports only master-slave replication: only
>>> one node receives updates and inserts, and replicates to the slaves.
>>>
>>> - Nebu
>>>
>
>
Re: CouchDB's advantages over MongoDB
Posted by John Taber <jo...@gmail.com>.
On 04/14/2011 09:56 AM, Kinley Dorji wrote:
> @Sean: Thanks for a great summary of CouchDB's awesomeness. :)
Yes, but the discussion lacks the disadvantages, some are:
1) really poor how-to use case documentation, especially around
map-reduce, auth (logins), syncing between mobile, servers,
using nodejs to apply back-end logic, .......
2) db security
Mongo is very easy to use and get projects going - at the moment, it is
a huge winner for time-to-market.
> On Thu, Apr 14, 2011 at 9:01 PM, Nebu Pookins<ne...@gmail.com> wrote:
>> On Thu, Apr 14, 2011 at 10:40 AM, Sean Copenhaver
>> <se...@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.
>> Thanks Sean, that makes sense. I've just now read another message by
>> Luciano Ramalho, where Luciano essentially writes the same in the
>> paper at http://journal.code4lib.org/articles/4893
>>
>> CouchDB was influenced by Lotus Notes, a networked, collaborative
>> application suite designed to support users who are often off-line.
>> So, CouchDB allows master-master replication, that is, synchronization
>> between peer nodes which have received inserts and updates
>> independently. MongoDB supports only master-slave replication: only
>> one node receives updates and inserts, and replicates to the slaves.
>>
>> - Nebu
>>
Re: CouchDB's advantages over MongoDB
Posted by Kinley Dorji <ki...@gmail.com>.
@Sean: Thanks for a great summary of CouchDB's awesomeness. :)
On Thu, Apr 14, 2011 at 9:01 PM, Nebu Pookins <ne...@gmail.com> wrote:
> On Thu, Apr 14, 2011 at 10:40 AM, Sean Copenhaver
> <se...@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.
>
> Thanks Sean, that makes sense. I've just now read another message by
> Luciano Ramalho, where Luciano essentially writes the same in the
> paper at http://journal.code4lib.org/articles/4893
>
> CouchDB was influenced by Lotus Notes, a networked, collaborative
> application suite designed to support users who are often off-line.
> So, CouchDB allows master-master replication, that is, synchronization
> between peer nodes which have received inserts and updates
> independently. MongoDB supports only master-slave replication: only
> one node receives updates and inserts, and replicates to the slaves.
>
> - Nebu
>
Re: CouchDB's advantages over MongoDB
Posted by Nebu Pookins <ne...@gmail.com>.
On Thu, Apr 14, 2011 at 10:40 AM, Sean Copenhaver
<se...@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.
Thanks Sean, that makes sense. I've just now read another message by
Luciano Ramalho, where Luciano essentially writes the same in the
paper at http://journal.code4lib.org/articles/4893
CouchDB was influenced by Lotus Notes, a networked, collaborative
application suite designed to support users who are often off-line.
So, CouchDB allows master-master replication, that is, synchronization
between peer nodes which have received inserts and updates
independently. MongoDB supports only master-slave replication: only
one node receives updates and inserts, and replicates to the slaves.
- Nebu
Re: CouchDB's advantages over MongoDB
Posted by Sean Copenhaver <se...@gmail.com>.
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 <ne...@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 <cz...@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í <it...@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
Re: CouchDB's advantages over MongoDB
Posted by Nebu Pookins <ne...@gmail.com>.
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 <cz...@dimagi.com> wrote:
> Master - Master replication
>
> On Thu, Apr 14, 2011 at 6:51 AM, Robert Newson <ro...@gmail.com>wrote:
>
>> 'Unlimited document size" - Not true.
>> "Atomic Bulk Operations" -- Not in the sense you probably mean.
>>
>> B.
>>
>> 2011/4/14 Daniel Itaboraí <it...@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.
>>>
>>
Re: CouchDB's advantages over MongoDB
Posted by Cory Zue <cz...@dimagi.com>.
Master - Master replication
On Thu, Apr 14, 2011 at 6:51 AM, Robert Newson <ro...@gmail.com>wrote:
> 'Unlimited document size" - Not true.
> "Atomic Bulk Operations" -- Not in the sense you probably mean.
>
> B.
>
> 2011/4/14 Daniel Itaboraí <it...@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.
> >
>
Re: CouchDB's advantages over MongoDB
Posted by Robert Newson <ro...@gmail.com>.
'Unlimited document size" - Not true.
"Atomic Bulk Operations" -- Not in the sense you probably mean.
B.
2011/4/14 Daniel Itaboraí <it...@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.
>
Re: CouchDB's advantages over MongoDB
Posted by Luciano Ramalho <lu...@ramalho.org>.
One word: simplicity.
One should always choose the simplest solution that solves a problem.
If CouchDB solves your problem, there's no reason to choose a more
complex alternative. It's just sound engineering.
Cheers,
Luciano
Re: CouchDB's advantages over MongoDB
Posted by Sean Copenhaver <se...@gmail.com>.
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 <se...@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í <it...@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
Re: CouchDB's advantages over MongoDB
Posted by Sean Copenhaver <se...@gmail.com>.
>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í <it...@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
Re: CouchDB's advantages over MongoDB
Posted by Mage <ma...@mage.hu>.
Hello,
I am new to CouchDB, coming from Postgresql (which doesn't mean I am
leaving PG). I never built anything on either MongoDB or CouchDB.
However I spent some time (two weeks maybe) to try and see the current
NOSql databases. I "tested" Cassandra, HBase, MongoDb, CouchDB and Neo4J
too. My tests were neither deep nor professional. I was just trying to
figure out which one to jump into.
And yes, they are very different. Finally I found myself thinking about
HBase and CouchDB. They are also totally different. I've chosen CouchDB
to learn.
The truth is that I wouldn't send my important data to MongoDB. And I
don't really send any non-important data anywhere.
MongoDB is not durable in my opinion. And in my test it wasn't even
stable, however that might be the fault if the client library I used.
I am using Gentoo amd64. Mongo version was 1.6 (there was not any stable
release for Gentoo amd64 that time). I used Rails 3.0.4 and gem
"mongo_mapper".
There were 97k records (users) migrated from a live, working
application, just copied from postgresql models to mongo_mapper without
any denormalization. Just for inserting something. Then I tried
delete_all (or destroy_all, can't recall) with MongoDB, which successed
in 1 second. Then I sent the very same command again to the
theoretically empty database. I pressed arrow up and enter. And I got an
exception from MongoDB or mongo_mapper. This should never happen.
My laptop has 4G ram, 4G swap on SSD. "Working" (well, I mean inserting
and deleting) with 97k records with MongoDB, mongo_mapper and Rails just
made the OOM Killer taking actions, several times. This was the point
when I said goodby to Mongo. Sorry, it might be my mistake, but too bad
for a first experience.
Again, I am not saying it was a native MongoDB fault, it could be the
client library too, however checking "top" command shown that Mongo is
eating the memory.
By the way, Postgesql or CouchDB is also very fast when installed into
ramdisk. This is how Mongo works.
For me MongoDB is something like MySQL. I think MySQL people will like
it. (Without starting any flame I would never use Mysql when it is
possible to avoid. And always is.)
For me CouchDB seems very exiting and fresh, something unique.
Mage
On 04/14/2011 03:47 PM, Daniel Itaboraí wrote:
> 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).
>
Re: CouchDB's advantages over MongoDB
Posted by Mage <ma...@mage.hu>.
On 04/14/2011 03:47 PM, Daniel Itaboraí wrote:
> -
>
> Crash Proof durability (not having to replicate to achieve durability as
> a best practice)
MongoDB will not become crash-proof just by migration. If your cluster
goes down together, for example by power failure in the datacenter, you
can end up all your nodes corrupted.
Since v1.7.5 it can be run with journaling, however you should read this
page before you decide:
http://www.mongodb.org/display/DOCS/Journaling
"Can I use the journaling feature to perform safe hot backups?
Not yet, as the journal files are rotated out (unlinked) after data is
safely in the data files."
"MongoDB may determine that it is faster to preallocate journal files
than to create them as needed. If MongoDB decides to preallocate the
files, it will not start listening on port 27017 until this process
completes, which can take a few minutes. This means that your
applications and the shell will not be able to connect to the database
immediately on initial startup."
Mage
Re: CouchDB's advantages over MongoDB
Posted by Joel Lucsy <jj...@gmail.com>.
2011/4/14 Daniel Itaboraí <it...@gmail.com>
> Crash Proof durability (not having to replicate to achieve durability as
> a best practice)
>
Latest version of MongoDB has a durability switch that should effectively
mimic CouchDB's crash protection, tho implemented completely differently.
Its more of a rollback if the change journal is present.