我最近发现 （例如，由于许可证更改）。 这让我想到，在过去的几年里，我看到了很多关于 MongoDB 有多糟糕以及任何人都不应该使用它的文章。 但在这段时间里，MongoDB 已经成为一个更加成熟的产品。 发生了什么？ 所有的仇恨真的都是新DBMS上市之初的失误造成的吗？ 或者人们只是在错误的地方使用了 MongoDB？
如果你突然觉得我在为 MongoDB 辩护，请阅读 在文章的最后。
新趋势
公平地说，我在软件行业工作的时间比我多，但我仍然只是冲击我们行业的趋势的一部分。 我见证了 4GL、AOP、Agile、SOA、Web 2.0、AJAX、区块链的兴起……这个列表是无止境的。 每年都有新的趋势。 有些正在迅速消失，而另一些正在从根本上改变软件的开发方式。
围绕每一个新趋势，都会产生某种普遍的兴奋：人们要么自己跳上船，要么看到别人发出的声音——然后随波逐流。 Gartner 已将此过程编入 . 虽然值得商榷，但这张图粗略地描述了技术在最终变得有用之前会发生什么。
但时不时会有（或有第二次出现，如本例）一项新的创新，仅由它的一个特定实施驱动。 就 NoSQL 而言，这种炒作在很大程度上是由 MongoDB 的出现和迅速崛起推动的。 MongoDB 并没有开启这个趋势：事实上，大型互联网公司开始出现处理大量数据的问题，这导致了非关系型数据库的回归。 一般运动始于 Google 的 Bigtable 和 Facebook 的 Cassandra 等项目，但 MongoDB 成为大多数开发人员可以访问的 NoSQL 数据库最著名和最易访问的实现。
注意：您可能认为我将文档数据库与列数据库、键/值存储或属于 NoSQL 通用定义的任何其他类型的数据存储混淆了。 你是对的。 但在当时，一片混乱。 人人都痴迷NoSQL，它已经成为一切 абсолютно 必要的，尽管许多人没有看到不同技术的差异。 对于许多人来说，MongoDB 已经成为 与...同义 无 SQL。
开发人员跳上了它。 无模式数据库可以神奇地扩展以解决任何问题的想法非常诱人。 2014年左右，好像一年前用MySQL、Postgres、SQL Server等关系型数据库的地方，都在部署MongoDB数据库。 当被问及原因时，您可能会得到从平庸的“这就是网络的规模”到更深思熟虑的“我的数据结构非常松散并且非常适合没有模式的数据库”的答案。
重要的是要记住，MongoDB 和一般的文档数据库解决了传统关系数据库的许多问题：
- 严格的计划：对于关系数据库，如果你有动态生成的数据，你将被迫创建一堆随机的“不同”数据列，将数据块推送到那里，或者使用配置 ……所有这些都有明显的缺点。
- 缩放难度：如果数据太多以至于一台服务器放不下，MongoDB 提供了允许它在多台机器上横向扩展的机制。
- 复杂的电路修改: 没有迁移！ 在关系数据库中，更改数据库的结构可能是一个巨大的问题（尤其是当有大量数据时）。 MongoDB 已经能够大大简化这个过程。 并使其变得如此简单，您可以随时随地更新模式并非常快速地继续前进。
- 写入性能：MongoDB 的性能很好，尤其是在适当调整的情况下。 即使是经常受到批评的 MongoDB 的开箱即用配置，也显示出一些令人印象深刻的性能数据。
所有风险由您承担
MongoDB 的潜在好处是巨大的，特别是对于某些类别的问题。 如果您阅读上面的列表而不了解上下文并且没有经验，那么您可能会觉得 MongoDB 确实是一个革命性的 DBMS。 唯一的问题是上面列出的好处伴随着一些警告，其中一些列在下面。
公平地说，10gen/MongoDB Inc. 没有人。 不会说下面的不是真的，这些只是妥协。
- 交易损失答：事务是许多关系数据库（不是全部，但大多数）的核心特征。 事务意味着您可以原子地执行多个操作，并可以确保数据保持一致。 当然，对于 NoSQL 数据库，事务性可以在单个文档中，或者您可以使用两阶段提交来获得事务性语义。 但是您必须自己实现此功能……这可能是一项困难且耗时的任务。 通常直到您看到数据库中的数据进入无效状态时您才意识到这个问题，因为无法保证操作的原子性。 注意：许多人告诉我，去年 MongoDB 4.0 中引入了事务，但有一些限制。 文章的结论保持不变：评估该技术如何满足您的需求。
- 关系完整性丢失（外键）：如果您的数据有关系，那么您将不得不在应用程序中应用它们。 拥有一个尊重这些关系的数据库将减轻应用程序的大量工作，从而减轻您的程序员的工作量。
- 无法应用数据结构：严格的模式有时可能是个大问题，但如果使用得当，它们也是良好数据结构的强大机制。 像 MongoDB 这样的文档数据库提供了令人难以置信的模式灵活性，但这种灵活性消除了保持数据清洁的责任。 如果您不处理它们，您将最终在您的应用程序中编写大量代码来说明未以您期望的形式存储的数据。 正如他们在我们公司 Simple Thread 中经常说的那样……应用程序总有一天会被重写，但数据将永远存在。 注意：MongoDB 支持模式验证，这很有用但不提供与关系数据库相同的保证。 首先，添加或更改架构验证不会影响集合中的现有数据。 您必须确保根据新模式更新数据。 自己决定这是否足以满足您的需求。
- 自己的查询语言/失去工具生态：SQL 的出现是一场绝对的革命，从那以后什么都没有改变。 这是一种非常强大的语言，但也非常复杂。 需要用一种新的语言构建数据库查询，由 JSON 片段组成，这被有 SQL 经验的人视为一大退步。 从 IDE 到报告工具，有一整套与 SQL 数据库交互的工具。 迁移到不支持 SQL 的数据库意味着您无法使用这些工具中的大部分，或者您需要将数据转换为 SQL 才能使用它们，这可能比您想象的要困难。
许多转向 MongoDB 的开发人员并没有真正理解其中的取舍，并且经常一头扎进将其设置为他们的主要数据存储。 在那之后，要回去往往是非常困难的。
可以做些什么？
不是每个人都是头先跳后坠入谷底的。 但是有相当多的项目在它不适合的地方安装了 MongoDB 基础——他们将不得不使用它很多年。 如果这些组织花一些时间系统地考虑他们的技术选择，许多人会做出不同的选择。
如何选择合适的技术？ 已经有几次尝试创建一个系统的技术评估框架，例如 и ，但在我看来，这是一种不必要的复杂性。
只需提出两个基本问题，就可以对许多技术进行明智的估值。 问题在于找到能够负责任地回答他们的人，花时间寻找答案并且没有偏见。
如果您没有遇到问题，则不需要新工具。 点。
问题 1：我想解决什么问题？
如果您没有遇到问题，则不需要新工具。 点。 无需寻找解决方案，然后提出问题。 除非您面临的问题是新技术无法比现有技术更好地解决问题，否则这里没有什么可讨论的。 如果您正在考虑使用这项技术，因为您看到其他人使用它，请考虑他们遇到的问题并询问您是否遇到这些问题。 拥抱技术很容易，因为其他人正在使用它，困难在于知道你是否面临同样的问题。
问题 2：我错过了什么？
这当然是一个比较难的问题，因为你必须对新旧技术都进行深入挖掘和理解。 有时你无法真正理解一个新的，直到你用它构建了一些东西或者有一个有这种经验的同事。
如果您两者都没有，那么考虑用最少的可能投资来确定该工具的价值是有意义的。 如果您进行了投资，那么要扭转这个决定会有多难？
人们总是毁掉一切
在尝试尽可能公正地回答这些问题时，请记住一件事：你必须与人性作斗争。 为了有效地评估技术，必须克服许多认知偏差。 这里仅仅是少数：
- 人人都知道他，但还是很难对付他。 只要确保该技术真正适合您的实际需求即可。
- 许多开发人员倾向于低估他们已经使用了很长时间的技术，而高估了新技术的好处。 不仅是程序员，每个人都会受到这种认知偏差的影响。
- 我们倾向于看到什么是什么，而忽视什么不是。 这可能会导致混乱，再加上新奇效应，因为你不仅天生高估了新技术，而且忽视了它的缺点。.
客观评估并不容易，但了解潜在的认知偏差将帮助您做出更理性的决定。
总结
当一项创新出现时，需要非常谨慎地回答两个问题：
- 这个工具能解决实际问题吗？
- 我们善于理解权衡取舍吗？
如果您不能自信地回答这两个问题，请退后几步思考一下。
那么 MongoDB 通常是正确的选择吗？ 当然可以； 与大多数工程技术一样，它取决于许多因素。 在回答这两个问题的人中，许多人已经从 MongoDB 中受益，并将继续这样做。 对于那些还没有经历过的人，我希望你们已经学到了关于穿越炒作周期的宝贵且不太痛苦的一课。
免责声明
我想澄清一下，我既不喜欢也不讨厌 MongoDB。 我们只是没有 MongoDB 最适合解决的那种问题。 我知道 10gen/MongoDB 公司。 一开始非常大胆，设置不安全的默认值并在任何地方（尤其是在黑客马拉松上）推广 MongoDB 作为处理任何数据的一站式解决方案。 这可能是一个错误的决定。 但它证实了这里描述的方法：即使对技术进行肤浅的评估，也可以非常快速地检测到这些问题。
来源： habr.com