本文在考虑查询交互存在的前提下，对在数据库中并行执行的查询进行查询响应时间预测建模，在建模过程中，在保持精度不变的前提下，为了减少样本数量和使样本具有代表性，在取样过程中依据查询组合的相似性进行取样。最后，利用所建立模型提出设计查询进度指示器的相关技术对查询响应时间进行预测。

论文组织结构

第1部分 绪论 这一部分对课题的研究背景和意义及国内外研究现状进行了综述，给出课题的主要研究内容以及论文的组织结构。

第2部分 相关工作 这一部分对课题用到的相关术语进行了定义与解释，对课题需要用到的工具、查询模版进行了简单的介绍。

第3部分 模型构建与进度指示器的实现 具体阐述了查询间交互影响程度的衡量、查询组合相似性度量方法、查询时间预测模型的构建以及查询进度指示器的设计技术。

第4部分 实验结果与分析 利用Eclipse、Postgresql收集实验数据，RStudio分析实验数据构建模型并验证其正确性。

第5部分 全文总结

......

查询响应时间预测对于数据库系统管理来说是一件十分重要的事情，例如查询调度、查询进度可视化和负载平衡等。由于查询运行过程中查询交互的存在，以及数据库管理系统进程运行的不确定性，很难准确预测查询的响应时间。本文首先提出一种判断查询组合相似性的方法，在不改变精度的前提下，为之后的建模和进度指示选取具有代表性的样本。其次，与现有解析模型和统计模型不同，在考虑查询交互的前提下，本文计划以查询组合相似性为基础，构建基于查询组合相似性的查询响应时间预测模型，对组合中的查询响应时间进行范围预测。模型的建立既减少了查询成本，又减少了用户对查询的盲目性。最后本文会向大家介绍一种简单可行的查询进度指示器技术，为关系型数据库查询运行的响应时间提供指示，给用户提供了良好的体验。

......

正如在第3部分中所提到的，被预测的查询成本、目前的查询执行速度都要用抽象的单元U来衡量。一个U代表着一个工作单元。在这个陈述中，因为一些切实可行的替代物的存在，所以我们故意地将这个概念变得模糊和一般化。成为U的最重要的必要条件就是它可以很容易地估计一个查询的执行需要多少U，同时可以很容易地把所估计的U转换成时间，因为最后对于用户来说，时间或许才是最有意义的单元。一些可以代表U的合理的候选物包括I/O输入输出设备、cpu循环周期、亦或者是两者的结合，当然也有可能使用一些额外的因素。

我们的查询进度指示器一方面不断地更新它的预测关于一个查询中的段（段将在4.2中被定义）执行需要花费多少U，另一方面不断预测它从U到时间的转换因素。随着查询的运行，系统聚集中间结果数据的增多，所估计的被要求执行一个段的U也会发生变化。对从U到时间这个转化因素的提炼在于对系统执行U的快慢程度的观察物。（如果U被选做是cpu循环周期，随之而来的就是这样一个公认的十分响亮的问题：“系统执行cpu周期的速度到底有多快？”；既然这样，这个问题实际上就是：“这个查询一秒钟会有多少cpu投入？”）

在这篇论文中，简单讲，我们根据被处理过的字节数来定义U。直觉告诉我们，这是非常容易去测量的，而且是cpu和I/O的一个粗糙的结合。那么，一个查询Q的成本就是将要被Q读和写的元组的总和，这些元组包括输入和中间结果。类似地，在任何时候，我们就可以使用被查询Q处理过的字节数来表示查询Q已经完成的工作量。

我们把U设置为一页字节，并且一开始（在查询开始运行之前）假设执行查询需要要求的U的量就相当于查询优化器对此查询I/O量的估计。在给予它的第一次运行时间预测之前，查询进度指示器“观察”一些数量的数据处理，目的是为了看看系统消耗U有多快；我们将在4.6中详细讨论它的更多细节。

随着查询的运行，估计的处理一单位U的时间将会改变来反映系统中观察的数据处理的比率。处理一单位U所花费的时间可能在一次物理的输入输出（如果系统是磁盘绑定）所花费的时间和处理一个居于缓冲池的数据页（如果被查询所处理的数据是在高速缓存中）所花费的时间之间......