面向關(guān)系數(shù)據(jù)庫查詢的能耗建模及計劃評價

國冰磊 于 炯 楊德先 廖 彬

(新疆大學(xué)信息科學(xué)與工程學(xué)院 烏魯木齊 830008)

大規(guī)模數(shù)據(jù)中心在全球范圍內(nèi)的廣泛部署使高能耗、高費(fèi)用、高污染等問題日益突出[1].2014年數(shù)據(jù)中心能效現(xiàn)狀白皮書報道，2013年世界數(shù)據(jù)中心能耗總量為8102.5×108kW·h，同年我國數(shù)據(jù)中心耗電量達(dá)772.1×108kW·h，同比增長16.2%.其中IT設(shè)備和軟件的能耗占數(shù)據(jù)中心整體能耗的45.4%.數(shù)據(jù)中心的能耗逐年攀升，不僅給企業(yè)帶來沉重的經(jīng)濟(jì)負(fù)擔(dān)，產(chǎn)生的全球性碳排放也帶來一系列的社會及環(huán)境問題，促使世界各地的政府部門要求IT企業(yè)提高數(shù)據(jù)中心的能耗效率[2-4].根據(jù)著名研究機(jī)構(gòu)Gartner[5]報道，IT領(lǐng)域目前的CO2排放量占全球總排放量的2%，并保持著高達(dá)11%的年增長率[6],到2020年這一比例將翻一番.

在2008年全球最頂級的數(shù)據(jù)庫研究會議(Senior Database Researcher Meeting)上，研究人員共同提出“研究與設(shè)計低能耗但不犧牲可擴(kuò)展性的節(jié)能DBMS”是未來數(shù)據(jù)庫領(lǐng)域的研究熱點(diǎn)[7].降低數(shù)據(jù)庫的能源消耗對提高數(shù)據(jù)中心整體的能耗效率具有推動作用.數(shù)據(jù)庫系統(tǒng)的能耗管理問題也成為近期數(shù)據(jù)庫領(lǐng)域頂級期刊和會議的討論熱點(diǎn)[8-29].傳統(tǒng)數(shù)據(jù)庫以高性能為主要設(shè)計目標(biāo)，而綠色數(shù)據(jù)庫系統(tǒng)則是要保障系統(tǒng)性能，同時降低能耗[30].關(guān)系數(shù)據(jù)庫在大數(shù)據(jù)時代仍然占據(jù)著重要地位，所以關(guān)注關(guān)系數(shù)據(jù)庫系統(tǒng)的能耗問題、研究面向可持續(xù)發(fā)展的綠色數(shù)據(jù)庫系統(tǒng)，具有重要的應(yīng)用價值和社會意義[20,30-32].

已有研究[13,21,28]指出，在關(guān)系數(shù)據(jù)庫中，存在大量被查詢優(yōu)化器忽略的節(jié)能查詢計劃.因?yàn)閿?shù)據(jù)庫在設(shè)計之初缺少能耗方面的考慮，查詢優(yōu)化器會選擇執(zhí)行時間最短、忽視性能可以接受而且更加節(jié)能的計劃.對一條語句而言，其不同查詢計劃之間的響應(yīng)時間、執(zhí)行功率及能耗等指標(biāo)也各不相同.本文構(gòu)建查詢計劃的能耗預(yù)測模型，在語句執(zhí)行前預(yù)測查詢計劃的能耗，利用評價模型使查詢優(yōu)化器選擇節(jié)能的計劃，降低查詢的能量消耗，實(shí)現(xiàn)提高數(shù)據(jù)庫整體能耗效率的目標(biāo).Oracle數(shù)據(jù)庫是目前市場占有比率最大的關(guān)系型數(shù)據(jù)庫，所以選取Oracle數(shù)據(jù)庫為主要對象研究查詢能耗預(yù)測與計劃評價的相關(guān)問題.

1 相關(guān)研究

已有的數(shù)據(jù)庫節(jié)能工作可從硬件和軟件2個方面進(jìn)行分類，下文將挑選一些具有代表性的工作進(jìn)行詳細(xì)探討.

1.1 基于硬件的節(jié)能方法

基于硬件的節(jié)能方法主要有2種思路：1)關(guān)閉空閑設(shè)備[33]；2)用低能耗高效率的設(shè)備替換高能耗低效率的設(shè)備[27,34-39].Meza等人[33]將數(shù)據(jù)庫重新配置到更少的磁盤上并關(guān)閉空閑的磁盤，只犧牲5%的峰值性能可降低45%的功率.閃存以及固態(tài)硬盤相比傳統(tǒng)機(jī)械磁盤具有耗電少、無機(jī)械延遲等特點(diǎn).許多研究者都提出應(yīng)該在綠色數(shù)據(jù)庫系統(tǒng)中考慮閃存的使用[38-41]，并對比了磁盤和閃存的能耗有效性.隨著硬件技術(shù)的發(fā)展，基于硬件的節(jié)能方法利用現(xiàn)代硬件的新特性，在不影響服務(wù)級目標(biāo)的前提下，盡可能地將服務(wù)器從高能耗的狀態(tài)轉(zhuǎn)換到低能耗的狀態(tài).動態(tài)電壓頻率調(diào)整(dynamic voltage and frequency scaling, DVFS)[10,40-43]是常用的CPU功率調(diào)節(jié)技術(shù)，通過動態(tài)調(diào)節(jié)CPU時鐘頻率和供電電壓調(diào)整CPU功率，進(jìn)而降低其能耗.基于硬件的節(jié)能方法不需要復(fù)雜的能耗管理組件且效果顯著.然而簡單地替換不能充分發(fā)揮硬件的特性，對已經(jīng)部署的大型應(yīng)用系統(tǒng)批量的硬件替換也會造成成本過高等問題[40,43].

1.2 基于軟件的節(jié)能方法

基于軟件的節(jié)能方法主要是構(gòu)建數(shù)據(jù)庫常用查詢的能耗預(yù)測模型，進(jìn)而實(shí)現(xiàn)預(yù)測整個數(shù)據(jù)庫系統(tǒng)能耗的目的[18].根據(jù)模型的粒度，可將現(xiàn)有的能耗預(yù)測模型分為運(yùn)算符級的能耗模型與語句級的能耗模型.

運(yùn)算符級的模型將查詢計劃分解為一個或多個運(yùn)算符，如全表掃描(table scan)、索引掃描(index scan)、排序(sort)等.Xu等人[13,22]利用運(yùn)算符的共同資源消耗特征，定義每個元組(CPU處理的普通元組數(shù)或索引元組數(shù))和每頁的能耗常量(讀取的磁盤頁面數(shù))，為每個運(yùn)算符構(gòu)建功耗模型，最終形成整個查詢計劃的功耗模型.基于此，文獻(xiàn)[26,28]利用PostgreSQL查詢優(yōu)化器中的性能代價估算模型，將CPU與磁盤作為主要的能耗組件，構(gòu)建動態(tài)的運(yùn)算符級別的能耗模型.Liu等人[44]基于文獻(xiàn)[13]利用CPU檢索的列數(shù)與元組數(shù)的乘積，為查詢負(fù)載構(gòu)建功耗模型.刑寶平[45]利用數(shù)據(jù)庫應(yīng)用層信息和操作系統(tǒng)層信息，建立了基于回歸分析方法的運(yùn)算符級別的功耗模型.

語句級的能耗模型忽略查詢計劃的內(nèi)部細(xì)節(jié)，并不深入研究每個運(yùn)算符的資源消耗特征，而是將查詢或查詢負(fù)載看作一個整體.Rodriguez-Martinez等人[46]通過提取選擇查詢的共同特征(元組數(shù)、列數(shù)、平均元組長度、謂詞的選擇率(selectivity factor)等)在集群環(huán)境下構(gòu)建了峰值功耗預(yù)測模型.楊良懷等人[47]從執(zhí)行核粒度考察CPU執(zhí)行頻率及利用率對系統(tǒng)功耗的綜合影響，采用線性回歸方法擬合CPU各個核的利用率、執(zhí)行頻率、磁盤利用率來預(yù)測整個系統(tǒng)的功耗.金培權(quán)等人[48-49]采用軟硬件集成的方式，設(shè)計出一個用于測試綠色數(shù)據(jù)庫系統(tǒng)能耗有效性的工具DBPower.楊濮源等人[50]以TPC-H為基準(zhǔn)，設(shè)計了一個用于測試移動智能終端數(shù)據(jù)庫查詢能耗的工具TPCDroid.我們已有的工作[51-53]提出一種基于查詢資源消耗最小單位的數(shù)據(jù)庫動態(tài)能耗模型.Sarda等人[54]提出一種基于查詢計劃回收利用的工具PLATIC(plan selection through incre-mental clustering)，幫助查詢優(yōu)化器攤銷優(yōu)化代價，從而降低優(yōu)化時間加速查詢執(zhí)行.Harizopoulos等人[9]提出QED機(jī)制(improved query energy-efficiency by introducing explicit delays)，引入顯示延遲和設(shè)置閾值，對查詢進(jìn)行聚類并將查詢的公共部分放入隊列統(tǒng)一處理.文獻(xiàn)[29]通過僅處理一次公共子表達(dá)式并將其執(zhí)行結(jié)果共享給其他查詢，達(dá)到降低執(zhí)行總時間進(jìn)而節(jié)能的效果.

現(xiàn)有的數(shù)據(jù)庫能耗建模方法[12-13,22,26,28,44-45]直接使用了PostgreSQL數(shù)據(jù)庫中的時間代價公式，雖然通過數(shù)學(xué)方法重新確定了公式中的系數(shù)，但是能耗預(yù)測值的精度有待提高[30].本文與現(xiàn)有工作不同之處有3點(diǎn)：

1) 已有研究通過定義CPU檢索元組的能耗常量為CPU預(yù)測功率[12-13,21-22,26,28,44-46].本文綜合考慮CPU在查詢執(zhí)行過程中的作用，選取能更好反映CPU工作量的指令數(shù)[55-59]，通過定義CPU執(zhí)行指令的能耗常量為CPU預(yù)測能耗.

2) 現(xiàn)有研究[12-13,21-22,26,28,44-50]在構(gòu)建查詢能耗預(yù)測模型時，只考慮CPU和磁盤的動態(tài)能耗，沒有考慮內(nèi)存的動態(tài)能耗.本文分析并驗(yàn)證了緩存在內(nèi)存中的數(shù)據(jù)對查詢能耗及能耗預(yù)測精度的影響，并將內(nèi)存的動態(tài)能耗構(gòu)建在模型內(nèi)，提高模型的預(yù)測精度.

3) 已有的工作[26-28,46-47]大多集中在構(gòu)建能耗預(yù)測模型，使數(shù)據(jù)庫系統(tǒng)能夠感知能耗，很少關(guān)注具體如何利用能耗模型進(jìn)一步實(shí)現(xiàn)節(jié)能.本文在解析查詢處理與查詢優(yōu)化機(jī)制的基礎(chǔ)上，構(gòu)建適應(yīng)綠色數(shù)據(jù)庫系統(tǒng)的查詢計劃評價模型.模型改進(jìn)了查詢優(yōu)化器在選擇計劃時忽略能耗因素的缺陷，將功率和能耗也作為優(yōu)化目標(biāo)，實(shí)現(xiàn)為數(shù)據(jù)庫系統(tǒng)節(jié)能的目的.

2 能耗預(yù)測模型

在不考慮性能的情況下，構(gòu)建節(jié)能數(shù)據(jù)庫是沒有意義的.根據(jù)經(jīng)典能耗公式(式(1))，可以得出2種降低數(shù)據(jù)庫能耗的方法：1)提高查詢的速度，減少其響應(yīng)時間，即傳統(tǒng)數(shù)據(jù)庫的優(yōu)化目標(biāo)；2)降低查詢的執(zhí)行功率.

E=P×T，

(1)

其中，E，P，T分別為能耗、功率、響應(yīng)時間。本文專注于第2種方法，同時保證性能退化度在可接受的范圍內(nèi).

傳統(tǒng)基于存儲的能耗模型[60]未將內(nèi)存能耗構(gòu)建在模型內(nèi).本文不僅在2.1節(jié)中驗(yàn)證了內(nèi)存對查詢功率及能耗的影響，而且將內(nèi)存能耗加入能耗預(yù)測模型.

2.1 內(nèi)存對查詢能耗的影響

查詢語句的處理過程主要包括3個階段：解析(parse)、執(zhí)行(execute)、提取數(shù)據(jù)(fetch).3個階段都需要利用緩存在cache結(jié)構(gòu)中的數(shù)據(jù)來減少I/O或CPU資源的消耗.已有研究[61]指出在查詢執(zhí)行的過程中內(nèi)存同樣是服務(wù)器中重要的能耗部件，所以在構(gòu)建查詢能耗模型時，為提高查詢能耗預(yù)測的精度，需將內(nèi)存的動態(tài)能耗構(gòu)建在能耗預(yù)測模型內(nèi).

為研究緩存在內(nèi)存中的數(shù)據(jù)對查詢功率及能耗的影響，分別在2種不同的設(shè)置下對20條查詢語句進(jìn)行測試，收集能耗相關(guān)數(shù)據(jù).實(shí)驗(yàn)結(jié)果如圖1、圖2所示.2種設(shè)置分別是：1)緩存數(shù)據(jù)可用；2)緩存數(shù)據(jù)不可用，需要從磁盤再次讀入內(nèi)存并由CPU重新計算得到.

Fig. 1 Power of queries under 2 different settings圖1 查詢語句的功率

Fig. 2 Energy of queries under 2 different settings圖2 查詢語句的能耗

由圖1、圖2可知，無緩存執(zhí)行場景下的功率、能耗總是大于有緩存的場景.查詢的總功率在2種情況下的平均差異為2.56%，最高可達(dá)5.94%；總能耗的平均差異為30.07%，最高可達(dá)195.09%.有緩存時更節(jié)能的原因是緩存在buffer cache和shared pool中的數(shù)據(jù)可以被查詢重復(fù)使用，加快查詢的執(zhí)行，節(jié)省查詢執(zhí)行過程中的資源消耗.說明緩存在內(nèi)存中的數(shù)據(jù)是否可用，是影響查詢執(zhí)行能耗的重要因素.

執(zhí)行查詢所需的數(shù)據(jù)的量是固定的[62]，一般情況下，這些數(shù)據(jù)都是從磁盤中讀取.如果內(nèi)存中存在緩存數(shù)據(jù)，應(yīng)區(qū)分?jǐn)?shù)據(jù)來源(內(nèi)存或磁盤)，將數(shù)據(jù)獲取過程中產(chǎn)生的能耗進(jìn)行分類(內(nèi)存能耗或磁盤能耗).

2.2 系統(tǒng)各組件能耗建模

對數(shù)據(jù)庫而言，查詢語句的執(zhí)行代價是由其使用相關(guān)資源產(chǎn)生的代價線性累加而成[28,63]：CPU、磁盤I/O、內(nèi)存和網(wǎng)絡(luò)資源(針對分布式數(shù)據(jù)庫系統(tǒng)).資源的消耗會產(chǎn)生2種基礎(chǔ)代價：時間代價和功率代價，而查詢的能耗代價則是時間代價與功率代價的積分.網(wǎng)絡(luò)相關(guān)的能耗模型主要針對交換設(shè)備，其能耗模型和節(jié)能方法與節(jié)點(diǎn)服務(wù)器有較大不同[60].本文是在多組同配置單節(jié)點(diǎn)服務(wù)器下進(jìn)行實(shí)驗(yàn)，所以暫時未考慮網(wǎng)絡(luò)資源的能耗.

1) CPU代價.在執(zhí)行查詢語句時，對數(shù)據(jù)處理過程中執(zhí)行的每一步操作都會依據(jù)處理量與處理方式的不同請求CPU執(zhí)行一定數(shù)量的指令.已有研究[12-13,21-22,26,44-46]大多基于CPU處理的元組總數(shù)對CPU代價進(jìn)行估算.但是CPU除負(fù)責(zé)檢索元組外，還需檢索和計算與查詢執(zhí)行相關(guān)的其他重要信息(如解析查詢語句、構(gòu)建查詢樹、計算查詢代價、選擇最優(yōu)的查詢計劃、檢索數(shù)據(jù)字典等)，這些操作都需要消耗CPU指令.不同于元組總數(shù)，CPU指令總數(shù)量能更真實(shí)地反應(yīng)CPU的工作量.本文通過定義CPU執(zhí)行指令的能耗常量來估算CPU的能耗.

將查詢語句執(zhí)行過程中消耗的CPU指令總數(shù)量設(shè)為CPU總指令數(shù)(NCPU)，為方便計算，CPU指令數(shù)以萬為計量單位.對于不同型號的CPU，其處理指令的能力存在較大的差異，指令處理能力是指CPU的指令功率能力(NCPU_watt，即每瓦特完成指令數(shù)).設(shè)執(zhí)行每萬條CPU指令的功率為PCPU，時間為TCPU，則CPU的動態(tài)能耗ECPU為

ECPU=NCPU(PCPU×TCPU),

(2)

PCPU=10000NCPU_watt.

(3)

2) 磁盤代價.在查詢執(zhí)行過程中，磁盤產(chǎn)生的時間代價與功率代價取決于磁盤讀取的數(shù)據(jù)塊數(shù)量.從磁盤讀取的數(shù)據(jù)與緩存在內(nèi)存中的數(shù)據(jù)之和等于查詢執(zhí)行所需數(shù)據(jù)的總量.在查詢執(zhí)行過程中常見的I/O類型為：單數(shù)據(jù)塊讀(single read data block)、多數(shù)據(jù)塊讀(multiple read data block).當(dāng)出現(xiàn)索引范圍掃描、索引唯一掃描、索引完全掃描、ROWID訪問表等操作時會出現(xiàn)單數(shù)據(jù)塊讀操作；當(dāng)出現(xiàn)全表掃描和快速完全索引掃描時會出現(xiàn)多數(shù)據(jù)塊讀操作.以O(shè)racle DBMS為例，其讀取磁盤數(shù)據(jù)的最小I/O單位是數(shù)據(jù)塊(data block).單數(shù)據(jù)塊讀是指一次I/O僅從磁盤讀取單個數(shù)據(jù)塊，并把它讀入共享緩存(buffer cache)中.多數(shù)據(jù)塊讀是一次I/O操作讀取系統(tǒng)規(guī)定數(shù)量的數(shù)據(jù)塊.

將查詢語句執(zhí)行所需數(shù)據(jù)塊的總量設(shè)為NAll，已緩存在內(nèi)存中的數(shù)據(jù)塊總量設(shè)為NMem，從磁盤訪問的數(shù)據(jù)塊總量設(shè)為NDisk.在執(zhí)行查詢語句的過程中，設(shè)磁盤產(chǎn)生單數(shù)據(jù)塊讀操作的總次數(shù)為NSingle，磁盤產(chǎn)生多數(shù)據(jù)塊讀操作的總次數(shù)為NMulti，一次多數(shù)據(jù)塊讀操作從磁盤讀取數(shù)據(jù)塊的數(shù)量為MBRC(multiple blocks read count)，由參數(shù)db_file_multiblock_read_count決定，則：

NAll=NMem+NDisk.

(4)

NDisk=NSingle+NMulti×MBRC.

(5)

設(shè)執(zhí)行一次單數(shù)據(jù)塊讀操作的功率為PSingle，時間為TSingle，則磁盤IO類型為單塊讀時，磁盤的動態(tài)能耗為

EDisk_Single=NSingle(PSingle×TSingle).

(6)

設(shè)執(zhí)行一次多數(shù)據(jù)塊讀操作的功率為PMulti，時間為TMulti，則磁盤IO類型為多塊讀時，磁盤的動態(tài)能耗為

EDisk_Multi=NMulti(PMulti×TMulti).

(7)

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

(8)

3) 內(nèi)存代價.內(nèi)存產(chǎn)生的時間代價和功率代價與內(nèi)存讀取的數(shù)據(jù)量大小密切相關(guān).雖然記錄最后一層cache的缺失次數(shù)可以對內(nèi)存吞吐量進(jìn)行輕量級評估[64].但為更加直觀方便地評估與計算內(nèi)存的動態(tài)能耗，模型將從內(nèi)存讀取的數(shù)據(jù)塊總量作為反映內(nèi)存資源消耗的參數(shù).數(shù)據(jù)塊總量可以從數(shù)據(jù)庫系統(tǒng)中獲取，且更加符合數(shù)據(jù)庫的應(yīng)用環(huán)境.內(nèi)存和磁盤資源采用同一參數(shù)來衡量，也降低計算讀取數(shù)據(jù)產(chǎn)生的能耗的復(fù)雜度.

設(shè)從緩存讀取一個數(shù)據(jù)塊到請求進(jìn)程消耗的單位功率為PMem，單位時間為TMem，則內(nèi)存的動態(tài)能耗為

EMemory=NAll(PMem×TMem).

(9)

由式(1)～(8)可得，執(zhí)行查詢語句產(chǎn)生的系統(tǒng)總功率為

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

(10)

其中，C為功率常數(shù).

設(shè)查詢執(zhí)行的總時間為T，由式(1)～(9)可得，當(dāng)查詢語句的IO類型為單塊讀時系統(tǒng)總能耗為

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)中，利用與查詢能耗關(guān)系最緊密的資源信息構(gòu)建能耗模型，具體的參數(shù)說明如表1所示.

精確地獲取統(tǒng)計數(shù)據(jù)是研究能耗相關(guān)問題的重要前提之一.查詢計劃包含的固定信息有消耗每種資源的統(tǒng)計量(即NCPU,NSingle,NMulti,NAll,NDisk,NMem)及響應(yīng)時間[65].獲取查詢語句的執(zhí)行計劃有3種常用方式，分別是SQL_Trace、10046事件、10053事件.SQL_Trace和10046事件獲取的計劃是查詢的實(shí)際執(zhí)行計劃，其中，SQL_Trace命令可以跟蹤當(dāng)前進(jìn)程和其他用戶進(jìn)程中的查詢運(yùn)行情況，將查詢執(zhí)行的整個過程輸出到一個trace文件；10046事件是SQL_Trace的擴(kuò)展跟蹤，用于獲取更加詳細(xì)的計劃信息.而10053 事件可以獲取查詢優(yōu)化器為一條語句生成的所有執(zhí)行計劃，便于了解執(zhí)行計劃的選擇過程.

Table 1 Parameter Specification of Energy Prediction Model表1 能耗預(yù)測模型參數(shù)說明

3種方式的跟蹤結(jié)果都會輸出一個trace文件，且使用方法類似.首先，啟動事件需要以DBA(database administrator)的身份登錄獲取相關(guān)權(quán)限.然后，在當(dāng)前會話中激活事件，設(shè)置跟蹤級別(由level參數(shù)指定)，設(shè)置事件的相關(guān)參數(shù)(timed_statistics：計時信息、max_dump_file_size：trace文件大小、user_dump_dest：文件的寫入路徑).最后，執(zhí)行語句并關(guān)閉事件，性能統(tǒng)計數(shù)據(jù)會記錄到指定目錄下的跟蹤文件oracle_sid_ora_pid.trc中.Oracle的TKPROF工具可用于規(guī)范化trace文件的格式，使文件更具有可讀性，方便統(tǒng)計與分析.

時間常量(即TCPU,TSingle,TMulti,TMem)是系統(tǒng)統(tǒng)計數(shù)據(jù)的一部分，調(diào)用系統(tǒng)提供的dbms_stats包中的存儲過程gather_system_stats來收集系統(tǒng)統(tǒng)計數(shù)據(jù)，獲取時間常量的值.調(diào)用存儲過程后即開始收集統(tǒng)計數(shù)據(jù)，設(shè)置interval參數(shù)值可以讓數(shù)據(jù)庫自動啟動和停止收集過程.統(tǒng)計量和時間常量可以通過事件或包直接獲取，功率常量需要利用訓(xùn)練集對模型進(jìn)行求解得到.

3 查詢計劃評價模型

Fig. 3 Green query optimizer schematic圖3 節(jié)能查詢優(yōu)化器原理圖

為獲取最優(yōu)的查詢計劃，查詢優(yōu)化器需要盡可能多地創(chuàng)建和評估大量的候選計劃.優(yōu)化器通過給對象創(chuàng)建不同的訪問方法(access method)、連接算法(join algorithm)以及連接順序(join order)，為語句生成一組各不相同的計劃[65-66].每個計劃都是一個唯一的樹狀結(jié)構(gòu)，在這個樹狀結(jié)構(gòu)中，每個節(jié)點(diǎn)代表一個操作，并且每個節(jié)點(diǎn)下都有一個或多個子操作.操作由上向下調(diào)用，數(shù)據(jù)由底向頂返回.其中常見的訪問方式有全表掃描(full table scan)、 索引范圍掃描(index range scan)、 索引唯一掃描(index unique scan)等.常見的連接算法有nested loop join,sort merge join，Hash join.連接順序的可能排列方式總量是訪問對象數(shù)的階乘.除了為語句生成計劃，傳統(tǒng)的查詢優(yōu)化器還需估算每個計劃的代價，比較計劃的代價，最終選擇一個代價最小的計劃去執(zhí)行.

因此設(shè)計節(jié)能的查詢優(yōu)化器(如圖3所示)是構(gòu)建綠色數(shù)據(jù)庫的關(guān)鍵.在能耗預(yù)測模型的基礎(chǔ)上，評價模型能夠感知查詢計劃的性能、功率及能耗.隨著用戶和服務(wù)供應(yīng)商的多樣化需求(如響應(yīng)時間、節(jié)能、設(shè)備可靠性等)，評價模型需要將功率和能耗也當(dāng)作優(yōu)化目標(biāo)，并考慮多個優(yōu)化目標(biāo)之間的相互關(guān)系，利用評價算法在多個目標(biāo)之間進(jìn)行權(quán)衡，輔助查詢優(yōu)化器進(jìn)行計劃選擇.

圖3描述了查詢計劃的評價過程：1)查詢優(yōu)化器接收到一條查詢語句，生成一組查詢計劃{plan1,plan2,…,plann}；2)查詢優(yōu)化器內(nèi)部的時間代價模型計算查詢計劃的響應(yīng)時間，并由DBA設(shè)置一個可以接受的最低性能需求閾值，得到另一組查詢計劃{plan1,plan2,…,planm}(1≤m

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

(14)

C代表計劃的總成本，也是計劃的優(yōu)先級.模型的默認(rèn)設(shè)置是總是選擇C小的計劃去執(zhí)行，C越小優(yōu)先級越高.P代表功率，T代表響應(yīng)時間(性能).α是調(diào)節(jié)因子，通過改變α的值，可以調(diào)節(jié)P和T在總成本(C)中所占的權(quán)重，進(jìn)而調(diào)節(jié)計劃的成本，達(dá)到選擇特定需求計劃的目的.α的取值范圍是[0,1].α的值由DBA設(shè)置，DBA根據(jù)數(shù)據(jù)庫系統(tǒng)的當(dāng)前運(yùn)行狀態(tài)調(diào)整優(yōu)化目標(biāo)，選擇更加適應(yīng)需求的計劃.基于式(14)，針對任意一條查詢，都可實(shí)現(xiàn)3個優(yōu)化目標(biāo)(性能、功率、能耗)：

1)α=1

查詢優(yōu)化器的優(yōu)化目標(biāo)是功率，評價模型傾向于選擇功率小的計劃.

2)α=0

查詢優(yōu)化器的優(yōu)化目標(biāo)是性能，評價模型傾向于選擇性能好的計劃(即傳統(tǒng)查詢優(yōu)化器的優(yōu)化目標(biāo)).

查詢優(yōu)化器的優(yōu)化目標(biāo)是能耗，評價模型會權(quán)衡P和T，并選擇能耗最小的計劃.此時，優(yōu)先級最高的計劃其能耗也最小，且α值使性能與功率為最佳折中(best trade-off).

更細(xì)粒度地調(diào)節(jié)α的值可以獲得性能與功率不同程度的折中，折中代表性能與功率之間的置換.基于本文的評價模型，當(dāng)性能退化為原來的1n時，功率降低n(1-α)α(單位為W).但要謹(jǐn)慎選擇α的極值，因?yàn)闃O值會導(dǎo)致性能或功率太差而給節(jié)能帶來負(fù)面影響.

4 實(shí)驗(yàn)評價與比較

4.1 實(shí)驗(yàn)環(huán)境及數(shù)據(jù)采集

圖4是實(shí)驗(yàn)部署示意圖.如圖4所示，需要建立能耗模型的服務(wù)器B事先設(shè)置采樣事件收集自身的資源信息，并通過功率測量儀連接到電源上.服務(wù)器A上裝有統(tǒng)計與分析能耗信息的功率監(jiān)控軟件，通過功率測量儀實(shí)時收集電流、電壓和功率信息.服務(wù)器B的詳細(xì)配置信息如表2所示.

Fig. 4 Experimental platform of energy sampling 圖4 能耗測試平臺示意圖

Table 2 Description of Experimental Platform表2 總體實(shí)驗(yàn)環(huán)境描述

表2描述了服務(wù)器主要部件的靜態(tài)功率(無負(fù)載運(yùn)行時的功率)和峰值功率(部件滿載時的功率)，為獲取部件的峰值功率，實(shí)驗(yàn)使用Prime95，Stress-MyPC，Memtes等工具對服務(wù)器各組件(包括CPU、硬盤、內(nèi)存)進(jìn)行壓力測試.在部件滿載的情況下，循環(huán)不斷地對硬件進(jìn)行檢測.每次檢測穩(wěn)定運(yùn)行2 h，待溫度及功率穩(wěn)定后，讀取功率測量儀中的數(shù)據(jù).

實(shí)驗(yàn)使用TPC-C基準(zhǔn)作為訓(xùn)練集獲取能耗模型的參數(shù)，TPC-H基準(zhǔn)作為測試集對能耗模型的有效性進(jìn)行檢驗(yàn).TPC-H基準(zhǔn)在生成訓(xùn)練數(shù)據(jù)時，通過調(diào)節(jié)比例因子(scale factor, SF)可以設(shè)定生成數(shù)據(jù)集的大小.TPC-C基準(zhǔn)生成測試數(shù)據(jù)時，通過設(shè)定倉庫數(shù)目(W)來確定數(shù)據(jù)集的規(guī)模.

4.2 能耗預(yù)測模型求解與驗(yàn)證

DBMS獨(dú)占系統(tǒng)資源的情況下，執(zhí)行訓(xùn)練集，收集統(tǒng)計數(shù)據(jù).在MATLAB中，將數(shù)據(jù)帶入多元線性回歸模型中，采用最小二乘法求解回歸系數(shù)，得到處理查詢產(chǎn)生的系統(tǒng)總功率：

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

(15)

把求解出的回歸系數(shù)帶入式(13)得到系統(tǒng)總能耗：

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

(16)

判斷模型是否精確的標(biāo)準(zhǔn)是相對偏差.將模型預(yù)測的相對偏差(prediction error rate, PER)定義為EPER，計算公式為

(17)

其中，Actualvalue代表測量的真實(shí)值,Predictionvalue代表模型的預(yù)測值，通過比較二者的相對偏差，可計算模型預(yù)測的精確度.

由2.1節(jié)可知，內(nèi)存對查詢能耗有重要影響.為進(jìn)一步驗(yàn)證計算內(nèi)存能耗對能耗預(yù)測模型精確度的影響，在2種場景下對測試集中的22條查詢語句進(jìn)行功率與能耗的預(yù)測(數(shù)據(jù)庫大小為1 GB)：1)計算內(nèi)存能耗；2)不計算內(nèi)存能耗.為保證內(nèi)存當(dāng)中有一定數(shù)量的緩存數(shù)據(jù)，在執(zhí)行測試集前運(yùn)行了一系列面向商務(wù)應(yīng)用且針對標(biāo)準(zhǔn)數(shù)據(jù)庫的查詢.實(shí)驗(yàn)結(jié)果如圖5、圖6所示：

Fig. 5 Comparison of power prediction under 2 different settings 圖5 功率預(yù)測結(jié)果對比圖

Fig. 6 Comparison of energy prediction under 2 different settings圖6 能耗預(yù)測結(jié)果對比圖

如圖5、圖6所示：當(dāng)模型包含內(nèi)存時，查詢的功耗預(yù)測精度最高可提高2.81%，平均精度提高0.625%；能耗預(yù)測精度最高可提高3.37%，平均精度提高2.06%.內(nèi)存本身不是一個能耗消費(fèi)很高的部件，但將內(nèi)存能耗構(gòu)建在預(yù)測模型內(nèi)仍然能夠提高2.06%的精度.由此可得，構(gòu)建存儲相關(guān)的能耗模型需要將內(nèi)存能耗構(gòu)建在模型內(nèi)提高預(yù)測精度.

在本文的實(shí)驗(yàn)環(huán)境下，將本文提出的能耗預(yù)測方法與已有的典型數(shù)據(jù)庫查詢能耗預(yù)測方法[28]進(jìn)行預(yù)測精度對比.本文中的方法稱為方法A，將文獻(xiàn)[28]中的方法稱為方法B.方法B采用CPU處理的元組數(shù)對CPU功率和能耗進(jìn)行估算，利用磁盤讀取的頁面數(shù)對磁盤功率和能耗進(jìn)行估算.實(shí)驗(yàn)結(jié)果如圖7、圖8所示：

Fig. 7 Comparison of power prediction of method A and B圖7 方法A/B功率預(yù)測結(jié)果對比圖

Fig. 8 Comparison of energy prediction of method A and B圖8 方法A/B能耗預(yù)測結(jié)果對比圖

由圖7、圖8可知，方法A對單條查詢語句功率和能耗的預(yù)測更加接近真實(shí)值，平均預(yù)測正確率為95.68%.相對于方法B，方法A對功耗和能耗的預(yù)測準(zhǔn)確度分別平均提高了5.63和5.92個百分點(diǎn).對CPU的能耗進(jìn)行估算時，選取CPU執(zhí)行的指令總數(shù)而不是處理的元組總數(shù)；在估算讀取數(shù)據(jù)產(chǎn)生的能耗時，區(qū)分?jǐn)?shù)據(jù)來源并將內(nèi)存的動態(tài)能耗構(gòu)建在模型內(nèi)，這二者對提高模型精確度都有較大的幫助.

由以上實(shí)驗(yàn)可知，本文提出的能耗模型對單個復(fù)雜查詢的能耗能夠進(jìn)行較為精確的預(yù)測.為進(jìn)一步探究模型對不同復(fù)雜度的查詢的預(yù)測效果，基于測試集(數(shù)據(jù)庫大小為10 GB)，設(shè)計了3個簡單查詢(Q1，Q2，Q3).Q1執(zhí)行的操作是在對Orders范圍掃描后進(jìn)行等值查詢；Q2中查詢語句執(zhí)行的操作是在對Supplier和PartSupp范圍掃描后再對兩表進(jìn)行merge join；Q3中的查詢語句執(zhí)行的操作是對Customer進(jìn)行基于索引的范圍掃描.查詢的真實(shí)能耗與預(yù)測能耗對比如圖9所示：

Fig. 9 Comparison of predicted energy and actual energy of simple queries圖9 簡單查詢的能耗預(yù)測值與真實(shí)值對比圖

由圖9可得，能耗模型對簡單查詢的能耗預(yù)測接近其真實(shí)值，誤差在1.31%～4.98%之間且預(yù)測值總是小于真實(shí)值.誤差產(chǎn)生的原因主要有4點(diǎn)：

1) 模型誤差.即能耗模型本身的預(yù)測誤差.

2) 主板等其他組件消耗能量.本文不討論單獨(dú)將這些組件的資源消耗作為能耗模型的參數(shù)，而是以常量(C)的形式構(gòu)建在模型內(nèi).

3) 散熱.本文未將節(jié)點(diǎn)服務(wù)器散熱當(dāng)作能耗模型的參數(shù).雖然散熱也消耗能量[67-69]，但是采集熱量參數(shù)需要額外的硬件設(shè)備，且建立模型的方法和本文所陳述的方法有較大差異[1,63].

4) 系統(tǒng)的穩(wěn)定性.能耗模型是在線下訓(xùn)練的，系統(tǒng)的運(yùn)行狀態(tài)相對穩(wěn)定時能耗預(yù)測精度較高.但在真實(shí)的環(huán)境中無法預(yù)測查詢執(zhí)行時系統(tǒng)的動態(tài)變化，導(dǎo)致模型預(yù)測精度不穩(wěn)定.這也要求我們在未來的工作中改進(jìn)模型的動態(tài)自適應(yīng)性，使之能自動捕獲與分析系統(tǒng)當(dāng)前的狀態(tài)信息，動態(tài)調(diào)整模型的參數(shù)，進(jìn)而提高模型的預(yù)測精度.

4.3 查詢計劃評價模型驗(yàn)證

實(shí)驗(yàn)使用Oracle提供的外部接口及Java程序模擬節(jié)能查詢優(yōu)化器的工作.通過10053事件獲取查詢的所有計劃，將計劃信息格式化作為Java程序的輸入.能耗模型為每一條查詢計劃估算時間代價、功率代價及能耗代價.然后根據(jù)不同的優(yōu)化目標(biāo)，調(diào)節(jié)評價模型中α參數(shù)的值，選擇滿足特定需求的計劃并反饋給DBA.DBA根據(jù)反饋回來的計劃使用Hint改寫查詢語句.將DBA改寫后的查詢語句按照其優(yōu)化目標(biāo)分為3類，批量提交到Oracle中執(zhí)行.最后比較不同α值下，相同負(fù)載的執(zhí)行時間、功率、能耗，驗(yàn)證查詢評價模型的有效性.

基于以上的實(shí)驗(yàn)步驟，產(chǎn)生100個測試用戶，從同一個查詢池中隨機(jī)獲取語句并同時提交到數(shù)據(jù)庫，且在1 s內(nèi)完成全部提交.總共有3組測試，每組測試都包含100個測試用戶，分別采用3個不同的查詢池(pool1,pool2,pool3).每個查詢池中都包含22條查詢語句，但是每個查詢池中的查詢語句都只針對一個優(yōu)化目標(biāo)做Hint改寫,pool1中語句的優(yōu)化目標(biāo)是性能(α=0)，pool2是能耗(α值在折中點(diǎn))，pool3是功率(α=1).

在1 GB,10 GB,30 GB的數(shù)據(jù)庫大小下重復(fù)以上實(shí)驗(yàn).實(shí)驗(yàn)結(jié)果如圖10～12.在生成數(shù)據(jù)之前，為獲得較好的數(shù)據(jù)庫性能，在測試前需對數(shù)據(jù)庫的參數(shù)配置進(jìn)行適當(dāng)?shù)膬?yōu)化，優(yōu)化內(nèi)容如表3所示.

Fig. 11 Instant power cost of workload 2 under 10 GB size圖11 3種不同優(yōu)化目標(biāo)下查詢負(fù)載實(shí)時功率(10 GB)

Fig. 12 Instant power cost of workload 3 under 30 GB size圖12 3種不同優(yōu)化目標(biāo)下查詢負(fù)載實(shí)時功率(30 GB)

Table 3 Optimized System Parameters表3 系統(tǒng)性能配置參數(shù)優(yōu)化

由圖10～12可知，隨著α值的增加，負(fù)載的功率逐漸降低.優(yōu)化目標(biāo)是性能時，評價模型會選擇性能最佳的計劃，此時負(fù)載的實(shí)時功率最大；當(dāng)優(yōu)化目標(biāo)是功率時，評價模型會選擇功率最小的計劃，此時負(fù)載的實(shí)時功率是3種不同運(yùn)行狀態(tài)的最低值；當(dāng)優(yōu)化目標(biāo)是能耗時，評價模型選擇能耗最低的計劃，此時負(fù)載的功率介于最大功率與最低功率之間.圖10中出現(xiàn)負(fù)載實(shí)時功率突然下降的情況，是因?yàn)橛嬎忝芗?CPU-bound)的查詢先于訪問密集型(I/O-bound)的查詢執(zhí)行完.功率的突然下降，也說明CPU功率在負(fù)載總功率中占相當(dāng)大的比例，是查詢執(zhí)行功率的重要組成部分[28,51].實(shí)驗(yàn)中的數(shù)據(jù)總結(jié)如表4所示.

表4中的時間為負(fù)載執(zhí)行花費(fèi)的總時間，功率為負(fù)載運(yùn)行時的平均動態(tài)功率，能耗為平均動態(tài)功率與執(zhí)行時間的積分；功率節(jié)約、能耗節(jié)約、性能退化分別代表功率、能耗、性能相對于α=0時降低的百分點(diǎn).對數(shù)據(jù)庫大小分別是1 GB,10 GB,30 GB的負(fù)載來說，當(dāng)優(yōu)化目標(biāo)從性能變?yōu)楣β蕰r，可以觀測到的功率節(jié)約分別是2.69 W,10.29 W,20.41 W；當(dāng)優(yōu)化目標(biāo)由性能變?yōu)槟芎臅r，可以觀測到的能耗節(jié)約為5.87%,11.13%,11.34%.隨著數(shù)據(jù)庫數(shù)據(jù)由少到多，相同查詢涉及的數(shù)據(jù)量增多，產(chǎn)生的功率及能耗也增大，說明數(shù)據(jù)庫的規(guī)模對查詢的能耗有重要影響.本文提出的查詢評價模型，雖然在功率和能耗上取得了較好的優(yōu)化效果，但在性能上有不同程度的退化.性能的退化，正說明評價模型的關(guān)鍵是調(diào)節(jié)α的值，以達(dá)到性能與功率不同程度的折中，降低能耗.表4中的性能退化度只是相對于最佳性能而言，此外性能的退化可以通過將磁盤替換為更高效的基于閃存的存儲設(shè)備來緩解[14,38].文獻(xiàn)[21]指出，如果適當(dāng)?shù)难舆t不會引起性能滿意程度的下降，服務(wù)等級協(xié)議(service level agreement, SLA)允許查詢運(yùn)行得更慢，以降低能耗.因?yàn)镾LA是針對峰值需求來進(jìn)行設(shè)定的，而真正到達(dá)峰值負(fù)載的概率很低，服務(wù)器大部分時間都處在低利用率下，SLA這一靈活的設(shè)置提供了創(chuàng)建綠色數(shù)據(jù)庫的契機(jī)[70].

為進(jìn)一步研究3種不同的優(yōu)化目標(biāo)下查詢計劃的代價變化并深入解析節(jié)能原因，對測試集中22條查詢語句進(jìn)行測試與分析.實(shí)驗(yàn)結(jié)果如圖13所示.

Table 4 Experimental Results of Query Evaluation Model Verification表4 查詢評價模型實(shí)驗(yàn)結(jié)果匯總

Fig. 13 Comparison of plan costs under 3 different optimization goals圖13 3種不同優(yōu)化目標(biāo)下查詢計劃的代價比較

如圖13所示，在22條查詢語句中第2，5，11，12，16，21條查詢的功率節(jié)約程度小.分析原因是：1)這些節(jié)能潛力較差的查詢是一些相對簡單的查詢，涉及大量的表掃描(即I/O密集型查詢)或表關(guān)聯(lián)操作只涉及2～3個表.查詢優(yōu)化器為簡單查詢構(gòu)建的查詢計劃的數(shù)量有限，計劃的選擇空間較小.2)能耗模型本身的預(yù)測誤差，無論α取何值，評價模型都會選擇同一個計劃或代價相近的計劃.此外，功率節(jié)約程度較大的查詢大多是CPU密集型查詢.因此，在不違反SLA的情況下選擇CPU利用率低的查詢計劃能更好地挖掘數(shù)據(jù)庫的節(jié)能潛力.

當(dāng)優(yōu)化目標(biāo)為能耗時，除語句2，5，11，12，16，21外，其他查詢的功率節(jié)約程度都較大，但其預(yù)測的能耗節(jié)約(圖13(e))與真實(shí)的能耗節(jié)約(圖13(f))都較小.比較圖13(c)與圖13(d)可知，雖然功率節(jié)約程度大，但響應(yīng)時間的增長導(dǎo)致最終的能耗節(jié)約程度遠(yuǎn)比功率節(jié)約程度小.響應(yīng)時間的增長不可控是導(dǎo)致真實(shí)節(jié)能效果低于預(yù)測節(jié)能效果的主要原因.由圖13(e)與圖13(f)可知，對于語句11，17，18,20，當(dāng)優(yōu)化目標(biāo)為功率時(α=1)查詢的能耗比傳統(tǒng)優(yōu)化目標(biāo)(α=0)更高，原因也是響應(yīng)時間的增長.綜上：在查詢優(yōu)化時，選取α的極值會導(dǎo)致響應(yīng)時間的過度增長，進(jìn)而給能耗節(jié)約帶來負(fù)面影響；在能耗優(yōu)化時，建議選取適當(dāng)?shù)摩林?，在?jié)能的同時保障性能.

5 總結(jié)與展望

能源消耗已經(jīng)成為數(shù)據(jù)庫系統(tǒng)設(shè)計及實(shí)現(xiàn)過程中的重要優(yōu)化目標(biāo).為解決數(shù)據(jù)庫系統(tǒng)的高能耗問題，越來越多的研究工作投入到設(shè)計與實(shí)現(xiàn)綠色數(shù)據(jù)庫系統(tǒng)中.本文根據(jù)負(fù)載的資源消耗模式，以查詢負(fù)載為主要建模對象，構(gòu)建了一個較精確且可移植的能耗模型.解析查詢優(yōu)化的關(guān)鍵步驟，為查詢優(yōu)化器的計劃選擇構(gòu)建簡單且有效的評價模型.實(shí)驗(yàn)設(shè)計基于TPC-H基準(zhǔn)測試，實(shí)驗(yàn)結(jié)果表明模型能夠有效降低系統(tǒng)能耗.

在未來的工作中，我們將繼續(xù)對本文提出的模型進(jìn)行改進(jìn).下一步工作主要集中在3個方面：

1) 進(jìn)一步研究在動態(tài)環(huán)境下(非數(shù)據(jù)庫系統(tǒng)獨(dú)占服務(wù)器資源)，如何提高模型的健壯性并將模型擴(kuò)展到分布式的環(huán)境下；

2) 在進(jìn)行查詢能耗預(yù)測時如何減小模型誤差是將來研究的一個方向；

3) 構(gòu)建集群版本的SQL能耗模型使之能夠自動捕獲系統(tǒng)的動態(tài)信息，周期性地更新模型參數(shù)，以適應(yīng)服務(wù)器環(huán)境的動態(tài)變化也是將來研究的一個方向.