图表数据库与三重商店 - 何时使用哪个？

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的一些自定义解决方案subject.
• 想象一下,使用SPARQL松散地收集了要查询未知关系的节点.图数据库支持这一点.但为此,他们必须建立另一个我认为会更慢的指数吗？

编辑:我看到"失去关于连接的信息"是错误的方式.如果您按照接受的答案中所示执行操作并为2个节点+ 1个关系插入多个三元组,那么您将保留所有信息,特别是信息确切的节点连接的信息.

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中,它是两个节点之间的一个关系,每个节点都有一个属性.在RDF中,您倾向于通过URI识别事物,在neo4j中,它是一个自动获取数据库ID的数据库对象.这就是我所说的更原子/原始商店(三重商店)和更丰富的属性图之间的区别.

RDF和三重存储主要是针对您在语义Web中遇到的各种架构挑战而构建的.例如,XML架构是基于架构假设而构建的,您将混合使用许多不同的词汇表和命名空间.(这就是一个非常"语义网"的假设).因此,在SPARQL和RDF你通常会看到至少使用xsd,rdf和rdfs命名空间的同时,也可能包括owl,skos和其他许多人.SPARQL和RDF/RDFS还有许多钩子和功能,这些钩子和功能明确地使得本体推理更容易.您倾向于使用URI标识事物作为"命名您的标识符"的方式,但也因为某些人可能想要取消引用URI ...这里的假设再次是多方之间的广泛数据共享安排.

相比之下,属性存储是针对不同用例的关键,例如一个模型/命名空间内的数据的灵活建模,对象和图形之间的映射,用于企业应用程序的持久性,快速可演化性等等.您倾向于使用自己的方案(或内部数据库ID)识别事物.对于Web上的任何随机使用者而言,自动递增整数可能不是ID的最佳形式(并且它们当然不能像URL那样被取消引用),但它们可能不是您对公司内部应用程序的第一个想法.

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

图形是图形,它们都是图形,所以我认为它们可以代表什么或者如何在"图形术语"中思考问题方面存在很大差异.差异归结为引擎盖下的架构,以及您认为您需要的各种用例.我不会告诉你一个比另一个好,但明智地选择.