113

有人可以向我解释一下关系数据库（如 MySQL）与 Neo4j 等图形数据库相比的优缺点吗？

在 SQL 中，您有多个表，其中有各种 id 链接它们。然后你必须加入连接表。从新手的角度来看，为什么要将数据库设计为需要连接，而不是像图形数据库那样从一开始就将连接显式地作为边。从概念上讲，这对新手来说毫无意义。大概有一个非常技术性但非概念性的原因？

4

7 回答 7

142

这两种风格背后实际上都有概念上的推理。关于关系模型和图形数据库的维基百科对此进行了很好的概述。

主要区别在于，在图形数据库中，关系存储在单个记录级别，而在关系数据库中，结构是在更高级别（表定义）定义的。

这具有重要的影响：

  • 在处理大量记录时，关系数据库要快得多。在图形数据库中，必须在查询期间单独检查每条记录以确定数据的结构，而这在关系数据库中是提前知道的。
  • 关系数据库使用较少的存储空间，因为它们不必存储所有这些关系。

仅当关系中存在大量变化时，将所有关系存储在个人记录级别才有意义；否则你只是一遍又一遍地复制同样的东西。这意味着图形数据库非常适合不规则的复杂结构。但在现实世界中，大多数数据库都需要规则的、相对简单的结构。这就是关系数据库占主导地位的原因。

于 2012-10-24T09:51:51.897 回答
104

图和关系数据库之间的主要区别在于关系数据库使用集合，而图数据库使用路径。

对于 RDBMS 用户而言，这以意想不到且无益的方式表现出来。例如，当尝试通过递归加入关系数据库来模拟路径操作（例如朋友的朋友）时，查询延迟会像内存使用一样不可预测地大量增长，更不用说它会折磨 SQL 来表达这些类型的操作。在基于集合的数据库中，更多数据意味着更慢，即使您可以通过明智的索引来延缓痛苦。

正如 Dan1111 所暗示的那样，大多数图形数据库不会遭受这种连接痛苦，因为它们在基本级别上表达了关系。也就是说，关系物理上存在于磁盘上，它们被命名、定向，并且可以用属性自己装饰（这称为属性图模型，请参阅：https ://github.com/tinkerpop/blueprints/wiki/Property-Graph -型号）。这意味着如果您选择这样做，您可以查看磁盘上的关系并了解它们如何“加入”实体。因此，关系是图形数据库中的一等实体，并且在语义上比在运行时在关系存储中具体化的那些隐含关系强得多。

那么你为什么要关心呢？有两个原因：

  1. 对于连接数据，图形数据库比关系数据库快得多——这是底层模型的优势。这样做的结果是，图形数据库中的查询延迟与您选择在查询中探索的图形量成正比，与存储的数据量不成正比，从而消除了连接炸弹。
  2. 图数据库使建模和查询更加愉快，这意味着更快的开发和更少的 WTF 时刻。例如，在 Neo4j 的 Cypher 查询语言中为典型的社交网络表达朋友的朋友就是MATCH (me)-[:FRIEND]->()-[:FRIEND]->(foaf) RETURN foaf.
于 2013-07-30T09:17:31.810 回答
22

Dan1111 已经给出了一个标记为正确的答案。另外还有几点值得注意。

首先，几乎在图数据库的每个实现中，记录都是“固定”的，因为有未知数量的指针指向当前位置的记录。这意味着如果不将转发地址留在旧位置或破坏未知数量的指针，就无法将记录洗牌到新位置。

从理论上讲，可以一次对所有记录进行洗牌，并找出一种方法来定位和修复所有指针。在实践中，在大型图形数据库上执行此操作可能需要数周时间，在此期间数据库必须停止运行。这是不可行的。

相比之下，在关系数据库中，记录可以在相当大的范围内重新洗牌，唯一需要做的就是重建任何受影响的索引。这是一个相当大的操作，但远不及图形数据库的等效操作。

顺便提一下的第二点是，万维网可以看作是一个巨大的图形数据库。网页包含超链接，并且超链接尤其引用其他网页。引用是通过 URL，其功能类似于指针。

当一个网页被移动到一个不同的 URL 而不在旧 URL 上留下一个转发地址时，未知数量的超链接将被破坏。这些断开的链接随后会引发可怕的“错误 404：找不到页面”消息，从而打断了许多冲浪者的乐趣。

于 2012-10-26T05:12:10.593 回答
9

使用关系数据库，我们可以使用外键和自连接对图进行建模和查询。仅仅因为RDBMS'包含关系这个词并不意味着它们擅长处理关系。RDBMS 中的关系一词源于关系代数而不是关系。在 RDBMS 中，关系本身并不作为对象存在。它要么需要显式表示为外键，要么隐式表示为链接表中的值（当使用通用/通用建模方法时）。数据集之间的链接存储在数据本身中。

我们在关系数据库中增加的搜索深度越多，我们需要执行的自联接就越多，我们的查询性能受到的影响就越大。我们在层次结构中走得越深，我们需要加入的表就越多，我们的查询就越慢。从数学上讲，成本在关系数据库中呈指数增长。换句话说，我们的查询和关系越复杂，我们从图与关系数据库中受益越多。导航图形时，我们在图形数据库中没有性能问题。这是因为图形数据库将关系存储为单独的对象。然而，卓越的读取性能是以较慢的写入为代价的。

在某些情况下，在图形数据库中更改数据模型比在 RDBMS 中更容易，例如，在 RDBMS 中，如果我将表关系从 1:n 更改为 m:n，我需要应用 DDL 并可能导致停机。

另一方面，RDBMS 在其他领域具有优势，例如聚合数据或对数据进行时间戳版本控制。

我在关于用于数据仓库的图形数据库的博文中讨论了其他一些优缺点

于 2017-06-16T18:48:12.730 回答
4

虽然关系模型可以很容易地表示包含在图模型中的数据，但我们在实践中面临两个重大问题：

  1. SQL 缺乏轻松执行图遍历的语法，尤其是深度未知或无界的遍历。例如，使用 SQL 确定朋友的朋友很容易，但很难解决“分离度”问题。
  2. 当我们遍历图表时，性能会迅速下降。每个级别的遍历都会显着增加查询响应时间。

参考：下一代数据库

于 2018-10-02T08:18:12.440 回答
2

图数据库值得研究它们擅长的用例，但我有理由质疑上述回复中的一些断言。尤其：

在处理大量记录时，关系数据库要快得多（dan1111 的第一个要点）

对于连接数据，图形数据库比关系数据库快得多——这是底层模型的优势。这样做的结果是，图形数据库中的查询延迟与您选择在查询中探索的图形量成正比，与存储的数据量不成正比，从而消除了连接炸弹。（吉姆韦伯的第一个要点）

换句话说，我们的查询和关系越复杂，我们从图与关系数据库中受益越多。（Uli Bethke 的第 2 段）

虽然这些断言可能很有价值，但我还没有找到一种方法来让我的特定用例与它们保持一致。参考：图数据库或关系数据库公用表扩展：比较非循环图查询性能

于 2020-08-10T00:01:19.420 回答
1

关系数据库在存储表格数据方面效率更高。尽管名称中有“关系”一词，但关系数据库在存储或表达存储的数据元素之间的关系方面效率要低得多。关系数据库中的“关系”一词更多地与表中的相关列有关，而不是与不同表中的信息相关。存在列之间的关系以支持集合操作。因此，随着数据库以数百万或数十亿条记录增长，从关系数据库中检索数据变得极其缓慢。

与关系数据库不同，图数据库完全围绕数据关系构建。图数据库不将关系视为模式结构，而是将其视为数据，就像其他值一样。从图形数据库中检索数据非常快。从关系数据库的角度来看，您可以将其视为在插入时预先实现 JOIN，而不是为每个查询计算它们。因为数据完全围绕数据关系构建，所以无论数据集有多大或有多大连接，都可以实现实时查询性能。与关系数据库相比，图数据库占用更多的存储空间。

于 2020-10-23T16:16:44.673 回答