GaussDB for MySQL性能優(yōu)化的示例分析

小編給大家分享一下GaussDB for MySQL性能優(yōu)化的示例分析，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

背景

我們先來(lái)看看MySQL 8.0的事務(wù)提交的大致流程

以上流程，是MySQL8.0對(duì)WAL原則的一種實(shí)現(xiàn)，這個(gè)流程意味著，任何一個(gè)事務(wù)的提交，一定要完成write buffer和flush to disk流程。

然而那么這個(gè)流程中，有一個(gè)問(wèn)題：每個(gè)服務(wù)器的CPU是有限的，服務(wù)器能處理的Thread也是有上限的，那么當(dāng)我們的業(yè)務(wù)的并發(fā)數(shù)量，遠(yuǎn)遠(yuǎn)大于我們服務(wù)器能并行處理的數(shù)量時(shí)，那么后來(lái)的事務(wù)，只能等待前面的事務(wù)提交后才能被處理。在這之前，他們什么也做不了。因此，在大并發(fā)場(chǎng)景下，如何進(jìn)一步提升線程的使用率，是大并發(fā)事物寫(xiě)入的一個(gè)關(guān)鍵。

靈感來(lái)源于生活

一個(gè)優(yōu)化，并不是憑空想象出來(lái)的，有時(shí)候，往往來(lái)源于現(xiàn)實(shí)生活。下面，我們先來(lái)看看我們身邊，和事務(wù)提交流程非常類似的一個(gè)例子：快遞。

現(xiàn)在的快遞配送，一般一個(gè)快遞員會(huì)負(fù)責(zé)一片區(qū)域，快遞剛開(kāi)始興起時(shí)，數(shù)量不多，那么一個(gè)快遞員基本上可以在規(guī)定時(shí)間內(nèi)完成配送。

但是，隨著快遞數(shù)量越來(lái)越多，一個(gè)快遞員要在一個(gè)小區(qū)配送很長(zhǎng)的時(shí)間，才能到下一個(gè)小區(qū)，常常導(dǎo)致了快遞員無(wú)法準(zhǔn)時(shí)的配送。在這個(gè)問(wèn)題的催動(dòng)下，隨后，一個(gè)新的行業(yè)開(kāi)始出現(xiàn) – 快遞驛站。

快遞的優(yōu)化原理

接下來(lái)，讓我們來(lái)看下，快遞驛站究竟解決了什么問(wèn)題。

快遞的配送過(guò)程中，最耗時(shí)的，不是裝貨，不是卸貨，而是電話和等待。配送一個(gè)小區(qū)的時(shí)間，取決于這個(gè)最后一個(gè)來(lái)取快遞的人的時(shí)間，在最后一個(gè)人取完快遞錢(qián)，快遞員除了打電話，做不了其他任何事情（也沒(méi)有辦法通知下一個(gè)小區(qū)的人，因?yàn)樽詈笠粋€(gè)人來(lái)取得時(shí)間是無(wú)法確定的）。那么這個(gè)等待的時(shí)間，對(duì)于快遞員來(lái)說(shuō)，就是一種浪費(fèi)。

快遞驛站可以很大程度解決這個(gè)問(wèn)題，快遞員到了以后，只需要將快遞卸貨，即可前往下一個(gè)小區(qū)，剩下的事情，就可以由驛站的人員來(lái)完成，大大提升了快遞員的配送效率。

分析

回過(guò)頭來(lái)，我們看看數(shù)據(jù)庫(kù)，如果把Transaction線程看做快遞員，存儲(chǔ)上的文件看做取快遞的人，那么我們會(huì)發(fā)現(xiàn)兩者有非常大的相似性。那么我們可以像快遞配送優(yōu)化那樣去優(yōu)化事務(wù)的處理流程嗎？答案是可以的。

根據(jù)快遞驛站的優(yōu)化原理，我們知道，快遞驛站幫快遞員免去了等待客戶取貨的時(shí)間，那么事務(wù)處理過(guò)程中，有沒(méi)有等待的過(guò)程呢？答案是有的，存儲(chǔ)的IO就是一個(gè)較長(zhǎng)的等待。數(shù)據(jù)庫(kù)使用經(jīng)驗(yàn)豐富的開(kāi)發(fā)人員來(lái)都知道，等待redo日志寫(xiě)入存儲(chǔ)的磁盤(pán)IO性能，很大程度上決定了數(shù)據(jù)庫(kù)的寫(xiě)入性能。對(duì)于現(xiàn)代數(shù)據(jù)庫(kù)來(lái)說(shuō)，尤其對(duì)于GaussDB(for MySQL)這樣計(jì)算于存儲(chǔ)分離的數(shù)據(jù)庫(kù)，存儲(chǔ)的IO耗時(shí)，在事務(wù)處理的總耗時(shí)中，占據(jù)了不小的比例，雖然有l(wèi)og buffer的合并寫(xiě)入，提升并發(fā)情況下的整體吞吐，但是如果在等待IO的這段時(shí)間中，這些線程能夠去做別的事情（例如處理等待中的其他事務(wù)）。那么將會(huì)有進(jìn)一步的性能提升。

GaussDB(for MySQL)的優(yōu)化

既然找到了等待的點(diǎn)，那么我們就可以像快遞配送的優(yōu)化方法，為數(shù)據(jù)庫(kù)，也創(chuàng)造一個(gè)“快遞驛站”，讓“快遞驛站”來(lái)做等待的事情，而事務(wù)線程就可以去處理其他等待中的事務(wù)，讓CPU不會(huì)“閑下來(lái)”。

如圖5所示，GaussDB(for MySQL)當(dāng)redo日志的flush to disk動(dòng)作完成后，即可進(jìn)行事務(wù)提交，但是此時(shí)并不應(yīng)答客戶端，而是直接處理下一個(gè)事務(wù)。同時(shí)使用少量”post comit worker線程”，來(lái)批量等待日志寫(xiě)入完成（等待的過(guò)程其實(shí)并不占用CPU），并應(yīng)答客戶端，這就可以讓“等待”和“下一個(gè)事務(wù)的處理”并行化，讓CPU“閑不下來(lái)”。

實(shí)際測(cè)試

根據(jù)實(shí)際測(cè)試，在標(biāo)準(zhǔn)的sysbench寫(xiě)入模型下，沒(méi)有使用Post Commit時(shí)，極限性能是35萬(wàn)QPS左右，而使用Post commit后，可以到大42萬(wàn)以上的QPS，提升了20%的寫(xiě)入性能。

以上是“GaussDB for MySQL性能優(yōu)化的示例分析”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對(duì)大家有所幫助，如果還想學(xué)習(xí)更多知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道！