sql - 图数据库与关系数据库中表示的图有何不同？

Question

我可以在具有两个表的关系数据库中简单地表示一个图形:vertex和 edge .更丰富的结构，如“属性”和“标签”(在 Neo4j 术语中)可以表示为更多的表。我是否误解了，或者像 Neo4j 这样的图形数据库是否允许我表示任何不容易通过关系表示的东西？

我可以使用 SQL 查询此图，必要时使用递归子查询，并在必要时使用事务中的多个单独查询。我是否误解了，或者像 Cypher 这样的图形查询语言是否提供了比 SQL 更好的表达能力？

图的关系模型被有效地存储和查询，AFAIK。图数据库是否以某种方式构建其存储或优化其查询，以提供无法从关系数据库中获得的性能特征？

我的关系数据库提供 ACID 保证，并允许我在我的图形数据上编写相当有表现力的约束(如果我将单个 vertex 表分解为正确规范化的模式，甚至更多约束)。我是否误解了，或者图形数据库是否提供了一些保证或验证了我的关系数据库中不可用的某种正确性属性？

我正在努力了解诸如 Neo4j 之类的图形数据库如何不是关系模型的子集。 (抱歉在这里使用 Neo4j 作为所有图形数据库的代表；这是我唯一看过的。)

简而言之:图数据库⊆是关系数据库吗？

Answer 1

一个是另一个的子集吗？

绝对没有；两者最终都以关系或图形的数学概念为模型。两种模型都是 super 通用的，基本上没有您不能使用任何一种来表示的信息内容。这意味着虽然它们在许多语法糖方面可能有所不同，并且在它们鼓励您建模/思考数据的方式上(就像编程语言不同一样)，但它们都具有相同的“表达能力”。

您在问题中描述的是一种对图形( vertex 和 edge 表)进行建模的方法。图的实现是关系可以表达的一个子集。类似地，我可以使用图形数据库模拟表和行，但我会选择一个特定的实现 - 这不会证明关系数据是图形数据的子集。

因此，第一个见解是它们具有大致相同的表达能力。你可以在任何一个中建模任何东西。所以你应该问的真正问题是为什么你会选择一个而不是另一个？

为什么你会选择一个？

所有数据库的存在都是为了方便数据访问。简单地说，您存储它以便您可以获取数据。但是，您究竟需要如何获取数据？有许多不同的访问模式。一般数据库的设计空间是巨大的 .每当数据库做出某个决定时，它往往会自动使其在某些方面变得更好，而在其他方面变得更糟。例如，当您在关系数据库中创建索引时，您只是加快了读取速度——但降低了写入性能，因为必须维护索引。

因此，在接近问题时，“图形还是关系？” - 您应该首先弄清楚您的数据是什么样的，以及您的数据访问模式是什么样的。如果您知道这些东西是什么，那么您可以评估一堆数据库，查看它们所做的选择，然后选择最适合您需要的数据库。然后，如果 DBMS 做出的选择会使某些访问模式变得困难、错误或缓慢——您可以避免该 DBMS 用于该数据集。

它(部分)关于数据访问模式

当存储的数据是图形时，当数据访问模式涉及大量图形遍历时，图形数据库往往比关系数据库更好，或两者兼而有之。 ( See this other answer I wrote 更深入地讨论为什么会这样)。该链接还提供了您的特定问题的答案:“图形数据库是否以某种方式构建其存储结构或优化其查询，以提供无法从关系数据库中获得的性能特征？”

你说:我可以使用 SQL 查询这个图，必要时使用递归子查询，必要时在一个事务中使用多个单独的查询。 -- 所以从技术上讲这是真的，但让我们举个例子来看看为什么关系可能不够好。假设我有一个图(在 RDBMS 中，一个节点表，一个边表，它们之间有一个连接键)。假设我选择了一个节点，我想识别离该节点 6 到 8 跳之间的所有内容。这是执行此操作的密码:

match (myChosenNode {id: 'foo'})-[r:relationshipType*6..8]->(y) return y;

我真的很想看到你把它写成 SQL。这是可能的，但它既困难又复杂。它也会像狗一样执行，因为您将在非平凡的数据量上进行大量的加入。

酸

现在确定 ACID 保证， Neo4J provides transactions with ACID guarantees .但是，对于不同的图形数据库，答案会有所不同，尤其是在 Hadoop/HBase 之上实现的图形数据库。 YMMV 那里，所以检查每个数据库的细则。

确实，RDBMS 有许多通常在图形数据库中找不到的功能，例如触发器和某些类型的约束。作为一个长期的 RDMBS Nerd ，我对丢失这些东西并不感到高兴，我认为它们很有值(value)。

概括

对我和与我一起工作的许多其他工程师来说，这主要归结为:

你的数据是什么？

你的访问模式是什么？

如果您的数据是图形，或者您的访问模式涉及大量图形遍历，则您可能应该使用图形数据库。如果您的数据更加表格化，或者您的访问模式更侧重于批量扫描，那么您应该使用 RDBMS。归根结底，它们是两种不同的工具，具有不同的利基。如果你在他们擅长的领域使用他们，你会很高兴。如果你使用 RDBMS 来建模一个图形只是“因为你可以”，你会受苦。如果您使用图形数据库对每个图形中的每个节点进行大量批量扫描，您将受苦。像大多数技术一样，这只是使用正确的工具来完成工作。