我最近发现Red Hat正在从Satellite移除MongoDB支持 （他们说是由于许可证更改）。 它使我认为，在过去的几年中，我看到了很多文章，MongoDB是如此糟糕，而且没人可以使用它。 但是在这段时间里，MongoDB已经成为更加成熟的产品。 怎么了 所有仇恨真的是由于营销新DBMS时的错误而引起的吗？ 还是人们只是在错误的地方使用MongoDB？

如果您突然觉得我正在保护MongoDB，请阅读本文末尾的免责声明 。

新趋势

我在软件行业工作了足够的时间，足以发表体面的讲话，但同样，影响我行业的趋势中只有一小部分是我的原因。 我亲眼目睹了4GL，AOP，敏捷，SOA，Web 2.0，AJAX，区块链的发展……这个列表是无止境的。 每年都有新趋势出现。 有些快速消失，而另一些从根本上改变了软件开发方式。

围绕每一个新趋势，都会产生某种普遍的刺激：人们要么跳上船，要么看到别人产生的噪音-跟着人群走。 高德纳（Gartner）在一个炒作周期中编纂了这个过程。 尽管有争议，但该图大致描述了技术最终可用之前发生的情况。

但是，有时会出现一种新的创新（或者是第二次出现，如本例所示），它仅由一个特定的实现驱动。 在NoSQL的情况下，MongoDB的出现和迅速崛起在很大程度上推动了这一炒作。 MongoDB并未引发这种趋势：事实上，大型互联网公司开始在处理大量数据时遇到问题，这导致了非关系数据库的回归。 普遍的运动始于诸如Google的Bigtable和Facebook的Cassandra之类的项目，但正是MongoDB成为NoSQL数据库最著名且可负担得起的实现，大多数开发人员都可以使用它。

注意：您可能会认为我正在将文档数据库与列数据库，键/值存储或NoSQL一般定义下的许多其他类型的数据存储中的任何一个混合在一起。 你是对的。 但是当时混乱局面。 每个人都沉迷于NoSQL，每个人都绝对需要NoSQL，尽管许多人没有看到不同技术之间的差异。 对于许多人来说，MongoDB已经成为NoSQL的代名词 。

开发人员攻击了她。 拥有一个没有可魔术地扩展以解决任何问题的架构的数据库是一个非常诱人的想法。 大约在2014年左右，似乎在一年前使用关系数据库的任何地方，例如MySQL，Postgres或SQL Server，都开始部署MongoDB数据库。 对于为什么这个问题，您可以从平庸的“这就是网络的规模”到更周到的“我的数据结构很差，并且无需计划即可很好地适合数据库”中得到答案。

重要的是要记住，MongoDB和文档数据库通常解决了传统关系数据库中的许多问题：

• 严格的方案 ：对于关系数据库，如果您具有动态生成的数据，则不得不创建一堆随机的“不同”数据列，将数据块推送到那里或使用EAV配置……所有这些都有明显的缺点。
  
• 扩展的困难 ：如果有太多数据无法容纳在单个服务器上，MongoDB提出了在多个计算机上扩展它们的机制。
  
• 复杂的电路修改 ：无需移植！ 在关系数据库中，更改数据库的结构可能是一个巨大的问题（尤其是在有大量数据的情况下）。 MongoDB能够大大简化该过程。 而且它非常容易，您可以随时随地更新电路并快速运行。
  
• 记录性能：MongoDB的性能很好，尤其是经过适当调整后。 甚至经常被批评的MongoDB配置也显示了一些令人印象深刻的性能指标。

所有风险都由您承担。

MongoDB的潜在利益是巨大的，尤其是对于某些类型的问题。 如果您在不了解上下文和没有经验的情况下阅读以上列表，您可能会感到MongoDB确实是革命性的DBMS。 唯一的问题是上述优点伴随着一些保留，其中一些保留如下。

公平地说，10gen / MongoDB Inc.中没有人。 他不会说以下说法不正确；这只是一种妥协。

• 事务丢失 ：事务是许多关系数据库（不是全部，而是大多数）的主要特征。 事务性意味着您可以自动执行多个操作，并可以保证数据保持一致。 当然，对于NoSQL数据库，事务性可以在同一文档中，或者您可以使用两阶段提交来获取事务语义。 但是您必须自己实现此功能……这可能是一项复杂且耗时的任务。 通常，直到看到数据库中的数据处于无效状态，您才意识到问题所在，因为无法保证操作的原子性。 注意：许多人告诉我，事务在去年的MongoDB 4.0中出现了，但是有很多限制。 本文的结论仍然是相同的：评估技术如何满足您的需求。
  
• 关系完整性的丢失（外键） ：如果数据中存在关系，则必须在应用程序中应用它。 具有符合这些关系的数据库将使应用程序中的大部分工作，因此也减少了程序员的工作。
  
• 缺乏应用数据结构的能力 ：严格的方案有时会成为一个大问题，但如果使用得当，它也是实现良好数据结构的强大机制。 诸如MongoDB之类的文档数据库提供了令人难以置信的架构灵活性，但是这种灵活性消除了保持数据整洁的责任。 如果您不照顾它们，那么最后您将不得不在应用程序中编写很多代码来解决未按您期望的形式存储的数据。 正如我们公司经常说的“简单线程...”，有一天应用程序将被重写，并且数据将永远存在。 注意：MongoDB支持模式验证：它很有用，但不能提供与关系数据库中相同的保证。 首先，添加或修改模式检查不会影响集合中的现有数据。 您自己必须确保根据新方案更新数据。 自己决定这是否足以满足您的需求。
  
• 本地查询语言/工具生态系统的丧失 ：SQL的出现已成为一场绝对的革命，此后没有任何改变。 它是一种非常强大的语言，但是也很复杂。 对具有JSON片段的新语言进行数据库查询设计的需求被具有SQL经验的人们视为一大步。 与SQL数据库交互的工具种类繁多：从IDE到报表工具。 进入不支持SQL的数据库意味着您无法使用这些工具中的大多数，或者您需要将数据转换为SQL才能使用它们，这可能比您想象的要困难。

许多求助于MongoDB的开发人员并没有真正理解权衡取舍，因此经常全力以赴，将其设置为主数据存储。 在此之后，通常很难回头。

本可以做些什么？

不是每个人都跳到头并触底。 但是许多项目在根本不适合的地方安装了MongoDB基础-他们将不得不与它一起生活很多年。 如果这些组织花费一些时间并有条理地考虑技术的选择，那么许多公司将做出不同的选择。

如何选择合适的技术？ 已经进行了多种尝试来创建用于评估技术的系统框架，例如“将技术引入软件组织的 框架 ”和“用于评估软件技术的框架” ，但是在我看来，这是不必要的复杂性。

仅问两个基本问题就可以合理地评估许多技术。 问题是找到能够对他们负责任的人，花时间寻找答案并且没有偏见。

如果您没有遇到任何问题，则不需要新工具。 重点。

问题1：我要解决什么问题？

如果您没有遇到任何问题，则不需要新工具。 重点。 无需寻找解决方案，然后再提出问题。 如果您没有遇到新技术无法解决比现有技术更好的问题，则无需讨论。 如果您因为看到其他人如何使用而考虑使用此技术，请考虑他们所面临的问题并询问您是否有此类问题。 接受这项技术很容易，因为其他人会使用它，难点在于了解您是否面临同样的问题。

问题2：我输了什么？

这无疑是一个更困难的问题，因为您必须对新技术和旧技术进行深入的了解和理解。 有时，您无法真正理解新员工，除非您用它来构建新东西，或者您有一位具有这种经验的员工。

如果您俩都不拥有，那么考虑最小的可能投资来确定此工具的价值是很有意义的。 而且，如果您进行投资，那么逆转决定有多困难？

人们总是宠坏一切

尝试尽可能公正地回答这些问题，请记住一件事：您必须与人性作斗争。 为了有效评估技术，必须克服许多认知偏见。 这里只是一些：

• 加入多数党的影响 -每个人都知道这一点，但是仍然很难与之抗衡。 只要确保该技术确实符合您的实际需求即可。
  
• 新颖性的影响 -许多开发人员倾向于低估长期使用的技术，而高估了新技术的优势。 不只是程序员，每个人都会遭受这种认知偏见。
  
• 积极特征的影响 -我们倾向于看到是什么，而看不到缺少的东西。 这可能会导致混乱和新颖效果，因为您不仅高估了新技术，而且还忽略了它的缺点 。

客观评估并不容易，但是了解基本的认知偏见将有助于做出更理性的决定。

总结

当某种创新出现时，必须非常小心地回答两个问题：

• 这个工具能解决一个真正的问题吗？
  
• 我们对妥协了解得很好吗？

如果您不能自信地回答这两个问题，请退后一步思考。

那么MongoDB通常是正确的选择吗？ 当然可以； 与大多数工程技术一样，这取决于许多因素。 在回答了这两个问题的人中，许多人已经从MongoDB中受益，并继续从中受益。 谁没有这样做，我希望他们能获得有关沿炒作周期运动的宝贵而又不太痛苦的教训。

免责声明

我想澄清一下，我对MongoDB既无爱又无恨。 只是我们没有遇到最适合MongoDB的问题。 我知道10gen / MongoDB Inc. 最初，她采取了大胆的行动，设置了不安全的默认值，并将MongoDB推广到任何地方（尤其是在黑客马拉松上），作为处理任何数据的通用解决方案。 这可能是一个错误的决定。 但是它证实了此处描述的方法：即使对技术进行了表面评估，也可以很快发现这些问题。