关系数据库与图数据库的比较

Question

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

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

Answer 1

两种风格背后都有概念推理。维基百科the relational model和graph databases给出了很好的概述。

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

这有重要的后果：

• 关于大数据操作的关系数据库要快得多 的记录。在图形数据库中，必须检查每个记录 在查询期间单独确定结构 数据虽然在关系数据库中提前知道。
• 关系数据库使用较少的存储空间，因为它们没有 存储所有这些关系。

只有在关系中存在很多变化时，才能将个人记录级别的所有关系存储起来。否则你只是一遍又一遍地重复相同的事情。这意味着图形数据库非常适合不规则，复杂的结构。但在现实世界中，大多数数据库需要定期的，相对简单的结构。这就是关系数据库占主导地位的原因。

Answer 2

图形和关系数据库之间的关键区别在于，关系数据库可以使用集合，而图形数据库可以使用路径。

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

正如Dan1111暗示的那样，大多数图形数据库都没有遭受这种联合痛苦，因为它们在基本层面上表达了关系。也就是说，关系在物理上存在于磁盘上，它们被命名，定向，并且可以自己用属性修饰（这称为属性图模型，请参阅：https://github.com/tinkerpop/blueprints/wiki/Property-Graph-Model）。这意味着如果您选择，您可以查看磁盘上的关系并查看它们如何“加入”实体。因此，关系是图数据库中的第一类实体，并且在语义上远远强于在关系存储中在运行时实现的隐含关系。

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

1. 图形数据库比连接数据的关系数据库快得多 - 这是底层模型的优势。这样做的结果是，图表数据库中的查询延迟与您在查询中选择要浏览的图表的数量成正比，并且与存储的数据量不成比例，因此会解除join bomb。
2. 图形数据库使建模和查询更加愉快，这意味着更快的开发和更少的WTF时刻。例如，在Neo4j的Cypher查询语言中表达典型社交网络的朋友朋友只是MATCH (me)-[:FRIEND]->()-[:FRIEND]->(foaf) RETURN foaf。

Answer 3

Dan1111已经给出了一个标记为正确的答案。其他几点值得注意。

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

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

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

值得注意的第二点是，万维网可以被视为一个巨大的图形数据库。网页包含超链接和超链接引用，以及其他网页。引用是通过URL，其功能类似于指针。

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

Answer 4

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

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

在某些情况下，更改图表数据库中的数据模型比在RDBMS中更容易，例如在RDBMS中如果我将表关系从1：n更改为m：n我需要应用具有潜在停机时间的DDL。

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

我在graph databases for data warehousing

的博客文章中讨论了其他一些优点和缺点

Answer 5

尽管关系模型可以轻松表示图模型中包含的数据，但我们面对两个问题 实践中的重大问题：

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

参考： Next Generation Databases

Answer 6

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

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

Answer 7

图形数据库值得研究它们擅长的用例，但是我有一些理由质疑上述响应中的某些断言。特别是：

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

图形数据库比连接数据的关系数据库要快得多，这是基础模型的优势。这样的结果是，图数据库中的查询等待时间与您选择在查询中浏览的图的数量成正比，与存储的数据量不成正比，从而缓解了连接炸弹的麻烦。 （吉姆·韦伯的第一个要点）

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

尽管这些断言可能很有价值，但我还没有找到一种方法来使我的特定用例与它们保持一致。 参考：Graph Database or Relational Database Common Table Extensions: Comparing acyclic graph query performance