什么时候应该使用 NoSQL 数据库而不是关系数据库？在同一个站点上同时使用这两种方法可以吗？

小开

NoSQL 解决方案通常用于解决关系数据库不太适合的问题，或者使用成本太高(如 Oracle) ，或者要求您实现一些打破数据库的关系特性的东西。

优点通常是特定于您的用法的，但是除非您在使用 RDBMS 建模数据时遇到某种问题，否则我认为没有理由选择 NoSQL。

我自己使用 MongoDB 和 Riak 来解决 RDBMS 不是可行解决方案的特定问题，我使用 MySQL (或 SQLite 进行测试)来解决所有其他问题。

如果你通常知道需要一个 NoSQL 数据库，可能的原因是:

客户需要99.999% 的可用性交通繁忙的地方。
你的数据在 SQL 中没有任何意义，你会发现自己执行多个 JOIN 查询获取一些信息。
你打破了我们的关系模特，你有 CLOB 的商店反规范化的数据，然后生成搜索该数据的外部索引。

如果您不需要 NoSQL 解决方案，请记住，这些解决方案并不是 RDBMS 的替代品，而是前者失败的替代品，更重要的是，它们相对较新，因此仍然存在许多 bug 和缺失的功能。

哦，关于第二个问题，将任何技术与另一个技术结合使用完全没有问题，所以根据我的经验，只要 MongoDB 和 MySQL 不在同一台机器上，它们可以很好地协同工作

小开

最佳答案

关系数据库执行酸。因此，您将拥有基于模式的面向事务的数据存储。它已经被证明适用于99% 的实际应用程序。您实际上可以使用关系数据库做任何事情。

但是，当涉及到大规模的高可用性数据存储时，速度和伸缩性都会受到限制。例如，谷歌和亚马逊在大数据中心存储了兆字节的数据。由于 RDBM 的阻塞/模式/事务特性，查询和插入在这些场景中不能执行。这就是为什么他们实现了自己的数据库(实际上是键值存储) ，以获得大量的性能提升和可伸缩性。

NoSQL 数据库已经存在很长时间了——只是这个术语是新的。有些例子是图形、对象、列、 XML 和文档数据库。

对于你的第二个问题: 在同一个站点上同时使用这两种方法可以吗？

为什么不呢? 两者的目的不同，对吧？

小开

Martin Fowler 有一个很好的视频，它很好地解释了 NoSQL 数据库。这个链接直接指向他使用它们的原因，但是整个视频包含了很好的信息。

您拥有大量的数据——特别是当您无法在一个物理服务器上将其全部放置时，因为 NoSQL 的设计就是为了很好地扩展。
对象关系不匹配 -域对象不适合关系数据库模式。NoSQL 允许您将数据保存为文档(或图形) ，这些文档(或图形)可能更接近于您的数据模型。

小开

NoSQL 是一个数据库系统，其中的数据被组织成文档(MongoDB)、键值对(MemCache、 Redis)和图形结构形式(Neo4J)。

也许对于“何时使用 NoSQL”这个问题，可能存在一些问题和答案:

需要灵活的模式还是处理树状数据？
一般来说，在敏捷开发中，我们开始设计系统时并不知道所有的前期需求，而后来在整个开发数据库系统中可能需要适应频繁的设计变更，展示 MVP (最小可行产品)。或者您正在处理一个本质上是动态的数据模式。例如，系统日志，非常精确的例子是 AWS 云路径日志。
数据集很大/很大？
是的 NoSQL 数据库是更好的候选应用程序，数据库需要管理数百万甚至数十亿的记录，而不影响性能和可用性，同时可能是不一致的交易(虽然现代数据库是例外，它允许可调整的一致性超过可用性，例如 Casandra，云提供商数据库 CosmosDB，DynamoDB)。
可伸缩性与一致性之间的权衡
与 RDMS 不同，NoSQL 数据库最终可以使数据集在其他节点之间保持一致，这是默认行为，但是在性能和可用性方面很容易扩展。示例: 这可能有助于将在线人员存储在即时通讯应用程序中，在数据库中存储 API 令牌，并记录网站流量统计数据。
执行地理定位操作: MongoDB 散列丰富支持地理查询和地理定位操作。我非常喜欢 MongoDB 的这个特性。PostresSQL 也是如此，但是实现的难易程度取决于用例

简而言之，MongoDB 非常适合于大规模存储动态结构化数据的应用程序。

编辑: 更新了关于数据库一致性的答案。

小开

我遇到这个问题时，正在寻找令人信服的理由来偏离 RDBMS 设计。

有一个伟大的邮寄的朱利安布朗，它阐明了分布式系统的约束。这个概念被称为布鲁尔的 CAP 定理，概括起来就是:

分布式系统的三个要求是: 一致性、可用性和分区容忍度(简称 CAP)。但你一次只能吃两个。

这就是我对自己的总结:

如果您正在牺牲一致性，那么您最好使用 NoSQL。

小开

缺少一些必要的信息来回答这个问题: 数据库必须能够覆盖哪些用例？是否必须从现有数据(OLAP)执行复杂的分析，还是应用程序必须能够处理许多事务(OLTP) ？数据结构是什么？问题还远没有结束。

在我看来，根据大胆的流行语做出技术决策，而不确切知道这些决策背后的原因是什么，这是错误的。NoSQL 经常因其可伸缩性而受到称赞。但是您还必须知道，横向扩展(在多个节点上)也有其代价，而且不是免费的。然后，您必须处理诸如最终一致性之类的问题，并定义如果数据冲突无法在数据库级别解决时如何解决它们。不过，这适用于所有分布式数据库系统。

开发人员在 NoSQL 中使用“ schema less”这个词的乐趣在一开始也是非常大的。经过技术分析之后，这个流行词很快就不再是幻想了，因为它在写作时正确地不需要模式，而是在阅读时发挥作用。这就是为什么它应该正确地是“已读模式”。能够自行决定写入数据可能很诱人。但是，如果存在现有数据，但应用程序的新版本需要不同的模式，那么我该如何处理这种情况呢？

文档模型(例如 MongoDB)是数据模型的不合适，其中数据之间存在许多关系。连接必须在应用程序级别上完成，这是额外的工作，为什么我应该编程数据库应该做的事情。

如果你认为谷歌和亚马逊已经开发了自己的数据库，因为传统的关系数据库管理系统不再能够处理大量的数据，你只能说: 你不是谷歌和亚马逊。这些公司是先锋，在传统数据库不再适用的情况下，有0.01% 的情况是这样，但是对于世界其他地方来说，它们是适用的。

不容忽视的是: SQL已经存在了40多年，数百万小时的开发进入了大型系统，如 Oracle 或 Microsoft SQL。这必须通过一些新的数据库来实现。有时，找到一个 SQL 管理员也比找到 MongoDB 管理员要容易。这就把我们带到了维护和管理的问题上。这个主题并不完全性感，但这是技术决策的一部分。

小开

我使用 NoSQL 数据库设计和实现了解决方案，下面是我的检查点列表，用于决定使用 SQL还是 面向文档的 NoSQL。

不要

SQL 并没有过时，在某些情况下仍然是一个更好的工具。很难证明使用面向文档的 NoSQL 的合理性

需要 OLAP/OLTP
这是一个小型项目/简单的 DB 结构
需要临时查询
无法避免立即的一致性
不明确的要求
缺乏经验丰富的开发人员

是的

如果你没有这些条件或者可以减轻它们，那么这里有两个你可以从 NoSQL 中受益的原因:

需要大规模运行
开发的便利性(更好地整合你的技术堆栈，不需要在 ORM 等等)

更多信息

在我的博客文章中，我详细解释了其中的原因:

注意: 以上仅适用于面向文档的 NoSQL。

小开

处理大量的读写操作

当你需要快速扩展的时候，看看 NoSQL 数据库，你通常什么时候需要快速扩展？

当你的网站上有大量的读写操作，当处理大量的数据时，NoSQL 数据库最适合这些场景。因为它们能够动态地添加节点，所以它们能够以最小的延迟处理更多的并发流量和大量数据。

数据建模的灵活性

第二个提示是在开发的初始阶段，当您对数据模型、数据库设计不确定时，预计事情会以很快的速度发生变化。NoSQL 数据库为我们提供了更大的灵活性。

强一致性的最终一致性

当我们可以放弃强一致性和不需要事务时，最好选择 NoSQL 数据库。

一个很好的例子就是像 Twitter 这样的社交网站。当一个名人的推特爆炸了，每个人都从世界各地喜欢和转发它。喜欢的数量在短时间内是上升还是下降有关系吗？

明星肯定不会在乎，如果不是实际的500万500个赞，系统显示同样的数字为500万250一会儿。

当一个大型应用程序部署在遍布全球的数百台服务器上时，地理上分布的节点需要一些时间来达成全球共识。

在他们达成共识之前，实体的价值是不一致的。实体的值最终在一段时间后变得一致。这就是最终一致性。

虽然不一致并不意味着有任何类型的数据丢失。这只是意味着数据需要很短的时间通过海底的互联网电缆传遍全球，以达成全球共识并保持一致。

我们一直都在经历这种行为。尤其是在 YouTube 上。通常你会看到一个有10次浏览和15个赞的视频。这怎么可能？

不是的。实际的观点已经比喜欢的多了。只是视图的数量不一致，需要很短的时间来更新。

运行数据分析

NoSQL 数据库也非常适合数据分析用例，因为我们必须处理大量涌入的数据。