基于機(jī)器學(xué)習(xí)的數(shù)據(jù)庫(kù)系統(tǒng)自動(dòng)調(diào)參研究

陳 鐳

（1.南京審計(jì)大學(xué) 信息工程學(xué)院，江蘇 南京 211815；2.南京大學(xué)計(jì)算機(jī)軟件新技術(shù)國(guó)家重點(diǎn)實(shí)驗(yàn)室，江蘇南京 210023）

0 引言

數(shù)據(jù)庫(kù)管理系統(tǒng)（Database Management System，DBMS）在管理大量數(shù)據(jù)和處理復(fù)雜工作的同時(shí)，自身也有成百上千個(gè)參數(shù)（Mysql 有幾百個(gè)，Oracle 則有上千個(gè)）需要配置，如緩存大小和讀寫(xiě)磁盤(pán)頻率等。DBMS 的性能很大程度上依賴于這些參數(shù)的合理設(shè)置，但應(yīng)用程序不能簡(jiǎn)單地復(fù)用先前配置，最佳配置往往取決于其工作負(fù)載和底層硬件。配置參數(shù)大多不是獨(dú)立的，其間存在復(fù)雜的隱式關(guān)系，更改一個(gè)參數(shù)可能會(huì)影響另一個(gè)參數(shù)的最佳設(shè)置，如何找到最優(yōu)參數(shù)配置是一個(gè)非確定性多項(xiàng)式（NP-hard）問(wèn)題。因此，數(shù)據(jù)庫(kù)管理人員往往需要花費(fèi)大量時(shí)間根據(jù)自身經(jīng)驗(yàn)調(diào)優(yōu)數(shù)據(jù)庫(kù)參數(shù)。隨著數(shù)據(jù)庫(kù)規(guī)模與復(fù)雜性的不斷增長(zhǎng)，以及工作負(fù)載的頻繁變化，數(shù)據(jù)庫(kù)管理人員的優(yōu)化工作量已經(jīng)超出其承受能力。

為解決上述問(wèn)題，利用機(jī)器學(xué)習(xí)技術(shù)改進(jìn)數(shù)據(jù)庫(kù)系統(tǒng)性能成為工業(yè)界和學(xué)術(shù)界的研究熱點(diǎn)。在工業(yè)界，Oracle公司于2017 年發(fā)布了無(wú)人駕駛數(shù)據(jù)庫(kù)，可以根據(jù)負(fù)載自動(dòng)調(diào)優(yōu)并合理分配資源；阿里云于2018 年啟動(dòng)數(shù)據(jù)庫(kù)智能參數(shù)優(yōu)化的探索［1］，目前已經(jīng)在阿里集團(tuán)10 000 個(gè)實(shí)例上實(shí)現(xiàn)了規(guī)模化落地，累計(jì)節(jié)省12%的內(nèi)存資源；華為于2019年發(fā)布了首款人工智能原生（AI-Native）數(shù)據(jù)庫(kù)，首次將深度學(xué)習(xí)融入分布式數(shù)據(jù)庫(kù)的全生命周期。在學(xué)術(shù)界，卡耐基梅隆大學(xué)數(shù)據(jù)庫(kù)研究組開(kāi)發(fā)的OtterTune 系統(tǒng)［2］維護(hù)了一個(gè)調(diào)優(yōu)歷史數(shù)據(jù)庫(kù)，可利用這些數(shù)據(jù)構(gòu)建監(jiān)督和無(wú)監(jiān)督的機(jī)器學(xué)習(xí)模型組合，進(jìn)而使用這些模型映射工作負(fù)載、推薦最優(yōu)參數(shù)等，使DBMS 調(diào)優(yōu)過(guò)程完全自動(dòng)化；Zhang等［3］利用基于策略的深度強(qiáng)化學(xué)習(xí)方法提出一種端到端的云數(shù)據(jù)庫(kù)調(diào)參系統(tǒng)CDBTune，首先從用戶處采集工作負(fù)載，然后內(nèi)置模型，根據(jù)當(dāng)前工作負(fù)載狀態(tài)推薦參數(shù)，并在線下數(shù)據(jù)庫(kù)中執(zhí)行負(fù)載，記錄當(dāng)前狀態(tài)和性能用于訓(xùn)練離線模型，同時(shí)對(duì)在線模型進(jìn)行相應(yīng)調(diào)整。此外，還有大量基于機(jī)器學(xué)習(xí)的數(shù)據(jù)庫(kù)系統(tǒng)綜述研究［4-9］。基于此，本文首先詳細(xì)介紹數(shù)據(jù)庫(kù)自動(dòng)調(diào)參系統(tǒng)的結(jié)構(gòu)和工作原理，然后對(duì)機(jī)器學(xué)習(xí)模型的應(yīng)用場(chǎng)景進(jìn)行分析，最后基于Otter?Tune 系統(tǒng)設(shè)計(jì)實(shí)驗(yàn)，對(duì)PostgreSQL 關(guān)系數(shù)據(jù)庫(kù)進(jìn)行自動(dòng)化參數(shù)調(diào)優(yōu)實(shí)驗(yàn)。

1 數(shù)據(jù)庫(kù)自動(dòng)調(diào)參系統(tǒng)介紹

數(shù)據(jù)庫(kù)自動(dòng)調(diào)參系統(tǒng)通常包含客戶端和服務(wù)端兩個(gè)部分?？蛻舳税惭b在DBMS 所在機(jī)器上，負(fù)責(zé)收集DBMS的統(tǒng)計(jì)信息，并上傳至服務(wù)端。服務(wù)端一般配置在云服務(wù)器上，負(fù)責(zé)訓(xùn)練機(jī)器學(xué)習(xí)模型并推薦參數(shù)文件，客戶端接收到推薦的參數(shù)文件后將其配置到目標(biāo)DBMS 上，評(píng)測(cè)其性能，直到用戶對(duì)推薦的參數(shù)滿意為止。

1.1 客戶端

客戶端通常由控制程序和驅(qū)動(dòng)程序組成。控制程序通過(guò)訪問(wèn)目標(biāo)數(shù)據(jù)庫(kù)收集DBMS 的各種配置參數(shù)和度量（吞吐率、響應(yīng)時(shí)間等）數(shù)據(jù)；驅(qū)動(dòng)程序則負(fù)責(zé)實(shí)現(xiàn)客戶端的所有控制流，主要與服務(wù)端進(jìn)行交互。

客戶端組件工作流程如圖1 所示，具體為：

（1）驅(qū)動(dòng)程序首先清除緩存并重啟DBMS，檢查磁盤(pán)使用量是否過(guò)多，確?？刂瞥绦蚩梢允占瘮?shù)據(jù)。

（2）工作負(fù)載生成，驅(qū)動(dòng)程序啟動(dòng)工作負(fù)載，并作為后臺(tái)作業(yè)運(yùn)行。當(dāng)準(zhǔn)備開(kāi)始測(cè)量時(shí)，驅(qū)動(dòng)程序向控制程序發(fā)送一個(gè)信號(hào)，并等待基準(zhǔn)完成。

（3）在測(cè)量前，控制程序首先收集旋鈕和度量數(shù)據(jù)。

（4）完成工作負(fù)載測(cè)量后，驅(qū)動(dòng)程序向控制程序發(fā)送終止信號(hào)，控制程序再次收集數(shù)據(jù)?？刂瞥绦?qū)⑺惺占降臄?shù)據(jù)以及元數(shù)據(jù)摘要（數(shù)據(jù)庫(kù)名稱和版本、觀察長(zhǎng)度、開(kāi)始/結(jié)束時(shí)間、工作負(fù)載名稱）發(fā)送回驅(qū)動(dòng)程序。

（5）驅(qū)動(dòng)程序?qū)⒖刂瞥绦蚴占降乃蠨BMS 數(shù)據(jù)上載至服務(wù)器，并定期檢查服務(wù)器是否已完成推薦的新配置。

（6）如果服務(wù)端已成功生成下一個(gè)配置，驅(qū)動(dòng)程序?qū)姆?wù)端查詢新配置并將其安裝至目標(biāo)DBMS。

Fig.1 Client side workflow圖1 客戶端工作流程

1.2 服務(wù)端

服務(wù)端通常由調(diào)優(yōu)管理和作業(yè)調(diào)度兩部分組成。調(diào)優(yōu)管理負(fù)責(zé)處理和存儲(chǔ)調(diào)優(yōu)數(shù)據(jù)，并可視化每個(gè)調(diào)優(yōu)會(huì)話的結(jié)果；作業(yè)調(diào)度負(fù)責(zé)計(jì)算機(jī)器學(xué)習(xí)模型并提出配置建議。

如圖2 所示，當(dāng)調(diào)優(yōu)管理從控制器接收到目標(biāo)DBMS的數(shù)據(jù)后，首先將這些信息存儲(chǔ)在數(shù)據(jù)存儲(chǔ)庫(kù)中，然后在前端可視化結(jié)果。作業(yè)調(diào)度負(fù)責(zé)調(diào)度任務(wù)，以便在機(jī)器學(xué)習(xí)管道中重新計(jì)算模型，將新的數(shù)據(jù)合并到機(jī)器學(xué)習(xí)模型中，計(jì)算DBMS 要嘗試的下一個(gè)配置。任務(wù)完成后，調(diào)優(yōu)管理將任務(wù)狀態(tài)返回給客戶端，客戶端根據(jù)鏈接下載下一個(gè)推薦配置。

Fig.2 Server side workflow圖2 服務(wù)端工作流程

2 自動(dòng)調(diào)優(yōu)方法框架

從調(diào)優(yōu)會(huì)話中收集到的數(shù)據(jù)需要使用機(jī)器學(xué)習(xí)模型進(jìn)行處理，如圖2 中的作業(yè)調(diào)度模塊所示，數(shù)據(jù)應(yīng)用場(chǎng)景為工作負(fù)載特征化、特征選擇與自動(dòng)調(diào)優(yōu)算法。

2.1 工作負(fù)載特征化

通常使用DBMS 內(nèi)部運(yùn)行時(shí)的度量數(shù)據(jù)描述工作負(fù)載行為，因?yàn)樗鼈儾东@了數(shù)據(jù)庫(kù)運(yùn)行時(shí)方方面面的信息，能夠提供工作負(fù)載的準(zhǔn)確表示。然而，不同DBMS 提供的度量具有不同的名稱和粒度，有些度量是重復(fù)的，有些度量高度相關(guān)。修剪冗余度量能夠減少機(jī)器學(xué)習(xí)算法的搜索空間，降低機(jī)器學(xué)習(xí)模型的復(fù)雜性，加速整個(gè)調(diào)優(yōu)過(guò)程。因此，有必要使用因子分析方法將高維度量指標(biāo)轉(zhuǎn)換為低維數(shù)據(jù)，然后通過(guò)聚類算法從每個(gè)集群中選擇一個(gè)具有代表性的度量，即最靠近集群中心的度量，組成機(jī)器學(xué)習(xí)模型訓(xùn)練需要的特征向量。

2.2 特征選擇

DBMS 有數(shù)百個(gè)配置參數(shù)，需要找到最能影響其性能的配置參數(shù)。使用特征選擇技術(shù)（例如lasso）對(duì)配置參數(shù)的重要性進(jìn)行排序，可確定哪些配置參數(shù)對(duì)系統(tǒng)整體性能的影響最大。在提出配置建議時(shí)，還需決定使用多少個(gè)配置參數(shù)。使用過(guò)多參數(shù)會(huì)顯著增加優(yōu)化時(shí)間，過(guò)少則會(huì)妨礙找到最佳配置。為自動(dòng)完成該流程，推薦使用遞增的方法，即逐漸增加調(diào)優(yōu)會(huì)話中配置參數(shù)的數(shù)量。

2.3 自動(dòng)調(diào)優(yōu)算法

自動(dòng)調(diào)優(yōu)算法需要識(shí)別先前調(diào)優(yōu)會(huì)話中與當(dāng)前工作最為相似的負(fù)載。首先確保所有度量標(biāo)準(zhǔn)具有相同的數(shù)量級(jí)，然后計(jì)算當(dāng)前工作負(fù)載與存儲(chǔ)庫(kù)中歷史工作負(fù)載的差異（如歐式距離），差異值越小表示越相似。

典型的自動(dòng)調(diào)優(yōu)方法包括：①OtterTune 系統(tǒng)采用高斯過(guò)程回歸（Gaussian Process Regression，GPR）為工作負(fù)載推薦合適的參數(shù)，該模型可以預(yù)測(cè)DBMS 在每種配置參數(shù)下的性能，在推薦過(guò)程中，需要平衡探索（獲得新知識(shí)）和利用（根據(jù)現(xiàn)有知識(shí)進(jìn)行決策），否則可能會(huì)陷入局部最優(yōu)而無(wú)法達(dá)到全局最優(yōu)；②CDBTune 系統(tǒng)使用深度強(qiáng)化學(xué)習(xí)算法將數(shù)據(jù)庫(kù)的調(diào)參過(guò)程刻畫(huà)成強(qiáng)化學(xué)習(xí)問(wèn)題，狀態(tài)即參數(shù)文件，動(dòng)作即調(diào)整某個(gè)參數(shù)的值，而反饋則是當(dāng)前參數(shù)下數(shù)據(jù)庫(kù)的性能。其利用深度確定性策略梯度（Deep Deter?ministic Policy Gradient，DDPG）算法，最終達(dá)到了與Otter?Tune 系統(tǒng)近似的調(diào)優(yōu)效果。

3 數(shù)據(jù)庫(kù)自動(dòng)調(diào)優(yōu)實(shí)驗(yàn)

采用卡耐基梅隆大學(xué)數(shù)據(jù)庫(kù)研究組開(kāi)發(fā)的OtterTune系統(tǒng)對(duì)PostgreSQL 關(guān)系數(shù)據(jù)庫(kù)進(jìn)行自動(dòng)化參數(shù)調(diào)優(yōu)實(shí)驗(yàn)。

3.1 實(shí)驗(yàn)環(huán)境

主機(jī)硬件配置：Intel（R）Core（TM）i5-8500U CPU@3.00GHz 處理器，16GB DDR4 內(nèi)存，240GB SSD 硬盤(pán)。Otter?Tune 分為服務(wù)端和客戶端兩部分：服務(wù)端包含Mysql 數(shù)據(jù)庫(kù)（用于存儲(chǔ)所有網(wǎng)站數(shù)據(jù)、調(diào)優(yōu)數(shù)據(jù)，供機(jī)器學(xué)習(xí)模型使用），Django（前端網(wǎng)站）；客戶端包含目標(biāo)DBMS（存儲(chǔ)用戶的業(yè)務(wù)數(shù)據(jù)，支持多種DBMS），Controller（用于控制目標(biāo)DBMS），Driver（用于調(diào)用Controller，入口文件為fabfile.py）。

軟件環(huán)境搭建步驟為［10-13］：

（1）準(zhǔn)備兩臺(tái)Ubuntu18.04 的虛擬機(jī)，配置均為4 核心CPU，4GB 內(nèi)存，40G 硬盤(pán)。一臺(tái)用作服務(wù)端，另一臺(tái)用作客戶端。

（2）配置好網(wǎng)絡(luò)連接。

（3）服務(wù)端、客戶端分別下載最新版OtterTune，按照官方配置安裝好必要的軟件包。

（4）OtterTune 需要Python3.6 版本以上配置，而Ubun?tu18.04 系統(tǒng)安裝的是Python2.7 和Python3.6，默認(rèn)使用Py?thon2.7，因此需要通過(guò)ln-s 軟連接命令，修改系統(tǒng)默認(rèn)使用Python3.6。

3.2 服務(wù)端配置

S1：安裝Mysql，新建名為ottertune 的數(shù)據(jù)庫(kù)。

S2：編輯配置文件，修改credentials.py 文件，并更新數(shù)據(jù)庫(kù)名稱、用戶名和密碼等信息，設(shè)置DEBUG=True。

S3：配置Django 網(wǎng)站后端，將需要的表放進(jìn)MySQL 的ottertune 數(shù)據(jù)庫(kù)內(nèi)。創(chuàng)建Django 網(wǎng)站的超級(jí)用戶，在MySQL 的ottertune 數(shù)據(jù)庫(kù)中建立數(shù)據(jù)表。值得注意的是，website_knobcatalog 和website_metriccatalog 兩個(gè)表中存儲(chǔ)了待觀測(cè)的信息。

S4：?jiǎn)?dòng)Celery（用于調(diào)度機(jī)器學(xué)習(xí)任務(wù)）和Django Server，完成后通過(guò)瀏覽器打開(kāi)http：//127.0.0.1：8000，在其中建立一個(gè)tuning session，并記下upload_code，使用celery beat 啟動(dòng)周期任務(wù)。

3.3 客戶端配置

C1：安裝PostgreSQL9.6（作為目標(biāo)DBMS），安裝成功后會(huì)自動(dòng)添加一個(gè)名為postgres 的系統(tǒng)用戶，密碼隨機(jī)，然后在postgres 用戶中新建名為tpcc 的數(shù)據(jù)庫(kù)，供oltpbench 用。

C2：下載最新版OltpBench Repo（數(shù)據(jù)庫(kù)測(cè)試框架），同樣存儲(chǔ)在用戶根目錄下。編輯tpcc_config_postgres.xml，配置oltpbench（用于周期性地在目標(biāo)DBMS 上運(yùn)行bench?mark）。

C3：配置Controller、Driver，編輯sample_postgres_config.json，driver_config.py，填入目標(biāo)DBMS 類型、用戶名、密碼、oltpbench 路徑、配置文件等信息。對(duì)于save_path 這一項(xiàng)，要事先建立好對(duì)應(yīng)的文件夾；對(duì)于upload_code 這一項(xiàng)，要與S4 中分配的upload_code 一致。

C4：加載初始化oltpbench 數(shù)據(jù)到目標(biāo)DBMS（Post?greSQL）中。

C5：編譯Controller，執(zhí)行g(shù)radle build。

C6：在完成上述步驟后，開(kāi)始運(yùn)行循環(huán)程序。在每個(gè)循環(huán)中收集目標(biāo)DBMS 信息，上傳至服務(wù)端，獲取新的推薦配置，安裝配置并重啟DBMS，直到用戶對(duì)推薦的配置滿意為止。在驅(qū)動(dòng)程序文件otertune/client/driver/fabfile.py 中定義loop 函數(shù)，fab loop：i=1 表示運(yùn)行一個(gè)單循環(huán)，fab run_loops：max_iter=10 表示運(yùn)行10 次循環(huán)，可通過(guò)修改命令中的數(shù)字更改迭代次數(shù)。

3.4 實(shí)驗(yàn)效果

實(shí)驗(yàn)環(huán)境配置完成后，通過(guò)瀏覽器打開(kāi)網(wǎng)站主頁(yè)，使用S3 步驟設(shè)置的超級(jí)用戶賬戶進(jìn)行登錄。登錄成功后首先需要?jiǎng)?chuàng)建一個(gè)新的project，然后在項(xiàng)目中創(chuàng)建session。

實(shí)驗(yàn)過(guò)程按照“3.2”和“3.3”小節(jié)中S1、S2、C1、C2、C3、C4、C5、S3、S4、C6 的順序執(zhí)行即可。實(shí)驗(yàn)結(jié)果如圖3 所示，可以看出session 的參數(shù)以及工作負(fù)載情況。在剛開(kāi)始運(yùn)行時(shí)，數(shù)據(jù)比較少，機(jī)器學(xué)習(xí)模型缺乏足夠的訓(xùn)練數(shù)據(jù)，Ot?terTune 傾向于探索而非利用，生成的配置參數(shù)可能是隨機(jī)的，因此系統(tǒng)的吞吐率較低，為個(gè)位數(shù)。但當(dāng)服務(wù)端配置到云上，有多個(gè)客戶端訪問(wèn)時(shí)，OtterTune 會(huì)將所有用戶嘗試的參數(shù)文件和對(duì)應(yīng)的性能數(shù)據(jù)存儲(chǔ)起來(lái)進(jìn)行利用。這意味著用戶越多，使用的時(shí)間越長(zhǎng)，收集的訓(xùn)練數(shù)據(jù)越多，推薦效果就會(huì)越好。從圖3 中可以看出，經(jīng)過(guò)10 輪周期的調(diào)整，OtterTune 生成的最佳配置使得系統(tǒng)的吞吐率顯著提高，達(dá)到了百位數(shù)級(jí)別，幾乎與數(shù)據(jù)庫(kù)管理人員的經(jīng)驗(yàn)配置一樣好。

Fig.3 Operation effect of parameter adjustment experiment圖3 調(diào)參實(shí)驗(yàn)運(yùn)行效果

4 結(jié)語(yǔ)

本文詳細(xì)介紹并采用實(shí)驗(yàn)驗(yàn)證了基于機(jī)器學(xué)習(xí)的數(shù)據(jù)庫(kù)自動(dòng)調(diào)參系統(tǒng)的原理與運(yùn)行機(jī)制，取得了較佳的配置效果。對(duì)于數(shù)據(jù)庫(kù)領(lǐng)域來(lái)說(shuō)，很多配置工作可嘗試與機(jī)器學(xué)習(xí)結(jié)合，參數(shù)文件調(diào)優(yōu)只是其中一小部分，還可以發(fā)展到更核心的部分，如學(xué)習(xí)型數(shù)據(jù)庫(kù)索引［14］、優(yōu)化器查詢優(yōu)化［15］等，可以作為今后的研究方向。此外，由于自動(dòng)調(diào)參系統(tǒng)與數(shù)據(jù)庫(kù)交互的只是一個(gè)參數(shù)文件，理論上也可以用于其他系統(tǒng)的調(diào)參，例如調(diào)優(yōu)操作系統(tǒng)的內(nèi)核參數(shù)，亦可取得不錯(cuò)效果。