C. 知识图谱 知识存储

C. 知识存储

基本知识

• 数据模型
  • RDF图（边属性）
  • 属性图：由节点集和边集组成
    • 每个节点具有唯一的id
    • 每个节点具有若干条出边
    • 每个节点具有若干条入边
    • 每个节点具有一组属性，每个属性是一个键值对
    • 每个边具有唯一的id
    • 每条边具有一个头节点
    • 每条边具有一个尾结点
    • 每条边具有一个标签，表示联系
    • 每条边具有一组属性，每个属性是一个键值对
• 查询语言
  • SparQL - RDF：声明式查询语言，源自SQL
  • Cypher - 属性图：声明式语言，只需要告诉司机要到哪里，具有的行车路线可由司机安排，乘客并不需要关心
    • 优点：便于用户学习掌握，同时给予数据库进行查询优化的空间
    • 缺点：不能满足高级用户导航式查询的要求
  • Gremlin - 属性图：过程式语言

常见知识图谱存储方法 - 关系型数据库

• 三元组：在关系型数据库简历一张具有3列的表
  • 缺点：一般自连接的数量与SPARKQL中三元组模式数量相当，当三元组表规模较大时，多个自连接操作会使SQL查询性能低下
  • 经典案例：3store
• 水平表：每行存储一个知识图谱一个主语和所有谓语和宾语，相当于邻接表
  • 缺点
    • 所列表的数据等于知识图谱中不同谓语数量，在真实知识图谱数据集中，不同谓语数量可能为几千个到上万个，很可能超出关系数据与允许的表中列数目的上线
    • 对于一行来说，仅在极少数列上具有值，表中存在大量空置，空值过多会影响表的存储、索引和查询性能
    • 在知识图谱中，同一主语和谓语可能具有多个不同宾语，即一对多联系和多值属性，而水平表的一行一列上智能存储一个值，无法应对这种情况
    • 知识图谱更新往往会引起谓语的增加、修改和删除，即水平表中列的增加、修改或删除，这是对于表结构的改变，成本很高
  • 经典案例：DLDB
• 属性表：对水平表的细分，将同类主语分到一个表中，不同类主语分到不同表中。这样就解决了表中列的数据过多的问题。
  • 缺点
    • 对于规模稍大的真实知识图谱数据，主语的类别可能有几千个到上万个，按照属性表方案，需要建立几千个到上万个表，这远远超过了关系型数据库的限制
    • 对于知识图谱上稍复杂的查询，属性表方案仍然会进行多个表之间的连接操作，从而影响查询效率
    • 即使同一个类中，不同主语具有的谓词也可能存在较大差异，这样会造成与水平表中类似的空值问题
    • 水平表方案中存在的一对多联系或多值属性存储问题仍然存在
  • 经典案例：Jena
• 垂直划分：为每种谓语建立一张表，表中存放知识图谱中由该谓语连接的主语和宾语值
  • 优点
    • 谓词表仅出现在知识图谱的三元组，解决了空值问题
    • 一个主语的一对多联系和多值属性存储在谓语表的多行中，解决了多值问题
    • 每个谓语表都按主语列的值进行排序，能够使用归并排序连接快速执行不同谓语表的连接查询操作
  • 缺点
    • 需要创建的表的数目与知识图谱中不同谓语数据相等个，而大规模的真实知识图谱中谓词数据可能超过几千个，在关系数据库中维护如此规模的表需要很大的开销
    • 越是复杂的知识图谱查询操作，需要执行的表连接操作数量越多，而对于未指定谓语的三元组查询，将发生需要连接全部谓语表进行查询的极端情况
    • 谓语表的数量越多，数据更新维护代价越大，对于一个主语的更新将涉及多张表，产生很高的更新时I/O开销
  • 经典案例：SW-store
• 六重索引：典型的“时间换空间”策略，将三元组全部6种排列对应地建立6张表
  • 优点
    • 缓解了三元组表的单表自连接问题，加速了某些典型知识图谱查询的效率
    • 每种三元组模式查询可以直接使用相应的索引表进行快速的前缀范围查找
    • 可以通过不同索引表之间的连接操作直接加速知识图谱上的连接查询
  • 缺点
    • 花费6倍的存储空间开销、索引维护代价和数据更新时的一致性维护代价
    • 党知识图谱查询变得复杂时，会产生大量的连接索引表查询操作，索引表的自连接依然不可避免
  • 经典案例：RDF-3X，Hexastore
• DB2RDF

常见知识图谱存储方法 - 三元组数据库

• RDF4J
  • 背景：前身是荷兰软件公司Aduna开发的Sesame框架
  • 功能：RDF数据的解析、存储、推理和查询等
  • 存储：内存和磁盘两种RDF存储机制
  • 查询语言：SPARQL 1.1 查询和更新语言，支持主流的RDF数据格式，包括RDF/XML、Turtle、N-Triples、N-Quads、JSON-LD、TriG和TriX
  • 高层架构图
    • 底层的RDF模型定义了URI、空节点、字面值和语句等RDF基本元素
    • API
      • Rio 代表"RDF I/O"，即RDF输入/输出，包括各种RDF文件格式的解析器和编写器，解析器负责将RDF文件解析为RDF模型中的三元组语句，编写器负责将三元组语句写成RDF文件
      • Sail API 代表 “存储和推理层API”，是实现RDF存储和推理的底层系统 API，其作用是将RDF存储和推理功能从底层实现细节中抽象出来，使得底层存储和推理实现模块可以透明地被替换
      • 存储库API是用户使用的RDF管理和处理高层API，提供RDF的存储、查询和推理等服务，面向终端用户，简单易用；
    • 架构图的顶层是用户开发的应用程序和HTTP服务器，用户应用程序直接调用存储库API
• RDF-3X
  • 背景：德国马克斯.普朗克计算机科学研究所的RDF三元组数据库系统
  • 技术特点：压缩物理存储方案、查询处理和查询优化技术
    • 在逻辑存储上，虽然以简单的三元组表为基础，但首先提出全索引方案
      • 建立6种三元组索引：spo、sop、osp、ops、pso、pos
      • 建立6种二元聚合索引
      • 建立3种一元聚合索引
    • 在物理存储上，基于B+树的压缩方案
      • 使用字典快速查找表建立RDF字符串到整数id映射
      • 使用面向字节的增量编码压缩技术，实现三元组的压缩存放
      • 三元组压缩限于B+树页面内部，不会跨越不同页面，避免了不必要的解压缩操作，能够提高查询效率
    • 优化算法
      • 自底向上的动态规划优化算法，其优化过程充分考虑了SPARQL查询的特点，并且最大限度地保持了有利于用全索引方案进行归并链接的连接顺序
      • 开发了基于代价模型的选择度评估机制，采用选择度直方图和频繁连接路径相结合的方法进行查询执行计划的选择度评估
• gStore
  • 背景
  • 技术特点
    • 将RDF图G中的每个实体节点及其邻居属性和属性值编码成一个二进制位串，由这些位串作为节点组成一张与RDF图G对应的变迁图G*
    • 在执行SPARQL查询时，将查询图Q也转化为一张查询的标签图Q*
    • gStore的研究工作已经证明了Q在G上的匹配是Q在G上匹配的超集
    • 为了支持在G上快速地查找到Q的匹配位置，gStore系统提出建立"VS树"索引
      • 为标签图G*建立不同详细程度的摘要图
      • 利用"VS"树索引提供的摘要图，gStore系统提出可以大幅削减SPARQL查询的搜索空间，加快查询速度
• Virtuoso
  • 背景
  • 技术特点：基础源自开发了多年的传统关系数据库管理系统，因此具备较为完善的事务管理、并发控制和完整性机制
• AllegroGraph
  • 背景：Franz公司开发的RDF三元组数据库
  • 技术特点
    • 公司早期一直开发Common Lisp和Prolog语言的实现工具，这使得AllegroGraph对语义推理功能具有较为完善的支持
    • 除了三元组数据库的基本功能外，还支持动态物化的RDFS++推理机、OWL2推理机、Prolog规则推理系统、时空推理机制、社会网络分析库、可视化RDF图浏览器等
• GraphDB
  • 技术特点
    • Workbench 是GraphDB 的Web管理工具
    • Engine 是查询处理和推理引擎，由查询优化器、推理机、存储层和插件管理器组成
    • 查询优化器能够在多种查询执行计划中挑选出较高级的一种，查询经过解析后会交由查询优化器进行优化
    • 推理机执行基于RDF规则的前向链推理，由显示三元组推导出全部导出三元组，导出三元组会随显式三元组的更新而同步更新；
    • 存储层使用pos和pso两种三元组索引，psco和pocs两种带有上下文信息的四元组索引以及字面值索引存储RDF数据；实体池是GraphDB存储层的核心部件，起到将RDF实体映射到内部整数ID的字典编码器的作用，同时还实现了对事务管理的支持机制
    • Connectors 是GraphDB连接外部工具的桥梁，包括用于建立快速关键字查找功能的Lucene和用于建立搜索引擎的Solr和Elasticsearch
    • 插件管理器在Engine内起到插件管理作用，既包括GraphDB内部实现的插件，也包括各种外部工具连接器
• Blazegraph
• Stardog
  • 技术特点
    • Stardog支持RDF图数据模型、SPARQL查询语言、属性图模型、Gremlin图遍历语言、OWL2标准、用户自定义的推理与数据分析规则、虚拟图、地理空间查询以及多种编程语言与网络接口支持

常见知识图谱存储方法 - 原生图数据库

• Neo4j
  • 技术特点
    • 基于属性图模型，其存储管理层为属性图结构中的节点、节点属性、边、边属性等设计了专门的存储方案
  • 优点
    • 存取效率天生就优于关系数据库，同时还具备OLTP数据库必需的ACID事务处理功能
  • 缺点
    • 单机版
• JanusGraph
  • 技术特点
    • 借助第三方分布式索引库Elasticsearch、Solr和Lucene实现各种类型数据的快速检索功能，包括地理信息数据、数值数据和全文搜索
• OrientDB
  • 技术特点
• Cayley

技术趋势

• 基于RDF知识表示的分布式存储
• 设计高适应性的知识存储
  • 随着知识图谱的规模越来越庞大、知识的表示方式越来越复杂，这对 目前的知识存储方式提出了挑战。如何设计出可支持对复杂节点的定制、 具有良好可伸缩性和灵活性的知识存储模式，满足复杂的查询、读取、计 算和应用需求成为面向知识图谱的知识存储的迫切要求。
• 基于LOD(Linked Open Data)的知识存储
  • 由于知识表示RDF模型的通用性和灵活性，知识图谱供应方越来越 倾向将自身的知识图谱数据表示成RDF格式并发布到互联网上。通过URI 相互链接起来，这些发布在互联网上的RDF数据共同构成了一个覆盖整个 互联网的庞大知识图谱。为了让这个庞大知识图谱网络更加丰富和完善， W3C积极推进LOD项目。LOD已成功将数百个RDF数据集相互链接在一起 以增强数据的可用性。
• 超图的进一步研究和应用
  • 随着知识图谱的普及，未来对于复杂关系的表示的需求，将逐步 增多，超图技术的研究和应用探索将是知识图谱的下一个方向。