本文是卡耐基梅隆大學的 Dana Van Aken、Andy Pavlo 和 Geoff Gordon 所寫。這個項目展示了學術研究人員如何利用 AWS Cloud Credits for Research Program 來助力他們的科技突破的。

數據庫管理系統(DBMS)是任何數據密集應用的關鍵部分。它們可以處理大量數據和復雜的工作負載，但同時也難以管理，因為有成百上千個“旋鈕”(即配置變量)控制著各種要素，比如要使用多少內存做緩存和寫入磁盤的頻率。組織機構經常要雇傭專家來做調優，而專家對很多組織來說太過昂貴了。卡耐基梅隆大學數據庫研究組的學生和研究人員在開發一個新的工具，名為 OtterTune，可以自動為 DBMS 的“旋鈕”找到合適的設置。工具的目的是讓任何人都可以部署 DBMS，即使沒有任何數據庫管理專長。

OtterTune 跟其他 DBMS 設置工具不同，因為它是利用對以前的 DBMS 調優知識來調優新的 DBMS，這顯著降低了所耗時間和資源。OtterTune 通過維護一個之前調優積累的知識庫來實現這一點，這些積累的數據用來構建機器學習(ML)模型，去捕獲 DBMS 對不同的設置的反應。OtterTune 利用這些模型指導新的應用程序實驗，對提升最終目標(比如降低延遲和增加吞吐量)給出建議的配置。

本文中，我們將討論 OtterTune 的每一個機器學習流水線組件，以及它們是如何互動以便調優 DBMS 的設置。然后，我們評估 OtterTune 在 MySQL 和 Postgres 上的調優表現，將它的***配置與 DBA 和其他自動調優工具進行對比。

OtterTune 是卡耐基梅隆大學數據庫研究組的學生和研究人員開發的開源工具，所有的代碼都托管在 Github 上，以 Apache License 2.0 許可證發布。

OtterTune 工作原理

下圖是 OtterTune 組件和工作流程

調優過程開始，用戶告知 OtterTune 要調優的最終目標(比如，延遲或吞吐量)，客戶端控制器程序連接目標 DBMS，收集 Amazon EC2 實例類型和當前配置。

然后，控制器啟動***觀察期，來觀察并記錄最終目標。觀察結束后，控制器收集 DBMS 的內部指標，比如 MySQL 磁盤頁讀取和寫入的計數。控制器將這些數據返回給調優管理器程序。

OtterTune 的調優管理器將接收到的指標數據保存到知識庫。OtterTune 用這些結果計算出目標 DBMS 的下一個配置，連同預估的性能提升，返回給控制器。用戶可以決定是否繼續或終止調優過程。

注意

OtterTune 對每個支持的 DBMS 版本維護了一份“旋鈕”黑名單，包括了對調優無關緊要的部分(比如保存數據文件的路徑)，或者那些會產生嚴重或隱性后果(比如丟數據)的部分。調優過程開始時，OtterTune 會向用戶提供這份黑名單，用戶可以添加他們希望 OtterTune 避開的其它“旋鈕”。

OtterTune 有一些預定假設，對某些用戶可能會造成一定的限制。比如，它假設用戶擁有管理員權限，以便控制器來修改 DBMS 配置。否則，用戶必須在其他硬件上部署一份數據庫拷貝給 OtterTune 做調優實驗。這要求用戶或者重現工作負載，或者轉發生產 DBMS 的查詢。完整的預設和限制請看我們的論文 。

機器學習流水線

下圖是 OtterTune ML 流水線處理數據的過程，所有的觀察結果都保存在知識庫中。

OtterTune 先將觀察數據輸送到“工作流特征化組件”(Workload Characterization component)，這個組件可以識別一小部分 DBMS 指標，這些指標能最有效地捕捉到性能變化和不同工作負載的顯著特征。

下一步，“旋鈕識別組件”(Knob Identification component)生成一個旋鈕排序表，包含哪些對 DBMS 性能影響***的旋鈕。OtterTune 接著把所有這些信息“喂”給自動調優器(Automatic Tuner)，后者將目標 DBMS 的工作負載與知識庫里最接近的負載進行映射，重新使用這份負載數據來生成更佳的配置。

我們來深入挖掘以下機器學習流水線的每個組件。

工作負載特征化： OtterTune 利用 DBMS 的內部運行時指標來特征化某個工作負載的行為，這些指標精確地代表了工作負載，因為它們捕獲了負載的多個方面行為。然而，很多指標是冗余的：有些是用不同的單位表示相同的度量值，其他的表示 DBMS 的一些獨立組件，但它們的值高度相關。梳理冗余度量值非常重要，可以降低機器學習模型的復雜度。因此，我們基于相關性將 DBMS 的度量值集中起來，然后選出其中***代表性的一個，具體說就是最接近中間值的。機器學習的后續組件將使用這些度量值。

旋鈕識別： DBMS 可以有幾百個旋鈕，但只有一部分影響性能。OtterTune 使用一種流行的“特性-選擇”技術，叫做 Lasso，來判斷哪些旋鈕對系統的整體性能影響***。用這個技術處理知識庫中的數據，OtterTune 得以確定 DBMS 旋鈕的重要性順序。

接著，OtterTune 必須決定在做出配置建議時使用多少個旋鈕，旋鈕用的太多會明顯增加 OtterTune 的調優時間，而旋鈕用的太少則難以找到***的配置。OtterTune 用了一個增量方法來自動化這個過程，在一次調優過程中，逐步增加使用的旋鈕。這個方法讓 OtterTune 可以先用少量最重要的旋鈕來探索并調優配置，然后再擴大范圍考慮其他旋鈕。

自動調優器： 自動調優器組件在每次觀察階段后，通過兩步分析法來決定推薦哪個配置。

首先，系統使用工作負載特征化組件找到的性能數據來確認與當前的目標 DBMS 工作負載最接近的歷史調優過程，比較兩者的度量值以確認哪些值對不同的旋鈕設置有相似的反應。

然后，OtterTune 嘗試另一個旋鈕配置，將一個統計模型應用到收集的數據，以及知識庫中最貼近的工作負載數據。這個模型讓 OtterTune 預測 DBMS 在每個可能的配置下的表現。OtterTune 調優下一個配置，在探索(收集用來改進模型的信息)和利用(貪婪地接近目標度量值)之間交替進行。

實現

OtterTune 用 Python 編寫。

對于工作負載特征化和旋鈕識別組件，運行時性能不是著重考慮的，所以我們用 scikit-learn實現對應的機器學習算法。這些算法運行在后臺進程中，把新生成的數據吸收到知識庫里。

對于自動調優組件，機器學習算法就非常關鍵了。每次觀察階段完成后就需要運行，吸收新數據以便 OtterTune 挑選下一個旋鈕來進行測試。由于需要考慮性能，我們用 TensorFlow來實現。

為了收集 DBMS 的硬件、旋鈕配置和運行時性能指標，我們把 OLTP-Bench 基準測試框架集成到 OtterTune 的控制器內。

實驗設計

我們比較了 OtterTune 對 MySQL 和 Postgres 做出的***配置與如下配置方案進行了比較，以便評估：

• 默認： DBMS 初始配置
• 調優腳本： 一個開源調優建議工具做出的配置
• DBA： 人類 DBA 選擇的配置
• RDS： 將亞馬遜開發人員管理的 DBMS 的定制配置應用到相同的 EC2 實例類型。

我們在亞馬遜 EC2 競價實例上執行了所有的實驗。每個實驗運行在兩個實例上，分別是m4.large 和 m3.xlarge 類型：一個用于 OtterTune 控制器，一個用于目標 DBMS 部署。OtterTune 調優管理器和知識庫部署在本地一臺 20 核 128G 內存的服務器上。

工作負載用的是 TPC-C，這是評估聯機交易系統性能的工業標準。

評估

我們給每個實驗中的數據庫 —— MySQL 和 Postgres —— 測量了延遲和吞吐量，下面的圖表顯示了結果。***個圖表顯示了“第99百分位延遲”的數量，代表“最差情況下”完成一個事務的時長。第二個圖表顯示了吞吐量結果，以平均每秒執行的事務數來衡量。

MySQL 實驗結果

OtterTune 生成的***配置與調優腳本和 RDS 的配置相比，OtterTune 讓 MySQL 的延遲下降了大約 60%，吞吐量提升了 22% 到 35%。OtterTune 還生成了一份幾乎跟 DBA 一樣好的配置。

在 TPC-C 負載下，只有幾個 MySQL 的旋鈕顯著影響性能。OtterTune 和 DBA 的配置給這幾個旋鈕設置了很好的值。RDS 表現略遜一籌，因為給一個旋鈕配置了欠佳的值。調優腳本表現最差，因為只修改一個旋鈕。

Postgres 實驗結果

在延遲方面，相比 Postgres 默認配置，OtterTune、調優工具、DBA 和 RDS 的配置獲得了近似的提升。我們大概可以把這歸于 OLTP-Bench 客戶端和 DBMS 之間的網絡開銷。吞吐量方面，Postgres 在 OtterTune 的配置下比 DBA 和調優腳本要高 12%，比 RDS 要高 32%。

結束語

OtterTune 將尋找 DBMS 配置旋鈕的***值這一過程自動化了。它通過重用之前的調優過程收集的訓練數據，來調優新部署的 DBMS。因為 OtterTune 不需要生成初始化數據集來訓練它的機器學習模型，調優時間得以大大減少。

下一步會怎么樣? 為了順應的越來越流行的 DBaaS (遠程登錄 DBMS 主機是不可能的)，OtterTune 會很快能夠自動探查目標 DBMS 的硬件能力，而不需要遠程登錄。