论文部分内容阅读
随着RDF数据集的规模和数量不断增大，传统方案基于三元组表将RDF数据导入关系数据库进行管理缺乏结构信息，无法有效利用数据库的索引、找到优化的执行路径，导致该方案查询效率低下。为了解决这个问题，存在两条思路，一条是为RDF数据管理开发专用的查询引擎和优化器，另一条是将RDF数据转换成关系数据使之能利用关系数据的优化器，提高RDF数据的查询效率。第一条思路是一个革命性的想法，但由于RDF数据的适用范围很广泛，具体的应用特点仍在研究当中，很难找到一个适用于所有RDF数据的有效优化策略，该方法目前并不可行。本文推荐采用第二条渐进演化的思路，将RDF数据转换为关系数据存储。RDF数据转换需要面对结构设计、数据重组代价过高、SPARQL查询优化等几个问题，本文针对这些问题提出了一套解决方案，并形成了一个原型系统CODE3.0。 首先，本文提出一个将RDF数据转换成关系数据的解决方案，将每个主语对应的三元组集合映射成一条元组，将该主语的描述谓语映射成元组的属性，将宾语映射成为元组的属性值，然后设计一个用于存储该元组的表（该表所存储的数据称为一个元组束）。随着数据的导入，这种设计方法的最大问题是数据库中将存在大量稀疏的、仅包含少量元组的表。为此，本文提出一个基于格结构的元组束演化算法用于合并结构相近的元组束以提高存储效率，并定义了一个判断元组束演化质量的指标-元组束冗余距离。通过在FreeToGovCyc和Yago两个特征不同的实用数据集上做实验，本文验证了该算法的有效性。 其次，在关系数据库的实现中，元组束合并会导致对应表中原有数据的重写，这将带来大量时间开销。原因在于:现有关系数据库的实现中，元组属性值的排列顺序与其对应属性在表结构中的排列顺序相同。当两表合并后，由于共有属性在原表的顺序与其在新表的顺序不同，导致原有的元组无法正确解释，需要重构原表的数据。为解决这个问题，本文引入解释型存储方案，在每个数据页面中加入属性值对应属性这类解释信息。本文引入了三种解释型信息的页面设计方案，PAX-Interpret、Tuple-Interpret和Page-Interpret，并通过实验证明各自的优劣。 第三，RDF数据的查询采用SPARQL标准，为了支持SPARQL查询，需要有一个将SPARQL翻译成SQL的中间模块。由于数据存储方案发生变化，原有的SPARQL翻译方法无法适用，需要对其进行改写。针对两类基本SPARQL查询--星型查询和链型查询，本文提出了两个优化技巧，对SPARQL—SQL转换的结果进行优化。本文证明了这两个优化技巧的正确性和有效性。 第四，本文将之前提到的三个改进合并起来，形成一个支持RDF数据自适应存储的原型系统-CODE3.0。本文介绍了CODE3.0系统的缘起、发展历史、体系结构和具体实现中的需要注意的细节。