5 ms·

Keep in mind this is a year old and MongoDB has since implemented journalling (although afaik it's not on by default yet). It's not specifically a response to

Keep in mind this is a year old and MongoDB has since implemented journalling (although afaik it's not on by default yet). It's not specifically a response to this article - But you can read 10gen's view on durability here: http://blog.mongodb.org/post/381927266/what-about-durability http://blog.mongodb.org/post/381927266/what-about-durability

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 ago
  If 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 ago
    And that is a good feature on a database to have! Why not make it the default?
    - rit 15y ago
      When 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 ago
  One 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.
rdtsc 15y ago
From the article: > To start, there are some very practical reasons why we think single server durability is overvalued. Most people should just stop reading at that line. > If you have durability through a transaction log, then you have to replay it to come back up. That shows a serious misunderstanding how append-only can work. In CouchDB's case there is no need to replay the whole file just find last consistent piece of data at the end. So seek close to end & find last consistent header. > If you have a master and slave in the same data center and you lose power, both will have to recover which could take 5-30 minutes.[1] If you use MongoDB your DB apparently can get corrupted and you won't find out about for another month (link from article): http://www.korokithakis.net/posts/using-mongodb-for-great-science-part-2/ http://www.korokithakis.net/posts/using-mongodb-for-great-sc... > If you have a 100 node cluster, worrying about every machine is a liability. I see having to buy 100 nodes to get durability as a non-starter. I mentioned this before and I'll say it again that calling their product a database and by default not returning write results is dishonest. 10gen employee (Kristina Chodorow) replying to the article admits that "We did this to make MongoDB look good in stupid benchmarks" Well that's fine but then just call it rrdtool-ng
- wisty 15y ago
  I think she was being sarcastic. But yes, it does make MongoDB look good (as in, better than Redis, not just 10X the speed of CouchDB) in stupid benchmarks. MongoDB is designed to be fast by default, which I like. But it can bite you. I like its speed, and its interface, binary data (which saves disk space), and documentation. I'm not sure if it's data structure is sound though. I'd really like something with CouchDB's append only log, and MongoDB's interface (fast and easy), rich updates, and documentation.
  - rdtsc 15y ago
    I don't mind it being fast by default if they don't call it a 'database', they should have made the fast+lose_your_data mode a user configuration not the default. People have lost and will lose their data. They see aha database [check], download [check], run benchmark [check], ok, put in production.

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 ago
If 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 ago
  And that is a good feature on a database to have! Why not make it the default?
  - rit 15y ago
    When 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 ago
One 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.

rdtsc 15y ago

From the article: > To start, there are some very practical reasons why we think single server durability is overvalued. Most people should just stop reading at that line. > If you have durability through a transaction log, then you have to replay it to come back up. That shows a serious misunderstanding how append-only can work. In CouchDB's case there is no need to replay the whole file just find last consistent piece of data at the end. So seek close to end & find last consistent header. > If you have a master and slave in the same data center and you lose power, both will have to recover which could take 5-30 minutes.[1] If you use MongoDB your DB apparently can get corrupted and you won't find out about for another month (link from article): http://www.korokithakis.net/posts/using-mongodb-for-great-science-part-2/ http://www.korokithakis.net/posts/using-mongodb-for-great-sc... > If you have a 100 node cluster, worrying about every machine is a liability. I see having to buy 100 nodes to get durability as a non-starter. I mentioned this before and I'll say it again that calling their product a database and by default not returning write results is dishonest. 10gen employee (Kristina Chodorow) replying to the article admits that "We did this to make MongoDB look good in stupid benchmarks" Well that's fine but then just call it rrdtool-ng

wisty 15y ago
I think she was being sarcastic. But yes, it does make MongoDB look good (as in, better than Redis, not just 10X the speed of CouchDB) in stupid benchmarks. MongoDB is designed to be fast by default, which I like. But it can bite you. I like its speed, and its interface, binary data (which saves disk space), and documentation. I'm not sure if it's data structure is sound though. I'd really like something with CouchDB's append only log, and MongoDB's interface (fast and easy), rich updates, and documentation.
- rdtsc 15y ago
  I don't mind it being fast by default if they don't call it a 'database', they should have made the fast+lose_your_data mode a user configuration not the default. People have lost and will lose their data. They see aha database [check], download [check], run benchmark [check], ok, put in production.