查询感知的关系-图数据库自适应存储技术研究

张 孝 ，孙一铭 ，吴旭峰

1.教育部数据工程与知识工程重点实验室（中国人民大学），北京 100872

2.中国人民大学 信息学院，北京 100872

1 引言

近年来，社会上的数据量以指数级的增长速度在增长。根据IDC于2018年时的报告[1]上预测，中国的总数据量预计将达到8 060 EB，占到全球数据总量的18%。大数据时代，数据规模的不断发展给人们带来了诸多机遇，同时在技术上带来了更多的挑战。图数据是具有节点或者边标签等图结构特点的数据，并且可能附加信息与图形相关联。其特点主要在于数据集规模巨大，数据本身结构类型多变，应用场景丰富，使得用户会在不同场景下有着不同的查询操作需求。如何高效、智能地管理图数据如今正在被广泛研究。目前主流的单数据模型引擎对于图数据的管理都只能提供部分应用场景上的高效查询性能。多数据引擎协同存储图数据，可以在整个数据管理平台中实现牺牲部分存储成本，大大提高数据管理系统的查询性能。同时提出的查询感知的存储优化算法，为这种存储模式节省出更多的存储成本。

在众多的不同的数据模型中，关系数据模型一直自20 世纪80 年代就处于一个强势统治地位，出现了以MySQL、Oracle 等为代表的关系数据库管理系统[2]。但涉及到图数据管理存储时，由于当时的数据建模中的一些缺陷与问题，使得关系数据库一度产生了对于高效存储管理图数据上的不适应。当时人们为了解决图数据存储管理问题，基于NoSQL[3]技术开发了新的数据模型，图数据库从此诞生。当前，多种并行的图数据处理系统正在被不断研究与提出用以提高图数据的查询与处理效率[4]。图数据库因其独特的图算法优化，使得它在很多图数据处理场景下拥有较好的表现。然而，很多图数据引擎都因为其不够成熟，在实际应用中有着大大小小不同的问题。

图数据库虽然有亮眼之处，但是缺陷无法掩盖。因此，许多学者重新将思路放回了拥有几十年的工程积累的关系型数据库。基于关系型数据库，利用其良好的可拓展性构建图数据库。相对于图数据库，关系数据库系统在并发、锁、安全性和查询优化等方面，有着工业级强度的支持。以PostgreSQL为例，目前已经有通过基于关系代数的运用来拓展PostgreSQL 数据库系统在图数据集上的表达能力[5]。尽管利用关系数据库系统图处理能力扩展研究正在发展，但图数据的本质难题在关系数据库中还是没有得到太好的解决，即数据的高度关联所带来的严重的随机访问问题。传统的关系型数据库由于是靠连接实现关系，随机访问的情况会显得更加严重。

针对如何在数据云服务平台DataCloud中向用户提供稳定高效的图数据查询性能的问题，基于单个数据模型在管理图数据时的局限，本文提出了使用关系数据模型与图数据模型协同存储数据的方式来管理数据，目标在牺牲一小部分存储成本之后，大大提高整个系统的查询性能，从而达到更佳的管理效果。同时针对多数据模型管理方式下需要面对的数据冗余问题，使用查询感知的自适应存储算法。通过定期分析用户提交的查询，解析出不同用户的个人需求与数据集特点，按照不同数据引擎的查询优势，完成数据的存储删减移动等优化。

本文主要贡献包括：（1）对关系数据模型与图数据模型研究与实验测评，提出了利用两个数据模型协同管理数据的模式；（2）通过实验测试对比了关系数据库PostgreSQL 与图数据库Neo4J 各自在实际应用中的查询优势；（3）设计了基于用户查询感知的自适应存储优化技术，结合用户需求与引擎特点，对数据存储位置进行存储调优。

2 相关工作

本章主要介绍了相关背景与现有的图数据管理方式，主要有图数据库存储与关系数据库存储两种。

2.1 DataCloud数据服务平台

大数据云服务平台DataCloud表示将不同类型的数据储存在一个平台中进行统一管理，允许多用户访问，或者单用户进行不同需求的分析操作。它的主要特点如下：能够处理、存储不同类型的数据，包括关系数据、图数据等；能够适用于多种数据使用场景，比如不同需求目标的数据分析，针对数据的智能推荐服务等；提供持续稳定的高性能价比的数据和计算服务。如何能够管理好复杂的图数据也是DataCloud服务目标之一。因此，本文针对在该平台背景下探求更智能、更科学的存储模式提出了对应的存储优化方案。

2.2 图数据库技术

图数据的处理目前也正在被广泛研究，面向大规模在线社交网络、RDF、知识图谱、生物网络提出了大量图算法。类似于广度优先搜索[6]、连通分量计算、最短距离计算、拓扑排序[7]、PageRank[8]计算等算法在图数据的处理中被大量使用。针对于此，学者们开发了大量不同类型的图数据库。

图数据库目前可以称得上是种类繁多。其中主流的一类是以Neo4J[9]为代表的Native 图数据库。其主要特点是当用户查找一个节点的边或者是查找边上的端节点时，不需要再走一次B+树索引，而是直接通过指针直接指向下一个的物理地址，由此保持这种查询下的高性能。通常其关系查询时的时间复杂度可以达到O(n)。另一类热门的图数据库是以Titan/JanusGraph[10]为代表的分布式图数据库。JanusGraph 利用Hadoop[11]进行图的分析与图的批处理，同时系统所支持外部的存储系统包括 Apache Cassandra[12]、Apache HBase[13]、Google Cloud BigTable[14]、Apache Solr[15]与 Lucene 索引[16]、ElasticSearch[17]索引系统等。

为了解决图数据高度关联所带来的严重随机访问问题，所开发的图数据库在很多场景下虽有很好的表现，但也暴露了不少问题。例如上面所提的Neo4J数据库的数据属性查询慢、IO 性能低下等问题；JanusGaph存在查询与存储严重分离的问题等。因此，单单依靠目前的图数据库系统不能很好地达到高性能的管理图数据的目标。

2.3 关系数据库的图数据管理技术

目前在关系数据库上图数据管理的研究愈发热烈。Srihari教授在研究中发现了一种能够在关系数据库系统中有效挖掘图数据中密集子图的算法[18]；文献[19]利用SQL中的窗口函数，在关系数据库系统中实现了最短路径算法；文献[20]在研究中提出了基于SQL的声明性查询语言SciQL，作用是为了给关系数据库系统提供图的计算能力；文献[21]研究开发了图形存储系统SQLGraph，它将邻接信息的关系存储与顶点和边的属性存储用JSON 形式相结合，并通过实验证明了该系统比大多的NoSQL图形存储性能要强。

除了在关系数据库上实现图操作的研究以外，部分研究者尝试为关系数据库添加新逻辑，由此成为新的图数据库。这种方式虽然形成了新的数据库，但基本依然是凭借着关系数据库的基础。其中，这类典型之一，目前火热的图数据库AgensGraph，就是在PostgreSQL 上重新添加新的一层逻辑，成为新的图数据库。AgensGraph作为新一代多模型数据库，它能够支持经典的关系型数据模型，允许开发人员仍然能够集成经典的关系数据库模型，同时也能够支持提供图数据分析环境。

基于关系数据库的图存储管理技术开发，解决了很多之前纯图数据库存储图数据时遇到的诸多问题，但由于关系数据模型本身的影响，导致面对复杂的图运算时，数据库的能力还是表现不足。

2.4 多模型数据管理系统

目前市场上虽说有数量不少的多模型数据库产品，但是实际上大多只是将产品炒作成了多模型数据库，只有少部分的系统才是真正的多数据模型数据库。针对图数据管理的多模型系统更是少。

ArangoDB 作为原生的多模型数据库，它将多种不同的数据存储组合在一起存储在了一个数据库当中。在这个多模型数据库中，用户可以将数据存储为键/值对形式、图形形式或者是文档形式。用户可以使用统一的查询语言进行访问，单次查询也允许用户涉及多个数据模型的数据。

不同类型、不同结构的数据采用不同数据模型进行存储，可以获得更高的查询效率，尤其在大型的数据管理平台当中，具有很强的应用价值。ArangoDB 通过自身的实践应用，证明了多模型数据库的价值，在应用上拥有很高的访问效率，当然为了获得这些收益，必须面对一定的维护代价与数据冗余问题。

3 数据引擎查询性能差异

本章主要介绍了关系数据库PostgreSQL 与图数据库在存储数据时的具体查询性能差异。

3.1 TPC-H查询测试

TPC-H 是由TPC 事务处理性能委员会组织提供的一套工具包，用户进行OLAP 测试，主要目的是评价特定的一系列查询的决策支持能力，关注的是数据库平台的查询能力。使用TPC-H 数据集进行引擎性能对比的实验测试的最大原因是一方面它成熟的测试体系与接近真实应用的数据集环境，另一方面它测试的查询包含多个查询要素，包括多表连接、聚集、排序等典型查询，进而可以比对不同查询的性能差别。

通过每个查询数据库查询的响应时间，进行两个数据模型实际应用下的性能对比。TPC-H测试中共22个查询，尽管每个查询的内容不同，但是包含查询类型存在重复情况，鉴于测试侧重于对比不同类型查询的性能差异，因此在对22个查询结构进行解析后，选取11个代表性查询，如表1 所示。在这里需要补充的是，关系数据引擎与图数据引擎查询差异一般体现在复杂关系查询与其他类型查询上，因此实验查询主要是在此基础上进行的。而表1 中查询类型既包含着关系数据模型的查询也包含着图数据模型的查询。为了保证实验的准确性和可靠性，针对不同的测试实验，需要做关系和图数据查询语言的转换（查询语言的转换在实验前统一完成），使其查询条件是一一对应，从而也确保了TPC-H在多数据模型下的查询测试的通用性。具体的语言转换以表1中的序号1为例子进行说明：

关系数据库查询：

select filed，count（filed） from tname group by filed having coun（tfiled）＞count order by id

图数据库查询：

START n=node（num）

MATCH（n）--＞（x）

WHERE coun（tx.filed）＞count

return x.filed，coun（tx.filed）

order by x.id

说明：id、filed为字段名称，tname为表名，num为节点编号，count为常量值。

表1 实验选取查询包含类型情况

以上语言转换，目前是根据sql 语句手工模拟出对应的图查询语句（下一步将做成程序自动模拟），从而执行Neo4J查询，完成整个实验过程。

实验服务器环境基本配置如下：Windows10 专业版，i7-3770CPU，主频 3.4 GHz，8 GB 内存，200 GB 硬盘。关系数据库系统为PostgreSQL，图数据库系统为Neo4J。实验数据来源为网页爬取，在PostgreSQL 中生成后，然后转换成CSV 的形式，再导入到Neo4J 中。每个查询分别在每个数据引擎中进行20 次查询（相同的查询采用缓存机制），在去除最大值与最小值以排除偶然性因素后，取每一个查询的平均值。最后的测试结果对比如图1所示。

图1 查询时间对比

总体而言，PostgreSQL 查询时间几乎都优于Neo4J的。这主要是因为TPC-H 依然是关系数据库上的测试基准，查询上做了相对的优化。但随着查询序号增加，表的连接数同时增加，查询时间开始逐渐接近。达到五表连接时，查询时间就非常贴近了，最后，甚至出现了Neo4J 查询时间少于PostgreSQL 的情况。这说明了Neo4J 在关系复杂情况下的查询优势。而在其他查询类型下，关系数据引擎相比图数据引擎依然有着不小优势。

3.2 Yelp数据集查询测试

通过上一节的测试，可以得到关系数据模型与图数据模型下不同查询的性能差异：图数据模型在复杂关系查询上有着优势，但在其他方面表现不如关系数据库。为了进一步地明确具体查询在两个引擎上的表现，本节使用知名数据集Yelp进行实验测试，从而得到每一个具体查询在不同数据引擎下的对比。

Yelp 数据集来源于美国最大点评网站Yelp。数据集涵盖了Yelp 内部存储的商户、点评和用户数据，具体包括了用户评价、商户信息等。数据集由于来源真实，具有很强的实际意义，同时内部既存在复杂关系，也存在多样的属性集合。因此选取Yelp 在两个数据引擎进行不同基本查询的性能对比。实验环境跟上一测试相同。本次实验相对更为具体，以SQL语句关键词为标志进行测试，具体为：（1）Order by，排序查询；（2）Aggregate，聚集查询；（3）Join，四表五表连接查询；（4）Having，聚集子句；测试的关键词选用标准来自上一个实验总结。测试语句为基础查询语句，返回1 000条记录，每种查询类型都会用3 个不同的查询语句测试，最后取加权平均值，得到这类查询最终的平均查询时间。

实验为得到直观的数据引擎的性能比，对查询时间进行了相对得分处理，每一类查询在两个数据引擎中的总分为100，各自根据查询平均时间的比值得到对应的性能比，如图2所示。由图可知，Yelp数据集的测试下，Neo4J的优势查询在于超过四层关联关系查询时，速度远远优于关系数据库，而在其他查询需求上，性能比不上传统的关系数据引擎。

图2 不同引擎下不同查询类型的性能对比

4 关系-图协同存储与优化

基于第3 章中介绍的关系数据模型与图数据数据模型的实际查询性能的不同，提出两个数据引擎协同存储来获得查询的高性能，并介绍了查询感知的自适应存储优化技术的研究与实现。

4.1 协同存储的查询优势

本节通过实验举例说明的方式，简单证明关系-图协同存储下的查询优势。用户查询可以分为简单查询与复合查询。简单查询是查询结构简单，只包含多表连接、聚集查询等查询中的一个或者两个。简单查询情况下，由于两个引擎可以根据自己的优势进行查询选择，查询效率一定会比单个引擎进行所有查询的效率要高。因此在证明关系-图协同存储下的查询优势，只需要证明用户复合查询下多数据模型管理的性能优势。

复合查询是指查询包含图数据引擎擅长的复杂多表查询，同时包含关系数据库擅长的排序聚集等查询。对此，分别使用单个图数据引擎、单个关系数据引擎与双引擎进行查询，通过对比三种情况的查询时间得到性能对比。实验环境与数据集同上一章Yelp实验相同，实验方式具体如下，设置四组复合查询，具体包含类型为：（1）三表连接、排序、聚集；（2）四表连接、排序；（3）五表连接、聚集；（4）五表连接、聚集、排序。实验通过查询分割，将复合查询中各自擅长的查询分配至对应查询引擎，再将总的时间与中间成本进行整合得到复合查询总时长。

对实验结果进行比例调整，将协同存储下的查询时间设为单位1，则其他查询结果如图3所示。可以看到，在使用单个图数据引擎或者单个关系数据引擎存储时的查询平均时间都是关系-图复合存储下的查询时间的2～5倍。使用多数据模型协同管理复杂关系数据集时，用户的查询性能得到了相应的提高，验证了这种存储模式在查询上的优势性。

图3 单引擎与多引擎查询性能对比

4.2 查询感知的关系-图的存储优化

多数据模型对数据集进行协同存储体现了其性能的优越性，但也同时需要付出一定的代价。这方面主要体现在复杂的运维与冗余存储上。本节提出了查询感知的存储优化方式，来结合数据特点与用户需求，来解决冗余存储的问题。

由于数据存储的优化方案受到数据集本身特点与用户个人查询需求的影响，系统很难一开始就对用户传入的数据集进行结构判断与需求分析，因此采用用户查询感知的方式进行协同存储调优，其机制是：定期解析用户输入的查询内容，分析用户的查询需求并解析数据库中的数据结构，进而完成自适应存储优化，达到为用户优化存储空间的目的。

根据上述基于查询感知的存储优化思路，用户上传至平台的数据流如图4 所示。用户上传数据并选择数据库默认选项为全冗余形式，即将数据全部传输至两个数据引擎当中。同时平台也提供了用户选项，用户可以在上传数据时或者在自适应优化存储过程中，申请主动分配数据至指定空间或申请主动从某一引擎删除部分数据。用户选项的设置一方面可以提高基于查询感知自适应调优程序的容错率，减少因调优程序引起部分查询效率降低的情况，另一方面也可以更好地获取用户个人需求信息，进行更准确的存储调优。

图4 数据库引擎间的数据流

在用户上传数据进入平台之后，数据将以全冗余的形式存入到两个数据引擎当中。接下来，平台的自适应调优程序将会对用户提交的每一个查询进行相应的分析，并存储至用户对应的查询历史记录当中。存储调优过程如图5 所示。调优程序将会定期调用存储的查询记录，根据解析用户提交的查询对数据集结构特点与用户需求进行判断，从而得到如何对数据进行存储判断。需要提及的是，程序中用户的查询输入暂时默认为SQL语句形式。

图5 自适应存储调优处理过程

基于以上的分析，协同存储优化实现算法主要分为两个部分：用户查询解析算法与存储优化算法。

4.2.1 用户查询解析算法

用户查询解析算法将用户的每一个查询进行结构上与内容上的解析，进而判断用户所存储的数据集中哪一部分数据参与了复杂的表连接查询，哪一部分数据经常参与了聚集查询等。将查询语句所隐含的信息解析出来之后，用作接下来自适应存储调优算法的判断依据，进而完成存储优化的目标。

算法整体可分为预处理阶段与信息解析阶段。预处理阶段将用户输入的查询语句格式统一后分块。分块后有利于之后的信息挖掘与获取。信息解析阶段将分块后的信息进行解析整合。解析后，每个数据表的信息会以哈希表的形式存储下来：该表总查询访问数，该表参与属性查询数，该表参与查询的本身表连接数以及该表参与查询的总连接数。通过这些哈希表存储的信息，来传达用户查询中潜藏的表信息与用户需求。算法具体描述如下：

算法1查询解析算法

4.2.2 存储优化算法

用户查询解析后，算法将每个表的信息存到对应表中，接下来存储调优算法进行冗余存储优化。算法将使用解析信息，对用户需求与数据结构进行判断，由此完成对部分数据在某一引擎中的存储或者删除操作。数据存储调整单位为关系数据库中的数据表，当在关系数据库中的表发生存储变化时，只需按照表的形式进行调整；当图数据库中的数据发生调整时，则只需按照节点情况进行增减。值得一提的是，由于Neo4J的存储模式问题，在Neo4J引擎中进行任何的数据变更成本都比较高，所以算法在判断数据在Neo4J 中的存储或者删除时，要求会相对较高。

解析算法核心为启发式规则：（1）当数据表本身参与连接数不超过该表总查询数时，认定该表每次查询最多本身只参与一次表连接，可判断这类表基本主要职能为存储某一节点的属性集，因此这类表存储位置判断为关系数据库。（2）当该表每次查询都有x次（x为可调整系数，目前设定为2）聚集、排序等查询时，则该表至少存储在关系数据库中。若该表参与的每个查询都小于y表连接数（y为可调整系数，目前设定为3），删除该表在Neo4J 引擎中的存储，否则，两个引擎冗余存储这段数据。（3）当该表参与的每个查询都超过了z表连接数（z为可调整系数，目前设定为5），判断数据应存入Neo4J 数据引擎。若该表每次查询自身参与连接数超过n（n为可调整系数，目前设定为2），删除该表在关系数据引擎中的存储。算法具体描述如下：

算法2存储优化算法

4.2.3 存储优化算法分析

基于启发式的存储空间优化算法通过一系列的规则判断来完成以表为单位的删除与存储选择，而对于这个规则它是后期经过不断的学习和修改进行完善的。就目前来说，算法中的启发式规则借鉴了大量实践经验，可以保证绝大多数情况下存储优化算法判断的正确性，代表了一定的普遍性，但考虑到用户的查询不可预测性、数据的多样化性以及存储结构的不断调整可能会影响用户某些查询的执行性能以及协同存储的分配准确率，因此系统在优化上还进行了以下设定：一是定期调用自适应存储优化算法执行程序，待调优完毕后删除之前的查询解析信息，重新统计下一周期的用户查询信息，确保每一次存储调优都是基于用户最近时间的查询记录，同时根据变化完善算法规则；二是开放用户选项，允许用户申请调整数据的存储位置，若是采用这一过程将会加大数据分类存储的复杂性以及存储优化算法的适用性，增加了存储算法的挑战性，如果成功，则无异于增强了算法的健壮性与普遍性，从而使系统的执行更加完善和具有代表性。因此基于以上分析，采用定期调用存储优化程序与开放用户选项两者相结合的思路，从而实现协同存储算法的不断优化性、可用性与实用性和用户查询效率的最大化与最优化。

5 实验与分析

实验分为两部分：（1）测试双引擎全冗余存储下和优化存储后的查询性能对比与存储空间优化率；（2）测试单数据引擎存储情况下和优化存储后的查询性能对比与存储空间对比。通过两部分实验来评估查询感知的自适应存储调优性能。

5.1 实验环境

实验环境中的软硬件配置如表2 所示。实验使用数据集使用Yelp公开数据集，为了达到测试不同数据规模的算法效果，同时准备了2倍、4倍与8倍于原数据量的实验数据集。

Yelp 数据集本身的组织形式为JSON 格式，解析将其存入关系数据库PostgreSQL 中，一共18 张表。在将Yelp实际数据集导入关系数据库PostgreSQL中后，再将其转换成CSV 后导入Neo4J 当中。图数据Neo4J 中存储节点数量达到900万，节点主要类型有商家、用户、图片、评论和建议等。Yelp原数据集信息统计如表3所示。

表2 实验环境配置

表3 实验数据集统计信息

5.2 查询实验设置

为提高用户查询的仿真度，从数据源网站中随机选取了多个用户常见查询作为构造查询的主要参考。为了检测到存储优化算法的每一个规则是否都有作用，因此查询设置也尽可能地涉及了更多查询类型，同时查询的表也尽可能访问到数据库中18个数据表。具体查询类型设计情况如表4所示，并给出了简单的样例查询介绍。

表4 查询实验设置

实验查询组以包含查询类型为分组，在每一个实验查询组都包含15 个符合条件的查询，一共设有120个对应的查询。

5.3 实验结果与性能评估

本节主要说明两组对比实验的查询结果对比与存储情况对比，并根据两组实验对比的结果进行存储优化算法执行的性能评估。

5.3.1 全冗余存储与优化存储对比

该对比实验主要是为了检验查询感知的自适应存储优化算法的实际优化效果以及算法对整个系统查询性能影响。

实验具体操作如下：将设置好的查询在全冗余存储下进行测试，记录时间，并启动存储优化程序。查询实验全部完成后，按照调优程序进行存储位置优化后，重新使用查询实验进行测试，得到优化后的查询时间。图6 展示了不同规模大小数据集优化前后的存储空间变化。

图6 存储空间优化效果

存储算法优化空间效果达到了接近三分之一，已经十分接近理想情况下无冗余存储的0.5。对比不同大小实验集时，优化效果最好的为8 倍的数据集，最差的为原数据集。数据集本身的大小跟优化效果关联并不是很大。仅从存储空间优化来看，存储优化算法的优化效率还是比较理想的，但仍需关注存储优化对查询性能的影响。图7为不同规模数据集下，查询性能变化。

优化前全冗余的存储形式相对而言在查询性能上拥有优势。当数据规模大小增大时，部分设置的查询组的查询时间也随之变大了。这主要是因为随着数据集规模的增大，两个引擎中进行的数据查找操作也变得复杂起来。设置查询组后半部分变化较大，也是由于后半部分设置的查询组涉及查询类型较多，数据处理情况更为复杂。

从实验结果来看，存储优化算法产生的查询时间影响波动在5%到20%之间变化。其中，高幅度变化的查询数量实验下并不多。综合四个数据集下不同查询的平均变化来看，优化后的整体查询时间增加了12%左右。本文认为这个数值处于一个可接受的波动范围，并且未来认为同通过查询优化的方式进行进一步的时间优化。总体而言，存储优化算法在实验环境中为全冗余存储的实验数据完成了30%左右的实际存储空间优化，同时查询性能下降了12%左右，优化效果较为良好。

图7 查询性能优化效果

5.3.2 优化存储与单引擎存储对比

这一组实验对比是为了验证整个系统在经过多引擎协同存储与自适应存储优化后，与传统的单引擎管理图数据进行查询性能上与存储空间上的对比，从而得出查询感知的关系-图自适应存储优化的多模型协同管理方案的整体效果。

实验查询空间对比如图8所示。可以看到，在进行存储优化后，多数据模型协同管理数据依然需要使用大量存储空间。总的来看，相比单引擎，优化后的多数据引擎管理使用了多40%左右的实际存储。在不考虑查询的情况下，这种存储空间对比使用还是不可忽视的。所以依然还是需要结合查询时间对比得到更准确的性能对比结论。

图8 单引擎与优化多引擎存储对比

图9 为单引擎和优化后协同存储多引擎的查询时间对比实验结果。总的来看，在任何查询组中，优化过后的协同存储管理下的查询效率始终不是最差的。根据查询实验平均查询时间得出：单个引擎的查询时间都是优化存储查询时间的三倍以上。从这两个方面而言，优化组的查询性能相对是比较高的。

图9 单引擎与优化后存储多引擎的查询性能对比

从不同数据规模实验结果对比来看，随着数据规模的增加，实验查询组——后几组的性能差距也随之增大。本文认为这主要是因为数据规模的增加，使数据引擎需要做的查询操作变得更加复杂，不同引擎之间的查询性能差距将不断扩大，尤其是多表连接查询，使得后几组查询实验中涉及多表连接查询的实验，在使用单个数据库引擎管理数据时，性能会不断变差，而在多数据模型协同管理情况下的查询性能相对会好很多。这也证明了多数据模型管理在经过优化后，依然具有很大的整体查询优势。总体而言，优化后的多数据协同管理在多使用了不到五成的存储成本下，可以获得三倍以上的查询性能。

6 结束语

本文针对在数据云服务平台DataCloud中如何保证图数据在不同需求场景下的高查询性能问题，通过对多个数据模型的查询效率进行预备实验和结果分析，提出了多数据模型协同管理数据的模式，并提出了基于查询感知的自适应存储优化算法来解决多数据模型存储数据时的存储冗余问题。该方法利用查询历史，分析查询结构与内容，并利用启发式规则建立代价模型，来完成数据的迁移与删除等存储优化工作。实验结果表明，多数据模型协同存储数据相比单引擎存储，有着更好的查询效果；同时验证了存储优化算法为此种存储模式提供了良好的存储优化效果。未来将考虑文档、KV 等更多引擎，以及基于存储优化能力进一步优化系统查询处理操作或过程。

致谢本文工作得到中国人民大学信息技术与管理国家级实验教学示范中心的部分支持。感谢审稿专家们的宝贵修改意见和建议，同时感谢中国人民大学数据工程与知识工程教育部重点实验室人大行云云平台为本文项目提供的实验环境。