千万别用MongoDB？真的吗？！

     <p> 某人发了一篇 <a href="/misc/goto?guid=4958198683256833822" target="_blank">Don’t use MongoDB</a> 的血泪控诉，我把原文翻译如下，你可以看看。不过，我想我们还要去看看10gen <a href="/misc/goto?guid=4958198683997171044" target="_blank">CTO 的对此事的回复</a>，我们还要去在 <a href="/misc/goto?guid=4958198684713291757" target="_blank">Reddit 上</a>看看大家的说法，10gen <a href="/misc/goto?guid=4958198683997171044" target="_blank">CTO 的对此事的回复</a>后面也有一堆人在讨论这个事，还有一些程序员开始去读 MongoDB 的源码了，呵呵。看样子，说 MongoDB 的这些事并不是真的。</p>    <p> 10gen CTO 对此事的并不完全知道，其在回复，对些文中的每一条都做了回复。我把其回复的大体意思也放在原文中。不过，很有意思的是那些程序员的讨论。建议大家看看。</p>    <p> <strong>正文</strong></p>    <p> 因为各种政治原因，我这段时间没有说什么，但是现在我觉得因为要对社会负责，所以我要阻止大家不要把你们的业务放在 MongoDB 上。</p>    <p> 我的团队在一个有巨大用户量（一个有千万用户级的大型的公司）系统上使用的 MongoDB，这个系统上让 MongoDB 有非常大的负载。早期，我们以为使用 MongoDB 会像10gen 公司（MongoDB 背后的公司）宣扬其在长期性能扩展有很多好处。但是，我们错了，而这个 rant (长篇抱怨)就是为了让你不要相信那些所谓的成功经验而和我们一样犯了大错。如果有人能避免你上当，那么就得我写这么多。希望能警醒更多的人。</p>    <p> 注意，对于和10gen 打交道的经历来说，他们给予了我们充分了热情和帮助，而且非常地好。但是这并不能成为我不告诉大家他们的产品失败的理由。</p>    <p> <strong>为什么这么说？</strong></p>    <p> 数据库应该是正确的，或是仅可能的正确，因为数据库的错误会比其它使用更大。不仅仅是因为其对运行，性能，开销，和其价值影响巨大，还因为其连带的东西。匆忙去去移植 TB 级的数据相比起去修改代码中的一个逻辑错误来说是一个很巨大的工作。而在系统出问题后需要恢复 TB 级的数据，而你即被限制住了，你会有一种绝望的感觉。</p>    <p> 数据库是一个很复杂的系统，对于开发者来说就像一个黑盒一样。你需要对你所采用的数据库持绝对信任的态度，信任它会做正确的事，并尽会保持一致笥和可用性。</p>    <p> 为什么 MongoDB 会流行？</p>    <p> 说句公道话，我们必需承认 MongoDB 是流行的，因为下面这些原因让其流行变得很合理：</p>    <ul>     <li>它非常容易地运行</li>     <li>非常自由的 Schema 模型，而且可以很容易地和 JSON 类的数据结果映射起来，这对于程序员来于有很大的感染力（它完全符合程序员的逻辑思维），而且，程序员总是在项目可以做技术选型的人。</li>     <li>成熟和分健壮，有记录，被真实的 Use Case 测试过，等等。对于那些喜欢选择成熟的技术的系统管理员和运营专业来说，这是一个很典型的选择。</li>     <li>它单系统，低读并发的性能测试非常令人惊讶，而对于那些没有经验的评估者来说，这基本上来说是最重要的。</li>    </ul>    <p> 现在，你可能正在开发一个随便玩一玩的网站，或是一个原型，或是那种只考虑开发速度不考虑别的的项目。老实说，对于这种项止，无所谓你用什么样的技术，只要搞定工作就行了。</p>    <p> 但是，如果你想要在 MongoDB 上搞一个大规模的系统，在上面运行真实的业务，那么，请不要用 MongoDB。</p>    <p> <strong>为什么不？</strong></p>    <p> 1）MongoDB 为了赢得 Benchmark 测试而默认使用了不安全的写方式</p>    <p> 如果你不调用 getLastError ()，MongoDB 就不会在确认数据库写操作完成就返回了，这会引入至少两种问题：</p>    <ul>     <li>在并发的环境下（连接池，等），在一个读操作“完成”后的连续地读操作会出错，MongoDB 没有“栅栏条件锁”来知道什么时候完成写。</li>     <li>未知个数的保存操作会被丢弃，因为保存操作的队列会在不同的地方。比如 TCP 缓存等。当你和数据库连接因为一些意味情况断开的时候，这些东西就被丢弃了。</li>    </ul>    <blockquote>     <p>10gen CTO 回复： 这和 Benchmark 没有任何关系，并说这个就是 API 的设计，其交给用户自己去选择，因为写的方式也有很多种。</p>    </blockquote>    <p> 2）MongoDB 会以令人震惊的方式丢失数据</p>    <p> 下面是一个我们所经历过的它丢数据的列表：</p>    <ul>     <li>数据就是丢了，原因未知</li>     <li>从损坏的数据库中恢复数据不成功，如事务日志。</li>     <li>主从结点间的数据复制有缺口，导致从结点丢失主结点有的数据。是的，没有 CheckSum，并且是的，你还会看到数据复制过去了。</li>     <li>数据复制有时会停了，没有错误。你可以监控你的复制状态。</li>    </ul>    <blockquote>     <p>10gen CTO 逐一回复：1）从来没有一个数据丢失的 BUG 我们没有马上 fix 的事情。你能告诉我你报给我们的问题号吗？我们至少要明的是怎么一回事。如果是我们的问题，我们会马上 fix 的。2）从损坏了的数据库中不能完全恢复数据 ，这不挺正常的吗？但是如果有主从服务器互为备份应该会好一些。3）请告诉我你的问题号，我们从来没有接到过这样的错误报告。如果有，的确很严重。4）如果是说错误条件发生的时候没有通知，这有可能。另外，你可以监控数据复制的写操作，你可以使用w=2 为 getLastError 的参数。</p>    </blockquote>    <p> 3）MongoDB 需要全局写锁来请求写操作</p>    <p> 在写操作频繁的时候，这等同于杀了你。如果你运行一个 blog，你也许不会关心这个事，因为你的读写操作不高。</p>    <blockquote>     <p>10gen CTO 回复：读写锁永远都是问题，但是2.0会好很多，2.2会解决得更好一些。</p>    </blockquote>    <p> 4）MongoDB 的 Sharding (分区) 在高负载下会停止工作</p>    <p> 在高负载下加一个 shard 是一场恶梦。Mongo 要么会移动其数据块太快而导致 DOS 攻击产生很多流量占用带宽，要么就完全地拒绝更多的数据块。这会使一个高流量的网站承受着沉重地写操作。</p>    <blockquote>     <p>10gen CTO 回复：如果系统已经超过了其负载，那么移动数据当然会变得很难。我每一次的演讲都说得很清楚，不要在系统性能不行的时候才去加 shard，这不行的。</p>    </blockquote>    <p> 5）Mongo 不可靠</p>    <p> Mongod/配置服务器/mongos 的架构确定合理且聪明。不幸的是，mongos 完全就是垃圾。在有负载的情况下，它时不时就都会崩溃，有时几个小时，有时几天。进程重启监控有时也不管用，因为他会抛出一些断言会伪造出一个关键线程，其导致进程还在运行。Double Fail。</p>    <p> 最坏的是，唯一可行的方式是在一堆 mongos 实例前放一个 HaProxy (一种负载均衡器)，运行一个作业其缓慢地轮着访问这些 mongos 实例，并定期 kill 掉他们，以变可以重新启动新的实例。我没有在开玩笑。</p>    <blockquote>     <p>10gen CTO 回复：不可能有这种事，你能不能告诉我更多的细节？</p>    </blockquote>    <p> 6）MongoDB 有一次甚至删除了整个数据库</p>    <p> MongoDB 1.6，在数据同步配置中，有时会配置了一个错误的结点（经常是一个空结点）是一个最新的数据结点。于是其它同步数据的结果上的<strong>数据就这样被干掉了</strong>（我说的是700GB 的好数据），因为其把这个空结点的数据同步回有数据的结点上。数据库永远永远都不应该干这个。如果出现这种问题，数据库应该抛出一个错误而让 DBA 来选择合理的操作，或是强制使用正确的配置。而不应该删除所有的数据（那天太糟糕了）。</p>    <p> 他们在1.8中修复了这个问题，偶滴神啊。</p>    <blockquote>     <p>10gen CTO 回复：找不到这样的事，也找不到相应提交的代码，你能多给点信息吗？</p>    </blockquote>    <p> 7）发布了一些不应该发布东西</p>    <p> 众所周知，在稳定版里能找到一些尴尬的 bug 其会导致数据问题——而我们总是在出了问题后他们才告诉我们这些问题，这是因为我们购买了10gen 他们那超级诈骗的白金技术支持。他们回应是，发给我们一个 hot patch，他们内部叫 RC 的玩意，然后让这个 hot patch 运行在我们的数据上。</p>    <blockquote>     <p>10gen CTO 回复：关于白金的技术支持，我们所接手的所有问题都会公开，fix 也会公开。没有特定的情景，这种事很难讨论。我们会根据不同的情况作出不同的反应。我们希望我们的用户的问题能尽快得到解决。</p>    </blockquote>    <p> 8）复制器在繁忙的服务器上黯然失色</p>    <p> 复制器经常性的向 Master 发起 DOS 攻击，或是复制非常慢，花了巨长无比的时间，而 oplog 几乎被耗尽（就算是50GB 的 oplog）。</p>    <p> 我们有一个繁忙的，大的数据集我们不会复制他因为它是动态的。那是令人痛苦的一个月，或是我们需要在选择不同的数据库系统前交叉双指（注：好运的手势）</p>    <blockquote>     <p>10gen CTO 回复：这看起来像上服务器负载过重了。我前面提到过了。</p>    </blockquote>    <p> <strong>但是最糟糕的问题是：</strong></p>    <p> 你可能会说，我这些问题都是过去式了；他们修复了所有这些问题或是他们会在下一版本中修复这些问题；X问题可以用Y实践来减轻。等等，等等。</p>    <p> 不幸的是，你说这些东西一点用也没有。</p>    <p> 真正的问题是，这么多的问题都是首要的问题。 数据库开发者要能 hold 住比一般程序员更高的标准。也就是说，你的优先级应该像下面这个样子：</p>    <ol>     <li>别搞丢数据，对数据要有完全的把握</li>     <li>通过实践保证可用性</li>     <li>多结点的性能扩展性</li>     <li>最小延迟应该保持在99%和95%之间</li>     <li>每个资源的每秒请求数</li>    </ol>    <p> 10gen 的顺序好像是 #5  为每一，其它项随便，#1 并不在前3位。</p>    <blockquote>     <p>10gen CTO 回复：这明显不是真的。看一看我们提交的代码，看一看我们的 fix。 我们从来不会在 release 版中隐藏一个 bug。如果我们非常在乎性能的 benchmark 的话，我们会花精力解决那些锁的问题，这样一来，多线程并发会更快一些。</p>     <p>MongoDB 是一个新生的东西，还有很多东西需要打磨。如果你想来认识一下我们，我们欢迎你来认识一下我们。</p>    </blockquote>    <p> 这些失败，还有那所暗示的公司的优先级，指出了一个最基本的企业文化的问题，其会让问题出现在任一发布版中：因为他们缺乏尊守必要的数据库系统的设计律条。</p>    <p> 请慎重考虑这些警告。<br /> <br /> <br /> 来自: <a id="link_source2" href="/misc/goto?guid=4958198686128406496" target="_blank">coolshell.cn</a></p>