學術加油站｜機器學習應用在資料庫調優領域的前沿工作解讀

編者按
本文系北京理工大學科研助理牛頌登所著，本篇也是「 OceanBase 學術加油站」系列稿件第八篇。
「牛頌登：北京理工大學科研助理。 碩士期間在電子科技大學網路空間安全研究院從事聚類和強化學習相關演算法研究，在應用聚類研究個性化線上學習和強化學習的獎勵函式設計方向取得了一定成果，目前研究方向為機器學習和資料庫相結合的領域。」
本文以 VLDB 2021 的三篇 database tuning 論文為例，對機器學習應用在資料庫調優領域的前沿工作做了總結和概述。希望閱讀完本文，你可以對“database tuning”有新的認識，有什麼疑問也可以在底部留言探討。

現代資料庫管理系統(database management systems，下簡稱 DBMS)公開了許多可配置的控制執行時行為的旋鈕。正確選擇 DBMS 的配置對於提高系統效能和降低成本至關重要。但是由於 DBMS 的複雜性，調優 DBMS 通常需要有經驗的資料庫管理員(database administrators，簡稱 DBAs)付出相當大的努力。最近關於使用機器學習(Machine Learning，ML)的自動調優方法的研究表明，與專業 DBA 相比，基於 ML 的自動調優方法獲得了更好的效能。

An Inquiry into Machine Learning-based Automatic Configuration Tuning Services on Real-World Database Management Systems[1]

（一）調優過程

為了更好地理解 DBMS 的配置調優，探究在真實的企業級 DBMS 上 ML 調優方法的效果，論文透過執行在具有非本地儲存的虛擬計算設施上的 Oracle DBMS 例項來比較企業資料庫真實工作負載跟蹤下的三種 ML 演算法（GPR、DNN、DDPG）的調優效果。

論文的主要工作主要是擴充套件了 OtterTune 調優服務來支援三種 ML 調優演算法，並提出了對三種演算法的最佳化，在實驗的過程中發現了一些自動調優技術領域中被忽略的部署和度量問題。

圖 1 OtterTune 架構

OtterTune 是一個調優服務，它用來為 DBMS 的旋鈕配置找到合適的設定，由controller 和 tuning manager 組成。 其中 controller 充當目標 DBMS 和 tuning manager 之間的中介，它在目標 DBMS 上執行目標工作負載，並收集執行時資料（包括旋鈕配置和系統的度量）。Tuning manager 使用 controller 提供的調優會話資訊更新其資料儲存庫，並使用這些資訊建立 DBMS 如何響應不同旋鈕配置的 ML 模型，然後用這些模型來指導實驗並推薦新的配置給 controller，以將配置部署到 DBMS 上。這樣的迭代過程一直持續到使用者對配置的改進滿意為止。

▋ Target Database Application：

因為論文探究的是真實企業 DBMS 的 ML 自動調優對系統效能提升的效果，作者在 Société Générale （SG）多國銀行的實際業務資料下對 OtterTune 框架進行了評估。論文中使用了 TicketTracker 這一資料和工作負載跟蹤的應用程式，對 SG 的工作單據進行 2 小時的跟蹤，收到包含超過 360 萬個查詢呼叫。

作者使用 Oracle Recovery Manager 工具從 TicketTracker 資料庫的生產伺服器上建立了快照，複製了磁碟上未壓縮的 1.1 TB 大小的資料庫，並做了分析，其中 27%為表資料，19% 為表索引，54% 為大物件(Large objetcs)。TicketTracker 資料庫包含 1226 個表，其中只有 453 個有資料的表，資料庫基於它們包含 1647 個索引。

論文中使用 Oracle 的 real application testing（RAT）工具來捕獲在 DBMS 例項上執行的查詢，RAT 支援在測試資料庫上使用原始工作負載的精確時間、併發性和事務特徵對例項上的查詢進行多次重放；重放的時間被限制在一個 10 分鐘的片段（包含 23 萬條查詢）。

TicketTracker 資料庫相比於之前一些 ML 調優採用的工作負載 benchmark——TPC-C，有數百個表，而 TPC-C 只有 9 個表；TPC-C 查詢的寫的比率佔到46%，而 TicketTracker 裡只佔了 9%。這也表明實際的企業級 DBMS 與已有研究中的 benchmark 有很大不同。

最佳化演算法的目標函式設定為 Oracle 的 DB Time，它用於度量資料庫在處理使用者請求時所花費的總時間，也是 SG 專業 DBA 首選的指標。論文在 SG 私有云的單獨 Oracle v12.2 安裝上部署了 TicketTracker 資料庫和工作負載的五個副本。

（二）調優演算法

圖2 GPR/DNN調優管道

論文中的 GPR 實現基於 OtterTune 支援的原始演算法，採用高斯過程作為先驗函式，計算測試點與所有訓練點之間的距離，該演算法利用核函式來預測測試點的值和不確定度。由兩階段組成，第一個是資料預處理階段，它在 Otter Tune 的資料儲存庫中準備旋鈕配置和系統的度量資料。第二個是旋鈕推薦階段，為旋鈕選擇合適的值。

資料預處理： 目的是為了降低度量的維度，並選出最重要的一些的 knobs。在這一階段首先確定 DBMS 度量的子集，演算法使用因子分析（factor analysis）的降維技術，能夠將度量減少到更小的因子集合。將度量降維後，繼續計算對目標函式影響最大的旋鈕的排序列表。論文使用了 Lasso 的特徵選擇方法，其中旋鈕資料作為輸入 X，輸出的是結合已經修剪過的度量的目標資料。Lasso 在 X 和 y 之間的迴歸過程中確定了重要的旋鈕順序。

旋鈕推薦： 負責在調優會話的每次迭代結束時生成一個新的旋鈕配置建議。該演算法使用上一階段的輸出資料在給定旋鈕排序列表的情況下預測目標 DBMS 工作負載的度量值。然後，演算法使用目標工作負載和當前最相似工作負載的資料構建一個GPR 模型。將給定的旋鈕陣列(x)作為輸入，模型輸出目標值(y)和不確定性值(u)的對(y, u)。演算法計算 y 和 u 之和的置信上限(UCB)。然後在 UCB 上進行梯度上升，以找到能導致良好目標值的旋鈕配置。

因為高斯過程模型在較大的資料集和高維特徵向量上表現不佳[2]，所以，論文修改了 OtterTune 最初的基於 GPR 的演算法，使用深度神經網路(DNN)代替高斯模型。二者遵循相同的 ML 管道，都是先進行資料預處理，然後進行旋鈕推薦。

DNN 依賴於對輸入應用線性組合和非線性啟用的深度學習演算法，模型的網路結構有兩個隱含層，每層有 64 個神經元。所有各層均以整流線性單元(ReLU)作為啟用函式完全連線。模型實現了一種稱為 dropout 正則化的流行技術，以避免模型過擬合併提高其泛化。DNN 還在旋鈕推薦步驟期間將高斯噪聲新增到神經網路的引數中，以控制探索和利用。

圖 3 DDPG調優管道

DDPG 方法首先由 CDBTune[3]提出,它是在連續動作空間環境中搜尋最優策略的一種深度強化學習演算法。DDPG 由三個元件組成：(1)actor (2)critic 和(3)replay memory。actor 根據給定的狀態選擇一個動作(例如，對一個 knob 使用什麼值)。critic 根據狀態對選定的動作（即旋鈕值）進行評估，並且提供反饋來指導 actor。actor 的輸入是 DBMS 的度量，輸出推薦的旋鈕值。critic 將之前的度量和推薦的旋鈕作為輸入，輸出一個 Q 值，DDPG 神經網路的 Q 值計算的是對未來所有預期獎勵的疊加。replay memory 儲存按預測誤差降序排列的訓練資料。

對於每個旋鈕 k, DDPG 構造一個元組，其中包含 (1) 先前的度量 m_pre，(2) 當前的度量 m，以及(3)當前的獎勵值 r。在接收到一個新的資料時，CDBTune 首先透過比較當前、之前的和初始目標值來計算獎勵。訓練時從 memory 中獲取一個小批次排名靠前的 tuple，並透過反向傳播更新 actor 和 critic 的權重。最後，CDBTune 將當前度量 m 輸入 actor 以獲得下一旋鈕 k_next 的推薦。

論文對 CDBTune 的 DDPG 演算法進行了一些最佳化，以提高 DDPG 的收斂速度（新方法被叫做 DDPG++）。首先，DDPG++ 使用即時獎勵而不是累積的未來獎勵作為 Q 值。第二點，DDPG++ 使用了一個更簡單的獎勵函式，不考慮之前的或基礎目標值。第三點，DDPG++ 在得到一個新的結果時，從 replay memory 中獲取多個小批次，以訓練網路更快地收斂。

（三）實驗結果

第一個實驗評估了由 DBA 選出旋鈕後再由 ML 調優演算法在增加調優的旋鈕數量時生成的配置的質量。圖 4 顯示了演算法生成的最佳化配置在三個 vm 上的平均效能改進。（每個條的暗和亮部分分別代表每個演算法的最小和最大效能）。

圖4 DBA選出的調優旋鈕

為了理解為什麼配置執行起來效果不同，作者手動檢查了每個旋鈕配置，並確定了三個最重要的 Oracle 旋鈕，當演算法沒有正確設定它們時，會對 DB Time 產生最大的影響。其中前兩個引數控制 DBMS 的主緩衝區快取的大小，第三個旋鈕啟用基於 Oracle 版本的最佳化器特性。

作者發現，GPR 在四個演算法中總是快速收斂，但是 GPR 很容易陷入區域性極小值。DNN 的效能是整體最好的，而 DDPG 和 DDPG++需要更多的迭代次數才能達到好的最佳化效能。

第二個實驗是將人工完全排除在調優過程中。首先為了生成旋鈕列表排序，使用Lasso 演算法，根據旋鈕對目標函式的估計影響程度對其進行排序，並將排序列表分為 10knobs 和 20knobs，以供 ML 演算法進行調優。圖 5 顯示了 10 和 20 個knobs 配置的平均效能改進。

圖5 OtterTune選出的調優旋鈕

論文中認為，20knobs 配置的 DBMS 整體效能較差，部分原因是在 2020 年 8 月初作者進行這些實驗時，私有云儲存上存在更多的共享噪聲，論文中對效能測量的可變性支援了這一解釋。

第三個實驗，作者先在一個工作負載上訓練 ML 生成的模型，然後使用模型去調優另一個工作負載的 DBMS，分析另一工作負載上由 ML 生成的配置的質量。首先使用 OLTP-Bench 執行的 TPC-C 工作負載為每個演算法訓練模型。然後使用 TPC-C 訓練的模型對 TicketTracker 工作負載上的 DBMS 進行迭代調優。圖 6 是演算法在每個虛擬機器上對 SG 預設配置的效能改進。

圖6 對不同工作負載的適應性

CGPTuner: a Contextual Gaussian Process Bandit Approach for the Automatic Tuning of IT Configurations Under Varying Workload Conditions[4]

（一）背景知識

這篇論文做的主要工作跟上一篇有些類似，都是為了找到 DBMS 中能夠提升系統效能的配置，不同的是這篇論文首先認為 DBMS 處於整個 IT 棧的最頂端，下面的 JVM、作業系統的配置調優也都會影響 DBMS 的效能；第二點，DBMS 的效能還跟它所處的工作負載有關，即這篇論文分析的是實時的、線上的自動調優；論文的第三個亮點是它認為目前軟體版本更新的比較快，而且版本更新會修改其可用的引數，那麼從以前的知識庫中重用資訊就讓調優的問題變得比較複雜，因此它提出的方法是不需要利用以前的知識庫的。

圖7 改變MongoDB快取大小和虛擬機器dirty_ratio Linux引數對DBMS效能的影響

圖8 改變JVM併發垃圾收集器的執行緒和Linux核心的read_ahead_kb引數對Cassandra效能的影響

從圖 7 和圖 8 中可以看到，DBMS、JVM 和 OS 的配置都會影響 DBMS 的效能。

（二）所提模型

圖 9 調優過程和架構

論文所提模型的最佳化目標就是在給定的工作負載 w 下，找到一個配置向量 x，將其應用在 IT 棧上面來最佳化系統的效能指標 y。需要注意的是，調優器能夠利用先前所有迭代的 x,w 和 y，但是不需要其他額外的知識，這點是跟比如 OtterTune 這些需要利用其他知識的自動調優不同的地方。

機率模型：貝葉斯最佳化

替代模型： 高斯過程

採集函式： GP-Hedge。GP-Hedge 採用了多種獲取函式的組合，即EI(預期的改進)、PI(改進機率)、LCB(低置信區間）等。

之所以叫基於上下文的高斯過程最佳化，是因為作者認為某些工作負載下的最佳化是相關的，比如工作負載 w 下得到的資料，可能為另一工作負載 w’ 提供一些有用的資訊。基於此作者為高斯過程定義了新的正定核和新的協方差函式，作者認為如果兩個（x,w）組成的點是相似的只要它們的x是相似的或者 w 是相似。但是在最佳化的時候，作者只最佳化了配置空間這一子空間，在每次最佳化的時候是固定了另一維度進行探索和利用。採用基於上下文的高斯過程最佳化的好處是在迭代過程中，所有工作負載的資訊是共享的。

論文是用 MongoDB 和 Cassandra DBMS 來評估 CGPTuner，用了 YCSB 來模擬了三種不同的工作負載模式。實驗時的最佳化目標是在不增加響應時間的前提下最小化記憶體消耗，來提升部署的效益。作者手動選出了調優的引數，包含 IT 棧不同的元件（DBMS、JVM 和 OS）的引數。為了驗證調優器對於工作負載變化的適應能力，論文中設計了兩種工作負載模式，分別是對三種不同讀寫比例工作負載在一天中（也就是 1 次重複）中持續不同的迭代次數。執行的執行緒數也是變化的，以此來模擬一天中不同的工作負載密度。