騰訊雲TDSQL-C雲原生資料庫技術

9月16日，Distributed Cloud|2021全球分散式雲大會·上海站隆重召開。在全球分散式雲大會不懈佈道下，雲端計算行業對分散式雲的關注度愈發高漲，以全球分散式雲聯盟成員為代表，湧現出了大量分散式雲技術和實踐成果，為分散式雲端計算髮展夯實了基礎。

2021全球分散式雲大會為分散式雲端計算髮展再添強大推力，本次大會共設有分散式雲主題報告會、邊緣雲論壇、雲原生專題論壇、分散式資料庫論壇四大論壇，圍繞分散式雲、邊緣算力、雲原生、分散式架構等技術與實踐展開。全球分散式雲聯盟聯合阿里雲、騰訊雲、Google Cloud、中興通訊、京東雲、安邁雲、網心科技等國內外分散式雲頂尖技術服務商，共話分散式雲創新新趨勢，共謀雲端計算變革新未來，共享分散式雲端計算新紅利！

在9月16日下午召開的雲原生專題論壇上，騰訊雲資料庫專家工程師張遠發表了題為**《騰訊雲TDSQL-C雲原生資料庫技術》**的精彩演講。

# TDSQL-C簡介

張遠介紹說，TDSQL-C是騰訊雲自研的新一代企業級雲原生分散式資料庫，經過五年的打磨，**具有以下幾個關鍵的特性：**

**可靠性。**TDSQL-C基於共享儲存的雲原生架構，儲存是多副本的，能夠保證資料可靠性。同時能夠做到即時回滾，任意時間資料都可靠。

**極致效能。**騰訊雲對主備機讀寫效能做了全面優化，同時也根據不同規格做針對性優化。

**可用性。**TDSQL-C可以做到秒級的RTO，故障幾乎無感知，同時主備延遲可以做到毫秒級。此外，基於共享記憶體，資料能夠快速恢復、快速預熱。

**彈性擴充套件。**資料能夠快速透明擴充，而且容量最大可以達到1PB，滿足大的需求。


在總體架構上，TDSQL-C是基於共享儲存的儲存和計算分離的架構。與傳統的MySQL主備架構對比，可以看到傳統的MySQL主備通過binlog進行邏輯複製，而TDSQL-C是通過redo日誌進行的物理複製；傳統的MySQL需要向儲存寫多份資料包括data，binlog，redo log等， 而TDSQL-C只需向儲存寫一份redo日誌即可；傳統的MySQL主備各儲存一份資料，而TDSQL-C基於共享儲存只有一份資料。

# TDSQL-C核心關鍵技術

張遠演講的第二部分會圍繞關鍵特性展開，詳細介紹了TDSQL-C特性背後的技術原理和細節。

TDSQL-C之高效能。

TDSQL-C 高效能-plan cache

TDSQL-C 高效能的一個重要優化是實現了查詢計劃快取，稱之為plan cache。

圖中展示了一條SQL在資料庫中的執行過程，會經過以下幾個階段：

**首先MySQL server接受到使用者的SQL請求，在parse階段解析為邏輯的執行計劃樹；接下來在查詢優化階段生成物理的查詢計劃；然後執行器從儲存引擎獲取資料進行計算。**


經過plan cache優化後，一條SQL執行過程省略了前面的解析和查詢優化階段，SQL的執行時間大大縮短了。


優化效果以sysbench場景為例，不同顏色代表不同階段的耗時，可以看到經過plan cache優化後，parse和查詢優化時間減少了，效能提升了70%左右。

**TDSQL-C高效能-非同步組提交**


TDSQL-C是計算和儲存分離的架構，因此計算節點和儲存節點之間的網路IO存在一定時延。而寫事務提交時需要保證redo先刷盤才能完成提交，因此Redo日誌刷盤存在網路IO。TDSQL-C線上程池的基礎上進行了非同步組提交優化，事務提交交給後臺執行緒非同步完成，將執行緒池資源提前釋放從而能夠去處理更多的請求。優化後整體的讀寫事務QPS有70%的提升。

**TDSQL-C 高效能-Log Compaction**

TDSQL-C是基於日誌的資料庫，計算機節點和儲存節點之間有日誌的傳輸，同時Master節點和TXStore儲存之間也有redo日誌傳輸，TDSQL-C將redo日誌進行了壓縮。


下圖是redo日誌的結構，一條普通的redo日誌包括日誌頭和日誌內容，日誌頭主要包括日誌型別以及Space ID和pageno等資訊。通常情況下日誌頭佔了日誌的較大一部分。TDSQL-C對redo日誌進行壓縮儲存，對於同一頁面進行修改的多條redo日誌可以共享一個日誌頭。優化後redo日誌量減少了30%。


# TDSQL-C之高可用

**TDSQL-C 高可用-物理複製**


傳統的MySQL的是通過binlog進行復制的。Binlog複製是在MySQL server層進行的，binlog記錄的是邏輯的修改記錄，binlog在備庫apply需要經過server層的parser,optimizer後再經過engine的btree查詢才能修改到對應的記錄。這個路徑比較長，複製速度慢。

而騰訊雲TDSQL-C採用的是redo物理複製。Redo日誌記錄的是頁面物理修改記錄，redo複製是在engine層進行的，備庫apply redo日誌不需要查詢就可以直接定位到頁面，在記憶體中完成頁面的修改。因此複製速度快。

更重要的一點是，TDSQL-C是基於共享儲存的，主備資料物理上是一致的，而binlog複製只能保證邏輯一致。

**TDSQL-C 高可用-備庫延遲優化**

TDSQL-C高可用另一個優化是備庫延遲優化，TDSQL-C最多支援16個備庫提供讀服務，備庫延遲可以達到毫秒級別。其中一個優化就是備庫讀寫IO衝突優化。TDSQL-C備庫是提供讀服務的，同時備庫也會apply主庫傳來的redo日誌。

張遠以場景舉例說，首先使用者讀取pageA，pageA不在buffer pool中，那麼會從TXStore中請求pageA，TXStore中請求pageA就存在網路和IO的開銷。同時redo日誌回放執行緒上有log1/log2/log3正在等待回放到pageA上。也就是說，使用者發起的讀操作可能阻塞redo日誌回放執行緒，從而導致主備延遲。


優化方案是將pageA上的redo日誌快取到page上的連結串列中，pageA IO完成以後再將連結串列中的redo日誌回放到pageA上。這樣pageA的IO過程就不阻塞redo的回放了。

**TDSQL-C 高可用-獨立buffer pool**

TDSQL-C 高可用的另一個優化是獨立buffer pool。Buffer pool是InnoDB資料頁的快取。

計算節點HA重啟後，buffer pool需要重新載入進行預熱，持續時間比較長，期間業務會受到較大影響。

TDSQL-C 將buffer pool從計算節點獨立出來放到共享記憶體中，計算節點crash後buffer pool可以獨立存在。這樣一來，Buffer pool 不需要預熱，重啟時間也縮短了。

**TDSQL-C 高可用-秒級RTO**

TDSQL-C在基於redo日誌的架構下，計算節點crash recovery不需要apply redo，redo的apply由儲存節點來完成。從而crash recovery時間相比傳統MySQL要快很多。在此基礎上，TDSQL-C做了更多的優化，可以做到秒級RTO。例如經過測試，大規格例項重啟速度比較慢，例如buffer pool為500G的大例項重啟，初始化buffer pool耗時23秒，這對於使用者來說是不可接受的。優化方案是並行初始化加pag上的mutex延遲初始化。並行初始化是指按InnoDB buffer pool instance來並行初始化。而page mutex延遲初始化，是指當page首次使用時才初始化，而不是在啟動時全部都初始化。優化後buffer pool初始化速度提升近20倍，而且騰訊雲將這個方案也貢獻給了MySQL官方。另外回滾段並行初始化也貢獻給了MySQL官方。

**TDSQL-C 之彈性擴充套件**

TDSQL-C 備庫可以提供讀服務。為了提供更好的讀服務，騰訊雲做了許多讀優化。Btree一致性讀優化就是其中一個。

Btree在資料的更新過程中會發生SMO操作，即btree的分裂或合併。


如圖所示，Btree發現分裂，page B分裂為pageB和pageC。Btree分裂時，使用者查詢pageB可能導致資料不一致甚至crash。但主庫在Btree發生分裂時會通過index鎖和page lock的方式保證正在發生分裂的page不被其他使用者訪問。但對於備庫來說，備庫通過redo日誌不能感知Btree的SMO操作，SMO操作所產生的日誌只有頁面修改的資訊，redo日誌中沒有index lock上鎖資訊。因此備庫在SMO過程是沒有被保護的，備庫的查詢可能異常。

這裡有一個可選方案就是將SMO操作index lock記錄到日誌中，備庫解析index lock日誌對整個btree加index lock。但index lock會鎖整個btree導致併發查詢效能比較差。


TDSQL-C對此進行了優化，MySQL的SMO操作是原子的，所有產生的redo日誌都在一個mini-transaction中。引入新的日誌型別來標記redo日誌中SMO操作的邊界。這樣使用者在查詢btree過程遇到page在SMO操作重新掃描btree即可。例如使用者訪問page A時會判斷一下page是否在SMO，如果A在在mtr start和end之間則重試。

這樣優化後，備庫讀不會被主庫更新產生的SMO操作所阻塞。

# TDSQL-C 其它特性

**TDSQL-C 秒改列（instant modify column）**

在官方MySQL8.0支援instant add column後，修改列型別操作便順勢成為MySQL中最不友好的DDL型別，修改列型別既不是inplace的同時也需要rebuild table。而在我們使用者實踐中，修改列型別也是使用者執行比較頻繁的DDL之一，而此操作會長時間阻塞使用者的讀寫請求，對業務的影響非常大。

TDSQL-C創新的支援了instant modify column功能，達到了秒級修改列的效果。


**具體的實現方式是：**

後設資料多版本化, 表後設資料儲存列的多個版本資訊，使用者只能看到的總是最新的表後設資料。

行記錄增加版本資訊對應到不同版本的表後設資料上。

修改列只修改後設資料，修改列的過程中不修改實際的行記錄。

行記錄讀取時，老版本記錄會自動轉換為最新版本的記錄。

行記錄更新時，老版本記錄會自動更新為最新版本的記錄。

值得注意的是，這是業界首創的方案。

**TDSQL-C purge預讀**

Undo 空間膨脹問題是MySQL歷史老大難問題，TDSQL-C創新的通過purge預讀解決了此問題。

Purge會讀取undo page並清理delete mark的記錄，清理完成後會釋放undo page，從而最終釋放undo表空間。

IO bound場景， purge時讀取undo page更容易出現remote IO。而remote IO時佔用時間比較長，導致purge不及時undo日誌空間膨脹。

解決方法是實現purge預讀機制：根據事務提交順序在記憶體中儲存undo page的purge順序用於預讀。Purge coordinator非同步預讀這些page。


# TDSQL-C展望 

展望TDSQL-C的未來發展，張遠表示，未來TDSQL-C會進一步加強查詢優化的能力，比如增加新的join型別如SMJ， 以及在parallel query上做一些擴充。同時TDSQL在支援多寫方面會進一步探索，未來TDSQL-C也會向HTAP方向演進，TDSQL-C會同時具備OLTP和OLAP的能力。