Mongodb vs couchdb
Do you guys have any advice choosing between couchdb and mongodb?? My project is written in python and uses json documents to communicate with a javascript frontend. Runs on the tornado webserver.
CouchDB is pretty much the only (open-source) game in town if you care about offline replication. It is also designed for extreme reliability and concurrency. CouchDB's programming model is designed to scale from a smartphone to a datacenter, and ops teams can scale it strictly in the HTTP domain.
MongoDB trades robustness and concurrency for faster serial performance for single clients. MongoDB's programming model is closer to MySQL or redis, so it isn't as big a leap for developers used to traditional 3-tier architectures.
I expect to see a lot of apps move between the two platforms as people start to find the sweet spot that they are interested in.
Both are cool, seriously, and you know. Lots of developers are going to use this software, but every time the lack of such features just rejecting these people.
1. Add real transactions to CouchDB/Mongo 2. Add unique indexes to CouchDB. IIRC Mongo has already. 3. Add map/reduce chaining to CouchDB 4. Dominate the world!
Example, one op can pick a money account, decrement its balance, and push an entry to the list of outbound transfers. After a few more similarly atomic steps, you have a safe and restartable money transfer.
The upside of working with this extra complication is that your data scales via sharding far beyond the maximum size of a MySQL installation.
However I found that insert latency was very poor, and it could only about 16 inserts/second. My apps are generally write heavy (bulk not an option) so I felt it wouldn't be the right fit for me.
I also managed to accidentally cause CouchDB to use all my memory a few times. The fact that this was even possible out of the box would make me hesitant to use it in production.
one thing, though, to watch out for is that only the "unstable" dev version of mongodb (1.3.x) has read concurrency - before 1.3.x, mongo uses a global read/write lock per operation. general and index-assisted reads are ultra-fast in mongo, but a bigger map/reduce or group call will block other requests until complete, possibly causing traffic to back up. because of that global lock, all writes block, too, but i've never had a problem with that IRL. writes are super-fast.
if you want an orm for mongo, check out mongoengine on github: http://github.com/hmarr/mongoengine/tree/master/mongoengine/
:- alex