MongoDB和一般的文档数据库解决了传统关系数据库的一些问题：
- 严格的模式 - 使用关系数据库，如果你有动态形态的数据，你不得不创建一堆随机的“杂项”数据列，将数据作为一个数据块推送，或使用EAV设置...所有这些都有重要意义缺点。
- 难以扩展 - 使用关系数据库，如果您的数据太大而无法轻松地将其放入一台服务器中，MongoDB内置了允许您跨多台计算机扩展数据的机制。
- 困难的架构修改 - 没有迁移！使用关系数据库，更改数据库的结构可能是一个巨大的挑战（特别是一旦您的数据变得非常大）。MongoDB承诺使这一过程变得更加简单。它使得它很容易上手，你可以继续更新你的架构并快速移动。
- 写性能 - MongoDB的性能很好，特别是在以某种方式配置时。MongoDB开箱即用的写入配置，这是它受到批评的重大事件之一，它允许它提供一些令人印象深刻的性能数字。
MongoDB提供的潜在好处是巨大的，特别是对于面临某些类问题的人。在没有上下文或经验的情况下阅读上面的列表会让你相信它在数据库系统方面真正改变了游戏规则。唯一的问题是上面列出的好处带来了一些警告，其中一些我在下面列出：
- 没有事务 - 事务是许多关系数据库的核心特征（不是，不是全部，而是大多数）。进行事务意味着您可以原子地执行多个操作，并且可以确保您的数据保持一致。当然，使用NoSQL数据库，您可以在单个文档中拥有事务，或者您可以使用两阶段提交等策略来获得类似事务的语义。但关键是你必须自己做这项工作......而且要做到正确，这可能是一项具有挑战性和劳动力密集的工作。在您开始看到数据库中的数据进入无效状态之前，您通常不会意识到您放弃了多少，因为您无法保证操作的原子性。
- 失去关系完整性（外键） - 如果你的数据有关系，那么你就会有关系。几乎所有数据都有某种关系，如果您的数据库没有强制执行，那么您的应用程序将不得不这样做。让数据库强制执行这些关系可以从应用程序中卸载大量工作，从而减轻工程师的工作量。
- 缺乏执行数据结构的能力 - 强有力的模式有时可能是一种痛苦，但它们也可以成为确保数据结构良好的强大机制。如果您恰当地利用它们，它提供了一种强大的机制来确保您的数据符合您期望的形状。像MongoDB这样的文档数据库可以在模式周围提供令人难以置信的灵活性，但这种灵活性可以将责任转移到维护者身上，以保持数据的清洁。如果您没有付出这些努力，那么您最终会在应用程序中添加大量代码，以便考虑可能不符合您预期形状的数据。正如我们经常喜欢在简单线程中说的那样...您的应用程序将在某一天被重写，您的数据将永远存在。
- 自定义查询语言/工具生态系统的丢失 - SQL出现时是一场绝对的革命，从那以后没有任何变化。SQL是一种非常强大的语言，但也可能具有挑战性。必须使用由JSON片段组成的自定义查询语言查询数据库，对于经验丰富的SQL人员来说，这将被认为是一大步。有一整套工具可与SQL数据库互操作。从IDE到报告工具的一切。迁移到不支持SQL的数据库意味着您无法使用大多数这些工具，或者您必须找到一种方法将数据放入SQL数据库以便可以使用这些工具，这可能比您认为。
许多参与MongoDB的开发人员并没有深入理解他们所做的权衡，而且他们常常将它作为应用程序的主要数据存储区。这意味着这个决定通常是非常昂贵的。
未来几年将有一些项目将MongoDB从其不适合的地方移除。如果这些组织中的许多组织花了一些时间来有条不紊地思考他们所做的技术选择，那么很可能他们中的许多人都没有做出他们所做的决定。
那么，您如何确定哪种技术对您的用例有意义？已经有一些尝试创建用于评估技术的系统框架，例如“ 软件组织中的技术引入框架 ”和“ 评估软件技术的框架 ”，但我不认为它需要那么复杂。