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

數(shù)據(jù)庫管理系統(tǒng)(DBMS)是任何數(shù)據(jù)密集應用的關(guān)鍵部分。它們可以處理大量數(shù)據(jù)和復雜的工作負載，但同時也難以管理，因為有成百上千個“旋鈕”(即配置變量)控制著各種要素，比如要使用多少內(nèi)存做緩存和寫入磁盤的頻率。組織機構(gòu)經(jīng)常要雇傭?qū)＜襾碜稣{(diào)優(yōu)，而專家對很多組織來說太過昂貴了?？突仿〈髮W數(shù)據(jù)庫研究組的學生和研究人員在開發(fā)一個新的工具，名為 OtterTune，可以自動為 DBMS 的“旋鈕”找到合適的設置。工具的目的是讓任何人都可以部署 DBMS，即使沒有任何數(shù)據(jù)庫管理專長。

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

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

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

OtterTune 工作原理

下圖是 OtterTune 組件和工作流程

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

然后，控制器啟動***觀察期，來觀察并記錄最終目標。觀察結(jié)束后，控制器收集 DBMS 的內(nèi)部指標，比如 MySQL 磁盤頁讀取和寫入的計數(shù)。控制器將這些數(shù)據(jù)返回給調(diào)優(yōu)管理器程序。

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

注意

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

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

機器學習流水線

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

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

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

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

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

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

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

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

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

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

實現(xiàn)

OtterTune 用 Python 編寫。

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

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

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

實驗設計

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

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

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

工作負載用的是 TPC-C，這是評估聯(lián)機交易系統(tǒng)性能的工業(yè)標準。

評估

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

MySQL 實驗結(jié)果

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

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

Postgres 實驗結(jié)果

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

結(jié)束語

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

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