MongoDB永远是正确的选择吗？
此前，Simple Thread 的博客作者贾斯汀·埃瑟利奇（Justin Etheredge）列举了 MongoDB 独特的优势和缺点，试图回答上述问题，并分享了在确定技术方案时要思考的两个问题，以下为重点内容。
我所经历的发展趋势中的一小部分也一直困扰着我们的行业。我目睹了4GL，AOP，敏捷，SOA，Web 2.0，AJAX，区块链的兴起……列表永无止境。每年，软件工程领域都会涌现出新的趋势。有些迅速消失，而另一些则从根本上改变了软件开发的方式。
每隔一段时间，就会出现一项新的创新（或在本例中重新出现），该创新是由该创新的一种特定实现方式驱动的。对于NoSQL运动，它在很大程度上受到MongoDB的出现和迅猛发展的推动。MongoDB并没有开始发展，而是大型互联网公司的数据挑战真正推动了非关系数据库的回归。像Google的Bigtable和Facebook的Cassandra这样的项目开始了它，但是MongoDB是大多数开发人员可以访问的开源NoSQL数据库的最可见和可访问的实现。
您可能现在正在考虑，我正在将面向文档的数据库与列式数据库，键/值存储库或属于通用NoSQL旗帜的众多其他数据存储库类型中的任何一个合并。你是正确的。但这在当时很疯狂。每个人都跳入NoSQL的热潮，他们知道他们绝对需要NoSQL，但并不真正了解所涉及的不同技术。对许多人来说，MongoDB是NoSQL。
开发人员对此大加抨击。使用无格式的数据库的想法使用类似json的文档，可以轻松地跨多个服务器运行，并且可以神奇地扩展以应对任何挑战，这一想法非常诱人。大约在2014年左右，似乎到处可见有人在某个地方实施MongoDB，而一年前就已经使用了MySQL，Postgres或SQL Server等关系数据库。当被问及为什么要使用Mongo时，响应范围很广，从过时的“网络规模”到更周到的“我的数据结构非常松散，非常适合无模式数据库”。
首先，需要明确的是，MongoDB 以及文档数据库等能够帮助人们搞定很多传统关系数据库无法应对的难题，比如：
- 严格的模式：在传统数据库当中，如果你掌握的是动态数据，就必须创建一堆随机的“杂项”数据列以将数据作为数据块进行推送，或者使用 EAV 设置等，而这些都有着严重的缺陷。
- 难于扩展：在传统数据库中，如果你的数据规模太过庞大就无法被直接存放在单一服务器当中，相比之下，MongoDB 的内置功能允许你跨越多台计算机实现数据扩展。
- 架构修改难题：在使用关系数据库时，变更数据库结构无疑是一大难题。MongoDB 会简化这一过程，使得结构调整更加轻松顺手，你可以持续更新架构并快速完成迁移。
- 写入性能： MongoDB 的性能相当不错，特别是在配合正确的配置方式之后。MongoDB 开箱即用的写入配置虽然成为不少人抨击它的理由，但也确实带来了一些令人印象深刻的性能数字。MongoDB 能够带来的潜在优势无疑是巨大的，面对特定问题类型的用户确实可以从中获益良多。但它也存在不少问题，MongoDB 公司并不是没有考虑到这些问题，他们只是做出了自己的权衡。
事务机制的局限性。事务可以说是众多关系数据库的核心特征。事务机制意味着用户能够以原子方式执行多项操作，并始终确保数据内容保持一致。尽管 MongoDB 4.0 已经引入了事务机制，但其中仍然存在不少局限性。
关系完整性（外键）丢失。如果你的数据之间存在关系，那么这种关系就是一种客观现实。几乎所有数据中都包含某种关系，如果数据库没有强制体现这些关系，就得由应用程序负责构建。具体来讲，由数据库强制执行这些关系将帮助应用程序减轻大量负担，从而降低软件工程师们的日常工作量。
缺乏执行数据结构的能力。强模式有时候代表着一种短板，但只要加以合理运用，其同时也可能成为确保数据拥有良好结构的有力机制。相比之下，MongoDB 这类文档数据库能够在模式层面带来令人难以置信的灵活性，但这种灵活性同时会将责任转嫁到维护者身上，强制要求其保持数据清洁。如果没有给予应有的关注，那你最终不得不在应用程序中添加大量代码，从而消化那些在结构上与预期不符的数据。 注意：MongoDB 支持模式验证，这项功能非常有用，但仍然无法带来可与关系数据库相媲美的保障。首先，添加或修改架构验证不会影响集合中的任何现有数据，因此你需要自行确保数据更新以匹配新的架构。换言之，到底是否满足需求还是得由你自己决定。
以上就是埃瑟利奇的观点，希望能给你带来参考价值。原文链接：Was MongoDB Ever the Right Choice?
