Comparing Mongo dB and couch DB

Document directory

• MVCC
• Horizontal scalability
• Query expression
• Atomicity
• Durability
• Map reduce
• Javascript
• Rest
• Performance
• Use Cases

Http://www.mongodb.org/display/DOCS/Comparing+Mongo+DB+and+Couch+DB, English

Http://www.searchdatabase.com.cn/showcontent_46595.htm (Chinese)

 

The most fundamental difference is that the difference in application scenarios is the difference in the choice of CAP.

MongoDB chooses to sacrifice availability to ensure consistency and atomicity, while couchdb chooses to discard consistency and maintain high availability. Therefore, couchdb is more like kV and nosql, while MongoDB is too similar to relational databases.

 

We are getting a lot of questions "How are Mongo dB and couch different? "It's a good question: both are document-oriented databases with schemaless JSON-style object data storage. both products have their place -- we are big believers that databases are specializing and "one size fits all" no longer applies.

We are not couchdb gurus so please let us know in the forums if we have something wrong.

 

MVCC

OneBig DifferenceIs thatCouchdb isMVCCBased, AndMongoDBIs more ofTraditional Update-in-place store.
MVCC is very good for certain classes of problems:

• Problems which need intense versioning;
• ProblemsOfflineDatabases that Resync later;
• Problems where you want a large amountMaster-MasterReplication happening.

Along with MVCC comes some work too:

• First, the database must beCompactedPeriodically, if there are already updates.
• Second, whenConflictsOccur on transactions, they must be handled by the programmerManually(Unless the DB also does conventional locking -- although then master-master replication is likely lost ).

MongoDB updates an object in-place when possible. problems requiring high update rates of objects are a great fit; compaction is not necessary. mongo's replication works great but, without the MVCC model, it is more oriented towards master/slave and auto failover configurations than to complex master-master setups. with MongoDB you shoshould see high write performance, especially for updates.

This should be the biggest difference. MongoDB adopts a policy similar to traditional databases. The features of update in-place, Master/Slave, and auto failover. MongoDB are high efficiency, especially update.

Couchdb uses the append-only method, which is rare. It can support MVCC, Master/master, and offline operations.

 

Horizontal scalability

One fundamental difference is that a numberCouchUsers useReplication as a way to scale.

With Mongo, we tend to think of replication as a way to gain reliability/failover rather than scalability.MongoUses(Auto) shardingAs our path to scalabity (sharding is Ga As of 1.6). In this sense MongoDB is more like Google bigtable. (We hear that couch might one day add partitioning too .)

This is also a major weakness of couchdb. I don't think replication can calculate the horizontal scaling method. If partition is not supported...

 

Query expression

Couch uses a clever index building scheme to generate indexes which support fig. there is an elegance to the approach, although one must predeclare these structures for each query one wants to execute. one can think of them as materialized views.

Mongo uses traditional dynamic queries. As with, say, MySQL, We Can Do queries where an index does not exist, or where an index is helpful but only partially so. mongo includes a query optimizer which makes these determinations. we find this is very nice for inspecting the data administratively, and this method is also good when weDon'tWant an index: such as insert-intensive collections. when an index corresponds perfectly to the query, the couch and Mongo approaches are then conceptually similar. we find expressing queries as JSON-style objects in MongoDB to be quick and painless though.

Update aug2011: couch is adding a new Query Language"Unql".

Similar to traditional database systems, apsaradb for MongoDB supports dynamic queries, even on rows without indexes. Different from couchdb, couchdb does not support dynamic queries. You must create a view for each of your query modes and perform queries based on this view.

 

Atomicity

Both MongoDB and couchdb support concurrent modifications of single clients. Both forego complex transactions involving large numbers of objects.

All support atomic modification.

 

Durability

Couchdb is a "crash-only" design where the DB can terminate at any time and remain consistent.

Previous versions of MongoDB used a storage engine that wocould require a repairdatabase () operation when starting up after a hard crash (similar to MySQL's MyISAM ). version 1.7.5 and higher offer durability via journaling; specify-- JournalCommand Line Option

Couchdb is append-only, and the two-step commit can ensure data consistency. Crash will only lead to the loss of new data, but will not lead to the inconsistency of old data.

MongoDB is the same as traditional databases. Crash will inevitably lead to data inconsistency and needs to be repair

 

Map reduce

Both couchdb and MongoDB support MAP/reduce operations. for couchdb MAP/reduce is inherent to the building of all views. with MongoDB, MAP/reduce is only for data processing jobs but not for traditional queries.

The MAP/reduce of couchdb is only used for View queries on a single node.

MongoDB is relatively reliable for data statistics on multiple shard instances.

 

Javascript

Both couchdb and MongoDB make use of JavaScript. couchdb uses JavaScript extensively including in the building of views.

MongoDB supports the use of JavaScript but more as an adjunct. in MongoDB, Query expressions are typically expressed as JSON-style query objects; however one may also specify a javascript expression as part of the query. mongoDB also supports running arbitrary JavaScript Functions server-side and uses JavaScript For MAP/reduce operations.

Simply put, it is used in different places.

 

Rest

CouchUsesRest as its interfaceTo the database. With its focus on performance,MongoDBRelies on language-specific database drivers for access to the database overCustom binary Protocol. Of course, one cocould Add a rest interface atop an existing MongoDB driver at any time -- that wocould be a very nice community project. Some early stage rest implementations exist for MongoDB.

 

Performance

Philosophically, Mongo is very oriented toward performance, at the expense of features that wocould impede performance. we see Mongo dB being useful for your problems where databases have not been used in the past because databases are too "heavy ". features that give MongoDB good performance are:

• Client driver per language:Native SOCKET protocolFor Client/Server Interface (not rest)
• UseMemory mapped FilesFor data storage, memory consumption is very high
• Collection-oriented storage(Objects from the same collection are stored contiguously)
• Update-in-place (not MVCC)
• Written inC ++

 

Use Cases

It may be helpful to look at some special problems and consider how we cocould solve them.

• If we were building Lotus Notes, We wocould use couch as its programmer versioning reconciliation/MVCC model fits perfectly. any problem where data is offline for hours then back online wocould fit this. in general, if we need severalEventually consistent Master-master replicaDatabases, geographically distributed,Often offline, We wocould use couch.
• Mobile
  • CouchIs better as a mobileEmbedded DatabaseOn Phones, primarily because of its online/offine replication/Sync capabilities.
  • We likeMongo server-side; One reason is its geospatial indexes.
• If we hadVery high performanceRequirements we wocould useMongo. For example, web site user profile Object Storage and caching of data from other sources.
• For a problem with very high update rates, we wocould use Mongo as it is good at that because of its "Update-in-place" design. For example see updating Real Time analytics counters
• In contrast to the above, couch is better when lots of snapshotting is a requirement because of its MVCC design.

Generally, we find MongoDB to be a very good fit for Building Web infrastructure.