3 ms·
As I would put it: In the event of a single server crash, Mongo may need to be restored from backup, or another master. CouchDB handles this much better, and c
by wisty 15y ago
As I would put it:
In the event of a single server crash, Mongo may need to be restored from backup, or another master. CouchDB handles this much better, and can just restart where it left off. But in the worst possible single-server scenario, there's smoke coming out of your server and the hard drive is toast. CouchDB and MongoDB perform about the same - if you had replication or a recent backup, you are fine. If you didn't, you are f*cked.
CouchDB is better for small servers which crash a lot and can't use replication. You can run it on a mobile phone. Mongo is better for logging (where you need fast writes, and don't care about a couple of lost records). Most uses will be somewhere in between, and you need to know the limitations of the stack, so you can work around them.
- rit 15y agoIf you are running with journaling enabled, you should get a much stronger crash recovery case. In the event of a crash, the journal will be replayed: http://www.mongodb.org/display/DOCS/Journaling http://www.mongodb.org/display/DOCS/Journaling
- rdtsc 15y agoAnd that is a good feature on a database to have! Why not make it the default?
- rit 15y agoWhen we added it, being a new feature the decision was made not to initially flip it to default in case of bugs, unexpected behavior, etc. As noted, it's possible that will change in future releases; there's been a lot of improvements to journaling since its initial release.
- rdtsc 15y agoOne needs an off-site backup of the data anyway to handle the 'smoking server' case anyway. But I don't see how saying that a server can catch on fire so we should bother with default durability guarantees anyway is a sane choice. It is like saying that cars can catch on fire so why bother wearing seat-belts.