mysql dba失业_DBA要失业了？AI优化水平超DBA老炮儿
原標題：DBA要失業了？AI優化水平超DBA老炮兒
上周末，最不開心的應該是優秀的數據庫管理員了。
這些優秀的數據庫管理員(以下簡稱數據庫管理員為DBA)，原本可以靠自己的本事，享受高薪，可是，好景不長了，因為即便是資質平平的DBA，以后借助AI的力量，也能瞬間達到優秀DBA的水平。
來看最近來自卡耐基梅隆數據庫小組的最新研究成果，他們正用最新的深度學習技術，完成數據庫的調優工作。
卡耐基梅隆大學數據庫組的研究員和學生們研發了一款新工具，叫做OtterTune。OtterTune可以從數據庫成百上千個配置開關中自動發現最佳設置。它的目標是讓隨便一個工程師都可以更容易去部署一套關系型數據庫，即使他們在數據庫管理方面沒有任何專業知識也行。
OtterTune與其他的數據庫配置工具不一樣，因為它利用調優先前的數據庫配置知識去調優新的數據庫配置。這可以顯著地降低調優一個新的數據庫部署所需時間及相關的資源。為了做到這一點，OtterTune維持著一個資料庫，其中存放了從先前調優環境中采集回來的調優數據。OtterTune使用這些調優模型來指導新應用程序的實驗，推薦能夠改進目標對象(比如降低延時或者提升吞吐量)的設置。
在這篇文章中，我們討論OtterTune工具 ML pipeline(機器學習的工作流API庫)的每個組件，并展示他們之間怎樣互相協作去調優一個數據庫配置。我們在MySQL和Postgre上評估OtterTune的調優能力，通過將OtterTune最佳配置的性能與DBA選擇的配置及其他自動調優工具的配置得出的性能做比較。
OtterTune是一個開源工具，由卡耐基梅隆大學數據庫研究組的研究員和學生們研發。所有的工具代碼都放在GitHub上，遵從Apache License 2.0協議授權。
Otter Tune怎樣工作？
在一個新的調優場景，首先，用戶告訴OtterTune要通過調優來滿足哪個目標對象(比如，延遲或者吞吐量)。客戶端的控制器(controller)連接到目標數據庫，搜集它的Amazon EC2實例類型和當前配置。
然后控制器開始它的第一個探測周期，在這個期間內，它監控數據庫，并記錄目標對象。探測周期結束的時候，控制器從數據庫中采集好內部指標，比如MySQL中從磁盤讀取的頁面和寫到磁盤的頁面(pages)的計數器。控制器會將目標對象和內部指標信息都傳遞給調優管理器(tuning manager)。
當OtterTune調優管理器收到這些指標后，把它們存放在資料庫當中。OtterTune使用這些結果，計算下一個要部署的目標數據庫的配置。調優管理器將這一配置信息傳輸給控制器，并告訴控制器，采納這一配置后可能會獲得的性能提升。用戶可以決定是繼續調優，還是結束這次優化工作。
注意
OtterTune為它支持的每個數據庫版本維護著一個配置開關的黑名單。黑名單包括那些調整了不會產生效果的配置開關(比如，數據庫中存放文件的路徑名)，或者這些開關會有嚴重的或者潛在不良后果(比如，可能會導致數據庫丟失數據)。每場調優開始的時候，OtterTune都會給用戶提供一個黑名單，所以他/她可以增加其他開關進去，如果他們希望OtterTune不要去調優這部分的話。
OtterTune作了一些假設限制，可能會限制了一些用戶的可用性。比如，它假定用戶有允許控制器更改數據庫配置的管理權限。如果用戶沒有這個權限，那他或者她可以在其他硬件上部署一個數據庫鏡像，用于OtterTune調優實驗。這就需要用戶去重演(replay)一個工作負載跟蹤，或者在生產數據庫中轉發查詢。關于假定和限制的完整討論，詳見我們的論文(讀者可以點擊文末的“閱讀原文”進行閱讀)。
ML pipeline
下面的圖中展示了通過OtterTune的ML pipeline，數據在移動過程中是如何處理的。所有探查數據都存放在OtterTune資料庫中。
OtterTune首先將探測數據傳給“工作負載表征”(Workload Characterization)組件。該組件識別一組較小的數據庫指標度量，可以最佳地捕獲性能上的差異性，以及不同工作負載的區別特征。
接著，開關識別組件(Knob Identification)生成一個開關的排名列表，以對數據庫性能的影響度大小排序。OtterTune將所有這些信息提供給自動調優器(Automatic Tuner)組件。該組件在它的數據資料庫中為目標數據庫負載匹配(map)最相似的負載，并用這個負載數據生成最佳配置。
讓我們把ML pipeline中的每個組件再詳細說說。
工作負載表征(Workload Characterization)組件：OtterTune使用數據庫內部運行時的度量指標來表征(或識別)工作負載的行為。這些度量指標提供了負載的準確表現，因為它們捕獲了運行時行為的許多因素。可是，很多度量指標是冗余的，一些是相同的度量記錄只是單位不同，其他的則是表現數據庫不同組件，它們的值高度相關。所以裁剪冗余度量就很重要，這可以降低ML模型使用它們的時候的復雜性。為此，我們根據其相關性模型對數據庫的度量指標進行了聚類。然后，我們從每個聚類中選擇一個作為代表度量，就是最靠近聚類中心的那個度量。ML pipeline的后續組件直接使用這些度量。
開關識別組件(Knob Identification)：數據庫中可能有幾百個開關，但只有一小部分會影響數據庫的性能。OtterTune使用一個叫做Lasso的流行特征選擇(feature-selection)技術，來確定哪些開關會很大程度上影響系統的整體性能。通過使用這一技術于資料庫中的數據，OtterTune就可以列出數據庫中這些開關的重要性順序。
然后，OtterTune必須決定，做配置推薦的時候用多少個開關。使用太多必然會顯著增加OtterTune的調優時間。用得太少又會妨礙OtterTune去找到最佳配置。OtterTune使用漸進化的方式自動化這一過程，在調優時它會逐漸增加開關的個數。這個方式讓OtterTune在擴展到更多開關之前，探尋和優化一組最重要的開關配置。
自動調優(Automatic Tuner)組件：自動調優組件通過在每個觀察周期之后執行“兩步分析”(two-step analysis)來確定OtterTune應推薦的配置。
首先，系統使用工作負載表征組件中標識的度量性能數據，識別來自先前調優場景的最能匹配目標數據庫負載的負載。它將當前場景的度量指標與先前場景的度量指標進行比較，以確定哪些指標與不同的開關設置類似。
然后，OtterTune會選擇另一個開關設置去嘗試。它適用一個統計模型，搜集數據，與資料庫中最相近負載的數據一樣。這個模型讓OtterTune可以預測實施每個可能的配置后，數據庫性能會怎樣。OtterTune優化下一個配置，采用探索的方式(搜集信息以改進模型)而不是剝削的方式(試圖只在目標度量上就貪婪地做好)。
實現
OtterTune用Python編寫。
對工作負載表征和開關識別組件來說，運行時的性能并不特別需要考慮，因此我們用scikit-learn來實現相應的機器學習算法。這些算法以后臺進程的形式運行，并使用OtterTune資料庫中的新數據。
對自動優化組件來說，機器學習算法在關鍵路徑上。他們在每一個觀察周期后運行，獲取新數據以便OtterTune能取得一個開關配置進行下一次嘗試。因為它的性能是要特別考慮的，我們用TensorFlow來實現其算法。
搜集關于數據庫硬件的數據、開關配置以及運行時的性能度量指標，我們將OLTP-Bench測評框架集成到OtterTune的控制器中。
實驗設計
為了評估效果，我們使用OtterTune選擇的最佳配置來比較MySQL和Postgre的性能：
默認配置：數據庫安裝時的配置
優化腳本：由一個開源調優工具生成的配置
DBA：人類DBA選擇的配置
RDS：由亞馬遜研發定制的數據庫配置，部署在相同的EC2實例類型上
我們所有的實驗都是在Amazon EC2 Spot Instance上完成的。每一個實驗都用了2個實例：一個作為OtterTune控制器，一個作為目標數據庫部署用。我們分別使用m4.large和m3.xlarge實例類型。我們將OtterTune調優管理器和資料庫部署在本地服務器上，配置是20核CPU、128G內存。我們用TPC-C負載模型，這是評估OLTP系統性能的工業標準。
評估
對實驗中我們用到的每一種數據庫，MySQL及Postgre，我們評估延遲和性能。下面的圖展示了評估結果。第一個圖表展示了第99百分位數指標的延遲數量，代表完成交易所需的“最壞情況”時間長度。第二個圖展示吞吐量的結果，評估的是每秒完成的平均事務數。
MySQL評估結果：
比較由OtterTune生成的最佳配置與其他工具的“優化腳本”、RDS生成的配置，OtterTune推薦的配置對MySQL數據庫大約降低了60%的延遲，提升了22%到35%的吞吐量。OtterTune生成的配置幾乎與DBA做的選擇一樣好。
只有一些MySQL的開關會顯著影響TPC-C負載的性能。由OtterTune生成的配置和DBA為每個開關提供了很好的設置。RDS干的稍微要差點，因為它為一個開關提供了不是最優的設置。“優化腳本”的配置表現最差，因為它只改了一個開關。
Postgre評估結果：
對延遲來說，OtterTUne生成的配置，與“優化腳本”、DBA、RDS差不多，相對Postgre的默認設置都獲得了不少的提升。我們可以將其歸因于OTLP測評工具客戶端和數據庫之間的網絡開銷。對于吞吐量，OtterTune設置相對DBA和“優化腳本”的設置得到了12%的提升，相對RDS，得到了32%的提升。
跟MySQL相似，只要少數開關顯著影響Postgre的性能。OtterTune、DBA、“優化腳本”以及RDS都調整了所有這些開關，大多都提供了合理的設置。
結論
OtterTune為關系型數據庫的配置開關自動化發現最佳設置，用于調優新的數據庫部署，重用從先前調優場景獲取的訓練數據。因為OtterTune不需要為訓練ML模型生成廚師數據集，所需調優時間大大減少。
譯后記
OtterTune為關系型數據庫的配置開關自動化發現最佳設置，用于調優。
不客氣地說，OtterTune目前也只是支持MySQL和Postgre兩種數據庫，而且只是在開關設置層面，相比Oracle數據庫在自動化管理方面的強大功力，OtterTune只能算是一個玩具。我突然想到，2004年的時候，我去貴州給某個運營商做Oracle數據庫優化，只是把SGA從100M調大到1GB，客戶的核心業務整體性能就得到了飛速提升。放到今天來說是個不可思議的事情，今天隨便一個省級運營商的核心系統標配可能都是一個TB的內存，缺省安裝的時候，工程師就會把SGA缺省配到700G，其他相關參數也會按所謂的最佳實踐進行。
但是，沒有開關的問題，不代表就沒有數據庫的性能問題。
時至今日，Oracle數據庫的性能問題依然層出不窮(不是因為Oracle不行，其他數據庫還在后面遠遠的跟著Oracle在前進呢)，參數開關層面基本已經不太可能有遺漏。性能問題更多的層面來自于開發，開發部門數據模型設計得不合理，開發人員SQL寫得不合理，往往導致了90%的性能問題。前兩天朋友談及的一個案例，某銀行的信用卡業務查詢，每天一次，表當然有幾億條記錄，查詢一次要花費小時計的時間，通過一個簡單的rownum<2，查詢時間降低到秒級。單純的開發人員搞不定，普通的DBA也想不到，機器學習能做這種優化么？現在不好判斷。
有遠慮，不是壞事。但也無需太執著于遠慮，還是要把當前的事情先做好。
如果你們的開發團隊老是出一些表結構設計問題、索引問題、劣質SQL問題，不妨推薦他們先來上上D+學院先開設的精品SQL優化課程。Oracle和MySQL都有，只要一天時間，可以跟業界一線DBA大師學習怎樣做SQL優化，省時、省力、利人、利己。
當然，如果你連1天完整時間都抽不出來，也不用氣餒，DBAplus仍然不定期將各類優化妙文推送出來，給需要精進的你。
原文作者：
Dana Van Aken，卡耐基梅隆大學，計算機科學博士生。
Andy Pavlo博士，卡耐基梅隆大學，計算機科學系數據庫學的助理教授。
Geoff Gordon博士，卡耐基梅隆大學副教授，機器學習系教學副主任。
原文鏈接：https://aws.amazon.com/cn/blogs/ai/tuning-your-dbms-automatically-with-machine-learning/?tag=vglnk-c1507-20返回搜狐，查看更多
責任編輯：
《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀總結
以上是生活随笔為你收集整理的mysql dba失业_DBA要失业了？AI优化水平超DBA老炮儿的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： java 加法表编程_java编程——数
- 下一篇： mysql 万亿数据_sql-serve