千万别用MongoDB？真的吗？！

　某人发了一篇Don’t use MongoDB的血泪控诉，我把原文翻译以下，你能够看看。不过，我想咱们还要去看看10gen CTO的对此事的回复，咱们还要去在Reddit上看看你们的说法，10gen CTO的对此事的回复后面也有一堆人在讨论这个事，还有一些程序员开始去读MongoDB的源码了，呵呵。看样子，说MongoDB的这些事并非真的。

　　10gen CTO 对此事的并不彻底知道，其在回复，对些文中的每一条都作了回复。我把其回复的大致意思也放在原文中。不过，颇有意思的是那些程序员的讨论。建议你们看看。

　　正文

　　由于各类政治缘由，我这段时间没有说什么，可是如今我以为由于要对社会负责，因此我要阻止你们不要把大家的业务放在MongoDB上。

　　个人团队在一个有巨大用户量（一个有千万用户级的大型的公司）系统上使用的MongoDB，这个系统上让MongoDB有很是大的负载。早期，咱们觉得使用MongoDB会像10gen公司（MongoDB背后的公司）宣扬其在长期性能扩展有不少好处。可是，咱们错了，而这个rant(长篇抱怨)就是为了让你不要相信那些所谓的成功经验而和咱们同样犯了大错。若是有人能避免你上当，那么就得我写这么多。但愿能警醒更多的人。

　　注意，对于和10gen打交道的经从来说，他们给予了咱们充分了热情和帮助，并且很是地好。可是这并不能成为我不告诉你们他们的产品失败的理由。

　　为何这么说？

　　数据库应该是正确的，或是仅可能的正确，由于数据库的错误会比其它使用更大。不只仅是由于其对运行，性能，开销，和其价值影响巨大，还由于其连带的东西。匆忙去去移植TB级的数据相比起去修改代码中的一个逻辑错误来讲是一个很巨大的工做。而在系统出问题后须要恢复TB级的数据，而你即被限制住了，你会有一种绝望的感受。

　　数据库是一个很复杂的系统，对于开发者来讲就像一个黑盒同样。你须要对你所采用的数据库持绝对信任的态度，信任它会作正确的事，并尽会保持 一致笥和可用性。

　　为何MongoDB会流行？

　　说句公道话，咱们必需认可MongoDB是流行的，由于下面这些缘由让其流行变得很合理：

• 它很是容易地运行
• 很是自由的Schema模型，并且能够很容易地和JSON类的数据结果映射起来，这对于程序员来于有很大的感染力（它彻底符合程序员的逻辑思惟），并且，程序员老是在项目能够作技术选型的人。
• 成熟和分健壮，有记录，被真实的Use Case测试过，等等。对于那些喜欢选择成熟的技术的系统管理员和运营专业来讲，这是一个很典型的选择。
• 它单系统，低读并发的性能测试很是使人惊讶，而对于那些没有经验的评估者来讲，这基本上来讲是最重要的。

　　如今，你可能正在开发一个随便玩一玩的网站，或是一个原型，或是那种只考虑开发速度不考虑别的的项目。老实说，对于这种项止，无所谓你用什么样的技术，只要搞定工做就好了。

　　可是，若是你想要在MongoDB上搞一个大规模的系统，在上面运行真实的业务，那么，请不要用MongoDB。

　　为何不？

　　1）MongoDB为了赢得Benchmark测试而默认使用了不安全的写方式

　　若是你不调用getLastError()，MongoDB就不会在确认数据库写操做完成就返回了，这会引入至少两种问题：

• 在并发的环境下（链接池，等），在一个读操做“完成”后的连续地读操做会出错，MongoDB没有“栅栏条件锁”来知道何时完成写。
• 未知个数的保存操做会被丢弃，由于保存操做的队列会在不一样的地方。好比TCP缓存等。当你和数据库链接由于一些意味状况断开的时候，这些东西就被丢弃了。

10gen CTO 回复： 这和Benchmark没有任何关系，并说这个就是API的设计，其交给用户本身去选择，由于写的方式也有不少种。

　　2）MongoDB会以使人震惊的方式丢失数据

　　下面是一个咱们所经历过的它丢数据的列表：

• 数据就是丢了，缘由未知
• 从损坏的数据库中恢复数据不成功，如事务日志。
• 主从结点间的数据复制有缺口，致使从结点丢失主结点有的数据。是的，没有CheckSum，而且是的，你还会看到数据复制过去了。
• 数据复制有时会停了，没有错误。你能够监控你的复制状态。

10gen CTO 逐一回复：1）历来没有一个数据丢失的BUG咱们没有立刻fix的事情。你能告诉我你报给咱们的问题号吗？咱们至少要明的是怎么一回事。若是是咱们的问题，咱们会立刻fix的。2）从损坏了的数据库中不能彻底恢复数据 ，这不挺正常的吗？可是若是有主从服务器互为备份应该会好一些。3）请告诉我你的问题号，咱们历来没有接到过这样的错误报告。若是有，的确很严重。4）若是是说错误条件发生的时候没有通知，这有可能。另外，你能够监控数据复制的写操做，你可使用w=2 为getLastError的参数。

　　3）MongoDB 须要全局写锁来请求写操做

　　在写操做频繁的时候，这等同于杀了你。若是你运行一个blog，你也许不会关心这个事，由于你的读写操做不高。

10gen CTO 回复：读写锁永远都是问题，可是2.0会好不少，2.2会解决得更好一些。

　　4）MongoDB 的Sharding(分区) 在高负载下会中止工做

　　在高负载下加一个shard是一场恶梦。Mongo要么会移动其数据块太快而致使DOS攻击产生不少流量占用带宽，要么就彻底地拒绝更多的数据块。这会使一个高流量的网站承受着沉重地写操做。

10gen CTO 回复：若是系统已经超过了其负载，那么移动数据固然会变得很难。我每一次的演讲都说得很清楚，不要在系统性能不行的时候才去加shard，这不行的。

　　5）Mongo 不可靠

　　Mongod/配置服务器/mongos的架构肯定合理且聪明。不幸的是，mongos彻底就是垃圾。在有负载的状况下，它时不时就都会崩溃，有时几个小时，有时几天。进程重启监控有时也无论用，由于他会抛出一些断言会伪造出一个关键线程，其致使进程还在运行。Double Fail。

　　最坏的是，惟一可行的方式是在一堆mongos实例前放一个HaProxy(一种负载均衡器)，运行一个做业其缓慢地轮着访问这些mongos实例，并按期kill掉他们，以变能够从新启动新的实例。我没有在开玩笑。

10gen CTO 回复：不可能有这种事，你能不能告诉我更多的细节？

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

　　MongoDB 1.6，在数据同步配置中，有时会配置了一个错误的结点（常常是一个空结点）是一个最新的数据结点。因而其它同步数据的结果上的数据就这样被干掉了（我说的是700GB的好数据），由于其把这个空结点的数据同步回有数据的结点上。数据库永远永远都不该该干这个。若是出现这种问题，数据库应该抛出一个错误而让DBA来选择合理的操做，或是强制使用正确的配置。而不该该删除全部的数据（那天太糟糕了）。

　　他们在1.8中修复了这个问题，偶滴神啊。

10gen CTO 回复：找不到这样的事，也找不到相应提交的代码，你能多给点信息吗？

　　7）发布了一些不该该发布东西

　　众所周知，在稳定版里能找到一些尴尬的bug其会致使数据问题——而咱们老是在出了问题后他们才告诉咱们这些问题，这是由于咱们购买了10gen他们那超级诈骗的白金技术支持。他们回应是，发给咱们一个hot patch，他们内部叫RC的玩意，而后让这个hot patch运行在咱们的数据上。

10gen CTO 回复：关于白金的技术支持，咱们所接手的全部问题都会公开，fix也会公开。没有特定的情景，这种事很难讨论。咱们会根据不一样的状况做出不一样的反应。咱们但愿咱们的用户的问题能尽快获得解决。

　　8）复制器在繁忙的服务器上黯然失色

　　复制器常常性的向Master发起DOS攻击，或是复制很是慢，花了巨长无比的时间，而oplog几乎被耗尽（就算是50GB的oplog）。

　　咱们有一个繁忙的，大的数据集咱们不会复制他由于它是动态的。那是使人痛苦的一个月，或是咱们须要在选择不一样的数据库系统前交叉双指（注：好运的手势）

10gen CTO 回复：这看起来像上服务器负载太重了。我前面提到过了。

　　可是最糟糕的问题是：

　　你可能会说，我这些问题都是过去式了；他们修复了全部这些问题或是他们会在下一版本中修复这些问题；X问题能够用Y实践来减轻。等等，等等。

　　不幸的是，你说这些东西一点用也没有。

　　真正的问题是，这么多的问题都是首要的问题。 数据库开发者要能hold住比通常程序员更高的标准。也就是说，你的优先级应该像下面这个样子：

1. 别搞丢数据，对数据要有彻底的把握
2. 经过实践保证可用性
3. 多结点的性能扩展性
4. 最小延迟应该保持在99%和95%之间
5. 每一个资源的每秒请求数

　　10gen的顺序好像是 #5  为每一，其它项随便，#1 并不在前3位。

10gen CTO 回复：这明显不是真的。看一看咱们提交的代码，看一看咱们的fix。 咱们历来不会在release版中隐藏一个bug。若是咱们很是在意性能的benchmark的话，咱们会花精力解决那些锁的问题，这样一来，多线程并发会更快一些。

MongoDB是一个新生的东西，还有不少东西须要打磨。若是你想来认识一下咱们，咱们欢迎你来认识一下咱们。

　　这些失败，还有那所暗示的公司的优先级，指出了一个最基本的企业文化的问题，其会让问题出如今任一发布版中：由于他们缺少尊守必要的数据库系统的设计律条。

　　请慎重考虑这些警告。