If you are coming from the MySQL world, MongoDB is going to "feel" a lot more natural to you because of its query-like language support.
I think that is what makes it so friendly for a lot of people.
CouchDB is fantastic if you want to utilize the really great master-master replication support with a multi-node setup, possibly in different data centers or something like that.
MongoDB's replication (replica sets) is a master-slave-slave-slave-* setup, you can only write to the master in a replica set and read from any of them.
For a standard site configuration, that is fine. It maps to MySQL usage really well.
But if you are trying to create a global service like a CDN that needs to keep all global nodes synced even though read/write to all of them, something like the replication in CouchDB is going to be a huge boon to you.
While MongoDB has a query-like language that you can use and feels very intuitive, CouchDB takes a "map-reduce" approach and this concepts of views. It feels odd at first, but as you get the hang of it, it really starts feeling intuitive.
Here is a quick overview so it makes some sense:
- CouchDB stores all your data in a b-tree
- You cannot "query" it dynamically with something like "SELECT * FROM user WHERE..."
- Instead, you define discrete "views" of your data... "here is a view of all my users", "here is a view of all users older than 10" "here is a view of all users older than 30" and so on.
- These views are defined using map-reduce approach and are defined as JavaScript functions.
- When you define a view, the DB starts feeding all the documents of the DB you assigned the view to, through it and recording the results of your functions as the "index" on that data.
- There are some basic queries you can do on the views like asking for a specific key (ID) or range of IDs regardless of what your map/reduce function does.
- Read through these slides, it's the best clarification of map/reduce in Couch I've seen.
So both of these sources use JSON documents, but CouchDB follows this more "every server is a master and can sync with the world" approach which is fantastic if you need it, while MongoDB is really the MySQL of the NoSQL world.
So if that sounds more like what you need/want, go for that.
Little differences like Mongo's binary protocol vs the RESTful interface of CouchDB are all minor details.
If you want raw speed and to hell with data safety, you can make Mongo run faster than CouchDB as you can tell it to operate out of memory and not commit things to disk except for sparse intervals.
You can do the same with Couch, but it's HTTP-based communication protocol is going to be 2-4x slower than raw binary communication with Mongo in this "speed over everything!" scenario.
Keep in mind that raw crazy insane speed is useless if a server crash or disk failure corrupts and toasts your DB into oblivion, so that data point isn't as amazing as it might seem (unless you are doing real-time trading systems on Wall Street, in which case look at Redis).
Hope that all helps!
