7 ms·

Comparing Mongo DB and Couch DB

42 points by rgbrgb 15y ago

rgbrgb 15y ago
Basically I think this is pointing to mongo for replacing traditional website databases and couch for only special cases. Do you guys think this is fair? I haven't spent too much time with either but I'm a little bit suspicious because this is from mongodb. Anybody know of any other direct comparisons between these?
- rnewson 15y ago
  For my part (and I'm biased) a database that doesn't consider durability paramount shouldn't be considered a database at all.
  - StavrosK 15y ago
    I am inclined to agree. I don't trust Mongo with my data, although I would consider it for things I don't mind losing. That is, if redis didn't exist. Apart from that, I actually found the comparison fair and accurate.
  - rubyrescue 15y ago
    I don't consider redis durable for similar reasons as mongo - yet redis doesn't hide what it is or what it lacks in terms of durability... so it doesn't bother me that it isn't. but mongo often downplays it's lack of durability, which makes me wary of using it or recommending it because people don't know how to use it.
    - rbranson 15y ago
      This is exactly the problem with MongoDB. It's practical use is a semi-durable, in-memory data store, but they advertise it as a data store of record that can be used for large, >RAM sets of any conceivable use case.
  - rdtsc 15y ago
    It seemed a bit dishonest seeing benchmarks that showed how MongoDB beats CouchDB in write-performance tests when there was no acknowledgement of write requests comming back to the client. Not saying that MongoDB wouldn't be faster with full commits turn on, it is just that their design decision to pick that as the default and calling their product a 'database' seemed very strange at best, and dishonest at worst.
    - deleted 15y ago
      [deleted]
    - rit 15y ago
      For the record: we (MongoDB) have a policy of not posting official Benchmarks. Could you clarify what benchmarks you are referring to that were posted and "dishonest"? The only benchmarks we have ever done have been for internal testing comparisons between different versions. The "Benchmarks" page on our site clarifies this policy: http://www.mongodb.org/display/DOCS/Benchmarks http://www.mongodb.org/display/DOCS/Benchmarks Previously there were several third party benchmarks on this page, which we recently took down to stand firmer on our benchmark policy. In the interest of full disclosure however, you may examine the page history to verify that we have always clarified these as unaffiliated third party sourced.
mark242 15y ago
I'm a little biased, being a pretty heavy CouchDB user, but it seems like Mongo is claiming that their auto-sharding is the defining reason to use Mongo. The forthcoming release of Couchbase 2.0 is going to have the same type of functionality, with buckets distributed across the cluster rather than required replication of the full dataset. Couchbase 3.0 should (if I remember correctly) have the functionality for both the key/value store and for view results.
- rnewson 15y ago
  And BigCouch has sharding too (edited to add: for data and views)
ConstantineXVI 15y ago
I'm new to both (and noSQL in general), first heard about CouchDB a week or two ago. Would Couch be a good fit for building a logging system, or is there something else I should look into?
- rdtsc 15y ago
  I wouldn't use it for a write-heavy logging system ( and I am a big fan of it). Well actually it depends on what type of logging. If you plan on pouring megabytes of data/sec second into it continuously you might want to find something else. I don't think CouchDB would be a good candidate for that. It might be if you plan on archiving your post-processed logged data for a long term storage but you have to be smart about its format. Yeah 'logging' can mean a lot of things that it is hard to give a better advice without more information. Other DBs/tools you might want to look at: * rrdtool http://oss.oetiker.ch/rrdtool/ http://oss.oetiker.ch/rrdtool/ * MongoDB http://www.mongodb.org/ http://www.mongodb.org/ * Redis http://redis.io/ http://redis.io/ * Custom format + plain text files
  - andrewvc 15y ago
    So, both MongoDB and Redis are DB's optimized for keeping stuff heavily in memory. I wouldn't use either for heavy logging. RRDTool is nice, but only for data where you don't mind losing records. For straight logging, SQL is actually a better solution than a lot of those options. If you need weird queries, something like Elastic Search or Solr on top of your SQL DB can buy you quite a bit of freedom. As can denormalizing your SQL. One other thing to consider of course, is something like syslog.
    - tilgovi 15y ago
      HBase might be a good solution, too, but I don't know a whole lot about it. CouchDB would work fine but you'd want to add some operational automation and a proxy to roll over between temporary databases since deleting old logs from a single database won't fully reduce its size and, as stated above, compaction isn't terribly fun or fast but you can avoid it by just flat out deleting old log databases.
superjared 15y ago
--dur
shiflett 15y ago
Here are two relevant posts from a startup that migrated from CouchDB to MongoDB: http://seancoates.com/blogs/gimme-bar-no-longer-on-couchdb http://seancoates.com/blogs/gimme-bar-no-longer-on-couchdb http://seancoates.com/blogs/gimme-bar-on-mongodb http://seancoates.com/blogs/gimme-bar-on-mongodb
- js4all 15y ago
  I don't see how these posts are relevant for a general purpose comparison. It is one use case which doesn't fit CouchDB. Such articles give users a wrong impression. Fact is that MongoDB doesn't fit this use case either. Good solutions handle the following graph separate from the main implementation using specialized graph databases.
js4all 15y ago
I am a fan of both and decide from case to case which one to use. Both are under heavy development. I am often surprised about new features when checking the newest versions.

42 points by rgbrgb 15y ago

Basically I think this is pointing to mongo for replacing traditional website databases and couch for only special cases. Do you guys think this is fair? I haven't spent too much time with either but I'm a little bit suspicious because this is from mongodb. Anybody know of any other direct comparisons between these?

rnewson 15y ago
For my part (and I'm biased) a database that doesn't consider durability paramount shouldn't be considered a database at all.
- StavrosK 15y ago
  I am inclined to agree. I don't trust Mongo with my data, although I would consider it for things I don't mind losing. That is, if redis didn't exist. Apart from that, I actually found the comparison fair and accurate.
- rubyrescue 15y ago
  I don't consider redis durable for similar reasons as mongo - yet redis doesn't hide what it is or what it lacks in terms of durability... so it doesn't bother me that it isn't. but mongo often downplays it's lack of durability, which makes me wary of using it or recommending it because people don't know how to use it.
  - rbranson 15y ago
    This is exactly the problem with MongoDB. It's practical use is a semi-durable, in-memory data store, but they advertise it as a data store of record that can be used for large, >RAM sets of any conceivable use case.
- rdtsc 15y ago
  It seemed a bit dishonest seeing benchmarks that showed how MongoDB beats CouchDB in write-performance tests when there was no acknowledgement of write requests comming back to the client. Not saying that MongoDB wouldn't be faster with full commits turn on, it is just that their design decision to pick that as the default and calling their product a 'database' seemed very strange at best, and dishonest at worst.
  - deleted 15y ago
    [deleted]
  - rit 15y ago
    For the record: we (MongoDB) have a policy of not posting official Benchmarks. Could you clarify what benchmarks you are referring to that were posted and "dishonest"? The only benchmarks we have ever done have been for internal testing comparisons between different versions. The "Benchmarks" page on our site clarifies this policy: http://www.mongodb.org/display/DOCS/Benchmarks http://www.mongodb.org/display/DOCS/Benchmarks Previously there were several third party benchmarks on this page, which we recently took down to stand firmer on our benchmark policy. In the interest of full disclosure however, you may examine the page history to verify that we have always clarified these as unaffiliated third party sourced.

mark242 15y ago

I'm a little biased, being a pretty heavy CouchDB user, but it seems like Mongo is claiming that their auto-sharding is the defining reason to use Mongo. The forthcoming release of Couchbase 2.0 is going to have the same type of functionality, with buckets distributed across the cluster rather than required replication of the full dataset. Couchbase 3.0 should (if I remember correctly) have the functionality for both the key/value store and for view results.

rnewson 15y ago
And BigCouch has sharding too (edited to add: for data and views)

ConstantineXVI 15y ago

I'm new to both (and noSQL in general), first heard about CouchDB a week or two ago. Would Couch be a good fit for building a logging system, or is there something else I should look into?

rdtsc 15y ago
I wouldn't use it for a write-heavy logging system ( and I am a big fan of it). Well actually it depends on what type of logging. If you plan on pouring megabytes of data/sec second into it continuously you might want to find something else. I don't think CouchDB would be a good candidate for that. It might be if you plan on archiving your post-processed logged data for a long term storage but you have to be smart about its format. Yeah 'logging' can mean a lot of things that it is hard to give a better advice without more information. Other DBs/tools you might want to look at: * rrdtool http://oss.oetiker.ch/rrdtool/ http://oss.oetiker.ch/rrdtool/ * MongoDB http://www.mongodb.org/ http://www.mongodb.org/ * Redis http://redis.io/ http://redis.io/ * Custom format + plain text files
- andrewvc 15y ago
  So, both MongoDB and Redis are DB's optimized for keeping stuff heavily in memory. I wouldn't use either for heavy logging. RRDTool is nice, but only for data where you don't mind losing records. For straight logging, SQL is actually a better solution than a lot of those options. If you need weird queries, something like Elastic Search or Solr on top of your SQL DB can buy you quite a bit of freedom. As can denormalizing your SQL. One other thing to consider of course, is something like syslog.
  - tilgovi 15y ago
    HBase might be a good solution, too, but I don't know a whole lot about it. CouchDB would work fine but you'd want to add some operational automation and a proxy to roll over between temporary databases since deleting old logs from a single database won't fully reduce its size and, as stated above, compaction isn't terribly fun or fast but you can avoid it by just flat out deleting old log databases.

superjared 15y ago

--dur

shiflett 15y ago

Here are two relevant posts from a startup that migrated from CouchDB to MongoDB: http://seancoates.com/blogs/gimme-bar-no-longer-on-couchdb http://seancoates.com/blogs/gimme-bar-no-longer-on-couchdb http://seancoates.com/blogs/gimme-bar-on-mongodb http://seancoates.com/blogs/gimme-bar-on-mongodb

js4all 15y ago
I don't see how these posts are relevant for a general purpose comparison. It is one use case which doesn't fit CouchDB. Such articles give users a wrong impression. Fact is that MongoDB doesn't fit this use case either. Good solutions handle the following graph separate from the main implementation using specialized graph databases.

js4all 15y ago

I am a fan of both and decide from case to case which one to use. Both are under heavy development. I am often surprised about new features when checking the newest versions.