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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

這使得計(jì)算層得以輕量化，對(duì)于實(shí)例啟動(dòng)和關(guān)閉以及集群擴(kuò)容和縮容非常方便。

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

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

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

2.1 Serverless

第一個(gè)功能是計(jì)算存儲(chǔ)分離。實(shí)際上，將存儲(chǔ)層與計(jì)算層分離是彈性擴(kuò)展和Serverless的第一步。

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

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

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

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

二級(jí)緩存

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

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

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

自動(dòng)的無(wú)感知備份以及秒級(jí)回檔

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

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

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

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

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

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

下面大致介紹一些我們未來(lái)將探索的技術(shù)。

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

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

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

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

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

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