知识图谱与数据库技术：RDF三元组库和Neo4j图数据库

知识图谱与数据库系统

随着知识图谱规模的日益增长，知识图谱数据管理问题愈加突出。近年来，知识图谱和数据库领域均认识到大规模知识图谱数据管理任务的紧迫性。

由于传统关系数据库无法有效适应知识图谱的图数据模型，知识图谱领域形成了RDF数据的三元组库(Triple Store)，数据库领域开发了管理属性图的图数据库(Graph Database)。

知识图谱的主要数据模型有RDF图(RDFgraph) 和 属性图(Property Graph) 两种;知识图谱查询语言可分为 声明式(Declarative) 和 导航式(Navigational) 两类。

RDF三元组库

主要是由 Semantic Web 领域推动开发的数据库管理系统，其数据模型RDF 图和查询语言SPARQL均遵守W3C 标准。查询语言SPARQL 从语法上借鉴了 SQL语言，属于声明式查询语言。

最新的SPARQL 1.1版本为有效查询RDF三元组集合设计了

• 三元组模式(Triple Pattern)
• 基本图模式(Basic Graph Pattern)
• 属性路径(Property Path)

等多种查询机制。

图数据库

图数据库是数据库领域为更好地存储和管理图模型数据而开发的数据库管理系统。 其数据模型采用属性图，其上的声明式查询语言有:Cypher、PGQL和G-Core。

• Cypher 是开源图数据库 Neo4j 中实现的图查询语言。
• PGQL 是Oracle公司开发的图查询语言。
• G-Core是由**LDBC (Linked Data Benchmarks Council)**组织设计的图查询语言。

考虑到关系数据库采用统一的查询语言SQL，目前学术和工业界关于开发统一图数据库语言的呼声越来越高。

存储方案

目前，基于三元组库和图数据库能够提供的知识图谱数据存储方案可分为三类:

(1)基于关系的存储方案

基于关系的存储方案。包括三元组表、水平表、属性表、垂直划分、六重索引和 DB2RDF 等。

• 三元组表是将知识图谱中的每条三元组存储为一行具有三列的记录(主语，谓语，宾语)。三元组表存储方案虽然简单明了，但三元组表的行数与知识图谱的边数一样，其问题是将知识图谱查询翻译为SQL后会产生大量三元组表的自连接操作，影响效率。

• 水平表存储方案的每行记录存储知识图谱中一个主语的所有谓语和宾语，相当于知识图谱的邻接表。但其缺点在于所需列数目过多，表中产生大量空值，无法存储多值宾语等。

• 属性表存储方案将同一类主语分配到一个表中，是对水平表存储方案的细化。属性表解决了三元组表的自连接问题和水平表的列数目过多问题。但对于真实大规模知识图谱，属性表的问题包括:所需属性表过多，复杂查询的多表连接效率，空值问题和多值宾语问题。

• 垂直划分存储方案为知识图谱中的每种谓语建立一张两列的表(主语，宾语)，表中存放由该谓语连接的主语和宾语，支持“主语-主语”作为连接条件的查询操作的快速执行。垂直划分有效解决了空值问题和多值宾语问题;但其仍有缺点，包括:大规模知识图谱的谓语表数目过多、复杂查询表连接过多、更新维护代价大等

• 六重索引存储方案是将三元组全部6种排列对应地建立为6张表。六重索引通过“空间交换时间”策略有效缓解了三元组表的自连接问题，但需要更多的存储空间开销和索引更新维护代价。

• DB2RDF存储方案，是以往存储方案的一种权衡优化。三元组表的灵活性体现在“行维度”上，无论多少行三元组数据，表核式只有3列固定不变;DB2RDF了“列维度”，列名称不再和语绑定，将同一主语的所有谓语和宾语动态分配到某列。

(2)面向RDF的三元组。

主要的RDF三元组包括:

• 商业系统Virtuoso、
• AllegroGraph
• GraphDB
• BlazeGraph
• 开源系统Jena
• RDF-3X
• gStore

RDF4J目前是Eclipse基下的开源孵化项目，其功能包括RDF数据的解析、储、推理和查询等。RDF4J本身提供内存和磁盘两种RDF存储机制，支持全部的 SPARQL11 查询和更新语言，可以使用与访问本地RDF库相同的API访问远程RD库，支持所有主流的DF格式，包括DFXML、Turtle、N-Triples、N-Quads JSON-LD、TriG和TriXRDF4J框架的主要特点是其模块化的软件架构设计。

gStore 是由北京大学、加拿大滑铁卢大学和香港科技大学研究项目开发的基于图的RDF三元组数据库。gStore的底层存储使用RDF图对应的标签图(Signature Graph)并建立“VS树”索引结构以加速查找。gStore 系统提出建立“VS 树”索引，其基本思想实际上是为标签图G*建立不同详细程度的摘要图(SummaryGraph);利用“VS树”索引提供的摘要图，gStore 系统提出可以大幅削减 SPARQL 查询的搜索空间，以加快查询速度。

(3)原生图数据库Neo4j

Neo4j 是用 Java实现的开源图数据库。 可以说Neo4j是目前流行程度最高的图数据库产品。

Neo4j的不足之处在于其社区版是单机系统，虽然Neo4j企业版支持高可用性(High availability)集群，但其与分布式图存储系统的最大区别在于每个节点上存储图数据库的完整副本(类似于关系数据库镜像的副本集群)，而不是将图数据划分为子图进行分布式存储，而并非真正意义上的分布式数据库系统。如果图数据超过一定规模，系统性能就会因为磁盘、内存等限制而大幅降低。

JanusGraph 是在原有Titan系统基础上继续开发的开源分布式图数据库，目前是 Linux基金会旗下的一个开源项目。JanusGraph的存储后端与查询引擎是分离的，由于其可使用分布式Bigtable 存储库Cassandra或HBase 作为存储后端，因此 JanusGraph自然就成了分布式图数据库。JanusGraph分布式查询功能仅限于基于Cassandra或 HBase提供的分布式读写实现的简单导航查询，对于很多稍复杂的查询类型，目前还不了持真正意义上的分布式查询处理，例如子图匹配查询、正则路径查询等。

总结

总体来讲，基于关系的存储系统继承了关系数据库的优势，成熟度较高，在硬件性能和存储容量满足的前提下，通常能够适应千万到十亿三元组规模的管理。

官方测评显示，关系数据库Oracle 12c配上空间和图数据扩展组件(Spatial and Graph)可以管理的三元组数量高达1.08万亿条。

对于一般在百万到上亿三元组的管理，使用稍高配置的单机系统和主流RDF三元组数据库(如Jena、RDF4J、Virtuoso等)完全可以胜任。

如果需要管理几亿到十几亿以上大规模的RDF三元组，则可尝试部署具备分布式存储与查询能力的数据库系统(如商业版的GraphDB 和BlazeGraph、开源的JanusGraph等)。

近年来，以 Neo4j 为代表的图数据库系统发展迅猛，使用图数据库管理 RDF三元组也是一种很好的选择;但目前大部分图数据库还不能直接支持RDF三元组存储，对于这种情况，可采用数据转换方式，先将RDF 预处理为图数据库支持的数据格式(如属性图模型)，再进行后续管理操作。

目前，还没有一种数据库系统被公认为是具有主导地位的知识图谱数据库。但可以预见，随着三元组库和图数据库的相互融合发展，知识图谱的存储和数据管理手段将愈加丰富和强大。

参考资料： 知识图谱：方法、实践与应用：王昊奋 漆桂林等主编