原標(biāo)題：DBA要失業(yè)了？AI優(yōu)化水平超DBA老炮兒

上周末，最不開心的應(yīng)該是優(yōu)秀的數(shù)據(jù)庫(kù)管理員了。

這些優(yōu)秀的數(shù)據(jù)庫(kù)管理員(以下簡(jiǎn)稱數(shù)據(jù)庫(kù)管理員為DBA)，原本可以靠自己的本事，享受高薪，可是，好景不長(zhǎng)了，因?yàn)榧幢闶琴Y質(zhì)平平的DBA，以后借助AI的力量，也能瞬間達(dá)到優(yōu)秀DBA的水平。

來(lái)看最近來(lái)自卡耐基梅隆數(shù)據(jù)庫(kù)小組的最新研究成果，他們正用最新的深度學(xué)習(xí)技術(shù)，完成數(shù)據(jù)庫(kù)的調(diào)優(yōu)工作。

卡耐基梅隆大學(xué)數(shù)據(jù)庫(kù)組的研究員和學(xué)生們研發(fā)了一款新工具，叫做OtterTune。OtterTune可以從數(shù)據(jù)庫(kù)成百上千個(gè)配置開關(guān)中自動(dòng)發(fā)現(xiàn)最佳設(shè)置。它的目標(biāo)是讓隨便一個(gè)工程師都可以更容易去部署一套關(guān)系型數(shù)據(jù)庫(kù)，即使他們?cè)跀?shù)據(jù)庫(kù)管理方面沒有任何專業(yè)知識(shí)也行。

OtterTune與其他的數(shù)據(jù)庫(kù)配置工具不一樣，因?yàn)樗谜{(diào)優(yōu)先前的數(shù)據(jù)庫(kù)配置知識(shí)去調(diào)優(yōu)新的數(shù)據(jù)庫(kù)配置。這可以顯著地降低調(diào)優(yōu)一個(gè)新的數(shù)據(jù)庫(kù)部署所需時(shí)間及相關(guān)的資源。為了做到這一點(diǎn)，OtterTune維持著一個(gè)資料庫(kù)，其中存放了從先前調(diào)優(yōu)環(huán)境中采集回來(lái)的調(diào)優(yōu)數(shù)據(jù)。OtterTune使用這些調(diào)優(yōu)模型來(lái)指導(dǎo)新應(yīng)用程序的實(shí)驗(yàn)，推薦能夠改進(jìn)目標(biāo)對(duì)象(比如降低延時(shí)或者提升吞吐量)的設(shè)置。

在這篇文章中，我們討論OtterTune工具 ML pipeline(機(jī)器學(xué)習(xí)的工作流API庫(kù))的每個(gè)組件，并展示他們之間怎樣互相協(xié)作去調(diào)優(yōu)一個(gè)數(shù)據(jù)庫(kù)配置。我們?cè)贛ySQL和Postgre上評(píng)估OtterTune的調(diào)優(yōu)能力，通過(guò)將OtterTune最佳配置的性能與DBA選擇的配置及其他自動(dòng)調(diào)優(yōu)工具的配置得出的性能做比較。

OtterTune是一個(gè)開源工具，由卡耐基梅隆大學(xué)數(shù)據(jù)庫(kù)研究組的研究員和學(xué)生們研發(fā)。所有的工具代碼都放在GitHub上，遵從Apache License 2.0協(xié)議授權(quán)。

Otter Tune怎樣工作？

在一個(gè)新的調(diào)優(yōu)場(chǎng)景，首先，用戶告訴OtterTune要通過(guò)調(diào)優(yōu)來(lái)滿足哪個(gè)目標(biāo)對(duì)象(比如，延遲或者吞吐量)。客戶端的控制器(controller)連接到目標(biāo)數(shù)據(jù)庫(kù)，搜集它的Amazon EC2實(shí)例類型和當(dāng)前配置。

然后控制器開始它的第一個(gè)探測(cè)周期，在這個(gè)期間內(nèi)，它監(jiān)控?cái)?shù)據(jù)庫(kù)，并記錄目標(biāo)對(duì)象。探測(cè)周期結(jié)束的時(shí)候，控制器從數(shù)據(jù)庫(kù)中采集好內(nèi)部指標(biāo)，比如MySQL中從磁盤讀取的頁(yè)面和寫到磁盤的頁(yè)面(pages)的計(jì)數(shù)器。控制器會(huì)將目標(biāo)對(duì)象和內(nèi)部指標(biāo)信息都傳遞給調(diào)優(yōu)管理器(tuning manager)。

當(dāng)OtterTune調(diào)優(yōu)管理器收到這些指標(biāo)后，把它們存放在資料庫(kù)當(dāng)中。OtterTune使用這些結(jié)果，計(jì)算下一個(gè)要部署的目標(biāo)數(shù)據(jù)庫(kù)的配置。調(diào)優(yōu)管理器將這一配置信息傳輸給控制器，并告訴控制器，采納這一配置后可能會(huì)獲得的性能提升。用戶可以決定是繼續(xù)調(diào)優(yōu)，還是結(jié)束這次優(yōu)化工作。

注意

OtterTune為它支持的每個(gè)數(shù)據(jù)庫(kù)版本維護(hù)著一個(gè)配置開關(guān)的黑名單。黑名單包括那些調(diào)整了不會(huì)產(chǎn)生效果的配置開關(guān)(比如，數(shù)據(jù)庫(kù)中存放文件的路徑名)，或者這些開關(guān)會(huì)有嚴(yán)重的或者潛在不良后果(比如，可能會(huì)導(dǎo)致數(shù)據(jù)庫(kù)丟失數(shù)據(jù))。每場(chǎng)調(diào)優(yōu)開始的時(shí)候，OtterTune都會(huì)給用戶提供一個(gè)黑名單，所以他/她可以增加其他開關(guān)進(jìn)去，如果他們希望OtterTune不要去調(diào)優(yōu)這部分的話。

OtterTune作了一些假設(shè)限制，可能會(huì)限制了一些用戶的可用性。比如，它假定用戶有允許控制器更改數(shù)據(jù)庫(kù)配置的管理權(quán)限。如果用戶沒有這個(gè)權(quán)限，那他或者她可以在其他硬件上部署一個(gè)數(shù)據(jù)庫(kù)鏡像，用于OtterTune調(diào)優(yōu)實(shí)驗(yàn)。這就需要用戶去重演(replay)一個(gè)工作負(fù)載跟蹤，或者在生產(chǎn)數(shù)據(jù)庫(kù)中轉(zhuǎn)發(fā)查詢。關(guān)于假定和限制的完整討論，詳見我們的論文(讀者可以點(diǎn)擊文末的“閱讀原文”進(jìn)行閱讀)。

ML pipeline

下面的圖中展示了通過(guò)OtterTune的ML pipeline，數(shù)據(jù)在移動(dòng)過(guò)程中是如何處理的。所有探查數(shù)據(jù)都存放在OtterTune資料庫(kù)中。

OtterTune首先將探測(cè)數(shù)據(jù)傳給“工作負(fù)載表征”(Workload Characterization)組件。該組件識(shí)別一組較小的數(shù)據(jù)庫(kù)指標(biāo)度量，可以最佳地捕獲性能上的差異性，以及不同工作負(fù)載的區(qū)別特征。

接著，開關(guān)識(shí)別組件(Knob Identification)生成一個(gè)開關(guān)的排名列表，以對(duì)數(shù)據(jù)庫(kù)性能的影響度大小排序。OtterTune將所有這些信息提供給自動(dòng)調(diào)優(yōu)器(Automatic Tuner)組件。該組件在它的數(shù)據(jù)資料庫(kù)中為目標(biāo)數(shù)據(jù)庫(kù)負(fù)載匹配(map)最相似的負(fù)載，并用這個(gè)負(fù)載數(shù)據(jù)生成最佳配置。

讓我們把ML pipeline中的每個(gè)組件再詳細(xì)說(shuō)說(shuō)。

工作負(fù)載表征(Workload Characterization)組件：OtterTune使用數(shù)據(jù)庫(kù)內(nèi)部運(yùn)行時(shí)的度量指標(biāo)來(lái)表征(或識(shí)別)工作負(fù)載的行為。這些度量指標(biāo)提供了負(fù)載的準(zhǔn)確表現(xiàn)，因?yàn)樗鼈儾东@了運(yùn)行時(shí)行為的許多因素。可是，很多度量指標(biāo)是冗余的，一些是相同的度量記錄只是單位不同，其他的則是表現(xiàn)數(shù)據(jù)庫(kù)不同組件，它們的值高度相關(guān)。所以裁剪冗余度量就很重要，這可以降低ML模型使用它們的時(shí)候的復(fù)雜性。為此，我們根據(jù)其相關(guān)性模型對(duì)數(shù)據(jù)庫(kù)的度量指標(biāo)進(jìn)行了聚類。然后，我們從每個(gè)聚類中選擇一個(gè)作為代表度量，就是最靠近聚類中心的那個(gè)度量。ML pipeline的后續(xù)組件直接使用這些度量。

開關(guān)識(shí)別組件(Knob Identification)：數(shù)據(jù)庫(kù)中可能有幾百個(gè)開關(guān)，但只有一小部分會(huì)影響數(shù)據(jù)庫(kù)的性能。OtterTune使用一個(gè)叫做Lasso的流行特征選擇(feature-selection)技術(shù)，來(lái)確定哪些開關(guān)會(huì)很大程度上影響系統(tǒng)的整體性能。通過(guò)使用這一技術(shù)于資料庫(kù)中的數(shù)據(jù)，OtterTune就可以列出數(shù)據(jù)庫(kù)中這些開關(guān)的重要性順序。

然后，OtterTune必須決定，做配置推薦的時(shí)候用多少個(gè)開關(guān)。使用太多必然會(huì)顯著增加OtterTune的調(diào)優(yōu)時(shí)間。用得太少又會(huì)妨礙OtterTune去找到最佳配置。OtterTune使用漸進(jìn)化的方式自動(dòng)化這一過(guò)程，在調(diào)優(yōu)時(shí)它會(huì)逐漸增加開關(guān)的個(gè)數(shù)。這個(gè)方式讓OtterTune在擴(kuò)展到更多開關(guān)之前，探尋和優(yōu)化一組最重要的開關(guān)配置。

自動(dòng)調(diào)優(yōu)(Automatic Tuner)組件：自動(dòng)調(diào)優(yōu)組件通過(guò)在每個(gè)觀察周期之后執(zhí)行“兩步分析”(two-step analysis)來(lái)確定OtterTune應(yīng)推薦的配置。

首先，系統(tǒng)使用工作負(fù)載表征組件中標(biāo)識(shí)的度量性能數(shù)據(jù)，識(shí)別來(lái)自先前調(diào)優(yōu)場(chǎng)景的最能匹配目標(biāo)數(shù)據(jù)庫(kù)負(fù)載的負(fù)載。它將當(dāng)前場(chǎng)景的度量指標(biāo)與先前場(chǎng)景的度量指標(biāo)進(jìn)行比較，以確定哪些指標(biāo)與不同的開關(guān)設(shè)置類似。

然后，OtterTune會(huì)選擇另一個(gè)開關(guān)設(shè)置去嘗試。它適用一個(gè)統(tǒng)計(jì)模型，搜集數(shù)據(jù)，與資料庫(kù)中最相近負(fù)載的數(shù)據(jù)一樣。這個(gè)模型讓OtterTune可以預(yù)測(cè)實(shí)施每個(gè)可能的配置后，數(shù)據(jù)庫(kù)性能會(huì)怎樣。OtterTune優(yōu)化下一個(gè)配置，采用探索的方式(搜集信息以改進(jìn)模型)而不是剝削的方式(試圖只在目標(biāo)度量上就貪婪地做好)。

實(shí)現(xiàn)

OtterTune用Python編寫。

對(duì)工作負(fù)載表征和開關(guān)識(shí)別組件來(lái)說(shuō)，運(yùn)行時(shí)的性能并不特別需要考慮，因此我們用scikit-learn來(lái)實(shí)現(xiàn)相應(yīng)的機(jī)器學(xué)習(xí)算法。這些算法以后臺(tái)進(jìn)程的形式運(yùn)行，并使用OtterTune資料庫(kù)中的新數(shù)據(jù)。

對(duì)自動(dòng)優(yōu)化組件來(lái)說(shuō)，機(jī)器學(xué)習(xí)算法在關(guān)鍵路徑上。他們?cè)诿恳粋€(gè)觀察周期后運(yùn)行，獲取新數(shù)據(jù)以便OtterTune能取得一個(gè)開關(guān)配置進(jìn)行下一次嘗試。因?yàn)樗男阅苁且貏e考慮的，我們用TensorFlow來(lái)實(shí)現(xiàn)其算法。

搜集關(guān)于數(shù)據(jù)庫(kù)硬件的數(shù)據(jù)、開關(guān)配置以及運(yùn)行時(shí)的性能度量指標(biāo)，我們將OLTP-Bench測(cè)評(píng)框架集成到OtterTune的控制器中。

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

為了評(píng)估效果，我們使用OtterTune選擇的最佳配置來(lái)比較MySQL和Postgre的性能：

默認(rèn)配置：數(shù)據(jù)庫(kù)安裝時(shí)的配置

優(yōu)化腳本：由一個(gè)開源調(diào)優(yōu)工具生成的配置

DBA：人類DBA選擇的配置

RDS：由亞馬遜研發(fā)定制的數(shù)據(jù)庫(kù)配置，部署在相同的EC2實(shí)例類型上

我們所有的實(shí)驗(yàn)都是在Amazon EC2 Spot Instance上完成的。每一個(gè)實(shí)驗(yàn)都用了2個(gè)實(shí)例：一個(gè)作為OtterTune控制器，一個(gè)作為目標(biāo)數(shù)據(jù)庫(kù)部署用。我們分別使用m4.large和m3.xlarge實(shí)例類型。我們將OtterTune調(diào)優(yōu)管理器和資料庫(kù)部署在本地服務(wù)器上，配置是20核CPU、128G內(nèi)存。我們用TPC-C負(fù)載模型，這是評(píng)估OLTP系統(tǒng)性能的工業(yè)標(biāo)準(zhǔn)。

評(píng)估

對(duì)實(shí)驗(yàn)中我們用到的每一種數(shù)據(jù)庫(kù)，MySQL及Postgre，我們?cè)u(píng)估延遲和性能。下面的圖展示了評(píng)估結(jié)果。第一個(gè)圖表展示了第99百分位數(shù)指標(biāo)的延遲數(shù)量，代表完成交易所需的“最壞情況”時(shí)間長(zhǎng)度。第二個(gè)圖展示吞吐量的結(jié)果，評(píng)估的是每秒完成的平均事務(wù)數(shù)。

MySQL評(píng)估結(jié)果：

比較由OtterTune生成的最佳配置與其他工具的“優(yōu)化腳本”、RDS生成的配置，OtterTune推薦的配置對(duì)MySQL數(shù)據(jù)庫(kù)大約降低了60%的延遲，提升了22%到35%的吞吐量。OtterTune生成的配置幾乎與DBA做的選擇一樣好。

只有一些MySQL的開關(guān)會(huì)顯著影響TPC-C負(fù)載的性能。由OtterTune生成的配置和DBA為每個(gè)開關(guān)提供了很好的設(shè)置。RDS干的稍微要差點(diǎn)，因?yàn)樗鼮橐粋€(gè)開關(guān)提供了不是最優(yōu)的設(shè)置。“優(yōu)化腳本”的配置表現(xiàn)最差，因?yàn)樗桓牧艘粋€(gè)開關(guān)。

Postgre評(píng)估結(jié)果：

對(duì)延遲來(lái)說(shuō)，OtterTUne生成的配置，與“優(yōu)化腳本”、DBA、RDS差不多，相對(duì)Postgre的默認(rèn)設(shè)置都獲得了不少的提升。我們可以將其歸因于OTLP測(cè)評(píng)工具客戶端和數(shù)據(jù)庫(kù)之間的網(wǎng)絡(luò)開銷。對(duì)于吞吐量，OtterTune設(shè)置相對(duì)DBA和“優(yōu)化腳本”的設(shè)置得到了12%的提升，相對(duì)RDS，得到了32%的提升。

跟MySQL相似，只要少數(shù)開關(guān)顯著影響Postgre的性能。OtterTune、DBA、“優(yōu)化腳本”以及RDS都調(diào)整了所有這些開關(guān)，大多都提供了合理的設(shè)置。

結(jié)論

OtterTune為關(guān)系型數(shù)據(jù)庫(kù)的配置開關(guān)自動(dòng)化發(fā)現(xiàn)最佳設(shè)置，用于調(diào)優(yōu)新的數(shù)據(jù)庫(kù)部署，重用從先前調(diào)優(yōu)場(chǎng)景獲取的訓(xùn)練數(shù)據(jù)。因?yàn)镺tterTune不需要為訓(xùn)練ML模型生成廚師數(shù)據(jù)集，所需調(diào)優(yōu)時(shí)間大大減少。

譯后記

OtterTune為關(guān)系型數(shù)據(jù)庫(kù)的配置開關(guān)自動(dòng)化發(fā)現(xiàn)最佳設(shè)置，用于調(diào)優(yōu)。

不客氣地說(shuō)，OtterTune目前也只是支持MySQL和Postgre兩種數(shù)據(jù)庫(kù)，而且只是在開關(guān)設(shè)置層面，相比Oracle數(shù)據(jù)庫(kù)在自動(dòng)化管理方面的強(qiáng)大功力，OtterTune只能算是一個(gè)玩具。我突然想到，2004年的時(shí)候，我去貴州給某個(gè)運(yùn)營(yíng)商做Oracle數(shù)據(jù)庫(kù)優(yōu)化，只是把SGA從100M調(diào)大到1GB，客戶的核心業(yè)務(wù)整體性能就得到了飛速提升。放到今天來(lái)說(shuō)是個(gè)不可思議的事情，今天隨便一個(gè)省級(jí)運(yùn)營(yíng)商的核心系統(tǒng)標(biāo)配可能都是一個(gè)TB的內(nèi)存，缺省安裝的時(shí)候，工程師就會(huì)把SGA缺省配到700G，其他相關(guān)參數(shù)也會(huì)按所謂的最佳實(shí)踐進(jìn)行。

但是，沒有開關(guān)的問題，不代表就沒有數(shù)據(jù)庫(kù)的性能問題。

時(shí)至今日，Oracle數(shù)據(jù)庫(kù)的性能問題依然層出不窮(不是因?yàn)镺racle不行，其他數(shù)據(jù)庫(kù)還在后面遠(yuǎn)遠(yuǎn)的跟著Oracle在前進(jìn)呢)，參數(shù)開關(guān)層面基本已經(jīng)不太可能有遺漏。性能問題更多的層面來(lái)自于開發(fā)，開發(fā)部門數(shù)據(jù)模型設(shè)計(jì)得不合理，開發(fā)人員SQL寫得不合理，往往導(dǎo)致了90%的性能問題。前兩天朋友談及的一個(gè)案例，某銀行的信用卡業(yè)務(wù)查詢，每天一次，表當(dāng)然有幾億條記錄，查詢一次要花費(fèi)小時(shí)計(jì)的時(shí)間，通過(guò)一個(gè)簡(jiǎn)單的rownum<2，查詢時(shí)間降低到秒級(jí)。單純的開發(fā)人員搞不定，普通的DBA也想不到，機(jī)器學(xué)習(xí)能做這種優(yōu)化么？現(xiàn)在不好判斷。

有遠(yuǎn)慮，不是壞事。但也無(wú)需太執(zhí)著于遠(yuǎn)慮，還是要把當(dāng)前的事情先做好。

如果你們的開發(fā)團(tuán)隊(duì)老是出一些表結(jié)構(gòu)設(shè)計(jì)問題、索引問題、劣質(zhì)SQL問題，不妨推薦他們先來(lái)上上D+學(xué)院先開設(shè)的精品SQL優(yōu)化課程。Oracle和MySQL都有，只要一天時(shí)間，可以跟業(yè)界一線DBA大師學(xué)習(xí)怎樣做SQL優(yōu)化，省時(shí)、省力、利人、利己。

當(dāng)然，如果你連1天完整時(shí)間都抽不出來(lái)，也不用氣餒，DBAplus仍然不定期將各類優(yōu)化妙文推送出來(lái)，給需要精進(jìn)的你。

原文作者：

Dana Van Aken，卡耐基梅隆大學(xué)，計(jì)算機(jī)科學(xué)博士生。

Andy Pavlo博士，卡耐基梅隆大學(xué)，計(jì)算機(jī)科學(xué)系數(shù)據(jù)庫(kù)學(xué)的助理教授。

Geoff Gordon博士，卡耐基梅隆大學(xué)副教授，機(jī)器學(xué)習(xí)系教學(xué)副主任。

原文鏈接：https://aws.amazon.com/cn/blogs/ai/tuning-your-dbms-automatically-with-machine-learning/?tag=vglnk-c1507-20返回搜狐，查看更多

責(zé)任編輯：

《新程序員》：云原生和全面數(shù)字化實(shí)踐50位技術(shù)專家共同創(chuàng)作，文字、視頻、音頻交互閱讀

總結(jié)

以上是生活随笔為你收集整理的mysql dba失业_DBA要失业了？AI优化水平超DBA老炮儿的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。