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

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

在SQL中，您有多个具有各种ID的表链接它们。然后，您必须加入才能连接表。从新手的角度来看，您为什么要设计数据库以要求联接，而不是像图数据库那样从一开始就明确将连接作为边。从概念上讲，这对于新手来说毫无意义。大概有一个非常技术性但非概念性的原因吗？

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

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

这具有重要的影响：

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

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

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

对于RDBMS用户，这以意外和无益的方式表现出来。例如，当尝试通过递归加入关系数据库来模拟路径操作（例如，朋友的朋友）时，查询等待时间会像内存使用情况一样意外地，大量地增长，更不用说它折磨SQL来表达这些操作。即使可以通过明智的索引来延迟痛苦，但更多的数据意味着基于集合的数据库中的速度较慢。

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

那你为什么要在乎呢？有两个原因：

1. 对于连接的数据，图形数据库比关系数据库要快得多，这是基础模型的优势。这样的结果是，图数据库中的查询等待时间与您选择在查询中浏览的图的数量成正比，而不与所存储的数据量成正比，因此可以减轻联接炸弹的负担。
2. 图形数据库使建模和查询更加愉快，这意味着更快的开发速度和更少的WTF时刻。例如，用Neo4j的Cypher查询语言表达典型社交网络的“朋友的朋友” MATCH (me)-[:FRIEND]->()-[:FRIEND]->(foaf) RETURN foaf。

Dan1111已经给出了标记为正确的答案。还有几点需要注意。

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

从理论上讲，可以一次将所有记录洗牌，并找到一种定位和修复所有指针的方法。实际上，此操作可能需要在大型图形数据库上花费数周的时间，在此期间必须关闭数据库。只是不可行。

相比之下，在关系数据库中，记录可以以相当大的规模重新排列，唯一要做的就是重建所有受影响的索引。这是一个相当大的操作，但远不及图形数据库的等效操作大。

值得一提的第二点是，万维网可以看作是一个巨大的图形数据库。网页包含超链接，超链接引用以及其他网页。该引用是通过URL进行的，其功能类似于指针。

当网页移动到其他URL而不在旧URL上保留转发地址时，未知数量的超链接将损坏。这些断开的链接将引起可怕的“错误404：找不到页面”消息，从而中断了许多冲浪者的娱乐。

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

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

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

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

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

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

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

参考：下一代数据库

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

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

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

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

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