陳 鐳

（1.南京審計大學 信息工程學院，江蘇 南京 211815；2.南京大學計算機軟件新技術國家重點實驗室，江蘇南京 210023）

0 引言

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

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

1 數(shù)據(jù)庫自動調參系統(tǒng)介紹

數(shù)據(jù)庫自動調參系統(tǒng)通常包含客戶端和服務端兩個部分?？蛻舳税惭b在DBMS 所在機器上，負責收集DBMS的統(tǒng)計信息，并上傳至服務端。服務端一般配置在云服務器上，負責訓練機器學習模型并推薦參數(shù)文件，客戶端接收到推薦的參數(shù)文件后將其配置到目標DBMS 上，評測其性能，直到用戶對推薦的參數(shù)滿意為止。

1.1 客戶端

客戶端通常由控制程序和驅動程序組成?？刂瞥绦蛲ㄟ^訪問目標數(shù)據(jù)庫收集DBMS 的各種配置參數(shù)和度量（吞吐率、響應時間等）數(shù)據(jù)；驅動程序則負責實現(xiàn)客戶端的所有控制流，主要與服務端進行交互。

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

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

（2）工作負載生成，驅動程序啟動工作負載，并作為后臺作業(yè)運行。當準備開始測量時，驅動程序向控制程序發(fā)送一個信號，并等待基準完成。

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

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

（5）驅動程序將控制程序收集到的所有DBMS 數(shù)據(jù)上載至服務器，并定期檢查服務器是否已完成推薦的新配置。

（6）如果服務端已成功生成下一個配置，驅動程序將從服務端查詢新配置并將其安裝至目標DBMS。

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

1.2 服務端

服務端通常由調優(yōu)管理和作業(yè)調度兩部分組成。調優(yōu)管理負責處理和存儲調優(yōu)數(shù)據(jù)，并可視化每個調優(yōu)會話的結果；作業(yè)調度負責計算機器學習模型并提出配置建議。

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

Fig.2 Server side workflow圖2 服務端工作流程

2 自動調優(yōu)方法框架

從調優(yōu)會話中收集到的數(shù)據(jù)需要使用機器學習模型進行處理，如圖2 中的作業(yè)調度模塊所示，數(shù)據(jù)應用場景為工作負載特征化、特征選擇與自動調優(yōu)算法。

2.1 工作負載特征化

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

2.2 特征選擇

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

2.3 自動調優(yōu)算法

自動調優(yōu)算法需要識別先前調優(yōu)會話中與當前工作最為相似的負載。首先確保所有度量標準具有相同的數(shù)量級，然后計算當前工作負載與存儲庫中歷史工作負載的差異（如歐式距離），差異值越小表示越相似。

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

3 數(shù)據(jù)庫自動調優(yōu)實驗

采用卡耐基梅隆大學數(shù)據(jù)庫研究組開發(fā)的OtterTune系統(tǒng)對PostgreSQL 關系數(shù)據(jù)庫進行自動化參數(shù)調優(yōu)實驗。

3.1 實驗環(huán)境

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

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

（1）準備兩臺Ubuntu18.04 的虛擬機，配置均為4 核心CPU，4GB 內存，40G 硬盤。一臺用作服務端，另一臺用作客戶端。

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

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

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

3.2 服務端配置

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

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

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

S4：啟動Celery（用于調度機器學習任務）和Django Server，完成后通過瀏覽器打開http：//127.0.0.1：8000，在其中建立一個tuning session，并記下upload_code，使用celery beat 啟動周期任務。

3.3 客戶端配置

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

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

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

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

C5：編譯Controller，執(zhí)行gradle build。

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

3.4 實驗效果

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

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

Fig.3 Operation effect of parameter adjustment experiment圖3 調參實驗運行效果

4 結語

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