分布式數(shù)據(jù)庫(kù)創(chuàng)新技術(shù)獎(jiǎng)，TDSQL他來了！

日前，Distributed Cloud|2021全球分布式云大會(huì)·上海站隆重召開。騰訊云憑借其信息技術(shù)系統(tǒng)的安全可控性和前沿技術(shù)的創(chuàng)新性，在一眾企業(yè)中脫穎而出，榮獲“分布式數(shù)據(jù)庫(kù)創(chuàng)新技術(shù)獎(jiǎng)”。這是繼騰訊云數(shù)據(jù)庫(kù)TDSQL獲第四屆中國(guó)保險(xiǎn)大數(shù)據(jù)分析與人工智能創(chuàng)新國(guó)際峰會(huì)年度“保險(xiǎn)創(chuàng)新者大獎(jiǎng)”之后再次獲評(píng)。

在云原生專題論壇上，騰訊云數(shù)據(jù)庫(kù)產(chǎn)品專家梁文燦先生就騰訊云企業(yè)級(jí)分布式數(shù)據(jù)庫(kù)TDSQL生態(tài)發(fā)展戰(zhàn)略、落地應(yīng)用案例做出了詳細(xì)介紹。同時(shí)騰訊云數(shù)據(jù)庫(kù)專家工程師張遠(yuǎn)先生對(duì)云原生數(shù)據(jù)庫(kù)TDSQL-C的內(nèi)核關(guān)鍵技術(shù)進(jìn)行了深入解讀。

TDSQL-C基于全新計(jì)算存儲(chǔ)分離的分布式數(shù)據(jù)庫(kù)架構(gòu)，融合傳統(tǒng)數(shù)據(jù)庫(kù)和云計(jì)算技術(shù)優(yōu)勢(shì)，100%兼容MySQL和PostgreSQL，極致計(jì)算能力突破千核，存儲(chǔ)容量達(dá)PB級(jí)別，使得性能和安全性媲美商用數(shù)據(jù)庫(kù)。并且TDSQL-C支持集群和Serverless靈活彈性部署，克服傳統(tǒng)架構(gòu)下的存儲(chǔ)量受限、擴(kuò)展難、主從延遲高等缺點(diǎn)，充分釋放領(lǐng)先技術(shù)的成本效益，最高可為企業(yè)節(jié)省90%的成本。

下面帶來騰訊云數(shù)據(jù)庫(kù)專家工程師張遠(yuǎn)老師主題為《騰訊云TDSQL-C云原生數(shù)據(jù)庫(kù)技術(shù)》的文字版。

TDSQL-C簡(jiǎn)介

張遠(yuǎn)介紹說，TDSQL-C是騰訊云自研的新一代企業(yè)級(jí)云原生分布式數(shù)據(jù)庫(kù)，經(jīng)過五年的打磨，在總體架構(gòu)上，TDSQL-C是基于共享存儲(chǔ)的存儲(chǔ)和計(jì)算分離的架構(gòu)。

與傳統(tǒng)的MySQL主備架構(gòu)對(duì)比，可以看到傳統(tǒng)的MySQL主備通過binlog進(jìn)行邏輯復(fù)制，而TDSQL-C是通過redo日志進(jìn)行的物理復(fù)制；傳統(tǒng)的MySQL需要向存儲(chǔ)寫多份數(shù)據(jù)包括data，binlog，redo log等，而TDSQL-C只需向存儲(chǔ)寫一份redo日志即可；傳統(tǒng)的MySQL主備各存儲(chǔ)一份數(shù)據(jù)，而TDSQL-C基于共享存儲(chǔ)只有一份數(shù)據(jù)。

TDSQL-C具有以下幾個(gè)關(guān)鍵的特性：

（1）可靠性。TDSQL-C基于共享存儲(chǔ)的云原生架構(gòu)，存儲(chǔ)是多副本的，能夠保證數(shù)據(jù)可靠性。同時(shí)能夠做到即時(shí)回滾，任意時(shí)間數(shù)據(jù)都可靠。

（2）極致性能。騰訊云對(duì)主備機(jī)讀寫性能做了全面優(yōu)化，同時(shí)也根據(jù)不同規(guī)格做針對(duì)性優(yōu)化。

（3）可用性。TDSQL-C可以做到秒級(jí)的RTO，故障幾乎無(wú)感知，同時(shí)主備延遲可以做到毫秒級(jí)。此外，基于共享內(nèi)存，數(shù)據(jù)能夠快速恢復(fù)、快速預(yù)熱。

（4）彈性擴(kuò)展。數(shù)據(jù)能夠快速透明拓展，而且容量最大可以達(dá)到1PB，滿足大的需求。

TDSQL-C內(nèi)核關(guān)鍵技術(shù)

張遠(yuǎn)演講的第二部分圍繞關(guān)鍵特性展開，詳細(xì)介紹了TDSQL-C特性背后的技術(shù)原理和細(xì)節(jié)。

1、TDSQL-C之高性能

（1）TDSQL-C高性能-plan cache

TDSQL-C高性能的一個(gè)重要優(yōu)化是實(shí)現(xiàn)了查詢計(jì)劃緩存，稱之為plan cache。

圖中展示了一條SQL在數(shù)據(jù)庫(kù)中的執(zhí)行過程，會(huì)經(jīng)過以下幾個(gè)階段：

首先MySQL server接受到用戶的SQL請(qǐng)求，在parse階段解析為邏輯的執(zhí)行計(jì)劃樹，接下來在查詢優(yōu)化階段生成物理的查詢計(jì)劃，然后執(zhí)行器從存儲(chǔ)引擎獲取數(shù)據(jù)進(jìn)行計(jì)算。

經(jīng)過plan cache優(yōu)化后，一條SQL執(zhí)行過程省略了前面的解析和查詢優(yōu)化階段，SQL的執(zhí)行時(shí)間大大縮短了。

=優(yōu)化效果以sysbench場(chǎng)景為例，不同顏色代表不同階段的耗時(shí)，可以看到經(jīng)過plan cache優(yōu)化后，parse和查詢優(yōu)化時(shí)間減少了，性能提升了70%左右。

（2）TDSQL-C高性能-異步組提交

TDSQL-C是計(jì)算和存儲(chǔ)分離的架構(gòu)，因此計(jì)算節(jié)點(diǎn)和存儲(chǔ)節(jié)點(diǎn)之間的網(wǎng)絡(luò)IO存在一定時(shí)延。而寫事務(wù)提交時(shí)需要保證redo先刷盤才能完成提交，因此Redo日志刷盤存在網(wǎng)絡(luò)IO。TDSQL-C在線程池的基礎(chǔ)上進(jìn)行了異步組提交優(yōu)化，事務(wù)提交交給后臺(tái)線程異步完成，將線程池資源提前釋放從而能夠去處理更多的請(qǐng)求。優(yōu)化后整體的讀寫事務(wù)QPS有70%的提升。

（3）TDSQL-C高性能-Log Compaction

TDSQL-C是基于日志的數(shù)據(jù)庫(kù)，計(jì)算機(jī)節(jié)點(diǎn)和存儲(chǔ)節(jié)點(diǎn)之間有日志的傳輸，同時(shí)Master節(jié)點(diǎn)和TXStore存儲(chǔ)之間也有redo日志傳輸，TDSQL-C將redo日志進(jìn)行了壓縮。

下圖是redo日志的結(jié)構(gòu)，一條普通的redo日志包括日志頭和日志內(nèi)容，日志頭主要包括日志類型以及Space ID和pageno等信息。通常情況下日志頭占了日志的較大一部分。TDSQL-C對(duì)redo日志進(jìn)行壓縮存儲(chǔ)，對(duì)于同一頁(yè)面進(jìn)行修改的多條redo日志可以共享一個(gè)日志頭。優(yōu)化后redo日志量減少了30%。

2、TDSQL-C之高可用

（1）TDSQL-C高可用-物理復(fù)制

傳統(tǒng)的MySQL的是通過binlog進(jìn)行復(fù)制的。Binlog復(fù)制是在MySQL server層進(jìn)行的，binlog記錄的是邏輯的修改記錄，binlog在備庫(kù)apply需要經(jīng)過server層的parser,optimizer后再經(jīng)過engine的btree查找才能修改到對(duì)應(yīng)的記錄。這個(gè)路徑比較長(zhǎng)，復(fù)制速度慢。

而騰訊云TDSQL-C采用的是redo物理復(fù)制。Redo日志記錄的是頁(yè)面物理修改記錄，redo復(fù)制是在engine層進(jìn)行的，備庫(kù)apply redo日志不需要查找就可以直接定位到頁(yè)面，在內(nèi)存中完成頁(yè)面的修改，因此復(fù)制速度快。

更重要的一點(diǎn)是，TDSQL-C是基于共享存儲(chǔ)的，主備數(shù)據(jù)物理上是一致的，而binlog復(fù)制只能保證邏輯一致。

（2）TDSQL-C高可用-備庫(kù)延遲優(yōu)化

TDSQL-C高可用另一個(gè)優(yōu)化是備庫(kù)延遲優(yōu)化，TDSQL-C最多支持16個(gè)備庫(kù)提供讀服務(wù)，備庫(kù)延遲可以達(dá)到毫秒級(jí)別。其中一個(gè)優(yōu)化就是備庫(kù)讀寫IO沖突優(yōu)化。TDSQL-C備庫(kù)是提供讀服務(wù)的，同時(shí)備庫(kù)也會(huì)apply主庫(kù)傳來的redo日志。

張遠(yuǎn)以場(chǎng)景舉例說，首先用戶讀取pageA，pageA不在buffer pool中，那么會(huì)從TXStore中請(qǐng)求pageA，TXStore中請(qǐng)求pageA就存在網(wǎng)絡(luò)和IO的開銷。同時(shí)redo日志回放線程上有l(wèi)og1/log2/log3正在等待回放到pageA上。也就是說，用戶發(fā)起的讀操作可能阻塞redo日志回放線程，從而導(dǎo)致主備延遲。

優(yōu)化方案是將pageA上的redo日志緩存到page上的鏈表中，pageA IO完成以后再將鏈表中的redo日志回放到pageA上。這樣pageA的IO過程就不阻塞redo的回放了。

（3）TDSQL-C高可用-獨(dú)立buffer pool

TDSQL-C高可用的另一個(gè)優(yōu)化是獨(dú)立buffer pool。Buffer pool是InnoDB數(shù)據(jù)頁(yè)的緩存。計(jì)算節(jié)點(diǎn)HA重啟后，buffer pool需要重新加載進(jìn)行預(yù)熱，持續(xù)時(shí)間比較長(zhǎng)，期間業(yè)務(wù)會(huì)受到較大影響。

TDSQL-C將buffer pool從計(jì)算節(jié)點(diǎn)獨(dú)立出來放到共享內(nèi)存中，計(jì)算節(jié)點(diǎn)crash后buffer pool可以獨(dú)立存在。這樣一來，Buffer pool不需要預(yù)熱，重啟時(shí)間也縮短了。

（4）TDSQL-C高可用-秒級(jí)RTO

TDSQL-C在基于redo日志的架構(gòu)下，計(jì)算節(jié)點(diǎn)crash recovery不需要apply redo，redo的apply由存儲(chǔ)節(jié)點(diǎn)來完成。從而crash recovery時(shí)間相比傳統(tǒng)MySQL要快很多。在此基礎(chǔ)上，TDSQL-C做了更多的優(yōu)化，可以做到秒級(jí)RTO。例如經(jīng)過測(cè)試，大規(guī)格實(shí)例重啟速度比較慢。

例如buffer pool為500G的大實(shí)例重啟，初始化buffer pool耗時(shí)23秒，這對(duì)于用戶來說是不可接受的。優(yōu)化方案是并行初始化加pag上的mutex延遲初始化。并行初始化是指按InnoDB buffer pool instance來并行初始化。而page mutex延遲初始化，是指當(dāng)page首次使用時(shí)才初始化，而不是在啟動(dòng)時(shí)全部都初始化。優(yōu)化后buffer pool初始化速度提升近20倍，而且騰訊云將這個(gè)方案也貢獻(xiàn)給了MySQL官方。另外回滾段并行初始化也貢獻(xiàn)給了MySQL官方。

TDSQL-C之彈性擴(kuò)展

TDSQL-C備庫(kù)可以提供讀服務(wù)。為了提供更好的讀服務(wù)，騰訊云做了許多讀優(yōu)化。Btree一致性讀優(yōu)化就是其中一個(gè)。

Btree在數(shù)據(jù)的更新過程中會(huì)發(fā)生SMO操作，即btree的分裂或合并。

如圖所示，Btree發(fā)現(xiàn)分裂，page B分裂為pageB和pageC。Btree分裂時(shí)，用戶查詢pageB可能導(dǎo)致數(shù)據(jù)不一致甚至crash。但主庫(kù)在Btree發(fā)生分裂時(shí)會(huì)通過index鎖和page lock的方式保證正在發(fā)生分裂的page不被其他用戶訪問。但對(duì)于備庫(kù)來說，備庫(kù)通過redo日志不能感知Btree的SMO操作，SMO操作所產(chǎn)生的日志只有頁(yè)面修改的信息，redo日志中沒有index lock上鎖信息。因此備庫(kù)在SMO過程是沒有被保護(hù)的，備庫(kù)的查詢可能異常。

這里有一個(gè)可選方案就是將SMO操作index lock記錄到日志中，備庫(kù)解析index lock日志對(duì)整個(gè)btree加index lock。但index lock會(huì)鎖整個(gè)btree導(dǎo)致并發(fā)查詢性能比較差。

TDSQL-C對(duì)此進(jìn)行了優(yōu)化，MySQL的SMO操作是原子的，所有產(chǎn)生的redo日志都在一個(gè)mini-transaction中。引入新的日志類型來標(biāo)記redo日志中SMO操作的邊界。這樣用戶在查詢btree過程遇到page在SMO操作重新掃描btree即可。例如用戶訪問page A時(shí)會(huì)判斷一下page是否在SMO，如果A在，則會(huì)在mtr start和end之間則重試。

這樣優(yōu)化后，備庫(kù)讀不會(huì)被主庫(kù)更新產(chǎn)生的SMO操作所阻塞。

TDSQL-C其它特性

TDSQL-C秒改列（instant modify column）

在官方MySQL8.0支持instant add column后，修改列類型操作便順勢(shì)成為MySQL中最不友好的DDL類型，修改列類型既不是inplace的同時(shí)也需要rebuild table。而在我們用戶實(shí)踐中，修改列類型也是用戶執(zhí)行比較頻繁的DDL之一，而此操作會(huì)長(zhǎng)時(shí)間阻塞用戶的讀寫請(qǐng)求，對(duì)業(yè)務(wù)的影響非常大。

TDSQL-C創(chuàng)新的支持了instant modify column功能，達(dá)到了秒級(jí)修改列的效果。

具體的實(shí)現(xiàn)方式是：

a.元數(shù)據(jù)多版本化,表元數(shù)據(jù)保存列的多個(gè)版本信息，用戶只能看到的總是最新的表元數(shù)據(jù)。

b.行記錄增加版本信息對(duì)應(yīng)到不同版本的表元數(shù)據(jù)上。

c.修改列只修改元數(shù)據(jù)，修改列的過程中不修改實(shí)際的行記錄。

d.行記錄讀取時(shí)，老版本記錄會(huì)自動(dòng)轉(zhuǎn)換為最新版本的記錄。

e.行記錄更新時(shí)，老版本記錄會(huì)自動(dòng)更新為最新版本的記錄。

值得注意的是，這是業(yè)界首創(chuàng)的方案。

TDSQL-C purge預(yù)讀

Undo空間膨脹問題是MySQL歷史老大難問題，TDSQL-C創(chuàng)新的通過purge預(yù)讀解決了此問題。Purge會(huì)讀取undo page并清理delete mark的記錄，清理完成后會(huì)釋放undo page，從而最終釋放undo表空間。IO bound場(chǎng)景，purge時(shí)讀取undo page更容易出現(xiàn)remote IO。而remote IO時(shí)占用時(shí)間比較長(zhǎng)，導(dǎo)致purge不及時(shí)undo日志空間膨脹。

解決方法是實(shí)現(xiàn)purge預(yù)讀機(jī)制：

a.根據(jù)事務(wù)提交順序在內(nèi)存中保存undo page的purge順序用于預(yù)讀。

b.Purge coordinator異步預(yù)讀這些page。

TDSQL-C展望

展望TDSQL-C的未來發(fā)展，張遠(yuǎn)表示，未來TDSQL-C會(huì)進(jìn)一步加強(qiáng)查詢優(yōu)化的能力，比如增加新的join類型如SMJ，以及在parallel query上做一些拓展。同時(shí)TDSQL在支持多寫方面會(huì)進(jìn)一步探索，未來TDSQL-C也會(huì)向HTAP方向演進(jìn)，TDSQL-C會(huì)同時(shí)具備OLTP和OLAP的能力。