logo标签列表

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

sqlrelational-databasegraph-databases
124

请问有人可以为我解释关系数据库（如MySQL）与图形数据库（如Neo4j）之间的优缺点吗？

在SQL中，你有多个表格，并用不同的ID将它们链接在一起。然后您必须使用联接来连接这些表格。对于一个新手来说，为什么要设计需要使用连接的数据库，而不是在开始时将连接作为边缘显式呈现出来，就像图形数据库那样呢？对于一个新手来说，这在概念上毫无意义。也许这背后有非常技术性但非概念性的原因？

1
访问方法是不同的。在关系型数据库中，您使用关系代数，最好搭配递归使用，其中一种笨拙但流行的表示形式是（带有过程性额外功能）SQL。在图形数据库中，您使用图遍历语言，如Gremlin。底层的数据库实现直到磁盘布局都将被选择为相应访问方法提供最佳性能，并且在实现中可能会发现任意调整/变化。 - David Tonhofer
8个回答
155

实际上，这两种风格背后都有概念推理。维基百科关于关系模型和图数据库的介绍很好地解释了这一点。

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

这具有重要的影响：

  • 当操作大量记录时，关系型数据库比图形数据库快得多。在查询期间，图形数据库必须逐个检查每个记录以确定数据的结构，而在关系型数据库中，这已经预先知道。
  • 关系型数据库使用更少的存储空间，因为它们不必存储所有这些关系。

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

24
在其他情况下，按记录级别存储关系也是有道理的，因为它提供了无索引相邻性。也就是说，可以执行图遍历而不需要索引查找，从而获得更好的性能。而且这并不是重复，因为您存储的是实际上不同的关系。 - nawroth
4
你说：“在图形数据库中，每个记录在查询过程中都必须单独检查以确定数据的结构”。这是图形数据库的普遍特性还是一般情况下更或多或少正确的呢？那么支持顶点和边的完整模式的OrientDb呢？答案：这是图形数据库的普遍特性。即使某些图形数据库支持完整模式（如OrientDb），在查询期间仍需要检查每个记录以确定其数据结构。 - Lodewijk Bogaards
8
我强烈不同意这两个观点。当存在外键时，图形数据库始终更快，因为我们不需要连接操作。关系型数据库必须在许多表中存储外键。一条边和一个外键应该占用相同的存储空间。 - cegprakash
3
@cegprakash，你是否有相关文档可以让我们得出同样的结论？ - Victor
1
指向供应商的观点并不能得出明确的结论。 - Matthew Whited
显示剩余3条评论
107
图形数据库和关系型数据库的主要区别在于，关系型数据库使用集合，而图形数据库使用路径。
这对于关系型数据库用户来说，在尝试模拟路径操作（例如朋友的朋友）时会表现出意想不到和无用的方式。通过在关系型数据库中递归连接来模拟路径操作时，查询延迟和内存使用量会不可预测地增长，更不用说折磨 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。
4
在图形数据库中，关系是一流实体。在关系数据库中通常也是如此：实体被映射到关系中的元组，许多对多关系也是如此。你所描述的区别是否针对于那些经常被合并为实体关系的一对多关系？ - beldaz
65
这个比较似乎有点偏颇，那么它的缺点呢？ - Kurren
16
在我诚实的看法中，“稍微偏颇”这个词还不太足以形容。最好的情况下，这看起来像是一则“这是一个好产品！购买它”的广告！ - ilgaar
61
需要非常重要的说明：这个人是 Neo Technology 公司制作 Neo4J 图形数据库的“首席科学家”。 - Rob Grant
9
如何进行任意搜索？请给我列出过去90天在沃尔玛购物且年龄在35至55岁之间的所有用户。 - Matthew Whited
显示剩余3条评论
23

Dan1111已经给出了一个被标记为正确答案的答案。值得一提的是还有几点需要注意。

首先，在几乎所有图形数据库的实现中，记录都会被“固定”，因为有未知数量的指针指向记录的当前位置。这意味着记录不能在没有在旧位置留下转发地址或者破坏未知数量的指针的情况下被移动到新位置。

理论上，可以同时洗牌所有记录并找出一种方法来查找和修复所有指针。但实际上，这是一个在大型图形数据库上可能需要数周时间的操作，在此期间数据库必须处于离线状态。这是不可行的。

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

其次，值得一提的第二点是全球范围内的万维网可以被视为一个巨大的图形数据库。网页包含超链接，超链接引用了，除其他外，其他网页。引用是通过URL进行的，这类似于指针。

当网页被移动到不同的URL而没有在旧URL上留下转发地址时，许多超链接将变为失效。这些损坏的链接随后引发了令人生畏的“错误404：页面未找到”消息，中断了如此多冲浪者的乐趣。

7
大多数图形数据库都具有完整性规则，不允许存在断链。 - Michael Hunger
1
如果DBMS固定了目标，这显然会防止由于移动链接目标而导致的链接断裂。我不知道有任何图形数据库不固定可能成为链接目标的记录。 - Walter Mitty
图形数据库通常是无模式的吗？因为模式更改会非常耗费资源，需要重写所有指针。是否可以通过仅存储虚拟指针并通过查找表进行操作来避免重新排序问题？这仍然可以在O（1）上执行，对吗？ - Lodewijk Bogaards
我一直在使用图形数据库的定义，其中包括分层或网络等预关系性数据库。其中一些数据库具有模式，尽管不是关系模式。我不确定我的操作定义是否符合标准定义。 - Walter Mitty
提供虚拟指针和物理指针之间映射的数据结构本质上与索引相同，成本也差不多。你可以考虑使用关系型数据库。 - Walter Mitty
在 Web 项目中（类似于 Facebook），使用图形和关系型数据库是否高效？ - alayli
11
使用关系型数据库，我们可以通过使用外键和自连接来建模和查询图形。仅仅因为RDBMS中包含了关系这个词，并不意味着它们擅长处理关系。RDBMS中的关系本身并不存在于自己的对象中。它需要明确地表示为外键或者在链接表中隐式地表示为值（当使用通用/通用建模方法时）。数据集之间的链接存储在数据本身中。
随着在关系型数据库中增加搜索深度，我们需要执行更多的自连接，我们的查询性能也会受到影响。我们在层次结构中越深入，就需要连接更多的表，查询速度就越慢。在关系型数据库中，成本在数学上呈指数级增长。换句话说，我们的查询和关系变得越复杂，我们从图形相对于关系型数据库中受益就越多。当导航图形时，我们在图形数据库中没有性能问题。这是因为图形数据库将关系存储为单独的对象。然而，卓越的读取性能是以较慢的写入为代价的。
在某些情况下，图形数据库比关系型数据库更容易更改数据模型，例如，在关系型数据库中，如果我将一张表的关系从1：n更改为m：n，则需要应用DDL并可能导致停机时间。另一方面，关系型数据库在其他领域具有优势，例如聚合数据或对数据进行时间戳版本控制。我在我的博客文章中讨论了其他优缺点。
2
关系型数据库管理系统中的“关系”一词源于关系代数，而不是关系。在关系代数和关系型数据库管理系统中，“关系”一词的含义是指表格表示的关系/关联，而不是外键等关系的意义。那些误解关系模型的方法错误地将外键称为关系。外键不需要被知道或存在才能记录或查询。必要且充分的查询条件是要知道一个（基本表或查询结果）表格所代表的关系/关联。 - philipxy
5
虽然关系模型可以轻松地表示图形模型中包含的数据，但实际应用中存在两个重大问题：
  1. SQL缺乏语法来轻松执行图形遍历，特别是深度未知或无限制的遍历。例如，使用SQL确定您的朋友的朋友很容易，但难以解决“分离程度”问题。
  2. 随着我们遍历图形，性能会快速下降。每个遍历级别都会显著增加查询响应时间。
参考资料：Next Generation Databases
2
递归SQL可以解决这两个问题。Postgres、SQL Server、Oracle，甚至MySQL现在都支持递归查询。 - dakini
4
图形数据库值得研究其擅长的用例，但我对上面的回复中的某些说法产生了质疑。特别是：
一个关系型数据库在处理大量记录时速度更快（dan1111的第一个要点）。
图形数据库比关系型数据库更适合处理连接数据 - 这是底层模型的优势。其结果是，在图形数据库中，查询延迟与查询中选择探索图形的程度成正比，而不是与存储的数据量成正比，从而消除了连接炸弹。(Jim Webber的第一个要点)
换句话说，我们的查询和关系越复杂，使用图形数据库就能获得越多好处，而不是关系型数据库。（Uli Bethke的第二段）
虽然这些说法可能有道理，但我还没有找到一种方法使我的具体用例与它们相符。 参考：Graph Database or Relational Database Common Table Extensions: Comparing acyclic graph query performance
1
关系型数据库在存储表格数据方面更为高效。尽管其名称中带有“关系”一词，但与存储或表达存储数据元素之间的关系相比，关系型数据库在这方面要不那么有效。
“关系型”在关系型数据库中的含义更多地涉及到表内列之间的关系，而不是不同表中信息之间的关系。列之间的关系存在以支持集合操作。因此，随着数据库记录数量增加到数百万或数十亿条，从关系型数据库检索数据变得极其缓慢。
与关系型数据库不同，图形数据库完全围绕数据关系结构化。图形数据库将关系视为数据，而不是模式结构。
从关系型数据库的角度来看，您可以将其视为在插入时预先材料化JOIN，而不是为每个查询计算它们。由于数据完全围绕数据关系结构化，无论数据集有多大或连接，都可以实现实时查询性能。
与关系型数据库相比，图形数据库需要更多的存储空间。
0
关系型数据库如MySQL使用连接和规范化来确保数据一致性并优化存储。图形数据库如Neo4j将关系表示为边，提供了一种更自然和高效处理互联数据的方式，使其适用于具有复杂关系的场景。
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接