Comparison of Relational Databases and Graph Databases

小开

最佳答案

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

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

这有着重要的影响:

关系数据库在大规模运作时要快得多在图形数据库中，每个记录都必须被检查在查询期间单独执行，以确定这些数据，虽然在关系数据库中是提前知道的。
关系数据库使用较少的存储空间，因为它们没有存储所有这些关系。

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

小开

Dan1111已经给出了一个标记为正确的答案。

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

理论上讲，人们可以一次洗牌所有的记录，并找出一种方法来定位和修复所有的指针。在实践中，这是一个操作，可能需要几个星期的大型图形数据库，在此期间，数据库将不得不关闭空气。这不可行。

By contrast, in a relational database, records can be reshuffled on a fairly large scale, and the only thing that has to be done is to rebuild any indexes that have been affected. This is a fairly large operation, but nowhere near as large as the equivalent for a graph database.

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

当一个网页被移动到一个不同的网址而没有留下一个转发地址在旧的网址，一个未知数量的超链接将被破坏。这些破碎的链接引起了可怕的，“错误404: 页面未找到”的信息，中断了这么多冲浪者的乐趣。

小开

图形和关系数据库的关键区别在于，关系数据库处理集合，而图形数据库处理路径。

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

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

那么，你为什么要在乎呢? 原因有二:

Graph databases are much faster than relational databases for connected data - a strength of the underlying model. A consequence of this is that query latency in a graph database is proportional to how much of the graph you choose to explore in a query, and is not proportional to the amount of data stored, thus defusing the 加入炸弹.
图形数据库使建模和查询更加愉快，意味着开发速度更快，卧槽更少。例如，用 Neo4j 的 Cypher 查询语言为一个典型的社交网络表示朋友的朋友只有 MATCH (me)-[:FRIEND]->()-[:FRIEND]->(foaf) RETURN foaf。

小开

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

我们在一个关系数据库中增加的搜索深度越多，我们需要执行的自连接就越多，我们的查询性能就会受到越大的影响。我们在层次结构中进行的越深入，需要联接的表就越多，查询的速度也就越慢。从数学上讲，成本在关系数据库中呈指数级增长。换句话说，我们的查询和关系越复杂，相对于关系数据库，我们从图表中获得的好处就越多。在导航图形时，我们在图形数据库中不存在性能问题。这是因为图形数据库将关系存储为单独的对象。然而，优越的读性能是以较慢的写速度为代价的。

In certain situations it is easier to change the data model in a graph database than it is in an RDBMS, e.g. in an RDBMS if I change a table relationship from 1:n to m:n I need to apply DDL with potential downtime.

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

我在用于数据仓库的图形数据库的博客文章中讨论了一些其他的利弊

小开

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

SQL 缺乏易于执行图遍历的语法，尤其是 traversals where the depth is unknown or unbounded. For instance, 使用 SQL 来确定朋友的朋友是非常容易的，但是 “分离度”问题很难解决。
当遍历图时，性能会迅速下降显著增加了查询响应时间。

参考资料: 下一代数据库

小开

图形数据库对于他们擅长的用例是值得研究的，但是我有一些理由对上面的响应中的一些断言提出质疑。特别是:

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

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

换句话说，我们的查询和关系越复杂，相对于关系数据库，我们从图表中获得的好处就越多。(Uli Bethke 第二段)

虽然这些断言可能很有价值，但我还没有找到让我的特定用例与它们保持一致的方法。参考文献: < a href = “ https://stackoverflow. com/questions/63112168/Graph-Database-or-relations-Database-Common-Table- 比較-acycles/63213234 # 63213234”> 圖形數據或关系数据库通用表插件:

小开

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

与关系数据库不同，图形数据库完全是围绕数据关系构建的。图形数据库不将关系视为模式结构，而是像其他值一样视为数据。从图形数据库中检索数据非常快。 From a relational database standpoint, you could think of this as pre-materializing JOINs once at insertion time instead of computing them for every query. Because the data is structured entirely around data relationships, real-time query performance can be achieved no matter how large or connected the dataset gets. 与关系数据库相比，图形数据库需要更多的存储空间。