文档导向数据库是否意味着要取代关系型数据库？

Question

最近我在与MongoDB有所接触，我必须说我非常喜欢它。然而，它是完全不同类型的数据库，不像我以前用过的数据库。我注意到它绝对适合某些类型的数据，但对于高度规范化的数据库来说可能不是最佳选择。

但在我看来，它完全可以代替任何关系型数据库，而且在大多数情况下表现更好，这令人难以置信。这引发了我一些问题：

1. 文档导向数据库是否被开发成为下一代数据库并基本上完全取代关系型数据库？
2. 使用文档导向数据库和关系型数据库并排使用以适应更适合其中一种的各种数据是否会更好？
3. 如果文档导向数据库不打算取代关系型数据库，那么是否有一个例子表明某个数据库结构绝对适合关系型数据库（或反之亦然）？

- tplaner

---

简短回答：不。 - Nick Larsen

也感兴趣的是：https://dev59.com/cnRC5IYBdhLWcg3wUvQS - David Neale

我认为这种“简短回答”对我们来说几乎没有什么用处 :P - baraber

Answer 1

文档导向型数据库（如MongoDB）非常擅长处理现代网站中通常出现的任务类型（单个或少量项目的快速查找）。但是，它们与关系系统存在一些巨大的权衡。没有像ACID合规性这样的东西，它们将无法替代某些RDBMS。如果您看看像MongoDB这样的系统，缺乏ACID合规性是其如此之快的一个重要原因。 可以同时使用文档导向型数据库和关系型数据库来更好地为各自更适合的数据处理需求服务。在我运营的一个非常庞大的生产网站上，我们正在使用两种数据库。该系统最初使用MySQL启动，但我们已将部分内容迁移到MongoDB，因为我们需要一个键值存储，而MySQL在150M记录中查找单个项目方面并不太好。 文档导向型数据库非常适合存储易于包含在“键值”和简单的线性“父-子”关系中的数据。例如博客和维基百科等简单示例。然而，关系数据库仍然在报告等“基于集合”的事物方面具有很强的优势。老实说，我可以看到一个世界，其中大多数数据都由文档导向型数据库“处理”，但报告是由Map-reduce作业更新的关系数据库完成的。

- Gates VP

---

优秀的回答，被标记为答案，因为您实际上回答了我所有的问题。谢谢。 - tplaner

@Gates VP，当谈论关系数据库时，“基于集合”的意思是什么？您能简单解释一下吗？谢谢~ - DiveInto

Answer 2

这实际上是一个关于适用性的问题。

如果您想要连接一些表并返回过滤后的结果集，只有关系型数据库才能做到。如果您想获得惊人的性能并拥有大量数据，那么列族或文档导向数据库就可以发挥作用了。

这是一个经典的权衡。关系型数据库为您提供了整套功能，但会带来性能成本。如果您无法连接、索引、扫描或执行其他一系列功能，则可以消除对所有数据的视图需求，从而获得处理大量数据所需的性能和分布。

另外，我建议您关注Ayende Rahien在这个主题上的博客。 http://ayende.com/blog/

- Fenton

---

我一定会查看这篇博客，不过你觉得可能同时使用两种方案吗？ - tplaner

如果您的应用程序景观中有一个“巨大的量需求”需要处理，那么您只需要使用面向文档的数据库替换这一部分，并在性能不是问题的情况下保留关系型数据库及其所有功能。 - Fenton

Answer 3

@Sohnee说得很对。我可以补充一点，关系数据库

• 非常适合在意料之外的组合中检索信息--即使有时也会导致糟糕的想法：在时间敏感的生产系统上运行广泛的报告，而不是在单独的数据仓库上运行。
• 是一种成熟的技术，在这里你可以轻松地找到员工和经过充分测试的解决方案（包括关系模型的局限性以及 SQL 的不完美实现等问题）。

问问自己你想做什么，以及哪些特质对你来说很重要。你可以用 shell 脚本来完成所有与编程有关的事情。你想吗？

- Pontus Gagge

Answer 4

我一直在问同一个问题，这也是我来到这里的原因。我同时使用MySQL和MongoDB（目前不是同时使用，但这是个想法）。老实说，我很高兴再也不用碰MySQL了。当然，它符合“ACID”标准，但你是否曾经需要修复MySQL中的表格？你是否曾经遇到过数据库损坏的情况？这种情况确实存在。你是否曾经遇到过MySQL的任何其他问题？任何锁争用或死锁的问题？任何关于集群的问题？设置和配置有多容易？

MongoDB...打开它，就完成了……然后它就自动分片了。它非常简单，而且非常快。所以，请考虑一下。你的时间。

不，它们没有JOINs，但说它排除了超过99％的数据管理需求是完全错误的陈述。当我试图解释MongoDB时，我经常会遇到反对意见，甚至会有人嘲笑。让我们面对现实吧。人们不想学习新事物，他们认为他们所知道的就是他们所需要的。当然，你可以继续使用MySQL建立网站，它有效，我们知道它有效。我们也知道它会失败。如果不是这样，你永远不会提出这个问题，我们可能也不会看到这么多文档导向数据库。我们知道它可以扩展，但是扩展它很麻烦。

此外，让我们排除流量和扩展的因素。消除设置。现在让我们关注使用。当你使用MySQL时，你的经验如何？你对MySQL架构和制作高效查询有多好？你花多少时间来查看带有EXPLAIN的查询？你花多少时间制作模式图？……我说把那些时间拿回来。更好地利用它们。

这就是我的两分钱。我真的很喜欢MongoDB，并希望再也不用MySQL了。对于我构建的网站类型，很可能我不需要它。虽然我仍在努力找出何时我会想要使用MySQL而不是MongoDB，而不是我可以（让我们面对现实，它存储数据，恭喜，我也可以写一堆XML文件，但这不是一个好主意），而是何时使用其中之一会有益。与此同时，我将继续使用MongoDB进行工作，并减少头疼。

- Tom

Answer 5

只要您不需要多对象事务，MongoDB 可以成为关系型数据库的有利替代品，尤其是在 Web 应用程序的环境下。速度快、无模式和文档建模在这个领域都非常有帮助。

- Kyle Banker

Answer 6

在我看来，面向文档的数据库只适用于以下情况：

1. 使用分层（树形）模型更好地表示数据的数据库。这在网站数据库中并不常见。
2. 具有大量数据的数据库，例如 Facebook 和 Amazon 数据库。在这种情况下，需要放弃关系模型的优势。

- Bassem

Answer 7

MongoDB的主要特点包括：

• 文档模型（JSON）
  高级别（接近真实世界对象），少量集合
• 分片（可选）
• 程序员友好
  驱动程序，相同的数据结构数组/哈希映射

文档数据库
文档比表更通用，使用JSON表示表比将JSON存储到表中更容易。
因此，文档数据库可以替代表数据库。

分片
在任何数据库中，分片集合中的连接都很昂贵。 MongoDB多年前添加了$lookup，在MongoDB 5.1+中，即使两个集合都被分片，也可以使用它。
但是看起来，在分布式数据库中进行连接很慢，应该避免使用关系建模方式。

无分片
我认为当不使用分片时，MongoDB将与关系数据库共存并重叠（特别是在支持ACID和$lookup之后），难以取代它们，并且目前看来这也不是MongoDB的目标。

总的来说，MongoDB可以做到关系型数据库所能做的事情，但目前它并不能替代关系型数据库。 相反的情况并不成立，如果关系型数据库试图像MongoDB一样运作，那么它们会面临更大的问题。

- Takis

Answer 8

据我所知，文档数据库没有JOIN。这对于99%以上的数据管理需求来说几乎是一个致命缺陷。

正如Matthew Flaschen在评论中指出的那样，即使在桌面上，像SQLite这样的数据库也正在将SQL语义引入传统上使用专有文件格式或XML的领域。

- Marcelo Cantos

---

这意味着今天只有不到1%的数据没有存储和管理在关系型数据库中？然而，很多数据存储在电子表格、文件系统、日志文件、Word文档和PDF文件中。我认为Google Earth也没有使用关系型数据库。你会把假期照片存储在关系型数据库吗？我不会，我会将它们存储在文件系统中，并使用Picasa进行管理。关系型数据库尤其用于与金钱相关的事务。 - Theo

文档数据库使用不同的建模策略；例如，您可以轻松地在MongoDB上运行整个站点而不需要一个单一的连接。缺少连接几乎不会成为一个阻碍。 - Kyle Banker

@Theo，Picasa使用关系型数据库（http://www.mail-archive.com/[e-mail]/msg49389.html）。 - Matthew Flaschen

@kb，某些特殊类型的应用程序适合使用文档数据库。这并不意味着文档数据库将会主宰世界。我所做的许多工作需要涉及跨越许多表格的连接的非常复杂的查询，这在文档数据库中是完全不可能表达的。 - Marcelo Cantos

@kb，我在上一份工作中参与了一个“普通”（不知道是什么意思）的Web应用程序开发。该应用程序具有包含数十个表的数据模型，并且系统中几乎每个查询都需要使用连接操作，其中许多连接涉及半打甚至更多的表格。任何管理复杂度即使适度的数据的合理规模项目都不可能没有连接操作。认为否则是天真的。 - Marcelo Cantos