MySQL 8.0 | CATS排程演算法的效能提升
原文地址:
https://mysqlserverteam.com/contention-aware-transaction-scheduling-arriving-in-innodb-to-boost-performance/
譯者 沈剛
| 事務排程
目前大多數的資料庫系統都是通過鎖的方式來控制併發的情況。但是對於很多資料庫廠商來說,都會有一個問題:
當有多個事務同時需要獲取同一把鎖,那麼哪個事務應該最先獲得這把鎖?
包括之前版本的MySQL在內,幾乎所有的資料庫都是通過FIFO機制來解決這個問題。簡單來說,FIFO機制就是將鎖分配給最先請求該鎖的事務(即該事務在等待佇列的最前面,除非它們與當前鎖賦予的鎖不相容)。因為這種機制實現起來比較簡單,所以很多的資料庫廠商都是通過FIFO的策略進行事務排程,沒有考慮其他的排程策略。
最近一個密歇根大學的研究組織提出,這個問題背後隱藏著巨大的效能提升空間。Mozafari教授和他的學生證明了不同的鎖分配策略以及事務排程策略對於資料庫效能有著很大的影響。他們提出了一種稱之為Contention-Aware Transaction Scheduling(CATS)的演算法,使用這種演算法進行事務排程相較於之前的FIFO策略,顯著地減少了資料庫延遲,提高了吞吐量。
Oracle MySQL官方團隊和Mozafari教授以及他的學生們緊密合作,使得MySQL是第一個採用這種新技術的資料庫。在MySQL 8.0.3版本之後,CATS策略作為InnoDB的預設排程演算法,也就是說MySQL的使用者可以感覺到顯著的效能提升,尤其是在持續高壓力負載的情況下。
| CATS機制原理
CATS演算法是基於很簡單的一個觀點:不是所有的事務都是平等的,不是所有的物件都是平等的。當一個事務已經持有了多個物件的鎖,當該事務請求一個新的鎖的時候,該事務應該被優先分配。從另一個方面講,解鎖這樣的事務有助於解鎖更多的事務。因為該事務優先被分配鎖能更快的結束事務,釋放另外已經獲取到的物件的鎖。通過這種方式可以使資料庫獲得更高的吞吐和更低的延遲。
有一個比喻的例子:如果有一個計程車司機和一個公交車司機都在等咖啡,那麼先給公交車司機做咖啡(即使公交車司機比計程車司機遲來)可能會讓更多的人儘早到達他們的目的地。因為公交車上的乘客比計程車上的乘客多。這看起來似乎對計程車司機不公平,但是這種策略可以使得整個系統執行的更快,這對於系統內的每個人都是有利的。
當然,我們現在是在解決鎖的問題而不是交通司機的問題。讓我們通過一個簡單的例子來闡述一下CATS機制在資料庫中是如何工作的。我們知道在不同的事務隔離級別下,事務在讀取或者更新資料的時候,需要先獲取對應資料的鎖。當一個事務所需要的鎖已經被其他事務所持有了,那麼這個事務會一直等待直到其他事務釋放這個鎖。當事務已經持有一部分物件鎖的時候,可能會在獲取其他物件的鎖的時候一直被阻塞住,這個時候就需要死鎖檢測機制來檢測當前資料庫中沒有鎖等待迴圈,防止死鎖。來看下面這張圖:
Transaction contention
在這種場景下,FIFO策略很簡單,只需要考慮那個事務先請求O1物件的鎖。但是CATS演算法會更加智慧地處理這個情況:CATS演算法會計算每個事務直接阻塞和間接阻塞的事務數量,然後將O1物件的鎖分配給阻塞了更多事務的事務。在這個場景下,t1事務阻塞了4個事務,t2事務阻塞了3個事務。所以根據CATS演算法會將O1物件的鎖分配給t1事務。這樣可以將更多的事務釋放出來,這樣有利於提高系統整體的效能。
對於共享鎖(S鎖),CATS演算法會盡可能多的分配共享鎖。在這方面FIFO和CATS演算法有不同的地方。FIFO按照佇列的先後順序分配共享鎖,當遇到分配的物件上已經有排他鎖(X鎖)了,則停止分配。而在CATS中,按照事務阻塞的事務數進行倒序排序,然後按照這個順序進行鎖分配。
| CATS機制帶來的效能提升
Oracle的Dimitri Kravtchuk通過Sysbench 的OLTP指令碼測試這種新的演算法。通過結果顯示,在併發情況下,CATS演算法比FIFO演算法在TPS,平均延遲,95%延遲等指標方面都有顯著的效能提升。有趣的是,即使在沒有併發的情況下,CATS演算法的效能和FIFO演算法效能是一樣的。那是因為在沒有併發的時候,沒有事務需要進行排程,所以也就沒有效能的差異。換而言之,使用CATS演算法替換FIFO演算法,沒有任何損失,反而在資料庫繁忙的時候,有很大的效能提升。
CATS vs. FIFO in TPS, mean latency and 95th percentile (up to 5.05x improvement)
| 結論
MySQL是全球第一個使用這種最先進的CATS事務排程演算法的資料庫。這個演算法解決了資料庫在遇到高壓力情況下效能急劇下降的問題,這個也是MySQL 8.0主要想要達到的目標。
CATS演算法是針對當事務併發超過32的情況,這個數值沒有引數配置,是通過經驗設定的。
| 譯者簡介
沈 剛·沃趣科技資料庫技術專家
熟悉MySQL資料庫執行機制,豐富的資料庫及複製架構故障診斷、效能調優、資料庫備份恢復及遷移經驗。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/28218939/viewspace-2154297/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- MySQL 8.0 —— CATS事務排程演算法的效能提升MySql演算法
- MySQL優化--IO排程演算法優化MySql優化演算法
- MySQL8.0效能優化MySql優化
- cpu的排程演算法演算法
- 深度解讀昇騰CANN模型下沉技術,提升模型排程效能模型
- LVS排程演算法演算法
- MySQL8.0 view導致的效能問題MySqlView
- MySQL中的事件排程器EVENTMySql事件
- MySQL 配置InnoDB清理排程MySql
- Golang 的 協程排程機制 與 GOMAXPROCS 效能調優Golang
- MySQL5.7/8.0效能分析shell指令碼MySql指令碼
- MySQL8.0效能最佳化(實踐)MySql
- Ubuntu 16.04 安裝 MySQL 8.0 全過程UbuntuMySql
- T-One 社群版排程引擎替換至 runnerV2,效能提升 6.8 倍
- 程式排程的原理和演算法探析演算法
- 任務排程的並行演算法並行演算法
- 2.2.5排程演算法:時間片輪轉、優先順序排程、多級反饋排程演算法
- MySQL資料庫環境如何調整磁碟IO排程演算法MySql資料庫演算法
- Flink排程之排程器、排程策略、排程模式模式
- Linux系統下祼機安裝mysql8.0和docker mysql 8.0 效能差異對比~LinuxMySqlDocker
- 磁軌排程演算法介紹演算法
- linux之 修改磁碟排程演算法Linux演算法
- 從框架作者角度聊:React排程演算法的迭代過程框架React演算法
- MySQL效能基準測試對比:5.7 VS 8.0MySql
- Hadoop YARN:排程效能最佳化實踐HadoopYarn
- 演算法信仰的力量:改進演算法能提升多少效能?演算法
- cats 的集合 2
- cats 的集合 1
- 程式排程演算法之先到先服務演算法
- 作業系統之排程演算法作業系統演算法
- 排程器簡介,以及Linux的排程策略Linux
- 從零開始入門 K8s | 排程器的排程流程和演算法介紹K8S演算法
- Pod的排程是由排程器(kube-scheduler)
- cats 的電腦中毒
- PHP8.0新版再創奇蹟,效能提升10%,URLOS為您提供PHP8.0一鍵安裝方法PHP
- verilog的RR輪詢排程演算法的程式碼實現演算法
- Yarn的排程器Yarn
- 【作業系統】4.程序排程演算法作業系統演算法