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

Posted 2023-02-16

【中文标题】什么时候应该使用 NoSQL 数据库而不是关系数据库？可以在同一个网站上使用两者吗？

【英文标题】：When should I use a NoSQL database instead of a relational database? Is it okay to use both on the same site?

【发布时间】：2011-04-12 09:58:24

【问题描述】：

使用 NoSQL 数据库有哪些优势？我最近阅读了很多关于它们的内容，但我仍然不确定我为什么要实现一个，以及在什么情况下我想使用一个。

【参考方案1】：

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

但是，当涉及到海量高可用性数据存储时，速度和扩展性会受到限制。例如，谷歌和亚马逊有数 TB 的数据存储在大数据中心。由于 RDBM 的阻塞/模式/事务性质，在这些场景中查询和插入性能不高。这就是他们实现自己的数据库（实际上是键值存储）以实现巨大的性能提升和可扩展性的原因。

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

关于您的第二个问题：可以在同一个网站上同时使用两者吗？

为什么不呢？两者都有不同的用途对吧？

【讨论】：

我不认为 ACID 是关系数据库独有的。您可以在非关系数据库中获得持久性保证、事务、视图一致性。

@RamshVel 你能举一个键值存储类型数据库的例子吗？谢谢。

@Rachael，一些例子是 redis、leveldb 和 riak.. 周围有很多，你可以谷歌它

【参考方案2】：

NoSQL 解决方案通常旨在解决关系数据库不太适合、使用起来过于昂贵（如 Oracle）或要求您实现一些无论如何都会破坏数据库关系性质的问题。

优势通常取决于您的使用情况，但除非您在 RDBMS 中建模数据时遇到某种问题，否则我认为您没有理由选择 NoSQL。

我自己使用 MongoDB 和 Riak 解决 RDBMS 不是可行解决方案的特定问题，对于所有其他事情我使用 mysql（或 SQLite 进行测试）。

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

客户端希望 99.999% 的可用性 高流量网站。 您的数据使 在 SQL 中没有意义，你会发现自己 做多个 JOIN 查询 访问一些信息。 你打破了关系 模型，你有 CLOB 存储 非规范化数据，您生成 用于搜索该数据的外部索引。

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

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

【讨论】：

感谢您的回答。您关于何时使用 NoSQL 的示例充其量是模糊的。我希望有一个更具体的用例，这样我就可以决定是否将我的任何数据更好地存储在 NoSQL 数据库中。

我尽量不要两次回答同一个问题，看看我之前对一个非常相似的问题的回答***.com/questions/3621415/…

我同意 Asaf 的出色回答，实际上只有少数场景需要 NoSQL 而不是 RDBMS。我将 NoSQL 视为备份数据库或“附加数据库”，而不是主数据库。我还没有看到一个好的系统，其中核心数据库是 NoSQL。

【参考方案3】：

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

您拥有大量数据 - 尤其是当您无法将所有数据都放在一台物理服务器上时，因为 NoSQL 旨在很好地扩展。

Object-relational impedance mismatch - 您的域对象不适合关系数据库模式。 NoSQL 允许您将数据持久化为文档（或图表），这些文档（或图表）可以更紧密地映射到您的数据模型。

【参考方案4】：

NoSQL 是将数据组织成文档（MongoDB）、键值对（MemCache、Redis）、图结构形式（Neo4J）的数据库系统。

也许这里有关于“何时使用 NoSQL”的可能问题和答案：

需要灵活的架构或处理树状数据？ 通常，在敏捷开发中，我们在不了解所有需求的情况下就开始设计系统，随后整个开发数据库系统可能需要适应频繁的设计更改，展示 MVP（最小可行产品）。 或者您正在处理本质上是动态的数据模式。 例如系统日志，非常精确的例子是 AWS cloudwatch 日志。

数据集很大/很大？ 是的，对于需要在不影响性能的情况下管理数百万甚至数十亿条记录的应用程序，NoSQL 数据库更适合。

在缩放与一致性之间进行权衡 与 RDMS 不同，NoSQL 数据库可能会到处丢失小数据（注意：概率为 .x%），但在性能方面它易于扩展。 示例：这可能有助于在即时消息应用中存储在线人员、数据库中的令牌、记录网站流量统计信息。

执行地理定位操作： MongoDB 哈希对执行地理查询和地理定位操作的丰富支持。 我真的很喜欢 MongoDB 的这个特性。

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

【讨论】：

“NoSQL 数据库可能会到处丢失小数据” WTF！？现在有谁会愿意冒这个险呢？这一定是假的。

@JayQ。是的，它可能是假的。这就是为什么我说*也许。那么为什么我们不能使用 NpSQL DB 进行事务操作呢？

【参考方案5】：

缺少一些基本信息来回答这个问题：数据库必须能够覆盖哪些用例？是否必须从现有数据（OLAP）执行复杂的分析，还是应用程序必须能够处理许多事务（OLTP）？数据结构是什么？距离提问时间还很远。

在我看来，在不知道其背后的确切内容的情况下根据大胆的流行语做出技术决策是错误的。 NoSQL 经常因其可扩展性而受到称赞。但是您还必须知道，水平扩展（在多个节点上）也有其代价，而且不是免费的。然后您必须处理eventual consistency 之类的问题，并定义如果无法在数据库级别解决数据冲突，如何解决它们。但是，这适用于所有分布式数据库系统。

在 NoSQL 上用“少模式”这个词的开发人员一开始的喜悦也是很大的。在技​​术分析之后，这个流行词很快就消失了，因为它在写作时正确地不需要模式，但在阅读时会发挥作用。这就是为什么它应该正确地是“读取模式”。能够自行决定写入数据可能很诱人。但是，如果有现有数据但新版本的应用程序需要不同的架构，我该如何处理？

文档模型（例如在 MongoDB 中）是not suitable，用于数据之间存在许多关系的数据模型。连接必须在应用程序级别完成，这是额外的工作，为什么我要编写数据库应该做的事情。

如果你说谷歌和亚马逊开发了自己的数据库是因为传统的 RDBMS 无法处理海量数据，你只能说：你不是谷歌和亚马逊。这些公司是带头人，大约 0.01% 的场景不再适用于传统数据库，但对于世界其他地区来说却是。

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

【讨论】：

似乎是正确的，但我认为如果每个人都在他们的所有应用程序中都使用汇编语言的话，比较它花费了多少时间也是不对的到您的应用程序和用例

【参考方案6】：

处理大量读写操作

当您需要快速扩展时，请考虑使用 NoSQL 数据库。通常什么时候需要快速扩展？

当您的网站上存在大量读写操作以及处理大量数据时，NoSQL 数据库最适合这些场景。由于它们能够动态添加节点，因此它们可以以最小的延迟处理更多的并发流量和大量数据。

数据建模的灵活性

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

最终一致性优于强一致性

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

Twitter 等社交网站就是一个很好的例子。当名人的推文被炸毁，每个人都喜欢并转发来自世界各地的推文。点赞数在短时间内上升或下降有关系吗？

如果不是实际的 500 万 500 点赞，系统会在短时间内显示点赞数为 500 万 250，名人肯定不会在意。

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

在他们达成共识之前，实体的价值是不一致的。实体的价值最终会在短时间内保持一致。这就是最终一致性。

虽然不一致并不意味着有任何形式的数据丢失。这只是意味着数据需要很短的时间才能通过海底的互联网电缆在全球范围内传播，以达成全球共识并变得一致。

我们一直都在经历这种行为。特别是在 YouTube 上。通常你会看到一个有 10 次观看和 15 次喜欢的视频。这怎么可能？

不是。实际观看次数已经超过赞数​​。只是观看次数不一致，需要一段时间才能更新。

运行数据分析

NoSQL 数据库也最适合数据分析用例，在这些用例中我们必须处理大量涌入的数据。

【参考方案7】：

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

Julian Brown 有一个很棒的 post，它阐明了分布式系统的限制。这个概念被称为 Brewer 的 CAP 定理，总而言之：

分布式系统的三个要求是：一致性、可用性和分区容错性（简称CAP）。但是一次只能有两个。

这是我自己总结的：

如果你要牺牲一致性，你最好选择 NoSQL。

【参考方案8】：

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

不要做

SQL 并没有过时，在某些情况下仍然是更好的工具。当

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

要做的事情

如果您不具备这些条件或可以减轻这些条件，那么您可以从 NoSQL 中受益的 2 个原因：

需要大规模运行 开发方便（与您的技术堆栈更好地集成，无需 ORM 等）

更多信息

在我的博文中，我更详细地解释了原因：

7 reasons NOT to NoSQL 2 reasons to NoSQL

注意： 以上仅适用于面向文档的 NoSQL。 NoSQL有other types，需要其他考虑。