我们什么时候应该使用MongoDB？

MongoDB是一个NoSQL数据库，我发现它非常易于使用。最近，我不得不开发一个简单的应用程序，该应用程序需要使用HTTP请求收集一些数据并在处理数据后存储一些结果，然后我尝试使用MongoDB。

通过这种经验，我发现使用它比使用传统的关系数据库要好得多，并且由于我是开发人员而不是DBA，因此极大地简化了我的工作。

不过，有时我不确定何时应该使用MongoDB代替传统的关系数据库（如SQL Server或MySQL）。

在那种情况下，何时可以使用MongoDB代替关系数据库？是否有关于MongoDB的重大警告，使其在某些情况下不合适？

基本上：

• 如果您可以用一堆文档的形式表示数据，那么MongoDB可能是一个不错的选择。

• 如果您希望将数据想象成一堆相互关联的表，那么MongoDB可能不是一个好选择。

这是我发现的两个示例：

• 几年前，我创建了一个博客引擎。其目的是托管博客文章，并为每篇文章存储不同的版本，一些元数据，访问统计信息等。

  可以将其存储为一堆表，但是在尝试构建模型时，它会快速增长到十几个表，甚至更多。有些SQL查询可能会因为很多joins而变得丑陋，而且……嗯，您就知道了。

  这里的问题是，有一个核心内容-博客文章-文章中包含所有这些内容，这使其非常适合基于文档的数据库。使用MongoDB，对数据库进行建模非常容易：一个集合包含博客文章，而另一个小集合包含允许编写文章的用户列表。第一个集合中的每个文档将包含显示文章时我需要的所有信息，无论是作者的姓名还是标签。

• 现在想象一个非常不同的项目。有些用户可以编写内容，并共享其他用户编写的内容。在用户的页面上，您可能希望同时找到该用户编写的内容和她共享的内容。有一个限制：当某人编辑他过去写的内容时，更改会出现在共享原始文本的任何地方。

  使用基于文档的方法，很难找到要作为文档的内容。可能是用户？好吧，这是一个好的开始。用户文档将包含该用户编写的所有内容。但是她分享的东西呢？

  一种可能的方法是将这些内容放入同一文档中。这种方法的问题在于，如果有人编辑条目，则应用程序应遍历数据库中的每个用户文档，以便编辑每次出现的旧条目。不计算数据重复。

  另一种选择是在用户文档中仅保留该用户共享的条目列表（带有被引用用户的ID和条目）。但是现在，将会出现一个不同的问题：如果一个用户共享了成千上万个用户的成千上万个条目，则将需要打开成千上万个文档才能获得这些条目。

  或者，我们可以围绕条目本身对集合进行建模，每个条目都引用其作者并具有共享它的用户列表。同样，当您需要浏览所有文档以显示给定用户发布的文档时，性能问题可能会变得很明显。

  现在，如果您使用关系数据库，则需要多少张表？对三 这将很容易建模，也很容易使用。

每种技术都有其优势。

关系数据库的优点是RDBMS可以为您做一些事情，例如：

• 强制参照完整性（如果发票所属的发票不存在，则不允许插入发票明细）
• 避免冗余：事物仅存储一次。
• 可以使用成熟，经过时间证明且广泛使用的声明性语言（SQL）来完成复杂的查询。

所有这些可以归结为以下事实：您必须编写更少的代码，因为RDBMS会为您强制执行操作。

此外，数据独立性：通常，如果您使用标准SQL结构而不使用特定于供应商的结构，则可以以最小的麻烦将数据从一个RDBMS迁移到另一个RDBMS，而NOSQL数据库则完全没有标准化。

另一方面，NOSQL数据库的优点之一是它们可以扩展以更好地维护数百万行的性能。它们更适合于基于文档的存储，即非结构化数据。但是大多数应用程序不需要这些功能。

对于您的特定情况，MongoDB听起来是一个不错的选择，但是在很多情况下（可能是大多数情况），它并不是最佳选择。

MongoDB更适合需要读取/写入大量数据，而又不十分强调事务安全性的情况（如果某些数据偶尔在服务器崩溃中丢失，这没什么大不了的），希望扩大规模，而不要确实有一个稳定的架构。

MongoDB 不适合需要以下条件的方案：

1. 强大的ACID保证：MongoDB允许存储重复的数据，不一致的读取甚至丢失数据。这些东西在某些应用程序中很好，但在大多数应用程序中却不是。
2. 多对象事务：MongoDB确实支持ACID事务，但仅适用于单个对象/文档。这只是不会将其用于更复杂的操作，例如银行转账，预订等。
3. 传统的BI：有很多BI工具只能与传统的SQL一起使用。
4. SQL：MongoDB有一种非常特定的查询语言，而SQL被很多人所熟知（可能是要考虑的一个重要方面），可以做很多复杂的事情（而对于MongoDB，您将无法执行简单的操作联接），并且可以在许多实现中转移。

MongoDB更快，通过消除默认情况下RDBMS强制执行的许多工作（例如完整性检查），可以使您从系统中获得更多性能（请注意，您仍然可以为此目的调整RDBMS），但事实是，在大多数情况下，只是不需要它。另外，要权衡的是可靠性和灵活性（如果以后决定需要对现有数据执行更复杂的操作，将会遇到麻烦）。

这完全取决于您正在构建的应用程序的需求。是速度和可用性，还是安全性，可靠性和灵活性。您必须知道数据（以及数据连接）中的何处具有更大的价值。如果您还不知道，最好选择将来不会使您陷入困境的东西，并允许您添加功能并执行应用程序所需的操作。

当您可以将数据表示为独立的信息“包装”时，MongoDB非常有用。您有google maps邮政编码，其中嵌入的邮政编码是公司，公司内部是员工。所有邮政编码彼此独立，您可以通过简单，美观，快速的方式获取全部信息。对于非SQL解决方案，这是一个好方案。

曾经说过，我完全不同意当前的趋势，这暗示MongoDB是RDBMS的一种后期和高级解决方案，默认情况下noSQL必须是您的解决方案。所有这些都是荒谬的。MongoDB是一个利基数据库，并且90％的项目都是关系型的，并且需要RDBMS选项，因为您想要像SQL这样的强大查询解决方案来生成报告并查找分散数据：“ joins”是一个优点，而不是缺点。此外，现代的RDBMS支持BSON集合和地理空间集成，因此现在noSQL的市场可能会更狭窄。

MongoDB对于存储构建网页给定实例所需的全部结构化数据非常有用。您可以检索给定页面的数据，将其传递到客户端应用程序，然后可以呈现它。

在这种情况下，MongoDB非常快速且可靠。但是，永远不要忘记您的数据库中没有关系信息。这意味着，如果您更改网页的结构，则可能无法填补已存储页面中的漏洞，因为您没有这样做所需的数据。此处的更多信息：http : //www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/