面向关系数据库查询的能耗建模及计划评价

国冰磊 于 炯 杨德先 廖 彬

(新疆大学信息科学与工程学院 乌鲁木齐 830008)

大规模数据中心在全球范围内的广泛部署使高能耗、高费用、高污染等问题日益突出[1].2014年数据中心能效现状白皮书报道，2013年世界数据中心能耗总量为8102.5×108kW·h，同年我国数据中心耗电量达772.1×108kW·h，同比增长16.2%.其中IT设备和软件的能耗占数据中心整体能耗的45.4%.数据中心的能耗逐年攀升，不仅给企业带来沉重的经济负担，产生的全球性碳排放也带来一系列的社会及环境问题，促使世界各地的政府部门要求IT企业提高数据中心的能耗效率[2-4].根据著名研究机构Gartner[5]报道，IT领域目前的CO2排放量占全球总排放量的2%，并保持着高达11%的年增长率[6],到2020年这一比例将翻一番.

在2008年全球最顶级的数据库研究会议(Senior Database Researcher Meeting)上，研究人员共同提出“研究与设计低能耗但不牺牲可扩展性的节能DBMS”是未来数据库领域的研究热点[7].降低数据库的能源消耗对提高数据中心整体的能耗效率具有推动作用.数据库系统的能耗管理问题也成为近期数据库领域顶级期刊和会议的讨论热点[8-29].传统数据库以高性能为主要设计目标，而绿色数据库系统则是要保障系统性能，同时降低能耗[30].关系数据库在大数据时代仍然占据着重要地位，所以关注关系数据库系统的能耗问题、研究面向可持续发展的绿色数据库系统，具有重要的应用价值和社会意义[20,30-32].

已有研究[13,21,28]指出，在关系数据库中，存在大量被查询优化器忽略的节能查询计划.因为数据库在设计之初缺少能耗方面的考虑，查询优化器会选择执行时间最短、忽视性能可以接受而且更加节能的计划.对一条语句而言，其不同查询计划之间的响应时间、执行功率及能耗等指标也各不相同.本文构建查询计划的能耗预测模型，在语句执行前预测查询计划的能耗，利用评价模型使查询优化器选择节能的计划，降低查询的能量消耗，实现提高数据库整体能耗效率的目标.Oracle数据库是目前市场占有比率最大的关系型数据库，所以选取Oracle数据库为主要对象研究查询能耗预测与计划评价的相关问题.

1 相关研究

已有的数据库节能工作可从硬件和软件2个方面进行分类，下文将挑选一些具有代表性的工作进行详细探讨.

1.1 基于硬件的节能方法

基于硬件的节能方法主要有2种思路：1)关闭空闲设备[33]；2)用低能耗高效率的设备替换高能耗低效率的设备[27,34-39].Meza等人[33]将数据库重新配置到更少的磁盘上并关闭空闲的磁盘，只牺牲5%的峰值性能可降低45%的功率.闪存以及固态硬盘相比传统机械磁盘具有耗电少、无机械延迟等特点.许多研究者都提出应该在绿色数据库系统中考虑闪存的使用[38-41]，并对比了磁盘和闪存的能耗有效性.随着硬件技术的发展，基于硬件的节能方法利用现代硬件的新特性，在不影响服务级目标的前提下，尽可能地将服务器从高能耗的状态转换到低能耗的状态.动态电压频率调整(dynamic voltage and frequency scaling, DVFS)[10,40-43]是常用的CPU功率调节技术，通过动态调节CPU时钟频率和供电电压调整CPU功率，进而降低其能耗.基于硬件的节能方法不需要复杂的能耗管理组件且效果显著.然而简单地替换不能充分发挥硬件的特性，对已经部署的大型应用系统批量的硬件替换也会造成成本过高等问题[40,43].

1.2 基于软件的节能方法

基于软件的节能方法主要是构建数据库常用查询的能耗预测模型，进而实现预测整个数据库系统能耗的目的[18].根据模型的粒度，可将现有的能耗预测模型分为运算符级的能耗模型与语句级的能耗模型.

运算符级的模型将查询计划分解为一个或多个运算符，如全表扫描(table scan)、索引扫描(index scan)、排序(sort)等.Xu等人[13,22]利用运算符的共同资源消耗特征，定义每个元组(CPU处理的普通元组数或索引元组数)和每页的能耗常量(读取的磁盘页面数)，为每个运算符构建功耗模型，最终形成整个查询计划的功耗模型.基于此，文献[26,28]利用PostgreSQL查询优化器中的性能代价估算模型，将CPU与磁盘作为主要的能耗组件，构建动态的运算符级别的能耗模型.Liu等人[44]基于文献[13]利用CPU检索的列数与元组数的乘积，为查询负载构建功耗模型.刑宝平[45]利用数据库应用层信息和操作系统层信息，建立了基于回归分析方法的运算符级别的功耗模型.

语句级的能耗模型忽略查询计划的内部细节，并不深入研究每个运算符的资源消耗特征，而是将查询或查询负载看作一个整体.Rodriguez-Martinez等人[46]通过提取选择查询的共同特征(元组数、列数、平均元组长度、谓词的选择率(selectivity factor)等)在集群环境下构建了峰值功耗预测模型.杨良怀等人[47]从执行核粒度考察CPU执行频率及利用率对系统功耗的综合影响，采用线性回归方法拟合CPU各个核的利用率、执行频率、磁盘利用率来预测整个系统的功耗.金培权等人[48-49]采用软硬件集成的方式，设计出一个用于测试绿色数据库系统能耗有效性的工具DBPower.杨濮源等人[50]以TPC-H为基准，设计了一个用于测试移动智能终端数据库查询能耗的工具TPCDroid.我们已有的工作[51-53]提出一种基于查询资源消耗最小单位的数据库动态能耗模型.Sarda等人[54]提出一种基于查询计划回收利用的工具PLATIC(plan selection through incre-mental clustering)，帮助查询优化器摊销优化代价，从而降低优化时间加速查询执行.Harizopoulos等人[9]提出QED机制(improved query energy-efficiency by introducing explicit delays)，引入显示延迟和设置阈值，对查询进行聚类并将查询的公共部分放入队列统一处理.文献[29]通过仅处理一次公共子表达式并将其执行结果共享给其他查询，达到降低执行总时间进而节能的效果.

现有的数据库能耗建模方法[12-13,22,26,28,44-45]直接使用了PostgreSQL数据库中的时间代价公式，虽然通过数学方法重新确定了公式中的系数，但是能耗预测值的精度有待提高[30].本文与现有工作不同之处有3点：

1) 已有研究通过定义CPU检索元组的能耗常量为CPU预测功率[12-13,21-22,26,28,44-46].本文综合考虑CPU在查询执行过程中的作用，选取能更好反映CPU工作量的指令数[55-59]，通过定义CPU执行指令的能耗常量为CPU预测能耗.

2) 现有研究[12-13,21-22,26,28,44-50]在构建查询能耗预测模型时，只考虑CPU和磁盘的动态能耗，没有考虑内存的动态能耗.本文分析并验证了缓存在内存中的数据对查询能耗及能耗预测精度的影响，并将内存的动态能耗构建在模型内，提高模型的预测精度.

3) 已有的工作[26-28,46-47]大多集中在构建能耗预测模型，使数据库系统能够感知能耗，很少关注具体如何利用能耗模型进一步实现节能.本文在解析查询处理与查询优化机制的基础上，构建适应绿色数据库系统的查询计划评价模型.模型改进了查询优化器在选择计划时忽略能耗因素的缺陷，将功率和能耗也作为优化目标，实现为数据库系统节能的目的.

2 能耗预测模型

在不考虑性能的情况下，构建节能数据库是没有意义的.根据经典能耗公式(式(1))，可以得出2种降低数据库能耗的方法：1)提高查询的速度，减少其响应时间，即传统数据库的优化目标；2)降低查询的执行功率.

E=P×T，

(1)

其中，E，P，T分别为能耗、功率、响应时间。本文专注于第2种方法，同时保证性能退化度在可接受的范围内.

传统基于存储的能耗模型[60]未将内存能耗构建在模型内.本文不仅在2.1节中验证了内存对查询功率及能耗的影响，而且将内存能耗加入能耗预测模型.

2.1 内存对查询能耗的影响

查询语句的处理过程主要包括3个阶段：解析(parse)、执行(execute)、提取数据(fetch).3个阶段都需要利用缓存在cache结构中的数据来减少I/O或CPU资源的消耗.已有研究[61]指出在查询执行的过程中内存同样是服务器中重要的能耗部件，所以在构建查询能耗模型时，为提高查询能耗预测的精度，需将内存的动态能耗构建在能耗预测模型内.

为研究缓存在内存中的数据对查询功率及能耗的影响，分别在2种不同的设置下对20条查询语句进行测试，收集能耗相关数据.实验结果如图1、图2所示.2种设置分别是：1)缓存数据可用；2)缓存数据不可用，需要从磁盘再次读入内存并由CPU重新计算得到.

Fig. 1 Power of queries under 2 different settings图1 查询语句的功率

Fig. 2 Energy of queries under 2 different settings图2 查询语句的能耗

由图1、图2可知，无缓存执行场景下的功率、能耗总是大于有缓存的场景.查询的总功率在2种情况下的平均差异为2.56%，最高可达5.94%；总能耗的平均差异为30.07%，最高可达195.09%.有缓存时更节能的原因是缓存在buffer cache和shared pool中的数据可以被查询重复使用，加快查询的执行，节省查询执行过程中的资源消耗.说明缓存在内存中的数据是否可用，是影响查询执行能耗的重要因素.

执行查询所需的数据的量是固定的[62]，一般情况下，这些数据都是从磁盘中读取.如果内存中存在缓存数据，应区分数据来源(内存或磁盘)，将数据获取过程中产生的能耗进行分类(内存能耗或磁盘能耗).

2.2 系统各组件能耗建模

对数据库而言，查询语句的执行代价是由其使用相关资源产生的代价线性累加而成[28,63]：CPU、磁盘I/O、内存和网络资源(针对分布式数据库系统).资源的消耗会产生2种基础代价：时间代价和功率代价，而查询的能耗代价则是时间代价与功率代价的积分.网络相关的能耗模型主要针对交换设备，其能耗模型和节能方法与节点服务器有较大不同[60].本文是在多组同配置单节点服务器下进行实验，所以暂时未考虑网络资源的能耗.

1) CPU代价.在执行查询语句时，对数据处理过程中执行的每一步操作都会依据处理量与处理方式的不同请求CPU执行一定数量的指令.已有研究[12-13,21-22,26,44-46]大多基于CPU处理的元组总数对CPU代价进行估算.但是CPU除负责检索元组外，还需检索和计算与查询执行相关的其他重要信息(如解析查询语句、构建查询树、计算查询代价、选择最优的查询计划、检索数据字典等)，这些操作都需要消耗CPU指令.不同于元组总数，CPU指令总数量能更真实地反应CPU的工作量.本文通过定义CPU执行指令的能耗常量来估算CPU的能耗.

将查询语句执行过程中消耗的CPU指令总数量设为CPU总指令数(NCPU)，为方便计算，CPU指令数以万为计量单位.对于不同型号的CPU，其处理指令的能力存在较大的差异，指令处理能力是指CPU的指令功率能力(NCPU_watt，即每瓦特完成指令数).设执行每万条CPU指令的功率为PCPU，时间为TCPU，则CPU的动态能耗ECPU为

ECPU=NCPU(PCPU×TCPU),

(2)

PCPU=10000NCPU_watt.

(3)

2) 磁盘代价.在查询执行过程中，磁盘产生的时间代价与功率代价取决于磁盘读取的数据块数量.从磁盘读取的数据与缓存在内存中的数据之和等于查询执行所需数据的总量.在查询执行过程中常见的I/O类型为：单数据块读(single read data block)、多数据块读(multiple read data block).当出现索引范围扫描、索引唯一扫描、索引完全扫描、ROWID访问表等操作时会出现单数据块读操作；当出现全表扫描和快速完全索引扫描时会出现多数据块读操作.以Oracle DBMS为例，其读取磁盘数据的最小I/O单位是数据块(data block).单数据块读是指一次I/O仅从磁盘读取单个数据块，并把它读入共享缓存(buffer cache)中.多数据块读是一次I/O操作读取系统规定数量的数据块.

将查询语句执行所需数据块的总量设为NAll，已缓存在内存中的数据块总量设为NMem，从磁盘访问的数据块总量设为NDisk.在执行查询语句的过程中，设磁盘产生单数据块读操作的总次数为NSingle，磁盘产生多数据块读操作的总次数为NMulti，一次多数据块读操作从磁盘读取数据块的数量为MBRC(multiple blocks read count)，由参数db_file_multiblock_read_count决定，则：

NAll=NMem+NDisk.

(4)

NDisk=NSingle+NMulti×MBRC.

(5)

设执行一次单数据块读操作的功率为PSingle，时间为TSingle，则磁盘IO类型为单块读时，磁盘的动态能耗为

EDisk_Single=NSingle(PSingle×TSingle).

(6)

设执行一次多数据块读操作的功率为PMulti，时间为TMulti，则磁盘IO类型为多块读时，磁盘的动态能耗为

EDisk_Multi=NMulti(PMulti×TMulti).

(7)

EDisk=NMulti(PMulti×TMulti)+
NSingle(PSingle×TSingle).

(8)

3) 内存代价.内存产生的时间代价和功率代价与内存读取的数据量大小密切相关.虽然记录最后一层cache的缺失次数可以对内存吞吐量进行轻量级评估[64].但为更加直观方便地评估与计算内存的动态能耗，模型将从内存读取的数据块总量作为反映内存资源消耗的参数.数据块总量可以从数据库系统中获取，且更加符合数据库的应用环境.内存和磁盘资源采用同一参数来衡量，也降低计算读取数据产生的能耗的复杂度.

设从缓存读取一个数据块到请求进程消耗的单位功率为PMem，单位时间为TMem，则内存的动态能耗为

EMemory=NAll(PMem×TMem).

(9)

由式(1)～(8)可得，执行查询语句产生的系统总功率为

P=C+NCPU×PCPU+NSingle×PSingle+
NMulti×PMulti+NAll×PMem，

(10)

其中，C为功率常数.

设查询执行的总时间为T，由式(1)～(9)可得，当查询语句的IO类型为单块读时系统总能耗为

E=C×T+NCPU(PCPU×TCPU)+

NSingle(PSingle×TSingle)+NAll(PMem×TMem).

(11)

E=C×T+NCPU(PCPU×TCPU)+
NMulti(PMulti×TMulti)+NAll(PMem×TMem).

(12)

E=C×T+NCPU(PCPU×TCPU)+NMulti(PMulti×
TMulti)+NSingle(PSingle×TSingle)+
NAll(PMem×TMem).

(13)

在式(10)～(13)中，利用与查询能耗关系最紧密的资源信息构建能耗模型，具体的参数说明如表1所示.

精确地获取统计数据是研究能耗相关问题的重要前提之一.查询计划包含的固定信息有消耗每种资源的统计量(即NCPU,NSingle,NMulti,NAll,NDisk,NMem)及响应时间[65].获取查询语句的执行计划有3种常用方式，分别是SQL_Trace、10046事件、10053事件.SQL_Trace和10046事件获取的计划是查询的实际执行计划，其中，SQL_Trace命令可以跟踪当前进程和其他用户进程中的查询运行情况，将查询执行的整个过程输出到一个trace文件；10046事件是SQL_Trace的扩展跟踪，用于获取更加详细的计划信息.而10053 事件可以获取查询优化器为一条语句生成的所有执行计划，便于了解执行计划的选择过程.

Table 1 Parameter Specification of Energy Prediction Model表1 能耗预测模型参数说明

3种方式的跟踪结果都会输出一个trace文件，且使用方法类似.首先，启动事件需要以DBA(database administrator)的身份登录获取相关权限.然后，在当前会话中激活事件，设置跟踪级别(由level参数指定)，设置事件的相关参数(timed_statistics：计时信息、max_dump_file_size：trace文件大小、user_dump_dest：文件的写入路径).最后，执行语句并关闭事件，性能统计数据会记录到指定目录下的跟踪文件oracle_sid_ora_pid.trc中.Oracle的TKPROF工具可用于规范化trace文件的格式，使文件更具有可读性，方便统计与分析.

时间常量(即TCPU,TSingle,TMulti,TMem)是系统统计数据的一部分，调用系统提供的dbms_stats包中的存储过程gather_system_stats来收集系统统计数据，获取时间常量的值.调用存储过程后即开始收集统计数据，设置interval参数值可以让数据库自动启动和停止收集过程.统计量和时间常量可以通过事件或包直接获取，功率常量需要利用训练集对模型进行求解得到.

3 查询计划评价模型

Fig. 3 Green query optimizer schematic图3 节能查询优化器原理图

为获取最优的查询计划，查询优化器需要尽可能多地创建和评估大量的候选计划.优化器通过给对象创建不同的访问方法(access method)、连接算法(join algorithm)以及连接顺序(join order)，为语句生成一组各不相同的计划[65-66].每个计划都是一个唯一的树状结构，在这个树状结构中，每个节点代表一个操作，并且每个节点下都有一个或多个子操作.操作由上向下调用，数据由底向顶返回.其中常见的访问方式有全表扫描(full table scan)、 索引范围扫描(index range scan)、 索引唯一扫描(index unique scan)等.常见的连接算法有nested loop join,sort merge join，Hash join.连接顺序的可能排列方式总量是访问对象数的阶乘.除了为语句生成计划，传统的查询优化器还需估算每个计划的代价，比较计划的代价，最终选择一个代价最小的计划去执行.

因此设计节能的查询优化器(如图3所示)是构建绿色数据库的关键.在能耗预测模型的基础上，评价模型能够感知查询计划的性能、功率及能耗.随着用户和服务供应商的多样化需求(如响应时间、节能、设备可靠性等)，评价模型需要将功率和能耗也当作优化目标，并考虑多个优化目标之间的相互关系，利用评价算法在多个目标之间进行权衡，辅助查询优化器进行计划选择.

图3描述了查询计划的评价过程：1)查询优化器接收到一条查询语句，生成一组查询计划{plan1,plan2,…,plann}；2)查询优化器内部的时间代价模型计算查询计划的响应时间，并由DBA设置一个可以接受的最低性能需求阈值，得到另一组查询计划{plan1,plan2,…,planm}(1≤m

C=αP+(1-α)T.

(14)

C代表计划的总成本，也是计划的优先级.模型的默认设置是总是选择C小的计划去执行，C越小优先级越高.P代表功率，T代表响应时间(性能).α是调节因子，通过改变α的值，可以调节P和T在总成本(C)中所占的权重，进而调节计划的成本，达到选择特定需求计划的目的.α的取值范围是[0,1].α的值由DBA设置，DBA根据数据库系统的当前运行状态调整优化目标，选择更加适应需求的计划.基于式(14)，针对任意一条查询，都可实现3个优化目标(性能、功率、能耗)：

1)α=1

查询优化器的优化目标是功率，评价模型倾向于选择功率小的计划.

2)α=0

查询优化器的优化目标是性能，评价模型倾向于选择性能好的计划(即传统查询优化器的优化目标).

查询优化器的优化目标是能耗，评价模型会权衡P和T，并选择能耗最小的计划.此时，优先级最高的计划其能耗也最小，且α值使性能与功率为最佳折中(best trade-off).

更细粒度地调节α的值可以获得性能与功率不同程度的折中，折中代表性能与功率之间的置换.基于本文的评价模型，当性能退化为原来的1n时，功率降低n(1-α)α(单位为W).但要谨慎选择α的极值，因为极值会导致性能或功率太差而给节能带来负面影响.

4 实验评价与比较

4.1 实验环境及数据采集

图4是实验部署示意图.如图4所示，需要建立能耗模型的服务器B事先设置采样事件收集自身的资源信息，并通过功率测量仪连接到电源上.服务器A上装有统计与分析能耗信息的功率监控软件，通过功率测量仪实时收集电流、电压和功率信息.服务器B的详细配置信息如表2所示.

Fig. 4 Experimental platform of energy sampling 图4 能耗测试平台示意图

Table 2 Description of Experimental Platform表2 总体实验环境描述

表2描述了服务器主要部件的静态功率(无负载运行时的功率)和峰值功率(部件满载时的功率)，为获取部件的峰值功率，实验使用Prime95，Stress-MyPC，Memtes等工具对服务器各组件(包括CPU、硬盘、内存)进行压力测试.在部件满载的情况下，循环不断地对硬件进行检测.每次检测稳定运行2 h，待温度及功率稳定后，读取功率测量仪中的数据.

实验使用TPC-C基准作为训练集获取能耗模型的参数，TPC-H基准作为测试集对能耗模型的有效性进行检验.TPC-H基准在生成训练数据时，通过调节比例因子(scale factor, SF)可以设定生成数据集的大小.TPC-C基准生成测试数据时，通过设定仓库数目(W)来确定数据集的规模.

4.2 能耗预测模型求解与验证

DBMS独占系统资源的情况下，执行训练集，收集统计数据.在MATLAB中，将数据带入多元线性回归模型中，采用最小二乘法求解回归系数，得到处理查询产生的系统总功率：

P=41.88+3.677×10-7×NCPU+
1.282×10-5×NMulti+2.482×10-4×
NSingle+6.74×10-6×NAll.

(15)

把求解出的回归系数带入式(13)得到系统总能耗：

E=41.88+3.15×10-12×NCPU+
1.00×10-7×NMulti+3.97×10-7×
NSingle+6.74×10-14×NAll.

(16)

判断模型是否精确的标准是相对偏差.将模型预测的相对偏差(prediction error rate, PER)定义为EPER，计算公式为

(17)

其中，Actualvalue代表测量的真实值,Predictionvalue代表模型的预测值，通过比较二者的相对偏差，可计算模型预测的精确度.

由2.1节可知，内存对查询能耗有重要影响.为进一步验证计算内存能耗对能耗预测模型精确度的影响，在2种场景下对测试集中的22条查询语句进行功率与能耗的预测(数据库大小为1 GB)：1)计算内存能耗；2)不计算内存能耗.为保证内存当中有一定数量的缓存数据，在执行测试集前运行了一系列面向商务应用且针对标准数据库的查询.实验结果如图5、图6所示：

Fig. 5 Comparison of power prediction under 2 different settings 图5 功率预测结果对比图

Fig. 6 Comparison of energy prediction under 2 different settings图6 能耗预测结果对比图

如图5、图6所示：当模型包含内存时，查询的功耗预测精度最高可提高2.81%，平均精度提高0.625%；能耗预测精度最高可提高3.37%，平均精度提高2.06%.内存本身不是一个能耗消费很高的部件，但将内存能耗构建在预测模型内仍然能够提高2.06%的精度.由此可得，构建存储相关的能耗模型需要将内存能耗构建在模型内提高预测精度.

在本文的实验环境下，将本文提出的能耗预测方法与已有的典型数据库查询能耗预测方法[28]进行预测精度对比.本文中的方法称为方法A，将文献[28]中的方法称为方法B.方法B采用CPU处理的元组数对CPU功率和能耗进行估算，利用磁盘读取的页面数对磁盘功率和能耗进行估算.实验结果如图7、图8所示：

Fig. 7 Comparison of power prediction of method A and B图7 方法A/B功率预测结果对比图

Fig. 8 Comparison of energy prediction of method A and B图8 方法A/B能耗预测结果对比图

由图7、图8可知，方法A对单条查询语句功率和能耗的预测更加接近真实值，平均预测正确率为95.68%.相对于方法B，方法A对功耗和能耗的预测准确度分别平均提高了5.63和5.92个百分点.对CPU的能耗进行估算时，选取CPU执行的指令总数而不是处理的元组总数；在估算读取数据产生的能耗时，区分数据来源并将内存的动态能耗构建在模型内，这二者对提高模型精确度都有较大的帮助.

由以上实验可知，本文提出的能耗模型对单个复杂查询的能耗能够进行较为精确的预测.为进一步探究模型对不同复杂度的查询的预测效果，基于测试集(数据库大小为10 GB)，设计了3个简单查询(Q1，Q2，Q3).Q1执行的操作是在对Orders范围扫描后进行等值查询；Q2中查询语句执行的操作是在对Supplier和PartSupp范围扫描后再对两表进行merge join；Q3中的查询语句执行的操作是对Customer进行基于索引的范围扫描.查询的真实能耗与预测能耗对比如图9所示：

Fig. 9 Comparison of predicted energy and actual energy of simple queries图9 简单查询的能耗预测值与真实值对比图

由图9可得，能耗模型对简单查询的能耗预测接近其真实值，误差在1.31%～4.98%之间且预测值总是小于真实值.误差产生的原因主要有4点：

1) 模型误差.即能耗模型本身的预测误差.

2) 主板等其他组件消耗能量.本文不讨论单独将这些组件的资源消耗作为能耗模型的参数，而是以常量(C)的形式构建在模型内.

3) 散热.本文未将节点服务器散热当作能耗模型的参数.虽然散热也消耗能量[67-69]，但是采集热量参数需要额外的硬件设备，且建立模型的方法和本文所陈述的方法有较大差异[1,63].

4) 系统的稳定性.能耗模型是在线下训练的，系统的运行状态相对稳定时能耗预测精度较高.但在真实的环境中无法预测查询执行时系统的动态变化，导致模型预测精度不稳定.这也要求我们在未来的工作中改进模型的动态自适应性，使之能自动捕获与分析系统当前的状态信息，动态调整模型的参数，进而提高模型的预测精度.

4.3 查询计划评价模型验证

实验使用Oracle提供的外部接口及Java程序模拟节能查询优化器的工作.通过10053事件获取查询的所有计划，将计划信息格式化作为Java程序的输入.能耗模型为每一条查询计划估算时间代价、功率代价及能耗代价.然后根据不同的优化目标，调节评价模型中α参数的值，选择满足特定需求的计划并反馈给DBA.DBA根据反馈回来的计划使用Hint改写查询语句.将DBA改写后的查询语句按照其优化目标分为3类，批量提交到Oracle中执行.最后比较不同α值下，相同负载的执行时间、功率、能耗，验证查询评价模型的有效性.

基于以上的实验步骤，产生100个测试用户，从同一个查询池中随机获取语句并同时提交到数据库，且在1 s内完成全部提交.总共有3组测试，每组测试都包含100个测试用户，分别采用3个不同的查询池(pool1,pool2,pool3).每个查询池中都包含22条查询语句，但是每个查询池中的查询语句都只针对一个优化目标做Hint改写,pool1中语句的优化目标是性能(α=0)，pool2是能耗(α值在折中点)，pool3是功率(α=1).

在1 GB,10 GB,30 GB的数据库大小下重复以上实验.实验结果如图10～12.在生成数据之前，为获得较好的数据库性能，在测试前需对数据库的参数配置进行适当的优化，优化内容如表3所示.

Fig. 11 Instant power cost of workload 2 under 10 GB size图11 3种不同优化目标下查询负载实时功率(10 GB)

Fig. 12 Instant power cost of workload 3 under 30 GB size图12 3种不同优化目标下查询负载实时功率(30 GB)

Table 3 Optimized System Parameters表3 系统性能配置参数优化

由图10～12可知，随着α值的增加，负载的功率逐渐降低.优化目标是性能时，评价模型会选择性能最佳的计划，此时负载的实时功率最大；当优化目标是功率时，评价模型会选择功率最小的计划，此时负载的实时功率是3种不同运行状态的最低值；当优化目标是能耗时，评价模型选择能耗最低的计划，此时负载的功率介于最大功率与最低功率之间.图10中出现负载实时功率突然下降的情况，是因为计算密集型(CPU-bound)的查询先于访问密集型(I/O-bound)的查询执行完.功率的突然下降，也说明CPU功率在负载总功率中占相当大的比例，是查询执行功率的重要组成部分[28,51].实验中的数据总结如表4所示.

表4中的时间为负载执行花费的总时间，功率为负载运行时的平均动态功率，能耗为平均动态功率与执行时间的积分；功率节约、能耗节约、性能退化分别代表功率、能耗、性能相对于α=0时降低的百分点.对数据库大小分别是1 GB,10 GB,30 GB的负载来说，当优化目标从性能变为功率时，可以观测到的功率节约分别是2.69 W,10.29 W,20.41 W；当优化目标由性能变为能耗时，可以观测到的能耗节约为5.87%,11.13%,11.34%.随着数据库数据由少到多，相同查询涉及的数据量增多，产生的功率及能耗也增大，说明数据库的规模对查询的能耗有重要影响.本文提出的查询评价模型，虽然在功率和能耗上取得了较好的优化效果，但在性能上有不同程度的退化.性能的退化，正说明评价模型的关键是调节α的值，以达到性能与功率不同程度的折中，降低能耗.表4中的性能退化度只是相对于最佳性能而言，此外性能的退化可以通过将磁盘替换为更高效的基于闪存的存储设备来缓解[14,38].文献[21]指出，如果适当的延迟不会引起性能满意程度的下降，服务等级协议(service level agreement, SLA)允许查询运行得更慢，以降低能耗.因为SLA是针对峰值需求来进行设定的，而真正到达峰值负载的概率很低，服务器大部分时间都处在低利用率下，SLA这一灵活的设置提供了创建绿色数据库的契机[70].

为进一步研究3种不同的优化目标下查询计划的代价变化并深入解析节能原因，对测试集中22条查询语句进行测试与分析.实验结果如图13所示.

Table 4 Experimental Results of Query Evaluation Model Verification表4 查询评价模型实验结果汇总

Fig. 13 Comparison of plan costs under 3 different optimization goals图13 3种不同优化目标下查询计划的代价比较

如图13所示，在22条查询语句中第2，5，11，12，16，21条查询的功率节约程度小.分析原因是：1)这些节能潜力较差的查询是一些相对简单的查询，涉及大量的表扫描(即I/O密集型查询)或表关联操作只涉及2～3个表.查询优化器为简单查询构建的查询计划的数量有限，计划的选择空间较小.2)能耗模型本身的预测误差，无论α取何值，评价模型都会选择同一个计划或代价相近的计划.此外，功率节约程度较大的查询大多是CPU密集型查询.因此，在不违反SLA的情况下选择CPU利用率低的查询计划能更好地挖掘数据库的节能潜力.

当优化目标为能耗时，除语句2，5，11，12，16，21外，其他查询的功率节约程度都较大，但其预测的能耗节约(图13(e))与真实的能耗节约(图13(f))都较小.比较图13(c)与图13(d)可知，虽然功率节约程度大，但响应时间的增长导致最终的能耗节约程度远比功率节约程度小.响应时间的增长不可控是导致真实节能效果低于预测节能效果的主要原因.由图13(e)与图13(f)可知，对于语句11，17，18,20，当优化目标为功率时(α=1)查询的能耗比传统优化目标(α=0)更高，原因也是响应时间的增长.综上：在查询优化时，选取α的极值会导致响应时间的过度增长，进而给能耗节约带来负面影响；在能耗优化时，建议选取适当的α值，在节能的同时保障性能.

5 总结与展望

能源消耗已经成为数据库系统设计及实现过程中的重要优化目标.为解决数据库系统的高能耗问题，越来越多的研究工作投入到设计与实现绿色数据库系统中.本文根据负载的资源消耗模式，以查询负载为主要建模对象，构建了一个较精确且可移植的能耗模型.解析查询优化的关键步骤，为查询优化器的计划选择构建简单且有效的评价模型.实验设计基于TPC-H基准测试，实验结果表明模型能够有效降低系统能耗.

在未来的工作中，我们将继续对本文提出的模型进行改进.下一步工作主要集中在3个方面：

1) 进一步研究在动态环境下(非数据库系统独占服务器资源)，如何提高模型的健壮性并将模型扩展到分布式的环境下；

2) 在进行查询能耗预测时如何减小模型误差是将来研究的一个方向；

3) 构建集群版本的SQL能耗模型使之能够自动捕获系统的动态信息，周期性地更新模型参数，以适应服务器环境的动态变化也是将来研究的一个方向.