本文是由卡內(nèi)基·梅隆大學(xué)的三位嘉賓達(dá)娜·范·阿肯（Dana Van Aken）、安迪·帕夫洛（Andy Pavlo）和杰夫·戈登（Geoff Gordon）共同撰寫的文章。該項目演示了學(xué)術(shù)研究人員如何可以使用AWS Cloud Credits for Research Program（）來支持其科研突破。
OtterTune是由卡內(nèi)基·梅隆大學(xué)數(shù)據(jù)庫小組（）的學(xué)生和研究人員開發(fā)的一種新工具，它能自動為DBMS的配置按鈕找到合適的設(shè)置。目的在于讓任何人都更容易部署DBMS，甚至是數(shù)據(jù)庫管理方面毫無專長的那些人。
OtterTune有別于其他的DBMS配置工具，原因在于它充分利用從調(diào)優(yōu)之前部署的DBMS獲得的知識來調(diào)優(yōu)新部署的DBMS。這大大減少了調(diào)優(yōu)新部署的DBMS所需要的時間和資源。為此，OtterTune維護一個資料庫，包含從之前的調(diào)優(yōu)會話收集而來的調(diào)優(yōu)數(shù)據(jù)。它使用該數(shù)據(jù)來構(gòu)建機器學(xué)習(xí)模型，這些模型采集了DBMS對不同配置作出反應(yīng)的信息。OtterTune使用這些模型來指導(dǎo)用戶針對新的應(yīng)用程序進行嘗試，建議使用改善特定目標(biāo)（比如縮短延遲或提高吞吐量）的設(shè)置。
我們在本文中探討了OtterTune的機器學(xué)習(xí)管道的每個組件，并演示了它們彼此如何聯(lián)系，從而調(diào)優(yōu)DBMS的配置。之后，我們評估了OtterTune對MySQL和Postgres的調(diào)優(yōu)效果：將其配置的性能與數(shù)據(jù)庫管理員（DBA）及其他自動調(diào)優(yōu)工具選擇的配置作了一番比較。
OtterTune是由卡內(nèi)基·梅隆大學(xué)數(shù)據(jù)庫小組的學(xué)生和研究人員開發(fā)的一種開源工具。所有代碼都放在GitHub上（），采用了Apache License 2.0這種許可證來發(fā)行。
工作原理下面這張圖顯示了OtterTune的組件及工作流程。
在新的調(diào)優(yōu)會話的開始階段，用戶告訴OtterTune優(yōu)化哪個特定目標(biāo)（比如延遲或吞吐量）。客戶端控制器連接至目標(biāo)DBMS，并收集Amazon EC2實例類型和當(dāng)前目標(biāo)。
然后，控制器開始了第一個觀察期，在此期間它觀察DBMS，并記錄特定目標(biāo)。觀察期結(jié)束后，控制器收集來自DBMS的內(nèi)部度量指標(biāo)，比如MySQL針對從磁盤讀取的頁面和寫入到磁盤的頁面的計數(shù)。控制器將特定目標(biāo)和內(nèi)部度量指標(biāo)都返回給調(diào)優(yōu)管理器。
OtterTune的調(diào)優(yōu)管理器收到度量指標(biāo)后，將它們存儲在資料庫中。OtterTune使用結(jié)果來計算控制器應(yīng)安裝到目標(biāo)DBMS上的下一個配置。調(diào)優(yōu)管理器將該配置返回給控制器，并通過實際運行來估計預(yù)期的改進。用戶可以決定繼續(xù)調(diào)優(yōu)會話，還是終結(jié)調(diào)優(yōu)會話。
說明OtterTune為它支持的每個DBMS版本維護一份按鈕黑名單。該黑名單包括沒必要調(diào)優(yōu)的按鈕（比如DBMS存儲文件的路徑名稱），或者可能有嚴(yán)重后果或隱性后果的按鈕（比如可能會引起DBMS丟失數(shù)據(jù)）。在每次調(diào)優(yōu)會話的開始階段，OtterTune向用戶提供黑名單，那樣用戶就能添加他們想要OtterTune避免調(diào)優(yōu)的其他任何按鈕。
OtterTune作出某些假設(shè)，可能會限制其對一些用戶而言的用處。比如說，它假設(shè)用戶擁有管理員權(quán)限，讓控制器可以修改DBMS的配置。如果用戶沒有管理員權(quán)限，那么他們可以將數(shù)據(jù)庫的第二個副本部署到其他硬件上，以便OtterTune的調(diào)優(yōu)試驗。這要求用戶重放工作負(fù)載跟蹤，或者轉(zhuǎn)發(fā)來自生產(chǎn)級DBMS的查詢。想了解假設(shè)和限制方面的完整討論，請參閱我們的論文（）。
機器學(xué)習(xí)管道下面這張圖顯示了數(shù)據(jù)在通過OtterTune的機器學(xué)習(xí)管道傳輸時如何加以處理。所有觀察結(jié)果都放在OtterTune的資料庫中。
OtterTune先把觀察結(jié)果傳送到Workload Characterization組件。該組件識別一小批最準(zhǔn)確地采集性能變化和不同工作負(fù)載獨特特點的DBMS度量指標(biāo)。
接下來，Knob Identification組件生成一份按鈕排序表，列出了對DBMS的性能影響最大的按鈕。然后，OtterTune將所有這些信息饋送給Automatic Tuner。該組件將目標(biāo)DBMS的工作負(fù)載與數(shù)據(jù)資料庫中最相似的工作負(fù)載對應(yīng)起來，并重復(fù)使用該工作負(fù)載數(shù)據(jù)，生成更合適的配置。
現(xiàn)在不妨深入探究機器學(xué)習(xí)管道中的每一個組件。
Workload Characterization：OtterTune使用DBMS的內(nèi)部運行時度量指標(biāo)來描述工作負(fù)載的行為特點。這些度量指標(biāo)準(zhǔn)確地表述了工作負(fù)載，因為它們采集了運行時行為的許多方面。然而，許多度量指標(biāo)是冗余的：一些是以不同單位記錄的同一個度量值，另一些表示DBMS中數(shù)值高度關(guān)聯(lián)的獨立部分。精簡冗余的度量指標(biāo)很重要，因為這降低了使用它們的機器學(xué)習(xí)模型的復(fù)雜性。為此，我們基于關(guān)聯(lián)模式，將DBMS的度量指標(biāo)分成聚類（cluster）。然后，我們從每個聚類中選擇一個代表性度量指標(biāo)，具體來說是最靠近聚類中心的那個度量指標(biāo)。機器學(xué)習(xí)管道中的后續(xù)組件使用這些度量指標(biāo)。
Knob Identification：DBMS可能有數(shù)百個按鈕，但只有一小批按鈕影響DBMS的性能。OtterTune使用一種流行的特征選擇技術(shù)（名為Lasso），決定哪些按鈕顯著影響系統(tǒng)的整體性能。通過將這種技術(shù)運用于資料庫中的數(shù)據(jù)，OtterTune可識別DBMS的按鈕重要性次序。
隨后，OtterTune得決定在建議配置時使用多少個按鈕。使用太多的按鈕大大增加了OtterTune的優(yōu)化時間。使用太少的按鈕又讓OtterTune無法找到配置。為了使這個過程實現(xiàn)自動化，OtterTune使用了一種增量方法。它逐步增加用于調(diào)優(yōu)會話中的按鈕數(shù)量。這種方法讓OtterTune得以為一小批最重要的按鈕探究和優(yōu)化配置，然后擴大范圍、考慮其他按鈕。
Automatic Tuner：Automated Tuning組件通過在每個觀察期之后執(zhí)行分兩步走的分析，決定OtterTune應(yīng)該建議使用哪個配置。
首先，系統(tǒng)使用針對Workload Characterization組件中識別的度量指標(biāo)的性能數(shù)據(jù)，從最能表示目標(biāo)DBMS工作負(fù)載的之前調(diào)優(yōu)會話識別工作負(fù)載。它將會話的度量指標(biāo)與來自之前工作負(fù)載的度量指標(biāo)進行比較，看看哪些對不同的按鈕設(shè)置有類似的反應(yīng)。
然后，OtterTune選擇另一個按鈕配置來試一試。它使統(tǒng)計模型適合已收集的數(shù)據(jù)，以及來自資料庫中最相似的工作負(fù)載的數(shù)據(jù)。該模型讓OtterTune可以預(yù)測DBMS使用每一種可能的配置會有怎樣的性能。OtterTune優(yōu)化下一個配置，在探索（收集信息來改善模型）和利用（盡可能在特定度量指標(biāo)方面表現(xiàn)不俗）之間求得平衡。
實現(xiàn)OtterTune是用Python編寫的。
就Workload Characterization和Knob Identification這兩個組件而言，運行時性能并不是擔(dān)心的主要問題，于是我們用scikit-learn實現(xiàn)了對應(yīng)的機器學(xué)習(xí)算法。這些算法在后臺進程中運行，一旦OtterTune的資料庫中有了新的數(shù)據(jù)，就會整合新數(shù)據(jù)。
至于Automatic Tuner，機器學(xué)習(xí)算法位于關(guān)鍵路徑上。它們在每次觀察期后運行，整合新數(shù)據(jù)，那樣OtterTune可以選擇一個按鈕配置接下來嘗試。由于性能是個考量因素，我們使用TensorFlow實現(xiàn)了這些算法。
為了收集DBMS硬件方面的數(shù)據(jù)、按鈕配置和運行時性能度量指標(biāo)，我們將OtterTune的控制器與OLTP-Bench基準(zhǔn)測試框架整合起來。
評估為了評估，我們針對MySQL和Postgres的性能，將OtterTune選擇的配置與下列配置進行了比較：
- 默認(rèn)：DBMS提供的配置
- 調(diào)優(yōu) ：開源調(diào)優(yōu)顧問工具生成的配置
- DBA：數(shù)據(jù)庫管理員生成的配置
- RDS：為DBMS定制的配置，由Amazon RD管理，部署在同樣類型的EC2實例上。
我們在Amazon EC2 Spot Instances（現(xiàn)貨實例）上進行了所有的試驗。我們在兩個實例上進行了每次試驗：一個實例用于OtterTune的控制器，另一個用于部署的目標(biāo)DBMS系統(tǒng)。我們分別使用了m4.large和m3.xlarge實例類型。我們將OtterTune的調(diào)優(yōu)管理器和數(shù)據(jù)資料庫部署在了搭載20個核心、128GB內(nèi)存的本地服務(wù)器上。
我們使用了TPC-C工作負(fù)載，這是評估聯(lián)機事務(wù)處理（OLTP）系統(tǒng)性能的行業(yè)標(biāo)準(zhǔn)。
針對我們在試驗中使用的每個數(shù)據(jù)庫：MySQL和Postgres，我們測量了延遲和吞吐量。下面幾張圖顯示了結(jié)果。第一張圖顯示了第99個百分位延遲的數(shù)量，這表示“在最糟糕情況下”事務(wù)完成所花的時間。第二張圖顯示了吞吐量的結(jié)果，以每秒完成的事務(wù)平均數(shù)量來測量。
MySQL的結(jié)果：
將OtterTune生成的配置與調(diào)優(yōu)和RDS生成的配置進行比較，就會發(fā)現(xiàn)：如果使用OtterTune配置，MySQL的延遲縮短了約60%，吞吐量提升了35%。OtterTune還生成了結(jié)果與數(shù)據(jù)庫管理員選擇的配置一樣好的配置。
少數(shù)幾個MySQL的按鈕對TPC-C工作負(fù)載的性能有重大影響。OtterTune和數(shù)據(jù)庫管理員生成的配置為這每一個按鈕提供了很好的設(shè)置。由于為一個按鈕提供了未達(dá)標(biāo)準(zhǔn)的設(shè)置，RDS的表現(xiàn)要遜色一點。由于只修改了一個按鈕，調(diào)優(yōu)腳本的配置表現(xiàn)最差。
Postgres的結(jié)果：
就延遲而言，OtterTune、調(diào)優(yōu)工具、數(shù)據(jù)庫管理和RDS生成的配置都比Postgres的默認(rèn)設(shè)置有了相似的改進。我們也許可以將這歸因于網(wǎng)絡(luò)上OLTP-Bench的客戶機和DBMS之間的往返所需要的開銷。至于吞吐量，如果使用OtterTune建議的配置，Postgres的性能比數(shù)據(jù)庫管理員和調(diào)優(yōu)腳本選擇的配置高出了約12%，比RDS更是高出了約32%。
類似MySQL，只有少數(shù)幾個按鈕對Postgres的性能有重大影響。OtterTune、數(shù)據(jù)庫管理員、調(diào)優(yōu)腳本和RDS生成的配置都修改了這些按鈕，大多數(shù)提供了相當(dāng)好的設(shè)置。
結(jié)束語OtterTune使得為DBMS的配置按鈕找到合適的設(shè)置這個過程實現(xiàn)了自動化。為了調(diào)優(yōu)新部署的DBMS，它重復(fù)使用從之前的調(diào)優(yōu)會話收集而來的訓(xùn)練數(shù)據(jù)。由于OtterTune不需要生成用于訓(xùn)練機器學(xué)習(xí)模型的初始數(shù)據(jù)集，因而顯著縮短了調(diào)優(yōu)時間。
接下來是什么？為了適應(yīng)部署的DBaaS越來越流行這個形勢（無法遠(yuǎn)程訪問DBMS的主機系統(tǒng)），OtterTune很快就能夠自動檢測目標(biāo)DMBS的硬件功能，而不需要遠(yuǎn)程訪問。
想了解OtterTune方面的更多細(xì)節(jié)，請參閱我們的論文或放在GitHub上的代碼。敬請關(guān)注這個網(wǎng)站（），我們很快就會推出OtterTune這項在線調(diào)優(yōu)服務(wù)。
