SIGMOD2021|業(yè)務驅(qū)動背景下，騰訊云原生數(shù)據(jù)庫TDSQL-C的技術演變之路

6月20-25日，數(shù)據(jù)庫國際頂會2021 ACM SIGMOD在西安舉行。本屆大會上，騰訊云數(shù)據(jù)庫技術總監(jiān)邱敏帶來了主題為“騰訊云數(shù)據(jù)庫技術演變之路”的演講。

以下為演講內(nèi)容的文字實錄：

數(shù)據(jù)庫是三大基礎軟件之一。近年來，騰訊也在不斷加強各類數(shù)據(jù)庫產(chǎn)品的研發(fā)投入。企業(yè)級分布式數(shù)據(jù)庫TDSQL是騰訊云數(shù)據(jù)庫的代表性產(chǎn)品，同時具備OLTP、OLAP，以及混合OLTP和OLAP的HTAP能力。它包括以下幾個系列的產(chǎn)品：

·企業(yè)級MySQL即騰訊云數(shù)據(jù)庫RDS系統(tǒng)(CDB)，相對原生MySQL進行了大量內(nèi)核級補丁修復、特性優(yōu)化和企業(yè)級功能，包括SQL審計，數(shù)據(jù)庫加密和防火墻等。

·云原生數(shù)據(jù)庫TDSQL-C，采用計算與存儲分離架構的共享存儲產(chǎn)品。包含兩大兼容版本：即MySQL版與PostgreSQL版。

·兼容MySQL的金融級分布式數(shù)據(jù)庫TDSQL-D。其基于零共享架構，適合具有海量數(shù)據(jù)和事務交易場景使用。

·分析型分布式數(shù)據(jù)庫TDSQL-A?；贛PP架構，具備出色的HTAP能力，和自主研發(fā)的列存引擎，它還與Oracle高度兼容。

TDSQL產(chǎn)品廣泛應用于不同領域，涵蓋電子商務、政務、金融、社交網(wǎng)絡、娛樂、視頻等，在騰訊公司內(nèi)則包括眾所周知的王者榮耀、微笑支付等。目前，騰訊云數(shù)據(jù)庫實例部署規(guī)模超過一百萬個CPU內(nèi)核，擁有超過100PB級存儲規(guī)模。

由于今天時間有限，不能涵蓋每一種產(chǎn)品。以下主要介紹云原生數(shù)據(jù)庫TDSQL-C。

1 TDSQL-C架構體系優(yōu)化

首先介紹TDSQL-C的體系架構。眾所周知，云原生本質(zhì)上是一套利用云基礎設施來為客戶提供具有成本效益和高度可用性的解決方案的技術體系和理念。云原生數(shù)據(jù)庫也是如此。

首先，我們來看當前MySQL數(shù)據(jù)庫架構存在哪些問題，以及為了構建云原生數(shù)據(jù)庫我們必須解決哪些挑戰(zhàn)。

第一，假設在傳統(tǒng)的MySQL集群中，每當一個節(jié)點加入集群時，它就必須創(chuàng)建完全相同數(shù)據(jù)的副本。一般來說，在本地存儲中，部署從屬實例時，數(shù)據(jù)庫越大，啟動實例所需的時間就越長。而且它增加了冗余存儲消耗。這是沒必要的，并且在某種程度上是浪費。舉個例子，“一主三從”集群的1TB容量數(shù)據(jù)庫，將完全占據(jù)約4TB的存儲空間。

第二，當單機磁盤存儲容量達到上限時，就必須將數(shù)據(jù)庫實例遷移到更大的節(jié)點，這個過程非常復雜也非常耗時。從可靠性和可用性方面來說，異步復制中可能發(fā)生數(shù)據(jù)丟失。同步復制安全性更高，但延遲也更高。此外，從HA切換恢復可能需要更長的時間，從DBA的角度來看，災備發(fā)生HA的時候，這個時間點是不可控的。

第三，計算與存儲緊耦合可能導致硬件資源利用率不理想。例如可以想象如下場景，當磁盤即將打滿時，但CPU使用率非常低。出于存儲目的，必須遷移到更大容量的機器。更大的機器通常配有高端CPU資源。這意味著客戶在大多數(shù)時候必須為CPU支付更多費用，這對于云的客戶而言沒有成本優(yōu)勢。

為了解決前述問題，我們要對數(shù)據(jù)庫架構進行一些根本性改造，即具備全新架構的云原生數(shù)據(jù)庫TDSQL-C(原CynosDB)。相同的地方是，它仍然是“一主多從”架構，支持一個讀寫節(jié)點、多個備庫節(jié)點，備庫節(jié)點最多可以擴展到15個讀節(jié)點。但最大的變化是其實現(xiàn)了計算與存儲分離，主節(jié)點和備節(jié)點共享一份存儲。TDSQL-C主備之間和原生MySQL不同的是它使用Redo log進行主備數(shù)據(jù)同步——Redo log發(fā)送到備庫之后只負責同步備庫的Buffer Pool，其性能比原始方案有極大的提升。TDSQL-C同時實現(xiàn)了新的數(shù)據(jù)庫概念，如日志即數(shù)據(jù)庫。

這使得計算層得以輕量化，對于實例啟動和關閉以及集群擴容和縮容非常方便。

計算存儲分離的架構，其好處是顯而易見的：計算節(jié)點和存儲節(jié)點可以單獨擴容。在計算節(jié)點上，TDSQL-C可以支持靈活的資源配置，從低端的1/4核和0.5GB內(nèi)存一直到96核和768GB內(nèi)存。與其他優(yōu)化一起，讀寫性能得到顯著提高——TDSQL-C單體實例可支撐上P數(shù)據(jù)百萬QPS。此外，對于備份的故障轉(zhuǎn)移和快照，操作可以秒級完成，同時回檔速度也是GB級的。

2 TDSQL-C的核心技術創(chuàng)新

以下介紹TDSQL-C關鍵技術突破。分為兩部分，一部分是Serverless功能，另一部分是性能優(yōu)化。

2.1 Serverless

第一個功能是計算存儲分離。實際上，將存儲層與計算層分離是彈性擴展和Serverless的第一步。

TDSQL-C計算和存儲分離，但是計算節(jié)點的主備節(jié)點會共享存儲，即Histor。和傳統(tǒng)MySQL架構不同，它是一個可計算存儲，體現(xiàn)在兩點：主節(jié)點的計算節(jié)點會把產(chǎn)生的Redo日志下發(fā)到存儲層，存儲層會依賴于它的Base page以及所產(chǎn)生的Redo log來負責數(shù)據(jù)的持久化操作，存儲層在收到Redo log后才會向計算層反饋信息，說明Redo log已經(jīng)持久化，證明現(xiàn)在的事務已經(jīng)結束，可以讓業(yè)務邏輯繼續(xù)進行。業(yè)務邏輯在進行的同時，存儲層會異步處理Redo log。和傳統(tǒng)的MySQL架構相比，不會有刷臟頁帶來的一些性能抖動問題。

在Histor把數(shù)據(jù)持久化之后，會把之前Redo log所占的空間回收。而我們的存儲也有以下特性：我們在把本地磁盤映射到網(wǎng)絡盤時，是根據(jù)它的物理地址映射到底下存儲空間的某一個cell中，所以它的日志是按照頁面來進行分發(fā)，每一個cell里都有相應的數(shù)據(jù)頁和Redo log。主節(jié)點和備節(jié)點共享存儲數(shù)據(jù)，支持多數(shù)據(jù)版本。數(shù)據(jù)多版本是由Base page加上從計算層傳遞下來的Redo log生成的一個具有指定版本的數(shù)據(jù)來實現(xiàn)的。

第二個功能是通過細粒度的資源統(tǒng)計，實現(xiàn)客戶只需按實際使用計費，不使用不收費。過去，隨著數(shù)據(jù)規(guī)模不斷增加，即使之后刪除數(shù)據(jù)，數(shù)據(jù)實際規(guī)模已大大縮小，但是已用空間不會減小，客戶仍需要為未使用空間資源買單。為了準確計算空間使用量，我們利用三個鏈表分別管理不同使用狀態(tài)的extent:完全占用，部分占用和未占用。只有完全占用和部分占用的extent才會被添加到空間使用計算規(guī)則中，從而幫助客戶節(jié)省成本。此外，TDSQL-C在分配空間的時候以1兆為單位進行分配，根據(jù)是否占用決定實際的計費存儲量。當資源無需被使用時，我們會將其回收到資源池，以便用于其它目的。所以從用戶的角度出發(fā)，降低了用戶的計費存儲量。后續(xù)我們還會繼續(xù)優(yōu)化，真正做到頁級別的使用計費。

2.2 TDSQL-C的性能優(yōu)化

二級緩存

我們在存儲架構中引入了一個非常重要的功能，稱為二級緩存。此前，我們做了很多努力來優(yōu)化讀取性能和寫入性能，但實際上，由計算和存儲分離帶來的遠程I/O不容忽視。最初，存儲層次結構中只有兩層，其中內(nèi)存始終是緩存頻繁訪問數(shù)據(jù)的第一優(yōu)先級。當緩存未命中時，我們必須依靠遠程I/O來讀取數(shù)據(jù)并緩存到buffer pool中。如果buffer pool已滿，則從中選擇記錄淘汰并加入新讀取數(shù)據(jù)。

在TDSQL-C中，我們在遠程存儲和Buffer Pool之間實現(xiàn)了二級緩存層，它使用本地存儲介質(zhì)。為了提升性能，可以使用SSD或NVM存儲設備作為二級緩存的介質(zhì)。從Buffer Pool中淘汰的頁面緩存在該層——實際上并不是淘汰，而是把從Buffer Pool移出的數(shù)據(jù)緩存到本地的SSD存儲或者AEP存儲。下次訪問該數(shù)據(jù)時，滿足一定的條件下，可以直接從本地讀取，這樣就可以最大限度降低網(wǎng)絡I/O的消耗。

這項工作是今年SIGMOD收錄論文《Spitfire:A Three-Tier Buffer Manager for Volatile and Non-Volatile Memory》思想的工程實踐。

自動的無感知備份以及秒級回檔

備份和恢復對于確保數(shù)據(jù)安全非常重要。由于架構優(yōu)勢，我們還可以在存儲層非?？焖俚剡M行備份和恢復。在備份中TDSQL-C實現(xiàn)了兩個突破：一個是無感知備份，計算層沒有察覺。備份和恢復可以在每個單元并行完成。我們有一種機制來確?？梢詾閭浞葜谱魅挚煺铡５诙菢O速回檔。在我們的實驗中，備份只需幾秒鐘即可完成，數(shù)據(jù)可以以GB級別的速度回檔，速度非?？?。

通過這些架構升級和優(yōu)化，我們可以看到TDSQL-C自發(fā)布以來經(jīng)歷了快速增長。過去十二個月的實例數(shù)量增加近34倍。TDSQL-C適用于來自不同領域的許多客戶，包括電子商務，金融，視頻等。所以目前的結果非常喜人。當然，我們還有很多事情要做，還有很長的路要走，將來肯定會遇到很多挑戰(zhàn)。

3 TDSQL-C未來探索規(guī)劃

展望未來，數(shù)據(jù)庫技術的發(fā)展方向?qū)⒗^續(xù)由業(yè)務驅(qū)動的需求來定義。

例如，電子商務和游戲行業(yè)需要極端的性能。為了滿足這個要求，也許我們可以依靠一些技術，如多重寫入來實現(xiàn)高可用性吞吐量，并且還可以在存儲層考慮硬件加速來讓I/O得以加速。

對于更關注高可用性和安全性的金融和政府應用，我們將開發(fā)SQL審計，數(shù)據(jù)庫加密和全球數(shù)據(jù)同步、就近訪問等功能。在Ads和SaaS領域，它涉及大量的混合架構能力要求。為了解決此問題，我們或?qū)⒁際TAP和執(zhí)行計劃緩存等。我們可能也要采用外部生態(tài)系統(tǒng)來支持不同的工作流。我們也可以考慮冷熱數(shù)據(jù)分離等技術探索。

下面大致介紹一些我們未來將探索的技術。

第一個是多點寫入。到目前為止，我們在擴展讀取吞吐量方面做了很多努力。但是單點寫入的問題仍然存在，這在某些情況下可能會成為系統(tǒng)瓶頸。

我們有一些正在探索的想法。例如，用于全局處理日志相關邏輯（如數(shù)據(jù)一致性）的專用日志服務器，從而不需要在主節(jié)點和從節(jié)點之間傳輸日志。同時，我們可以依靠邏輯分區(qū)的概念來進行無沖突的多點寫入。存儲層中的數(shù)據(jù)可以被物理分區(qū)，也可以不被物理分區(qū)。

第二是HTAP。傳統(tǒng)的T+1解決方案是通過ETL通道連接TP系統(tǒng)和AP系統(tǒng)，對于某些實時應用來說可能不是一個很好的解決方案。許多產(chǎn)品正在構建HTAP功能。我們還創(chuàng)建了一個基于列式存儲引擎來加速分析查詢。

屏幕左側(cè)是傳統(tǒng)的解決方案，其中系統(tǒng)以單個R/O節(jié)點部署。查詢基于行存或列存引擎中執(zhí)行，完全由Proxy通過手動指定的連接字符串或一些非常簡單的啟發(fā)式規(guī)則來確定，在許多情況下可能會導致一些不正確的查詢路線選擇。該解決方案的另一個問題是整個查詢必須完全在基于行或列的引擎上處理，它不能結合兩種引擎的優(yōu)點。

因此，為了支持精細的執(zhí)行計劃控制，我們需要在MySQL實例中構建一個列存引擎，作為對查詢計劃樹中物理操作的增強。優(yōu)化器將決定執(zhí)行計劃的哪一部分應該下發(fā)到列存引擎執(zhí)行，并將執(zhí)行的中間結果轉(zhuǎn)換為行存格式返回給行存引擎。

第三個，可計算存儲功能擴展。最初，我們在存儲層實現(xiàn)了redo log回放的數(shù)據(jù)庫邏輯，但我們可以做更多的擴展。比如通過將部分SQL計算下推到存儲層，我們可以提前將一些不符合謂詞條件的數(shù)據(jù)在存儲層過濾掉，減少網(wǎng)絡傳輸和數(shù)據(jù)格式轉(zhuǎn)換的開銷，減少計算層CPU的使用，類似的功能還包括聚合操作下推。為了做到這一點，我們需要定義內(nèi)部協(xié)議將SQL計算操作下發(fā)到存儲層，存儲層將中間結果（intermediate result）傳回到計算層。這個項目也還有很多工作要去開展。