知识图谱从入门到应用——知识图谱的存储与查询：基于原生图数据库的知识图谱存储

分类目录：《知识图谱从入门到应用》总目录
相关文章：
· 知识图谱的存储与查询：基于关系数据库的知识图谱存储
· 知识图谱的存储与查询：基于原生图数据库的知识图谱存储

---

关系数据库的局限性

尽管基于关系数据库的存储方式有很多优势，但是随着原生图数据库的技术及工具的逐步完善，原生图数据库已经成为知识图谱存储和查询引擎搭建的标准基础设施。在本文首先回答一个问题：为什么需要图数据库。关系数据库虽然被取名为“关系”，但却不善于处理“关系”。首先，关系模型将语义关联关系隐藏在外键结构中，无显示表达，并带来关联查询与计算的复杂性。其次，数据来源多样性带来大量离群数据（Outlier Data），导致数据集的宏观结构愈发复杂和不规整，对于包含大量离群数据的场景，关系模型将造成大量表连接、稀疏行和空值处理。最后，互联网的开放世界假设要求数据模型满足高动态和去中心化的扩增数据的能力，关系模型对表结构的范式要求限制了Schema层的动态性。因此，从根本上而言，关系模型背离了用接近自然语言的方式来描述客观世界的原则，这使得概念化、高度关联的世界模型与数据的物理存储之间出现了失配。

关系模型有很多局限，例如给定两个关系表，查询：“Who are Bob’s friends?”，这很容易通过写一个JOIN查询来实现。但如果将查询做一个非常简单的改变，即改为查询：“Who is friends with Bob？”Friends关系具有对称特性，即：$A$是$B$朋友，$B$也是$A$的朋友，这在RDF图模型中，只需声明friends具有这种对称特性就可以了。但对于关系数据库，受限于建表索引的范式约束，查询$A$的朋友是谁很高效，但反过来查询谁与$A$是朋友就必须遍历整个PersonFriend表，并逐一比对，这显然是不需要的。更为困难的问题是处理多跳查询，这在图查询中是非常常见的。例如要查询$A$的朋友的朋友的朋友是谁，这将带来大量的JOIN计算，且计算的复杂度随着跳数的增加呈指数级增长。更多类似的例子如给定客户信息和客户交易表，要求找出两个银行账户交易记录的最短路径，或者给定社交账户表，要求找出两个社交账户消息发送的最短路径等。这是Neo4J图数据库的评测比较结果之一：给定100万个用户账户，每个账户有大约50个朋友，要求查询5跳范围内的朋友关系。可以发现传统关系数据库在处理多跳查询时，到5跳时已经无法得出结果，但对于图数据库仍然可以在秒级范围内得出结果。

更为重要的是，知识图谱需要刻画更加丰富的关系语义表达与关联推理能力。在需要更加深入的研究数据之间的关系时，需要更加丰富的关系语义的表达能力，除了前述自反关系（Reflexive）和多跳关系，还包括传递关系（Transitive）、对称关系（Symmetric）、反关系（Inverse）和函数关系（Functional）等。除了关联查询能力，深层次的关系建模还将提供关联推理的能力，属性图数据库如Neo4J提供了由于关系模型的关联查询能力，而AllegroGraph等RDF图数据库则提供了更多的关联推理能力。关系在NoSQL数据库中也不是第一类公民（First-Class Citizen），在处理数据关联也需要使用类似于外键的Foreign Aggregates。Foreign Aggregates也不能处理自反关系，例如，查询“who is friends with Bob?”时，需要暴力计算，即扫描所有实体数据集。Foreign Aggregates也不负责维护Link的有效性，在处理多跳关系时效率也是低下的。

原生图数据库的优点

在图数据库中，有一个重要的不同于关系数据库的原则，即：Relations are first-class citizens。这是什么意思呢？在关系数据库中，属性都是从属于某个表的，而实体关系又被隐藏在外键定义中。但在图模型中，关系是显示描述和定义的，如下图所示。此外，属性都可以单独定义，不需要一定属于哪个类，也就是说在图数据库中，属性、关系和实体类型的地位是平等的，这将极大地增强数据建模的灵活性。

同时，图数据库可以充分利用图的结构特征建立索引，在下文中的原生图数据库实现原理会进一步展开介绍。这里的基本思想就是将一张图表示为一个邻接列表，即将相邻关系表示成邻接关系表，再基于这个邻接关系表建立索引，优化图上的查询。

因此，图数据库建模带来很多好处。首先是自然表达：图是十分自然的描述事物关系的方式，更加接近于人脑对客观事物的记忆方式。其次是易于扩展：图模型更加易于适应变化，例如在图中，临时希望获取历史订单，只需新增边即可。再次是复杂关联表达：图模型易于表达复杂关联逻辑的查询，例如：“查询生活在南方城市、年龄在20岁上下的人所喜欢的小吃的做法”等。最后是多跳优化：在处理多跳查询上，图模型有明显的性能优势。

原生图数据库使用举例

属性图是图数据库Neo4J实现的图结构表示模型，在工业界有广泛应用。在属性图的术语中，属性图是由顶点（Vertex）、边（Edge）、标签（Label）、关系类型和属性（Property）组成的有向图。属性图的优点是表达方式非常灵活，例如，它允许为边增加属性，非常便于表示多元关系。属性图的存储充分利用图的结构进行优化，因而在查询计算方面具有较高优势。

Nero4J定义了自己的图查询语言Cypher。Cypher和W3C定义的SPARQL，以及Apache ThinkerPop定义的Gremlin语言是目前知识图谱领域最主流的图查询语言。其中，SPARQL是描述性的查询语言，而Cypher和Gremlin是过程式查询语言，如下图所示。过程式的查询语言需要严格地根据图的结构精确定义查询语义，因此查询解析及查询处理的效率也非常高。描述性查询语言重在刻画查询本身的语义，通常还需要再经过一轮翻译，成为底层实际查询语言如SQL，其优势是更接近于人的自然语言并易于人理解和定义。详细的介绍这些语言的语法及使用不是本书的重点，感兴趣的读者可以查阅相关技术手册。这里仅给出一些示例用于介绍图数据库查询的特点和优势。

知识图谱的一个好处是可以将多源多领域的数据相互关联，实现跨领域的建模与查询。例如下图所示例子中，包含文学领域、歌剧院和地理信息三个领域的数据。可以利用图谱将这三个领域的数据进行关联，同时图数据模型允许按需要进一步扩展相关领域，而不影响已有的数据结构，此外，查询语句能表示跨多个领域的关联逻辑。

举一个跨领域逻辑查询的例子，例如需要查询在Newcastle的皇家剧院上演的莎士比亚的歌剧，这需要跨文学、歌剧院和地理信息三个领域的数据。这里用一个Cypher查询来描述这种查询。在一个Cypher查询中，查询通常从一个起始节点开始，例如“Theatre Royal”，然后通过多个图连接关系逐步扩展到图中的其他节点。可以像SQL语句那样为查询的遍历过程增加条件约束，并对结果进行排序。此外，还可以通过定义一些图的模式（Graph Pattern）来对图进行更细微的分析，例如，可以定义一个查询分析潜在的恶意账户：那些经常发送给自己的别名地址的账户更有可能是恶意账户。

使用原生图数据库的场景

是否使用原生图数据库主要的判断基于三个原则：

• 高性能的关系查询，即如果应用场景涉及很多复杂的关联查询，图数据库有显著的性能优势，大部分知识图谱应用都涉及这类复杂关联查询
• 模型的灵活性，在无法预先定义明确的数据模型（即Schema），或需要融合跨多个领域的多来源数据时，图数据库具有很好地适应变化的优势
• 复杂图分析需求，例如涉及子图匹配、图结构学习、基于图的推荐计算等，图数据库通常会外接图算法计算引擎，因而会有较大的优势，这一点会在后面的文章中进一步展开介绍。

原生图数据库的实现原理

免索引邻接

原生图数据库的实现原理并不复杂，其中的一个核心概念是免索引邻接，即：Index-free adjacency。其基本想法是为每一个节点维护了一组指向其相邻节点的引用，这组引用本质上可以看作是相邻节点的微索引（Micro Index）。这种微索引比起全局索引在处理图遍历查询时非常廉价，其查询复杂度与数据集整体大小无关，仅正比于相邻子图的大小。这里首先简单了解一下几种在关系数据库中实现的常见Table JOIN的计算复杂度。例如Nested JOIN复杂度是$O(M\times N)$，Hash JOIN是$O(M+N)$，而Merge JOIN的复杂度是$O(N\times \log N+M\times \log M)$，可以看到这几种JOIN的计算复杂度都与表或数据集的大小$M$和$N$有关。而对于Index-free adjacency，关系是直接基于某个节点的相邻节点获取的（tail to head, or head to tail）。例如，为了查询“who is friends with Alice”，只需要检索Alice的所有入度FRIEND关系即可。这个复杂度仅与节点的邻居个数有关，而与整个数据集的大小是无关的。

原生图数据库的物理存储设计

这里还是以Neo4j背后的实现为例来介绍，Neo4j最核心的实现是两个文件——节点存储文件和关系边存储文件，它通过设计这两个文件的物理结构，对图查询进行了全方位的优化。

节点和关系边的存储处理

知识图谱中的节点存储于独立的“节点存储文件”。首先，每个节点的存储空间固定，如14字节，这样便于直接通过ID编号计算获得访问地址，基于这种格式，节点查询成本为$O(1)$，而非$O(N)$。每个节点首字节标明是否inUse，接下来四个字节存储该节点的第一个关系边的ID，再接下来四个字节存储该节点的第一个属性边ID，再接下来4个字节存储该节点的第一个Label ID，这些ID都类似于指针，便于从该节点出发快速的检索与该节点有关的关系边、属性边和Label等。需要特别指出的是，节点的属性数据（如姓名、年龄等）是分开存储的，节点只存储其第一个属性边的ID，这样的设计是为了保证节点遍历的高效性。

知识图谱中的所有关系或边存储于独立的“关系边存储文件”。和节点存储类似，每个关系边的存储空间固定，如34字节，这种设计便于直接通过ID编号计算获得关系边的访问地址。每个节点首字节标明是否inUse，接下来四个字节存储该关系边的头节点ID，再接下来四个字节存储该关系边的尾节点ID，再接下来4个字节存储关系边类型ID，再下面存储头节点和尾节点的上一个关系边ID，以及头尾节点的下一个关系边ID。和节点存储的设计一样，这样做是为了非常快速地检索与该关系边相关的头尾节点、关系边类型、与头尾节点相连的前一条关系边和下一条关系边。

图遍历查询的物理实现

基于前面的节点存储文件和关系边存储文件，可以非常方便地对图进行遍历。如下图所示，给出了一个图谱的实际物理存储的结构设计，可以看到这种设计从各个方面都做了优化。例如可以快速地从一个节点出发找到它的第一条关系边，再从该关系边找到相邻的另外一个节点，或者进一步找第二条、第三条、第$N$条关系边。也可以从一条关系边出发，快速地找到它的头尾节点，以及遍历头尾节点的前一条或后一条关系边。也可以分别从节点和关系边出发快速地查询它们的第一条属性边，进而获得第二条、第三条、第$N$条属性边，同时也能快速地检索它们的节点类型或关系边类型等。这种全方位的优化使得从各个角度对图进行遍历都非常高效和便捷。

属性数据的物理存储处理

图数据库中存在大量属性，这些属性的检索与图遍历的计算是分开的，这是为了让节点之间的图遍历能不受大量属性数据的影响。节点和关系边的存储记录都包含指向它们的第一个属性ID的指针，属性记录也是固定大小，便于之间通过ID计算获得存储位置。每个属性记录包含多个属性块，以及属性链中下一个属性的ID。每个属性记录包含属性类型以及属性索引文件，属性索引文件存储属性名称。对于每一个属性值，记录包含一个指向动态存储记录的指针（大属性值）或内联值（小属性值）。

属性图与RDF图存储的比较

属性图实际上是Neo4j所引导的一种数据模型，尚未形成工业标准，但因为推出时性能比较好，因而得到工业界的大量实践。RDF图模型确切地说不是一个数据存储模型，而是一种数据交换的格式标准，它由国际万维网联盟W3C倡导和推动，因为来源于人工智能领域有关知识表示方向的研究，因而具有较好的理论基础。一般而言，如果应用场景重图结构和查询分析，属性图会更合适一些；如果应用场景重知识建模，特别是要求描述和表示复杂的关联关系且有知识推理要求，采用RDF图模型会更适合一些。这里也比较分析一下几种常见的知识图谱查询语言，其中SPARQL是W3C推动的工业级标准查询语言，因为与RDF对应，也具有较好的理论模型基础，同时对于更复杂知识表示的查询支持度比较好。而其他几种查询语言，如Cypher、Gremlin等主要是针对图的结构设计的语言，一般对于比较强调图结构的应用更加适合。

知识图谱存储方式的选择需要综合考虑性能、动态扩展、实施成本等多方面因素。首先需要区分原生图存储和非原生图存储：**原生图存储在复杂关联查询和图计算方面有性能优势，非原生图存储兼容已有工具集，通常学习和协调成本会低。**其次，需要区分RDF图存储和属性图存储：**RDF存储一般支持推理，属性图存储通常具有更好的图分析性能优势。**此外，在大规模处理情况下，需要考虑与底层大数据存储引擎和上层图计算引擎集成需求。图模型是更加接近于人脑认知和自然语言的数据模型，图数据库是处理复杂的、半结构化、多维度的、紧密关联数据的最好技术。我们鼓励在知识图谱项目中采用和实践图数据库。图数据库也有它的弱点，假如应用场景不包含大量的关联查询，对于简单查询，传统关系模型和NoSQL数据库目前在性能方面更有优势。RDF作为一种知识图谱表示框架的参考标准，向上对接OWL等更丰富的语义表示和推理能力，向下对接简化后的属性图模型以及图计算引擎，是最值得重视的知识图谱表示框架。

参考文献：
[1] 陈华钧.知识图谱导论[M].电子工业出版社, 2021
[2] 邵浩, 张凯, 李方圆, 张云柯, 戴锡强. 从零构建知识图谱[M].机械工业出版社, 2021