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

我知道在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关系插入几个三元组，那么您将保留所有信息，特别是确切节点连接的信息。

图形数据库和三元组存储之间的主要区别在于它们对图形的建模方式。在三重存储（或四重存储）中，数据往往非常原子化。我的意思是，图中的“节点”往往是原始数据类型，如字符串、整数、日期等。关系将原始数据链接在一起，因此三元组存储中的“论述单元”是三元组，而不是节点或关系

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

假设我有一个叫“鲍勃”的人，他认识“苏珊”。在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".

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

RDF和triple Store主要是针对您在语义web中遇到的各种架构挑战而构建的。例如，XML名称空间是内置的，其架构假设是您将混合和匹配许多不同词汇表和名称空间的使用。（这是一个非常“语义网”的假设）。因此，在SPARQL和RDF中，您通常会看到至少同时使用

xsd

、

RDF

和

rdfs

名称空间，并且可能还会看到

owl

、

SKO

和许多其他名称空间。SPARQL和RDF/RDFS也有许多挂钩和特性，这些挂钩和特性可以显式地使本体推理之类的事情变得更容易。您将倾向于将URI作为“为标识符命名空间”的一种方式来标识事物，但也因为有些人可能希望取消对URI的引用……这里的假设是，许多方之间有广泛的数据共享安排

相比之下，属性存储主要针对不同的用例，如在一个模型/名称空间中灵活建模数据、对象和图形之间的映射以实现企业应用程序的持久性、快速演化性等。您将倾向于使用自己的方案（或内部数据库ID）来识别事物。对于web上的任何随机消费者来说，自动递增的整数可能不是最好的ID形式（它们当然不能像URL一样被取消引用），但对于公司内部应用程序来说，它们可能不是您首先想到的

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

图形是图形，它们都是图形，所以我认为它们在表示什么，或者如何用“图形术语”来思考问题方面没有太大区别。这些差异可以归结为引擎盖下面的架构，以及您认为需要什么样的用例。我不会告诉你一个比另一个好，但要明智地选择。

（在回答关于这个答案的评论时：）

定义owl:inverseOf产生式规则时，推理器在添加或更新存储时，或在从存储中选择时，都会推断反向属性三元组。这是一种“物化关系”

org——一个RDFS词汇表——例如，定义为hasPart的反向属性。如果两者都指定了，则无需运行另一个图形模式查询来遍历另一个方向上的有向关系。（：book1模式：hasPart？o），（？o模式：isPartOf:boo）

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