面向分布式数据库的多并发OLAP型查询性能预测方法及系统

技术领域

本发明实施例涉及数据处理技术领域，特别涉及数据库数据处理技术。

背景技术

数据库中并行执行查询能够带来许多优势。例如，它能够缩短多个查询的整体运行时间并且提高硬件的利用率，但是，对于并发查询中的某一个查询，相较于其单独执行，它的执行时间可能会延长或缩短。主要原因是多个查询之间相互影响，有些查询能够促进该查询的执行，有些则由于与该查询存在资源竞争而延长查询执行。

并发查询性能预测对于查询调度控制等具有很大的应用价值，例如，如果事先能够知道查询执行时间，那么就可以改变多个查询的顺序，继而达到用户SLA要求。准确的查询性能预测技术还能够用于查询进度显示，以便了解当前查询的执行进度，然后DBA就可以做下一步的决策，等待该查询执行完毕或杀死该查询。查询性能预测还对查询优化器具有一定的指导作用，比如：查询优化器可以更好地创建并发查询感知的查询计划，以此来缩短查询的整体执行时间。

由于查询性能预测技术具有很大价值，所以，针对该方面有很多研究，这些研究主要面向两类查询，一是OLTP型查询，OLTP主要指在关系型数据库中一些对时间要求比较高的事务型查询，通常该类查询的执行时间较短；二是OLAP型查询，OLAP型查询主要运用于数据仓库，这种类型的查询面对的数据量比较大，执行时间比较长。本文主要面向OLAP型查询。当前已经有一些技术能够对分析型查询做性能预测，但这些技术在实用性和扩展性方面存在一定的局限。

发明人发现现有技术中至少存在如下问题：现有技术能够对分析型查询做性能预测，但这些技术在实用性和扩展性方面存在一定的局限。

发明内容

本发明实施方式的目的在于提供一种面向分布式数据库的多并发OLAP型查询性能预测方法及系统，使得查询优化占用资源少，从而确保实用性，且计算过程清晰简单、易于增强，从而确保扩展性。

为解决上述技术问题，本发明的实施方式提供了一种面向分布式数据库的多并发OLAP型查询性能预测方法，包括以下步骤：

计算干扰度：基于查询请求，对查询请求涉及到的计算资源占用情况进行计算，得到查询干扰度；

计算敏感度：基于查询请求，结合查询干扰度进行计算，得到查询敏感度；

预测延迟：基于查询敏感度计算查询延迟。

所述计算资源占用情况，具体包括：查询请求单独执行的时间、查询请求中I/O时间占总运行时间的百分比、主查询与并发查询共享的I/O时间、并向查询之间共享的I/O时间、并发查询对主查询的网络干扰。

所述步骤计算干扰度中，查询干扰度

其中，

所述查询敏感度，为查询干扰度的线性因变量，采用多组查询敏感度、查询干扰度数值训练得到线性关系参数；用于训练的查询敏感度基于查询延迟、查询请求在最差环境下执行时间、查询请求单独执行的时间计算得到。

所述查询延迟，用于训练的查询延迟通过测量得到。

所述查询敏感度和查询干扰度的线性关系为，

c

其中，μ

所述用于训练的查询敏感度，通过如下方式计算得到：

其中，τ

所述步骤预测延迟中，查询延迟基于如下公式计算得到：

其中，c

所述查询请求为主查询和/或并发查询。

本发明的实施方式还提供了一种面向分布式数据库的多并发OLAP型查询性能预测系统，包括：查询干扰度计算模块、查询敏感度计算模块、缓存模块和查询延迟计算模块，其中，

查询干扰度计算模块用于执行如上所述的计算干扰度的计算；

查询敏感度计算模块用于执行如上所述的计算敏感度的计算；

缓存模块用于缓存计算过程中的查询干扰度、查询敏感度和查询延迟数据；

查询延迟计算模块用于执行如上所述的预测延迟的计算。

本发明实施方式相对于现有技术而言，在查询优化方面占用资源少，算法部分清晰简单，对性能需求低，在实际使用时更易于部署，从而确保了实用性。

另外，本发明实施方式对数据的处理过程都是明确易懂的，易于后续进一步改进，故而易于增强，从而确保扩展性。

另外，本发明实施方式不仅计算快速，而且考虑了网络资源开销，对体现查询性能的查询延迟计算准确。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

一个或多个实施方式通过与之对应的附图中的图片进行示例性说明，这些示例性说明并不构成对实施方式的限定。

图1是根据本发明第一至第九实施方式提供的面向分布式数据库的多并发OLAP型查询性能预测方法的流程示意图；

图2是根据本发明第十实施方式提供的面向分布式数据库的多并发OLAP型查询性能预测系统模块的连接示意图；

图3是根据本发明第十一实施方式提供的面向分布式数据库的多并发OLAP型查询性能预测方法的流程示意图；

图4是根据本发明第十一实施方式提供的面向分布式数据库的多并发OLAP型查询性能预测方法进行实验的不同I/O争用优化的预测查询结果对比图；

图5是根据本发明第十一实施方式提供的面向分布式数据库的多并发OLAP型查询性能预测方法进行实验的不同并发查询量的预测查询结果对比图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合附图对本发明的各实施方式进行详细的阐述。然而，本领域的普通技术人员可以理解，在本发明各实施方式中，为了使读者更好地理解本申请而提出了许多技术细节。但是，即使没有这些技术细节和基于以下各实施方式的种种变化和修改，也可以实现本申请所要求保护的技术方案。以下各个实施例的划分是为了描述方便，不应对本发明的具体实现方式构成任何限定，各个实施例在不矛盾的前提下可以相互结合相互引用。

本发明的第一实施方式涉及一种面向分布式数据库的多并发OLAP型查询性能预测方法。本实施方式的核心在于计算查询干扰度和查询敏感度，并基于此计算得到查询延迟，从而准确地预测数据库查询(尤其是分布式数据库并发查询)的性能，通过计算资源占用情况，考虑了网络资源开销，对体现查询性能的查询延迟计算准确，且不采用深度学习等复杂模型，实现足够的实用性和扩展性。

本实施方式中的方法流程如图1所示，具体包括如下步骤：计算干扰度：基于查询请求，对查询请求涉及到的计算资源占用情况进行计算，得到查询干扰度；

计算敏感度：基于查询请求，结合查询干扰度进行计算，得到查询敏感度；

预测延迟：基于查询敏感度计算查询延迟。

上面的步骤划分，只是为了描述清楚，实现时可以合并为一个步骤或者对某些步骤进行拆分，分解为多个步骤，只要包括相同的逻辑关系，都在本专利的保护范围内；对算法中或者流程中添加无关紧要的修改或者引入无关紧要的设计，但不改变其算法和流程的核心设计都在该专利的保护范围内。

本发明的第二实施方式涉及一种面向分布式数据库的多并发OLAP型查询性能预测方法。第二实施方式与第一实施方式大致相同，在本发明第二实施方式中，计算资源占用情况，具体包括：查询请求单独执行的时间、查询请求中I/O时间占总运行时间的百分比、主查询与并发查询共享的I/O时间、并向查询之间共享的I/O时间、并发查询对主查询的网络干扰。此外，本领域技术人员可以理解，上述数据均可以采用现有技术手段在计算过程中直接从操作系统中通过实践比对获取得到。

本发明的第三实施方式涉及一种面向分布式数据库的多并发OLAP型查询性能预测方法。第三实施方式与第二实施方式大致相同，在本发明第三实施方式中，步骤计算干扰度中，查询干扰度

其中，

本发明的第四实施方式涉及一种面向分布式数据库的多并发OLAP型查询性能预测方法。第四实施方式与第一实施方式大致相同，在本发明第四实施方式中，查询敏感度，为查询干扰度的线性因变量，采用多组查询敏感度、查询干扰度数值训练得到线性关系参数；用于训练的查询敏感度基于查询延迟、查询请求在最差环境下执行时间、查询请求单独执行的时间计算得到。

本发明的第五实施方式涉及一种面向分布式数据库的多并发OLAP型查询性能预测方法。第五实施方式与第四实施方式大致相同，在本发明第五实施方式中，用于训练的所述查询延迟通过测量得到。此处测量具体为对比查询前后的系统实践，作减法计算得到。

本发明的第六实施方式涉及一种面向分布式数据库的多并发OLAP型查询性能预测方法。第六实施方式与第四实施方式大致相同，在本发明第六实施方式中，查询敏感度和查询干扰度的线性关系为，

c

其中，μ

本发明的第七实施方式涉及一种面向分布式数据库的多并发OLAP型查询性能预测方法。第七实施方式与第四实施方式大致相同，在本发明第七实施方式中，用于训练的查询敏感度，通过如下方式计算得到：

其中，τ

本发明的第八实施方式涉及一种面向分布式数据库的多并发OLAP型查询性能预测方法。第八实施方式与第一实施方式大致相同，在本发明第八实施方式中，步骤预测延迟中，查询延迟基于如下公式计算得到：

其中，c

本发明的第九实施方式涉及一种面向分布式数据库的多并发OLAP型查询性能预测方法。第九实施方式与第一实施方式大致相同，在本发明第九实施方式中，查询请求为主查询和/或并发查询。

本发明第十实施方式涉及一种面向分布式数据库的多并发OLAP型查询性能预测系统，如图2所示，包括：查询干扰度计算模块、查询敏感度计算模块、缓存模块和查询延迟计算模块，其中，

查询干扰度计算模块用于执行如上所述的计算干扰度的计算；

查询敏感度计算模块用于执行如上所述的计算敏感度的计算；

缓存模块用于缓存计算过程中的查询干扰度、查询敏感度和查询延迟数据；

查询延迟计算模块用于执行如上所述的预测延迟的计算。

不难发现，本实施方式为与第一实施方式相对应的系统实施例，本实施方式可与第一实施方式互相配合实施。第一实施方式中提到的相关技术细节在本实施方式中依然有效，为了减少重复，这里不再赘述。相应地，本实施方式中提到的相关技术细节也可应用在第一实施方式中。

值得一提的是，本实施方式中所涉及到的各模块均为逻辑模块，在实际应用中，一个逻辑单元可以是一个物理单元，也可以是一个物理单元的一部分，还可以以多个物理单元的组合实现。此外，为了突出本发明的创新部分，本实施方式中并没有将与解决本发明所提出的技术问题关系不太密切的单元引入，但这并不表明本实施方式中不存在其它的单元。

本发明第十一实施方式涉及一种面向分布式数据库的多并发OLAP型查询性能预测方法。第十一实施方式结合上述第一至第九实施方式，实现于一具体生产环境，其流程如图3所示。本实施方式中涉及到数学符号，主要符号定义如表1所示。

表1主要符号含义

A.关于查询干扰度的计算

查询干扰度(CQI,Concurrent Query Interference)用来描述主查询当前执行环境的优劣，也即描述资源的争用情况。

假定一个查询组合为m，它包括主查询q和与主查询并行执行的查询C＝{c

Baseline I/O指的是查询的基准I/O，即当一个查询独立执行时，它的I/O时间占用执行总时间的百分比，所占百分比越大，则表示此查询需要越多的I/O资源。用

当主查询与并发查询共同执行时，如果一个并发查询与主查询扫描不同的表，并发查询会对主查询产生“干扰”，这是因为不同查询会争用I/O。当并发查询与主查询扫描相同的表时，这种“干扰”会大大减小，甚至会对主查询产生“促进”作用，因为在数据库中，当频繁扫描一个表时，会把这个表的数据存入到共享缓存中，此后再请求这个表的数据，会直接从共享缓存中取，从而避免了重复性的I/O操作。

假设表t是主查询q与并发查询c

可以看到

其中，n表示主查询和并发查询需要扫描表的总个数，S

除了考虑主查询和并发查询的共享I/O之外，还需要度量并发查询之间的I/O影响。即主查询与两个并发查询a和b共同执行时，a和b由于并发执行所节省的I/O时间。首先定义表t为并发查询c

定义d

上面公式中的n同样是主查询和并发查询需要扫描表的总数。

当面向的是分布式数据库，数据分布在集群中的各个节点中，SQL查询中的表连接操作一定会发生数据传输，即把在一个节点上的数据迁移到另一个节点上。Greenplum中数据迁移的方式有两种：广播和重分布。广播就是把一个节点上的数据传输给其他所有节点，从而每个节点都有一个表的完整数据。重分布就是把表的数据根据关联键计算哈希值，然后再重新分布到各个节点上。假设一个表的记录数为N，那么重分布的数据量为N，广播的数据量为N*节点数，通过上述的方式就可以计算一个连接操作的数据迁移量。主查询的数据迁移总量为t

从上式可以看出，并发查询c

得到上述各个变量以后，就可以定义并发查询c

公式(7)可以理解为并发查询c

在一个查询组合中，定义主查询的CQI值为γ

上述公式即取各并发查询的

B.关于查询敏感度的计算

查询性能区间PR(Performance Range)指的是一个查询延迟时间范围，这个区间中的值表示查询在不同环境中的执行时间，区间的最大值为

当知道了c

给定一个查询组合m和一个主查询q，可以利用公式(8)来计算CQI值，然后使用线性回归模型预测查询的性能。为了进一步说明查询性能和CQI之间的线性关系，本文引入查询敏感度QS(Query Sensitivity)。

假定CQI和PRP存在线性的关系，定义如下公式：

c

式中，μ

综上，本实施方式的流程如下：

第一步，利用LHS生成查询组合m，其中包括主查询q；

第二步，分别得到关于q的τ

第三步，利用得到的(c

第四步，当q处于另一个查询组合中时，要预测此时q的查询延迟，先计算此时q的CQI值γ

第五步，通过第三步中产生的QS模型得到c′

第六步，把c′

对本发明的第十一实施方式进行实机实验，实验的环境为Greenplum分布式集群，Greenplum版本为5.0.0-alpha+79a3598。集群中共有4个节点，一个主节点和三个从节点，从节点主要用来存放数据并执行查询，主节点则负责分配查询和汇总结果。主节点的硬件配置为32GB的内存，CPU为4核Intel(R)Xeon(R)CPU E5-2630 v2@2.60GHz，从节点的内存16GB，CPU的核数和型号与主节点相同，在每个从节点中有四个数据库实例，每个数据库实例相当于一个完整PostgreSQL的数据库，用于处理一部分的数据。主节点和从节点的操作系统均为CentOS 7.4，linux内核版本为3.10。表和数据通过TPC-DS生成，TPC-DS是一个决策支持的benchmark。实验所用数据量大小为50G，选取TPC-DS中的10个模板生成10个查询用于训练和测试模型，这10个查询主要是I/O敏感型查询，执行时间较长，有利于提高预测模型的精度。

首先评估CQI的各个分量对误差率的影响，然后利用CQI预测查询延迟。当同时运行的查询个数MPL(Multi-programming Level)为3时，各个变量对查询延迟的预测误差如图4所示。图中：

Baseline I/O指的是查询的基准I/O，即当一个查询独立执行时，它的I/O时间占用执行总时间的百分比，所占百分比越大，则表示此查询需要越多的I/O资源

Positive I/O指的是并发查询对主查询产生“干扰”、争用I/O的情况。

Concurrent I/O指的是主查询与两个并发查询a和b共同执行时，a和b由于并发执行所节省的I/O时间。

Network指的是第十一实施方式优化后的I/O占用情况。

可以看到，只利用baseline I/O预测查询延迟的时候，它的误差较大，当加入并发查询交互的因素后，对误差率有明显的降低。考虑concurrent I/O和网络争用因素，对预测的准确率没有明显提高，说明positive I/O是影响预测模型准确率的主要因素，其他因素能够小幅度的提升准确率。综上，第十一实施方式考虑了并发查询之间的主要影响因素，是一个较好的预测模型。

对于一个特定的查询q，找到包含这个查询的查询组合，然后以q为主查询构建第十一实施方式的QS模型，利用该模型预测执行时间，并与实际执行时间比较，得到图5所示结果。

可以看出，不同的MPL，除去查询61和62，查询的误差都在25％以下，有的甚至能够达到20％以下。同样的，查询61和62的误差较高的原因在于它们的执行时间较短，从而造成误差较大。由此实验结果表明，QS模型能够适应不同的查询执行环境(不同MPL下的不同查询组合)，从而能够较准确地预测查询的执行延迟。

综上，实验结果表明本发明的预测误差率大部分能够维持在25％以下，能够较准确的预测查询的延迟时间。

即，本领域技术人员可以理解，实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序存储在至少一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

本领域的普通技术人员可以理解，上述各实施方式是实现本发明的具体实施例，而在实际应用中，可以在形式上和细节上对其作各种改变，而不偏离本发明的精神和范围。