有人什么时候可以在关系型DBMS上使用MongoDB（或类似的产品）？

我对整个NoSQL之类的东西有些困惑。您何时选择在Oracle或MySQL上使用MongoDB之类的东西？就它们之间的用法而言，我并不真正理解“差异”。

从我的理解来看，NoSQL类型数据库不是要取代RDBMS，而是它们到底要做什么？

我之前将CouchDB用于三个宠物项目。

• 微型博客系统。
• 为了保存我做的一个小笔记应用程序的信息。
• 通用头脑风暴应用程序。

我之所以选择它而不是诸如MSSQL或MySQL之类的主要原因是使用它时所获得的灵活性。没有严格的架构。如果下线三个月，您需要一个特定的表来拥有一个额外的字段，而仅此而已，您只需对其进行更改，它便会不断地波动。

我使用Apress的Beginning CouchDB来学习如何使用它。

例如，CouchDB使用json与数据库进行通信。如果您的语言可以发布数据，则可以使用它与数据库进行通信。

另请阅读： 为什么我应该使用基于文档的数据库而不是关系数据库？在StackOverflow

很抱歉添加另一个答案，但是这里没有一个答案令人满意。这个答案是针对MongoDB的（与非关系数据库之外的大量其他数据存储选项相对）。

优点：

• MongoDB的每个查询的等待时间较短，并且每个查询花费的CPU时间更少，因为它的工作量大大减少（例如，无联接，事务）。结果，它可以处理每秒更高的查询负载，因此如果您有大量用户，则经常使用它。
• MongoDB 更易于分片（在集群中使用），因为它不必担心事务和一致性。
• MongoDB具有更快的写入速度，因为它不必担心事务或回滚（因此也不必担心锁定）。
• 万一您有一个特殊的用例可以利用它，MongoDB 没有模式。

缺点：

• MongoDB 不支持事务。这就是它获得大部分收益的方式。
• 通常，MongoDB为客户端服务器创建更多工作（例如，更多的CPU成本）。例如，要联接数据，必须发出多个查询并在客户端上进行联接。
• 即使在2017年，MongoDB的工具支持也比关系数据库要少，这仅仅是因为它较新。 MongoDB专家也少于关系专家。

经常被误解的要点：

• MongoDB和关系数据库都支持索引。 在执行大型查询方面，它们的查询性能相似。
• MongoDB不会消除迁移的需求，更具体地说，不会随着架构的发展而更新现有数据。例如：如果您有一个依赖用户表来包含某些数据的应用程序，并且修改了该表以包含不同的数据（例如，您添加了个人资料图片字段），那么您仍然需要：
  • 编写应用程序以处理未定义此属性的对象，或者
  • 编写一次迁移以为此属性输入默认值，或者
  • 如果此字段不存在，请编写代码以在查询时提供默认值，或者
  • 以其他方式处理丢失的字段

要无耻地从Renesis窃取（实际上，我正在CW做出此回答）：

使用RDBMS代替其他类型：

• 阅读有关“ NoSQL”和其他数据库类型的思想：
  • NoSQL：只是那么简单
  • （以上链接来自）何时使用MongoDB或其他面向文档的数据库系统？^{目前已在SO上删除}（更多）
  • https://softwareengineering.stackexchange.com/questions/5354/are-nosql-databases-going-to-take-the-place-of-relational-databases-is-sql-going
  • 何时使用CouchDB与RDBMS
• RDBMS大量使用索引来提高性能。在非常大的数据库上，这可能会对性能产生不利影响，甚至会减少每个DB / Shard需要更多硬件的最佳行数
• 如果您要存储大量数据但读取频率较低，则不太理想
• 如果您没有很多外部关系，则关系数据库可能不理想（文档存储）

当您的数据不相关时，使用NoSQL数据库可能会带来主要好处，例如性能和可伸缩性（当然取决于情况）。某些设计模式（例如CQRS）使在通常要求专用于SQL数据库的领域中利用非关系数据变得容易得多。

通常使用诸如mongo之类的数据库来缓存数据。例如，如果您需要生成报告，则可以执行一个复杂的SQL查询，该查询可以动态地连接和聚合一堆数据，或者您可以仅从mongo数据库中获取一个已经拥有生成所需内容的json文档。那个报告。这使得读取数据确实非常容易（而且快！），但是会使写入数据变得非常复杂（这就是CQRS的来历）。

当您通常知道数据在哪里（而不是需要编写多个复杂的查询）时，像MongoDB这样的数据库非常有用。使用Mongo，“相关”数据要么嵌套在父数据中，要么具有主键/外键。例如，如果您有帖子和评论，那就太好了；通常，您不会在帖子的上下文之外显示评论，因此将评论包含在帖子中是很有意义的（这样您就可以获取帖子的所有评论，而无需查询单独的表）。

MongoDB是无模式的。这意味着，在大多数情况下，它将采用您要扔给它的任何数据结构。

另一方面，如果您需要使用聚合函数并感到需要通过Mongo中的嵌入或简单关系无法实现的复杂方式查询数据，那就是时候该使用像MySQL或PostgreSQL这样的RDBMS了。

MongoDB并不是要取代SQL。它仅满足不同的需求，并且MongoDB和RDBMS可以结合使用。我认为，如果您不需要数据灵活或嵌入到父文档中，MongoDB并不需要所有。使用MongoDB进行开发非常有趣，因为启动和运行项目（例如在Rails中）涉及的步骤要少得多。需要改变吗？没问题。只需在模型中添加一个属性即可。做完了

我无法代表许多其他NoSQL数据库，尽管我知道它们通常是为满足RDBMS无法满足的特定需求而设计的。有些完全驻留在内存中，或者可以很容易地分片或扩展。我非常确定，如果节点发生故障，Cassandra旨在继续运行而不会丢失数据。Redis基本上是一个驻留在内存中的键值存储（具有用于持久性的定期磁盘写入功能），但也具有存储数据类型（如集合）并对其进行排序的能力。

主要胜利是当您想要分片数据或拥有多个主数据库时。您可以在MySQL中分片数据，但这会带来很大的麻烦。如果您要进行大量写入操作，则将数据分片到多个服务器上通常很有用，问题是，如果要在执行此操作时具有强大的参照一致性，则很难（即使不是不可能）查找CAP定理。

SQL数据库具有非常好的一致性，但分区支持却很差，NoSQL数据库则倾向于相反。易于分区，但通常称为最终一致性。如果您建立的消息站点还可以，那么对于银行来说可能就不行了。

优点是，现在有多个用于存储数据的模型，因此可以选择实现方式的方式，而以前只有SQL数据库。

SE Radio在这个问题上有一些不错的插曲。

当您写入大量数据并且查询需求不太复杂时，MongoDB可以很好地工作。因此，当您在Command端通过事件源实现CQRS时，MongoDB非常适合-即您的事件存储是MongoDB数据库。

在查询方面，由于其灵活性，我们仍然使用SQL Server数据库，其视图和WCF数据服务位于顶部。我认为在大多数情况下，您确实需要关系数据库的功能来进行查询。

MongoDB和RDBMS之间的直接和根本区别是基础数据模型。关系数据库将数据结构化为表格和行，而MongoDB将数据结构化为JSON文档的集合。JSON是一种自我描述的，人类可读的数据格式。它最初是为浏览器和服务器之间的轻量级交换而设计的，现已被许多类型的应用程序广泛接受。

出于多种原因，JSON文档对于数据管理特别有用。JSON文档由一组字段组成，这些字段本身就是键值对。这意味着每个JSON文档随处携带其自己的可读模式设计，从而使文档可以轻松地在数据库和客户端应用程序之间移动而不会失去其含义。

JSON也是在应用程序层中使用的自然数据格式。与由列和行组成的表相比，JSON支持更丰富，更灵活的数据结构。除了支持数字，字符串，布尔值等字段类型外，JSON字段还可以是数组或嵌套的子对象。这意味着我们可以表示一组复杂的关系，这些关系可以更紧密地表示我们的应用程序所使用的对象。在我们的数据库中使用JSON文档意味着我们在数据库与其服务的应用程序之间不需要对象关系映射器。我们可以以正确的形式保存数据

如果您的数据需要大量查询，则NoSQL解决方案不是很好，而当您需要事务支持（ACID）时，NoSql并不是最佳选择。我认为当您需要快速进行大量读取并且结构有点特别时，您可以通过文档或页面结构进行检索，从而使NoSQL大放异彩。但是，许多NoSQL解决方案的改进非常快，因此缺点很快就会消失。无论如何，我认为关系数据库仍然适合大多数应用程序。