出于某些政治上的原因，我对这个问题沉默了一段时间，但是现在我觉得我有责任站出来以我的亲身经历来告诫那些想要在它们的业务中使用MongoDB的人们。

　　我们团队在一个很大的项目(几千万用户)中使用了MongoDB，根据早期的使用，我们希望可以像10gen公司吹捧的那样，通过长期使用来获得它 们宣扬的伸缩性上的好处，但是事实证明，我们错了，我觉得有必要分享下我们的教训，即使只有一个人从中收益，我认为也值了。要说明的是，10gen公司确 实尽了他们最大的努力并且很热情的帮助我们，有时甚至热心过度，但是，这并不妨碍我对他们失败产品的批评。

　　1. MongoDB为了追求赢得基准测试导致它默认以不安全的方式进行写操作

　　如果你不调用getLastError()，MongoDB会在写操作实际完成之前就返回了，这会导致2种问题：

• 　　在并发环境下(比如连接池)，如果你在“完成”一个写操作后接着去读刚刚写入的数据，可能会遇到一个读错误，并且你没法知道数据库会在什么时候完成这个写操作。
• 　　很多情况下，队列中的保存操作会被丢弃，而你得不到任何通知，比如连接中断，或者数据库崩溃或者其它意外情况下，TCP缓存中保存的操作就人间蒸发了。

　　2. MongoDB会以很多莫名其妙的方式弄丢你的数据

• 　　数据忽然就没了，不知道为什么
• 　　损坏的数据库没法恢复
• 　　主节点和从节点的备份存在缝隙，导致从节点经常缺少某些数据，是得，没有校验和，并且备份状态显示从节点的数据是同步的
• 　　备份经常不工作，没有错误，你需要自己监控你的备份状态。

　　3. 需要全局锁来发出写请求

　　4. MongoDB的分区(sharding)在带负载的情况下工作也不正常

　　在高负载的情况下添加一个shard简直就是噩梦，Mongo要么就是过快的在分区之间移动数据块，变成对自己的DOS攻击，要么就是拒绝接受更多的块。

　　5. Mongo完全没有可靠性可言

　　Mongod/配置服务器/mongos的架构确实很聪明，但不幸的是，mongos完全就是垃圾，在有负荷的情况下，它随时都会崩溃，短则几小时，长则几天，并且重启管理进程有时也不管用，有时它会抛出断言破坏一个关键线程，但是进程却依然在运行。

　　你猜怎么着，唯一可行的方式就是在mongos前面配置一个haproxy，然后启动一个外部监管程序对mongos进行轮询，定期清除老实例然后创建新实例，没错，就是这样，不开玩笑。

　　6. MongoDB有次甚至删除了整个数据库

　　MongoDB 1.6，在配置了备份后，有时会错误的将一个全新节点的数据当作是最新的数据，然后删除其它所有节点的所有数据(大约有700G的好数据被删掉了)，并将 这个空数据同步到其它所有节点，作为一个数据库，这种事情是绝对不应该发生的，如果不能确定，应该询问管理员来选择合适的操作，而不是删除所有数据。

　　谢天谢地，这个Bug在1.8已经修复了。

　　7. 他们总是交付些压根就不应该交付的东西

　　一个令人尴尬的事实就是，即使是稳定版也会存在破坏数据的Bug——而且总是在我们的数据被破坏之后我们才发现——我们购买了10gen的白金支持，但是我们得到的支持就是一堆它们称之为内部RC的热补丁，直接运行在我们的数据上。

　　8. 备份(Replication)在忙碌的服务器上基本就是废柴

　　备份经常性不工作，要么就是DOS master，要么就是消耗太多时间直到耗光oplog(即使oplog有50G的空间)。

　　但是，这些都不是最主要的，真正的问题：

　　你可能会说，这些都是老黄历了，他们已经在最新版修复了这些问题，但这不是我想说的，我要表达的是，作为一个数据库开发公司，它们应该按照下面的顺序来排列它们的工作优先级：

　　1. 不能丢失数据，确保数据非常可靠

　　2. 通过实践确保可达性

　　3. 多节点的伸缩性

　　4. 降低延迟到99%和95%之间

　　5. 单个资源的每秒请求数

　　10gen的排序似乎是#5是第一位的，其它几项的排序未知，但是可以肯定，第一条肯定不在它们的前三之列。

　　最后，希望你能认真考虑以上警告。