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

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

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

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

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

OtterTune 工作原理

下圖是 OtterTune 組件和工作流程

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

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

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

注意

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

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

機(jī)器學(xué)習(xí)流水線

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

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

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

我們來深入挖掘以下機(jī)器學(xué)習(xí)流水線的每個(gè)組件。

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

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

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

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

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

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

實(shí)現(xiàn)

OtterTune 用 Python 編寫。

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

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

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

實(shí)驗(yàn)設(shè)計(jì)

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

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

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

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

評估

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

MySQL 實(shí)驗(yàn)結(jié)果

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

在 TPC-C 負(fù)載下，只有幾個(gè) MySQL 的旋鈕顯著影響性能。OtterTune 和 DBA 的配置給這幾個(gè)旋鈕設(shè)置了很好的值。RDS 表現(xiàn)略遜一籌，因?yàn)榻o一個(gè)旋鈕配置了欠佳的值。調(diào)優(yōu)腳本表現(xiàn)最差，因?yàn)橹恍薷囊粋€(gè)旋鈕。

Postgres 實(shí)驗(yàn)結(jié)果

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

結(jié)束語

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

下一步會(huì)怎么樣? 為了順應(yīng)的越來越流行的 DBaaS (遠(yuǎn)程登錄 DBMS 主機(jī)是不可能的)，OtterTune 會(huì)很快能夠自動(dòng)探查目標(biāo) DBMS 的硬件能力，而不需要遠(yuǎn)程登錄。