知识图谱的存储

基于关系型数据库的知识图谱存储

    知识图谱的存储需要综合考虑知识结构、图的特点、索引和查询优化等问题。典型的知识图谱存储引擎分为基于关系数据库的存储和基于原生图的存储。图数据库存储并非必须，例如Wikidata项目后端是MySQL实现的。

属性图和RDF图模型都是有向标记图: Directed Labeled Graph

    图上的查询语言：SPARQL。属性表存储也称为垂直仍然基于传统关系数据库实现，典型的如Jena [Wilkinson et al., 2003] ,FlexTable [Wang et al., 2010] , DB2-RDF [Bornea et al., 2013]等实现，基本思想是以实体类型为中心，把属于同一个实体类型的属性组织为一个表，即属性表进行存储。优点：Join减少了，本质上接近于关系数据库，可重用RDBMS功能。缺点：很多空值，对Subject聚类比较复杂、不易处理多值属性。

    二元表也称为垂直划分表，也是基于关系数据库实现的三元组存储方式。基本思想是对三元组按属性分组，为每个属性在关系数据库中建立一个包含（subject、Object）两列的表。由于一个知识图谱中属性数量是有限的，表的总体数量是可控的。优点是没有空值、也不需要聚类、对于Subject-Subject-Join操作性能好。缺点是Insert性能损耗高、并且Subject-Object Join性能差。

    性能最好的存储方式是基于全索引结构的存储，典型的实现包括RDF-3X, Hexastore等。这种方法也仅维护一张包含(Subject, Predicate, Object）的三列表，但增加了多个方面的优化手段。第一个优化手段是建立Mapping Table，即将所有的字符串首先映射到唯一的数字ID，这一将大大压缩存储空间。

    进一步建立六种索引： SPO, SOP, PSO, POS, OPS, OSP，即分别建立SubjectPredicate-Object; Subject-Object-Predicate；Predicate-Subject-Object等六个方面的全索引，显然多种形式的索引覆盖了多个维度的图查询需求。同时三元组基于字符串排序，并利用clustered B+ tree树来组织索引以进一步优化索引检索的效率。

Exhaustive Indexing查询举例：

各种存储方案的优缺点比较：

基于原生图数据库的知识图谱存储

    关系模型将语义关联关系隐藏在外键结构中，无显示表达，并带来关联查询与计算的复杂性。数据来源多样性带来大量离群数据（Outlier Data），导致数据集的宏观结构愈发复杂和不规整，对于包含大量离群数据的场景，关系模型将造成大量表连接、稀疏行和非空处理。互联网的开放世界假设要求数据模型满足高动态和去中心化的扩增数据的能力，关系模型对表结构的范式要求限制了Schema层的动态性。关系模型背离了用接近自然语言的方式来描述客观世界的原则，这使得概念化、高度关联的世界模型与数据的物理存储之间出现了失配。

Asking “who are Bob’s friends?” is easy：

    处理Reflexive relationship的自反查询带来底层数据库的更多计算，从图的角度，只需声明friend关系是自反关系即可支持反向查询。处理Chain relationship 的多跳查询带来更加复杂的Join计算。有些数据库如Oracle提供了Syntax Suger如“Connect By”，但没有降低底层的计算复杂度。

    关系数据库的局限性：知识图谱需要更加丰富的关系语义表达与关联推理能力。在需要更加深入的研究数据之间的关系时，需要更加丰富的关系语义的表达能力，除了前述Reflesive和多跳关系、还包括传递关系Transitive、对称关系（非对称关系）Symmetric、反关系（Inverse）、函数关系（Functional）。除了关联查询能力，深层次的关系建模还将提供关联推理的能力，属性图数据库如Neo4J提供了由于关系模型的关联查询能力，AllegroGraph等RDF图数据库提供了更多的关联推理能力。

    关系在NoSQL数据库中也不是First-Class Citizen，在处理数据关联也需要使用类似于外键的Foreign Aggregates。Foreign Aggregates不能处理自反关系，例如，查询“who is friends with Bob?”时，需要暴力计算，即扫描所有实体数据集。Foreign Aggregates也不负责维护Link的有效性，在处理多跳关系时效率也很低下。

原生图数据库：利用图的结构特征建索引：

    自然表达：图是十分自然的描述事物关系的方式，更加接近于人脑对客观事物的记忆方式。易于扩展：图模型更加易于适应变化，例如在图中，临时希望获取历史订单，只需新增边即可。复杂关联表达：图模型易于表达复杂关联逻辑的查询，例如在推荐系统中，希望表达复杂的推荐逻辑，例如：“all the flavors of ice cream liked by people who enjoy espresso but dislike Brussels sprouts, and who live in a particular neighborhood.”多跳优化：在处理多跳查询上，图模型有性能优势。

    属性图是图数据库Neo4J实现的图结构表示模型，在工业界有广泛应用。在属性图的术语中，属性图是由 顶点（Vertex），边（Edge），标签（Label），关系类型还有属性（Property）组成的有向图。在属性图中，节点和关系是最重要的实体。节点上包含属性，属性可以以任何键值形式存在。

图查询语言: Cypher。利用图谱将不同领域的数据进行关联，要求模型能按需扩展，查询语句能表示跨多个领域的关联逻辑。

常见的图数据库列表：

    高性能关系查询：需要快速遍历许多复杂关系的任何用例。这实际上包括欺诈检测，社交网络分析，网络和数据库基础设施等。模型的灵活性：任何依赖于添加新数据而不会中断现有查询池的用例。模型灵活性包括链接元数据，版本控制数据和不断添加新关系。快速和复杂的分析规则：当必须执行许多复杂的规则时，例如子图的比较。这包括推荐，相似度计算和主数据管理。

原生图数据库实现原理浅析

    原生图是指采用免索引邻接（Index-free adjacency）构建的图数据库引擎，如：AllegroGraph, Neo4j等。采用免索引邻接的数据库为每一个节点维护了一组指向其相邻节点的引用，这组引用本质上可以看做是相邻节点的微索引（Micro Index）。这种微索引比起全局索引在处理图遍历查询时非常廉价，其查询复杂度与数据集整体大小无关，仅正比于相邻子图的大小。

    而对于 Index-free adjacency，关系是直接基于某个节点的相邻节点获取的(tail to head, or head to tail)；例如，为了查询“who is friends with Alice”, 我们只需要检索Alice的所有incoming FRIEND 关系即可；这个复杂度仅与节点的邻居个数有关，而与整个数据集的大小是无关的。

    节点存储于独立的“节点存储文件”，每个节点的存储空间固定，如14字节，便于直接通过ID编号计算获得访问地址，基于这种格式，节点查询成本为O(1)，而非O(N)。每个节点首字节标明是否inUse，接下来四个字节存储该节点的第一个关系边的ID，再接下来四个字节存储该节点的第一个属性ID，再接下来4个字节存储该节点的第一个Label ID。节点的属性数据（如姓名、年龄等）是分开存储的，节点只存储其第一个属性的ID，这样的设计是为了保证节点遍历的高效性。

    关系边存储于独立的“关系存储文件”，每个关系边的存储空间固定，如34字节，和节点一样，这种设计便于直接通过ID编号计算获得关系边的访问地址。每个节点首字节标明是否inUse，接下来四个字节存储该关系边的头节点ID，再接下来四个字节存储该关系边的尾节点ID，再接下来4个字节存储关系边类型ID，再下面存储头节点和尾节点的上一个关系边ID，以及头尾节点的下一个关系边ID。

    主要优化的点：1.节点的查找，关系的查找，2. 从节点到关系，从关系到节点，3. 从关系到关系，4. 从节点到属性，从关系到属性，5. 从关系到关系类型。

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

RDF图模型和属性图模型的比较：

    知识图谱存储方式的选择需要综合考虑性能、动态扩展、实施成本等多方 面综合因素。区分原生图存储和非原生图存储：原生图存储在复杂关联查询和图计算方面有性能优势，非原生图存储兼容已有工具集通常学习和协调成本会低。区分RDF图存储和属性图存储：RDF存储一般支持推理，属性图存储通常具有更好的图分析性能优势。在大规模处理情况下，需要考虑与底层大数据存储引擎和上层图计算引擎集成需求。

    图模型是更加接近于人脑认知和自然语言的数据模型，图数据库是处理复杂的、半结构化、多维度的、紧密关联数据的最好技术。我们鼓励在知识图谱项目中采用和实践图数据库。图数据库有它弱处，假如你的应用场景不包含大量的关联查询，对于简单查询，传统关系模型和NoSQL数据库目前在性能方面更加有优势。RDF作为一种知识图谱表示框架的参考标准，向上对接OWL等更丰富的语义表示和推理能力，向下对接简化后的属性图模型以及图计算引擎，是最值得重视的知识图谱表示框架。