图形数据库与三元存储数据库 - 何时使用哪种？

Question

我知道在Stackoverflow上有类似的问题，但我觉得它们并没有回答以下问题。

据我了解，图形数据库主要按照这个模式存储数据:

Table/Collection 1: store nodes with UID
Table/Collection 2: store relations referencing nodes via UID

这允许存储任意类型的图形。现在我理解三元存储只存储三元组：

Triple/Collection 1: store triples (2 nodes, 1 relation)

现在我将就用例阐述以下区别：

• 图数据库：当您拥有已知的静态连接时
• 三元组存储：当您拥有松散连接的节点并经常寻找新连接时

我迷惑的是，人们似乎没有根据这些标准来讨论使用哪种数据库。我找到的大多数文章都在谈论速度或兼容性等问题。但这不是最重要的吗?

反过来想:

• 想象一下，你有一个明确定义的相互连接的图形。为什么你会想把它只存储为三元组，失去所有关于连接信息的数据呢？或者需要实现某些自定义解决方案，在三元组“主语”中存储ID。
• 假设您有一些松散收集的节点，您希望使用SPARQL查询未知关系。图形数据库支持此操作。但是为此，它们必须建立另一个索引，我认为会更慢？

编辑： 我发现“失去关于连接信息的数据”是错误的表述。如果您按照接受的答案所示，为2个节点+1个关系插入多个三元组，则可以保留所有信息，特别是确切的节点连接信息。

- B M

---

三元存储只存储三元组，许多（甚至大部分）三元存储（即RDF）实际上是四元存储，因为它们具有命名图的概念（来自SPARQL数据集）。由于每个三元组都存在于一个图中，因此基本项实际上是（图、主语、谓语、宾语）。 - Joshua Taylor

三元组/集合1：存储三元组（2个节点，1个关系）。但顺序很重要。这不是一个无向边，实际上应该是（源，关系，目标），或者更常见的是（主语，谓词（或属性），宾语）。 - Joshua Taylor

你到底为什么要只将它存储为三元组，失去了所有关于连接的信息呢？我不确定你的意思。属性由URI / IRI标识，这与UID一样通用，只是它可能更容易记住，可以被引用（以便您可以获取有关它的更多信息等），主语和客体通常是URI或数据文字。哪些关于连接的信息会丢失呢？ - Joshua Taylor

OP，你的标准“静态连接 vs. 松散连接节点”在我看来不是一个好的问题划分方式。我认为任何一种技术都可以支持这两种连接方式。就像@JoshuaTaylor所说，我认为使用SPARQL/RDF并不会丢失任何关于连接的信息，这只是一个关于你选择建模/捕获的问题。 - FrobberOfBits

我看到 "丢失有关连接的信息" 是错误的表述方式。如果按照被接受的答案所示，插入2个节点和1个关系的多个三元组，则可以保留所有信息，特别是确切节点连接的信息。感谢所有评论！ - B M

Neo4j是为LPG设计的，而triplestore则是为RDF设计的。LPG与RDF的区别（有点偏见，请参见Reification as a red herring）。存在“调和”项目，如Blazegraph的RDF*。在RDF图中，“边的类型”（即具有相同URI的谓词）可以拥有自己的“属性”甚至“链接”。这使它们成为一流对象，可以被引用、记录等。从这个“语义”角度来看，LPG看起来像是“期间：両”的形式。 - Stanislav Kralin

Answer 1

图形数据库和三元组存储的主要区别在于它们如何对图进行建模。在三元组存储（或四元组存储）中，数据往往非常原子化。我的意思是图中的“节点”往往是基本数据类型，例如字符串、整数、日期等。关系将原语链接在一起，因此三元组通常是一个“话题单元”，而不是节点或关系。

相比之下，其他图形数据库通常被称为“属性存储”，因为节点是与域中的对象对应的数据容器。一个节点代表一个对象，并具有属性；它们是由图形建模者指定的丰富数据类型，而不仅仅是基本数据类型。在这些图形数据库中，节点和关系是“话题单元”。

假设我有一个名为“Bob”的人，他认识“Susan”。在RDF中，它可能是这样的：

<http://example.org/person/1> :hasName "Bob".
<http://example.org/person/1> foaf:knows <http://example.org/person/2>.
<http://example.org/person/2> :hasName "Susan".

在像neo4j这样的图形数据库中，它会是这样的：

(a:Person {name: "Bob"})-[:KNOWS]->(b:Person {name: "Susan"})

请注意，在RDF中，有3个关系，但只有其中一个关系实际上表达了两个实体之间的语义。另外两个关系仅跟踪高级实体（人）的属性。在neo4j中，是两个节点之间的1个关系，每个节点都有一个属性。在RDF中，你通常会通过URI来识别事物，在neo4j中，它是一个自动获取数据库ID的数据库对象。这就是我所说的更原子/原始存储（三元存储器）和更丰富的属性图之间的区别。

RDF和三元存储器大多针对语义网可能遇到的架构挑战而建立。例如，XML命名空间是内置的，并基于架构假设，即您将混合和匹配使用许多不同的词汇和命名空间。因此，在SPARQL和RDF中，您通常会同时看到xsd，rdf和rdfs命名空间的使用，可能还包括owl，skos和许多其他命名空间。 SPARQL和RDF / RDFS还具有许多钩子和功能，专门用于使本体推理等任务更加容易。您通常会使用URI标识事物作为“名称空间标识符”的一种方式，但还因为有些人可能想解除URI的引用……再次强调这里的假设是许多方之间存在广泛的数据共享安排。

相比之下，属性存储针对不同的用例进行了优化，例如灵活建模一个命名空间内的数据、对象和图形之间的映射，以实现企业应用程序的持久性，快速的可扩展性等。您通常会使用自己的方案（或内部数据库ID）来标识事物。递增的整数可能不是任何随机网站用户的最佳ID形式（它们当然不能像URL那样被解引用），但它们可能不是公司内部应用程序的首选。

那么哪个更好？更原子的三元存储格式还是更丰富的属性图？您需要在一个查询或数据模型中混合和匹配许多不同的词汇吗？您需要创建OWL本体还是进行推理？您需要将一堆Java对象序列化到数据库中吗？您需要快速遍历长路径吗？这些类型的问题将指导您的选择。

图形就是图形，它们都可以表示图形，因此我认为在“图形术语”中思考问题的方法没有太大区别。区别归结于引擎下面的架构，以及您认为需要哪些用例。我不会告诉您哪个更好，但要明智地选择。

- FrobberOfBits

---

你提到了关于语义网的很多内容，这很好。不过在RDF和neo4j（可能包括其他非RDF图形）之间有一个根本性的区别，就是在RDF中你有定向图形。而neo4j则允许你设计定向和无向图形。此外，neo4j内置了权重的概念（包括复杂权重）。这是在RDF中需要笨拙的解决方法的事情。 - Tomasz Pluskiewicz

neo4j并没有内置权重，但你可以选择将其建模。RDF也是同样的情况。Neo4j还拥有排他性的有向边（没有无向边），虽然你可以选择按照无向边的方式遍历它们。RDF也是同样的情况。 - FrobberOfBits

@FrobberOfBits 那Direction枚举呢？在RDF中，您需要显式地创建两个三元组。这与双向遍历不同，当然您也可以进行双向遍历。 - Tomasz Pluskiewicz

@FrobberOfBits 关于权重，我称之错误了。我指的是neo4j中的关系属性。RDF没有这种内置概念。当然，你可以使用空白节点或任何类型的再现建模，但这仍然不完全等同。 - Tomasz Pluskiewicz

有没有适用于Neo4j的推理引擎？我搜索了一下，但没有找到。如果实际上不存在，那么是否存在技术原因呢？ - Günter Zöchbauer

Answer 2

（回复这个答案的评论：https://dev59.com/Z10a5IYBdhLWcg3wk5hw#30167732）

当定义一个 owl:inverseOf 生产规则时，推理器将在添加或更新存储时推断出逆属性三元组，或者在从存储中选择时推断出它。这是一种“物化关系”。

例如，Schema.org 是一个 RDFS 词汇表，定义了 https://schema.org/isPartOf 作为 hasPart 的逆属性。如果两者都已指定，则不需要运行另一个图形模式查询来遍历另一个方向的有向关系。

(:book1 schema:hasPart ?o)

(?o schema:isPartOf :book1)

(?s schema:hasPart :chapter2)

可以使用RDFS和OWL来描述neo4j属性图中的模式，但是没有推理器可以推断逆属性或进行模式验证。

是否存在无法存储在neo4j中的RDF图形？ RDF具有对象的数据类型和语言：您需要重新定义指定了数据类型和/或语言的属性（并且您将重新实现明确定义的语义）

每个neo4j图形都可以用RDF表示吗？ 是的。

RDF是一种图形表示方法，有很多存储实现针对各种用例进行了优化，例如插入和查询性能。

与支持推理的特定三元组存储（Triplestore）进行比较可能会更有用，因为所有neo4j图形都可以表示为RDF。

- Wes Turner