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