“丢失数据”的批评在多大程度上对 MongoDB 仍然有效？ I'm referring to the following :
1. MongoDB issues writes in unsafe ways by default in order to win benchmarks
If you don't issue getLastError(), MongoDB doesn't wait for any confirmation from the database that the command was processed. This introduces at least two classes of problems:
- In a concurrent environment (connection pools, etc), you may have a subsequent read fail after a write has "finished"; there is no barrier condition to know at what point the database will recognize a write commitment
- Any unknown number of save operations can be dropped on the floor due to queueing in various places, things outstanding in the TCP buffer, etc, when your connection drops of the db were to be KILL'd or segfault, hardware crash, you name it
2. MongoDB can lose data in many startling ways
Here is a list of ways we personally experienced records go missing:
- They just disappeared sometimes. Cause unknown.
- Recovery on corrupt database was not successful, pre transaction log.
- Replication between master and slave had gaps in the oplogs, causing slaves to be missing records the master had. Yes, there is no checksum, and yes, the replication status had the slaves current
- Replication just stops sometimes, without error. Monitor your replication status!
...[other criticisms]
最佳答案
上下文注释:
这个问题是在 2012 年提出的，但直到今天仍然可以看到流量和投票。最初的答案是专门反驳一个在问题发生时很受欢迎的特定帖子。自从写下这个答案以来，事情已经发生了巨大的变化(并继续发生着变化)。与 2012 年相比，MongoDB 确实变得更加耐用和可靠，当时甚至基本日记等功能都相对较新。我对这个答案投了反对票和评论，因为人们觉得我没有解决当前(对于给定的当前值)对标题问题(不是细节)的一般答案:“丢失的数据批评仍然有效吗？”。我试图在下面的更新中澄清，但这个问题基本上没有完美的答案，这取决于你的观点，你的期望是什么，你使用的是什么版本，什么配置，你是否对默认设置感到不安等等。
原答案:
MongoDB 首席技术官兼联合创始人 Eliot Horowitz 在这里逐点揭穿了那个特定的帖子:
http://news.ycombinator.com/item?id=3202959
这里也有一个很好的总结:
http://www.betabeat.com/2011/11/10/the-trolls-come-out-for-10gen/
简短的版本是，看起来这基本上是有人在吸引注意力(成功)，没有确凿的证据或佐证。过去曾发生过真正的事件，随着产品的发展(例如，参见 1.8 中日记的介绍)或在发现并修复了更具体的错误时，这些事件已得到处理。
免责声明:我确实为 MongoDB(以前的 10gen)工作，并且喜欢 philnate 来到这里并首先独立反驳这一事实-这可能比其他任何事情都更能说明产品:)
更新:2013 年 8 月 19 日
我最近在这个答案上看到了很多事件，我认为这与 SERVER-10478 中的错误公告有关。 - 这肯定是一个极端情况，但我仍然建议任何使用大文档分片的人尽快将其升级到 v2.2.6 和 v2.4.6，其中包括针对此问题的修复。
更新:2017 年 3 月 24 日
我不再为 MongoDB 工作，但仍然支持这个答案。鉴于这个答案继续获得支持(和反对)票并收到很多观点，我想指出人们 this post这显示了自提出此问题以来 MongoDB 取得的进展。数据库现在通过了 Jepsen测试，并有 integrated the tests在它的构建过程中，有很多更成熟的系统没有通过。任何人在 2017 年仍然击败数据丢失鼓的人真的没有注意到。
更新:2020 年 5 月 24 日
杰普森有 re-analyzed MongoDB 4.2.6鉴于 MongoDB 现在提供“完整的 ACID 事务”，虽然它在某些方面变得非常技术性，但如果您担心 MongoDB 中的数据丢失，我强烈建议您阅读这篇文章(我建议您查看使用 Jepsen 测试的任何数据库，您可能会对他们的弱点感到惊讶)。该报告总结了默认读写问题的弱点，讨论了具有适当读写问题的非事务性读写的可靠性，解决了文档中的缺陷，然后提供了有关测试新版本时遇到的问题的重要细节ACID 事务(以及相关的读/写问题)。
那么，使用 MongoDB 还会丢失数据吗？ 是的，尤其是默认设置，但大多数数据库都是如此。事情比回答这个问题时要好得多，而且这些功能具有更高的可靠性和耐用性，而且它们似乎有效(交易除外)。我的建议是了解您操作的配置有哪些限制，然后确定您的产品/业务/用例的数据丢失风险是否可以接受。
关于mongodb - MongoDB 的 'lost data' 批评在多大程度上仍然有效？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/10560834/