我正在阅读一篇关于 MongoDB 和 CouchDB 的文章，发现 MongoDB 可能会丢失数据，但 CouchDB 在某种程度上是稳定的，不可能丢失任何数据。
Redis 和 mongodb 用户可能会惊讶地发现，默认情况下，如果进程崩溃或关闭，他们可能会丢失您的数据。
http://java.dzone.com/articles/should-i-use-mongodb-couchdb
在 MongoDB 中有解决这个问题的方法，但我是否正确理解：CouchDB 无需任何配置就更耐用、更稳定？因此，如果 CouchDB 崩溃，或者说在 CouchDB 系统的更新过程中炸弹会爆炸 => 永远不会丢失数据？
我只是想知道为什么。是因为 CouchDB 是用 Erlang 编写的吗？还是因为 CouchDB 使用了 MVCC？有任何想法吗？谢谢
在 MongoDB 中有解决这个问题的方法，但我是否正确理解：CouchDB 无需任何配置就更耐用、更稳定？因此，如果 CouchDB 崩溃，或者说在 CouchDB 系统的更新过程中炸弹会爆炸 => 永远不会丢失数据？
我不确定 CouchDB 的细节，但是快速的 Google 搜索显示，默认情况下 CouchDB 实际上是最终一致的（http://guide.couchdb.org/draft/consistency.html，http://en.wikipedia.org/wiki /Eventual_consistency ) 其中 MongoDB 被描述为具有强一致性。非 ACID 技术（包括 MongoDB）没有大多数属性来确保数据的完全持久性，即直接写入磁盘和立即复制。
但是，您必须记住，MongoDB 可能会丢失数据，因为它不直接写入磁盘（这就是使 MySQL 之类的技术“慢”的原因，尽管从技术上讲，SQL 技术也可能由于磁盘写入的执行方式而丢失数据；您可以'不写入未通电的磁盘），但窗口就像 60 毫秒或在完全失败的情况下可能会丢失的东西，如果您将命令发送到多个节点，则该 60 毫秒窗口发生的机会相同数据中心，变得相当远程，因此 MongoDB 不像写入/dev/null.
所以 CouchDB 永远不会丢失数据？不，它可以。
基本上你所说的链接对我来说似乎有点偏见，它没有考虑最终的一致性实际上是什么，也许它是由同一个人在这个视频上写的：http ://www.youtube.com/watch?v =b2F-DItXtZs
如果您想对此进行测试，我可以为您炸毁您的服务器。
MongoDB 旨在设置在至少两个节点的副本集中。只应在开发环境中运行单个节点。
当您有一个副本集并且其中一个节点崩溃时，其他节点将继续记录所有数据更改。当崩溃的节点恢复时，节点将自动同步。崩溃的节点将从其他节点接收所有丢失的更改，包括那些在崩溃之前无法写入磁盘的更改。
当您设置运行在不同物理服务器上的多个节点的副本集时，MongoDB 变得非常耐用。