何时弃用 MongoDB？| 技术头条

Posted 2021-05-01 CSDN

即使位列数据库排行榜的 Top 5，MangoDB 的日子也并不好过。

自去年 10 月，MangoDB 宣布将开源许可协议从 GNU AGPLv3 切换至 Server Side Public License 之后，AWS、RedHat、Fedora、Debian、Lyft 等项目以及企业随即相继宣布将移除 MangoDB，一时之间，MangoDB 成为众矢之的。但扪心自问，MangoDB 真的如此糟糕吗？我们又该如何做出正确的选择？

作者 | Justin Etheredge

译者 | 弯月

责编 | 屠敏

出品 | CSDN（ID：CSDNnews）

以下为译文：

最近，我读到了一篇关于红帽公司的Satellite不再支持MongoDB的文章（有些人说这是因为许可条款方面的修改。）这不禁让我想起过去几年里，我经常看到有关文章说为何MongoDB如此可怕，以及为何大家都不应该再使用MongoDB。然而，与此同时，MongoDB已经发展成为一款更为成熟的产品。那么 ，情况究竟如何呢？难道所有的这些仇恨真的只是由于MongoDB在早期实现和营销中犯下的错误吗？还是说人们责怪MongoDB，只是因为他们没能正确地评价MongoDB是否适合自己？

趋势聚焦

多年来，我一直在从事软件行业，但即便如此，我也只是经历了一小部分对该行业带来了冲击性的趋势。我目睹了4GL、AOP、敏捷、SOA、Web 2.0、AJAX、区块链，以及等等诸多技术的崛起。每年软件工程领域都会出现新的趋势。其中一些很快就遭遇了失败，还有一些则从根本上改变了软件开发的方式。

随着创新技术开始引领潮流，人们的兴趣骤然而生，于是大家纷纷开始涌入，或者看到其他跃跃欲试的人群为其造势。高德纳公司为整个过程专门定义了“技术成熟度曲线”（The Hype Cycle），虽然存在争议，但该曲线确实正确地评估了一项有价值的技术的发展成熟过程。

但每隔一段时间，就会出现一种新的创新（或者是旧已有技术的再度复苏），而这种创新由其中的某一种特定的实现所驱动。以NoSQL为例，其就受到了MongoDB的出现以及迅速崛起的大幅推动。这场运动并非源自MongoDB，但是大型互联网公司的数据挑战确实推动了非关系型数据库的回归。Google的Bigtable和Facebook的Cassandra等项目相继涌现，然而，MongoDB才是大多数开发人员最易获取，也是最方便实现的NoSQL数据库。

注：现在，你可能在想，我这不是把列式数据库、键/值存储或众多其他数据存储类型都混杂到了NoSQL旗下吗？你说的没错，但是当时这种情况确实发生了。每个人都一股脑扎进NoSQL中，坚称他们离不开NoSQL，但实际上他们并没有真正理解其中所涉及的不同技术。对于很多人来说，MongoDB就是NoSQL。

开发人员对此表示反对。无模式数据库无限扩展的概念可以应对任何挑战，因此非常诱人。在2014年左右，几乎到处都有人在使用MongoDB，而放到一年前人们都还都在使用mysql、Postgres或SQL Server这样的关系数据库。如果你问他们MongoDB，他们的回答各不相同：有人的说辞很老套“网络规模扩展的需要”，也有人经过了深思熟虑“我的数据结构非常松散，特别适合无模式数据库”。

重要的是不要忘记，MongoDB和一般的文档数据库可以解决传统关系数据库无法应对的如下难题：

• 严格的模式：在关系数据库中，如果你有动态的数据，则不得不创建一堆随机的“杂项”数据列，将数据按块保存起来，或者使用 EAVEAV设置……所有这些方法都存在严重的缺陷。

• 难以扩展：在关系数据库中，如果你的数据过于庞大，则无法保存到一太服务器中；而MongoDB拥有跨多台计算机扩展数据的机制。

• 难以修改模式：数据无法迁移！在关系数据库中，变更数据库的结构是一项巨大的挑战（特别是你的数据量十分庞大的情况下）。MongoDB可以大幅简化这一过程，而且很容易上手，你可以不断更新你的模式并快速移动。

• 写入性能：MongoDB的性能非常好，尤其是按照某种方式配置的情况下。MongoDB开箱即用的写入配置受到的抨击最多，但也确实带来了出色的性能。

注意事项

MongoDB提供的潜在优势非常大，尤其是对于面临某些特定类型的问题的人。如果不配合上下文，或对于没有经验的人来说，阅读了上述列表就会以为MongoDB确实给数据库系统带来了颠覆性的改变。然而，上述优势还存在一些注意事项，下面我会一一列出。

公平地说，10gen / MongoDB Inc.并不是没有考虑到这些问题，他们只是做出了权衡利弊。

• 没有事务 ：事务可以说是许多关系数据库的核心特征（虽然不是全部，但确实是大多数）。事务意味着你能够以原子方式执行多项操作，并始终确保数据保持一致。当然，在NoSQL数据库中，你可以在一个文档中包含一个事务，或者也可以通过分两个阶段提交的策略实现事务机制。但关键在于，这项工作必须由你自己完成……而且要保证正确无误的话，这可能也是一项富有挑战性且需要付出大量精力的工作。除非你看到数据库中的数据出现非法的状态，否则你往往无法意识到数据丢失的问题，只因为你无法保证操作的原子性。注意：很多人可能会提醒我，MongoDB 4.0已经于去年引入了事务机制，但是仍然存在很多局限性。正如本文开头所说，请评估是否能够满足你的需求。

• 没有关系完整性（外键）：如果你的数据之间存在关系，那么你就需要将这些关系保存下来。几乎所有数据中都包含某种关系，如果数据库强制体现这些关系，那么就必须由你的应用程序来负责。如果数据库强制执行这些关系，那么就可以大大减轻应用程序的负担，从而减轻工程师的工作量。

• 缺乏执行数据结构的能力：强模式有时候可能会带来痛苦，但它们也能成为确保数据结构良好的强大机制。如果合理利用，你就可以通过这种强大的机制，确保你的数据在结构上符合你的期望。MongoDB等文档数据库在模式方面提供了惊人的灵活性，然而，这种灵活性会将责任转嫁到维护者身上，由他们负责数据的清洁。如果你不付出这些努力，那么最终你不得不在应用程序中大量代码，处理那些结构上与预期不符的数据。我们常常说：应用迟早需要重写，但数据将永远存在。注意：MongoDB支持模式验证，该功能非常有用，但仍然无法提供可以与关系数据库相媲美的保障。主要在于添加或修改模式验证不会影响集合中现有的数据，你需要确保更新的数据匹配新模式。因此，到底是否满足需求还得由你自己来决定。

• 自定义查询语言/没有工具生态系统：SQL在刚刚出现时绝对掀起了一场革命，从那以后再也没有任何变化。SQL是一种非常强大的语言，但也富有挑战性。你必须使用由JSON片段组成的自定义查询语言查询数据库，对于经验丰富的SQL人员来说，这是一个巨大的退步。此外，我们有一整套可与SQL数据库互操作的工具，从IDE到报告工具，应有尽有。切换到不支持SQL的数据库意味着你就无法使用大多数的工具了，或者你也可以想办法将输入保存到SQL数据库中，那么你就可以继续使用这些工具了，只不过这个过程可能比你想象得还难。

许多使用MongoDB的开发人员没有深入理解他们为权衡付出的代价，而且他们常常将MongoDB作为应用程序的主要数据存储。而这样的决定通常意味着极为昂贵的成本。

我们应该怎么做？

当然，并不是每位开发人员都会不计后果地一头扎进去。但这样的情况也着实不少，未来几年会有不少项目在意识到不适合后放弃MongoDB。如果这些组织能够花点时间系统地考虑一下他们做出的技术选择，那么也许就不会有那么多人做出这样的选择了。

那么，我们怎样才能确定哪种技术适合实际情况呢？目前已经有不少人尝试为评估技术创建系统性的框架，例如“软件公司引入技术的框架”（http://www.wohlin.eu/spi96.pdf），“评估软件技术的框架”（https://pdfs.semanticscholar.org/4268/30dd5dd944d3b75ec56b2a3b151c18afbaf9.pdf）。但我认为不需要弄得如此复杂。

我们只需要通过以下两个主要问题，就合理地评估众多技术，但是难点在于找到能够负责任地回答这些问题的人，他们愿意花时间回答这些问题，同时确保答案中毫无偏见。

“如果你没有遇到某个特定问题，就不需要引入新的工具。”

问题一：我需要解决哪些问题？

如果你没有遇到某个特定问题，就不需要引入新的工具。你可以就此打住。不要拿着解决方案反过来找问题。如果你没有遇到问题，那么就不需要新技术来更好地解决问题，所以就不需要决策。如果你是看到别人在使用某种技术，才考虑自己也使用，那么你应该先想一想他们遇到的问题，然后再问问自己是否也面临同样的问题。当你看到别的公司使用某种技术时，自己也会情不自禁，难点在于判断你自己是否也面临相同的困难。

问题二：我放弃了什么？

很明显，这个问题更加难以回答，因为你必须深入剖析，并对新旧两种技术都有很好的理解。有时候，在使用新技术构建出产品之前，你很难真正掌握这项技术，你也可以咨询那些在这项技术上花费了大量时间的人。

如果你既没有实际的使用经验，也没有人可以咨询，那么就应该考虑如何通过最小的投资确认该技术是否有价值。此外，如果你进行了投资，那么撤销这项决策的难度有多大？

人类总是把事情搞砸

你必须时刻牢记，如果你想不偏不倚地回答这些问题，那么就必须与人类的天性作斗争。为了有效地评估技术，必须克服一系列的认知偏差，下面仅举几个例子：

• 从众心理：相信每个人都听说过，但要克服这一点却非常艰难。请确保只选择能够解决你的实际需求的技术，而不要盲目跟风。

• 喜新厌旧：许多软件开发人员都会低估他们长期使用的技术，同时高估新技术的优势。这不仅仅是软件工程师特有的问题，每个人都有这样的倾向。

• 正面特点效应：有时我们只能看到眼前的东西，而会忽略不存在的东西。如果这一点与“喜新厌旧”的心理交织起来，那么有可能造成严重的破坏。因为你不仅更加看重新技术，还会忽视新技术中存在的弊端。

客观地看待事物是一种挑战，但了解可能影响到你的偏见，有助于你做出更合理的决策。

总结

当一项新的创新出现（或复苏）时，我们需要非常谨慎地回答以下两个问题：

• 这个工具能为我们解决实际问题吗？

• 我们是否清楚其中的权衡利弊？

如果你无法自信地回答这两个问题，那么就需要后退一步，重新进行评估。

MongoDB到底是不是正确的选择？是，它当然是，但是与大多数软件工程中的问题一样，你需要视情况而定。对于那些在这两个问题上有明确答案的团队来说，他们很多人都发现了MongoDB的价值，而且他们还会不断挖掘更多的价值。对于那些没有具体答案的人，希望他们能够从中吸取宝贵的教训（而不用付出惨重代价），学习如何驾驭技术成熟度曲线。

免责声明

我想澄清一点，我既不喜爱MongoDB，也不讨厌它。我根本没遇到过真正适合MongoDB的问题。我了解10gen/MongoDB公司确实犯过一些错误，包括在项目早期采用不安全的默认设置，并在所有场合下（特别是在黑客马拉松活动中）推广MongoDB，将其描述成一切数据需求的终极解决方案。没错，这些可能都是错误的决定，但我认为这也证实了本文所阐述的观点——所有问题都可以通过技术评估快速发现。

原文：https://www.simplethread.com/was-mongodb-ever-the-right-choice/

本文为 CSDN 翻译，如需转载，请注明来源出处。作者独立观点，不代表 CSDN 立场。

 热 文 推 荐 

戳他↓↓↓

System.out.println("点个在看吧！");
console.log("点个在看吧！");
print("点个在看吧！");
printf("点个在看吧！\n");
cout << "点个在看吧！" << endl;
Console.WriteLine("点个在看吧！");
Response.Write("点个在看吧！");
alert("点个在看吧！")
echo "点个在看吧！"

点击阅读原文，输入关键词，即可搜索您想要的 CSDN 文章。

你点的每个“在看”，我都认真当成了喜欢