6 ms·
Respectfully, this isn't true. Yes, fire and forget is the default behavior, but there is a confirmation step that you can check. It may be implemented a bit di
by jasonmccay 15y ago
Respectfully, this isn't true. Yes, fire and forget is the default behavior, but there is a confirmation step that you can check. It may be implemented a bit differently from driver to driver, but it is generally called a "safe insert". Numerous people use this to ensure their writes across single databases as well as multi-node master-slave and replica sets.
- brndnhy 15y agoThat doesn't actually guarantee the write was written to disk unless an fsync was issued. Of course that comes with a significant effect on MongoDB's famously marketed write performance.
- hogu 15y agoyes but the redundancy you have to use with mongodb gives you a very low probability of that type of failure.
- brndnhy 15y agoThen in MongoDB's case durability is a function of scale, which leads back to the parent's suggestion that it is a technology optimized for performance. Personally I think this is a bad foundation for data that is important. There are probably a lot of use cases where data not being on disk for n seconds (or one minute in the case of MongoDB) is ok. Even when that is the case, I still think that is the most important question to be addressed when choosing MongoDB as a data store. The flexible query API, schema-less document format, secondary indices... those are siren songs of rapid development.
- mtogo 15y agoRespectfully, this isn't true. Safe inserts are safer, but not safe. There could still be a problem writing the data to disk, and (My|Postgre)SQL just doesn't have this problem.
- jasonmccay 15y agoAssuming the changes that were introduced in MongoDB 1.8 for single-server durability, writes are being put to disk with journaling. So, the data is written to disk.