MongoDB - 可靠性问题仍然显著吗？
我有几个sqlite数据库（大约15GB），总共有大约100万行数据，所以也不算特别大。我在看mongodb，感觉它挺好用的，特别是如果我想对构成这些数据库的文档进行一些基本的自然语言处理。
我以前从来没有用过Mongo，所以得从头学起（我会用python）。在网上查了一下，发现有一些关于MongoDB可靠性的问题，听起来挺可怕的。这个问题现在还严重吗？如果真的有问题，我当然会保留sqlite的备份，但我不想一直都在重建我的mongo数据库。
我只是想知道最近大家在使用Mongo时遇到的数据损坏问题是什么？这是个大问题吗？
谢谢！
5 个回答
MongoDB支持一种自动分片的架构，这样可以在多个节点之间进行横向扩展，也就是说可以轻松增加更多的服务器来处理更多的数据和请求。为了保持系统的平衡和应对故障，你需要运行多个节点。如果你只想运行一个单独的实例，并且希望在突然断电的情况下不会崩溃，那么你需要选择像CouchDB这样的数据库，它支持ACID特性。虽然我在工作中使用MongoDB一个月以来没有遇到崩溃的情况，但我们很快会迁移到一个6个节点的集群上。
持久性
不同的数据库在持久性方面采取了不同的策略。CouchDB采用的是一种“只崩溃”设计，这意味着数据库可以随时关闭，但数据仍然保持一致。而MongoDB在持久性方面采取了不同的方式。如果机器崩溃了，下次启动时需要运行一个repairDatabase()的操作来修复（这和MyISAM类似）。MongoDB建议使用复制功能，无论是局域网还是广域网，这样才能确保真正的持久性，因为某个服务器可能会永久性地失效。总的来说，CouchDB在使用单个服务器且没有复制的情况下，在持久性方面表现更好。
以上内容摘自mongodb.org的官方网站。
正如其他人所说，MongoDB 目前没有单机的持久性。不过，幸运的是，设置多节点复制非常简单。你甚至可以在另一个数据中心设置第二台机器，让数据实时自动复制到那台机器上！
如果你必须确保写入操作成功，你可以让 MongoDB 在插入或更新数据时，等到这些数据复制到 n 个从节点后再返回结果。这就保证了你至少有 n 份数据的副本。副本集让你可以随时添加或移除集群中的节点，而不需要做太多工作；只需添加一个新节点，它就会自动同步一份数据。移除一个节点后，集群会自动进行重新平衡。MongoDB 的设计就是为了在多台机器上使用，多个节点可以并行工作；这和 MySQL 不同，后者通常期望在一台大机器上运行，然后在需要扩展时再添加从节点。如果你花时间去理解它的不同之处，以及如何构建一个利用其优势的架构，这种数据存储和扩展方式会让你觉得很舒服。
是的，MongoDB在持久性方面确实存在问题。为了确保数据的持久性，你需要使用复制集（也就是至少要有两台机器），否则在停电的情况下，你可能会丢失最后一分钟的数据。MongoDB并没有单机的持久性，但我知道在1.7到1.8版本中会有所改进。发生崩溃后，你需要手动修复数据库，如果你的数据量很大，修复过程可能会耗费几个小时。MongoDB没有事务处理和ACID特性，所以不太适合电商或银行应用。
你不应该使用MongoDB的开发版本（像1.3.x、1.5.x、1.7.x这些奇数版本号都是开发版本），而且最好使用64位的操作系统。如果你在网上查找关于MongoDB的灾难性文章，问题的根源大多就是这两点。
CouchDB、Cassandra和PostgreSQL都具备强大的持久性（在Cassandra和PostgreSQL中，fsync的默认时间是10毫秒），所以它们都能在单机上保持数据的持久性。
如果你需要非常简单的扩展性、容错能力和负载均衡，Cassandra是最好的选择，但查询选项比较差。故障节点可以消失一段时间后再回来，没问题，系统会自动修复。
编辑：MongoDB 1.8引入了日志功能（可以实现数据持久性），但这不是默认设置。你也可以看看这个 http://news.ycombinator.com/item?id=2684423
祝好，
Serdar Irmak