作者 ｜ 張雷

日前，字節(jié)跳動技術(shù)社區(qū) ByteTech 舉辦的第四期字節(jié)跳動技術(shù)沙龍圓滿落幕，本期沙龍以《字節(jié)云數(shù)據(jù)庫架構(gòu)設(shè)計與實戰(zhàn)》為主題。在沙龍中，字節(jié)跳動基礎(chǔ)架構(gòu)數(shù)據(jù)庫資深工程師張雷，跟大家分享了《字節(jié)跳動數(shù)據(jù)庫的過去、現(xiàn)狀與未來》，本文根據(jù)分享整理而成。

數(shù)據(jù)庫技術(shù)一直是信息技術(shù)中極其重要的一環(huán)，在步入云原生時代后，云基礎(chǔ)設(shè)施和數(shù)據(jù)庫進(jìn)一步整合，彌補了傳統(tǒng)數(shù)據(jù)庫的痛點，帶來了高可擴(kuò)展性、全面自動化、快速部署、節(jié)約成本、管理便捷等優(yōu)勢。

從 2018 到 2021 年，伴隨業(yè)務(wù)和數(shù)據(jù)的迅猛增長，字節(jié)跳動的分布式數(shù)據(jù)庫系統(tǒng)取得了令人振奮的發(fā)展。如下圖所示，在這 4 年間，公司應(yīng)用側(cè)容器數(shù)量從 5 萬個增長到了 750 萬個，截至目前已經(jīng)突破 1000 萬。這 1000 萬個容器筑成了字節(jié)跳動堅實的云原生基礎(chǔ)設(shè)施，支撐著整個業(yè)務(wù)體系的發(fā)展。

從在線數(shù)據(jù)角度看，1000 萬個容器構(gòu)成了超過 10 萬個微服務(wù)，這些微服務(wù)在線上運行期間會產(chǎn)生大量數(shù)據(jù)。在 2020 年，字節(jié)跳動的在線數(shù)據(jù)量級達(dá)到 EB 級;到 2021 年 5 月份，字節(jié)跳動數(shù)據(jù)庫團(tuán)隊已支撐超過 10 EB 的存儲規(guī)模。

面對如此龐大的應(yīng)用規(guī)模和數(shù)據(jù)規(guī)模，如何在數(shù)據(jù)庫領(lǐng)域進(jìn)行數(shù)據(jù)管理和數(shù)據(jù)治理，成了擺在數(shù)據(jù)庫團(tuán)隊面前的巨大難題。而在字節(jié)跳動內(nèi)部，數(shù)據(jù)庫建設(shè)主要面臨三大挑戰(zhàn)：

業(yè)務(wù)種類繁多。以抖音為例，為了管理用戶之間復(fù)雜的社交關(guān)系，同時根據(jù)用戶點贊、關(guān)注等行為進(jìn)行智能推薦，我們需要用圖進(jìn)行管理。再如抖音電商商城設(shè)計訂單、庫存等數(shù)據(jù)，這些信息適合用關(guān)系型結(jié)構(gòu)化的結(jié)構(gòu)表達(dá)。除此之外抖音還存在大量結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)，如用戶上傳的圖片、視頻，這些信息適合用云存儲、對象存儲這樣的系統(tǒng)來管理。

業(yè)務(wù)增速快，訴求不斷變化。如上圖所示，近 3 年內(nèi)，字節(jié)跳動的數(shù)據(jù)量迎來了近 100 倍的增長，業(yè)務(wù)對數(shù)據(jù)的訴求也產(chǎn)生了一些變化。一開始客戶只需要幾 TB 或幾十 GB 的數(shù)據(jù)，到一年兩年后，他們就要求基礎(chǔ)架構(gòu)能應(yīng)對數(shù)十 TB 甚至數(shù)百 TB 的數(shù)據(jù)量級。如何快速滿足應(yīng)用側(cè)的數(shù)據(jù)容量需求、吞吐需求變化，是我們遇到的第二個挑戰(zhàn)。

數(shù)據(jù)存量太多，成本居高不下。隨著業(yè)務(wù)的快速發(fā)展，如何管理龐大的結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)，并有效應(yīng)對高昂的成本，對我們而言也十分具有挑戰(zhàn)性。

字節(jié)跳動數(shù)據(jù)庫的演進(jìn)

字節(jié)跳動數(shù)據(jù)庫經(jīng)歷了以下三個階段：

2015 - 2017 年：刀耕火種的石器時代。在這一階段，字節(jié)跳動的業(yè)務(wù)量級比較小，主要的 App 是今日頭條，因此數(shù)據(jù)庫的實例大概在 1~2k 量級，產(chǎn)品主要以開源的 MySQL 和 MyRocks 為主，運維體系主要是依靠人工和腳本。

2018 - 2021 年：標(biāo)準(zhǔn)化、系統(tǒng)化。隨著抖音的快速發(fā)展，字節(jié)的業(yè)務(wù)規(guī)模也迎來快速增長，達(dá)到數(shù)千套庫和數(shù)萬個數(shù)據(jù)庫實例，原有產(chǎn)品體系已難以解決用戶需求，因此我們引入了類似 MongoDB 等開源方案。此外，我們也從 2019 年開始研發(fā)云原生分布式數(shù)據(jù)庫產(chǎn)品 veDB 。我們還更新了運維體系，由原來半自動化半人工的狀態(tài)逐漸走向平臺化，大大提升運營效率。

2021 年底至今：融合智能化。當(dāng)前，字節(jié)跳動內(nèi)部已經(jīng)開始研發(fā)數(shù)據(jù)庫的第三代產(chǎn)品技術(shù)體系。在未來幾年內(nèi)，我們預(yù)計公司業(yè)務(wù)規(guī)模會上升到數(shù)萬套庫、數(shù)十萬數(shù)據(jù)庫實例，因此在原有產(chǎn)品體系基礎(chǔ)上，我們引入了 HTAP、Serverless DB、MemDB 等產(chǎn)品和技術(shù)，在運維體系上，也引入 AI 技術(shù)，使得運維更加智能化。

字節(jié)跳動數(shù)據(jù)庫的“過去”第一代數(shù)據(jù)庫系統(tǒng)架構(gòu)主要分三層，示意圖如下：

Application 層：前文提到的 1000 萬個容器及其構(gòu)成的 10 萬個微服務(wù)都部署在應(yīng)用層;

Proxy 層：代理層主要負(fù)責(zé)數(shù)據(jù)庫的一些接入工作，比如鑒權(quán)、流量染色、流量分發(fā)等;

Database 層：這一層部署著數(shù)據(jù)庫的一些實例，通過數(shù)據(jù)庫的 Binlog 實現(xiàn)數(shù)據(jù)的同步、高可用。

整體來講，第一代數(shù)據(jù)庫系統(tǒng)架構(gòu)以開源 MySQL 為主，通過分庫分表中間件為用戶提供較好的服務(wù)，以人工為主、腳本為輔進(jìn)行運維。它主要存在以下三個問題：

系統(tǒng)彈性較差。首先是容量難以得到靈活擴(kuò)展，抖音這類 App 通常都由數(shù)萬個微服務(wù)構(gòu)成，當(dāng)微服務(wù)的數(shù)據(jù)量從早期的數(shù)十 GB 發(fā)展到之后的數(shù)十 TB，我們不得不需要花費大量時間拆解原先的庫;其次，吞吐量彈性不如人意，互聯(lián)網(wǎng)行業(yè)經(jīng)常會有春晚、電商促銷等活動，我們需要提前進(jìn)行擴(kuò)容以應(yīng)對流量洪峰，活動過后，數(shù)據(jù)庫難以立即收縮，也需要團(tuán)隊花費時間搬遷大量數(shù)據(jù);

研發(fā)效率問題。在用戶側(cè)，從申請數(shù)據(jù)庫到數(shù)據(jù)庫上線，期間會經(jīng)過漫長的討論談判，因此如何提高數(shù)據(jù)庫的研發(fā)效率也是我們著重考慮的問題。此外，運維效率也有待提升——大量的拆庫和合并工作會為研發(fā)帶來不小的負(fù)擔(dān);

綜合成本偏高。第一代數(shù)據(jù)庫系統(tǒng)架構(gòu)為了 reserve CPU 和存儲資源以應(yīng)對流量洪峰和業(yè)務(wù)增長，早期 CPU 使用率十分低下，比如 MySQL 數(shù)據(jù)庫的 CPU 使用率通常只有 10%，有些節(jié)點甚至長期在 5% 以下;存儲空間也非常浪費，整個空間的利用率只有 20%-30%。

字節(jié)跳動數(shù)據(jù)庫的“現(xiàn)在”為了解決這三個問題，數(shù)據(jù)庫團(tuán)隊開發(fā)了第二代數(shù)據(jù)庫，圍繞標(biāo)準(zhǔn)化和系統(tǒng)化構(gòu)建了龐大的產(chǎn)品矩陣和運維平臺。

如上圖所示，當(dāng)前字節(jié)跳動數(shù)據(jù)庫體系呈現(xiàn)產(chǎn)品多樣化、產(chǎn)品智能化兩個特征，其中矩陣底層的 Inf-Brain 是數(shù)據(jù)庫管理大腦，主要承擔(dān)流量預(yù)測、熔斷預(yù)測、智能參數(shù)調(diào)優(yōu)等能力。上層各模塊則是各細(xì)分產(chǎn)品，比如智能運維、分布式中間件、分布式緩存、KV、圖等，也有云數(shù)據(jù)庫方向的veDB、HTAP 相關(guān)的一些技術(shù)。

veDB主體架構(gòu)

veDB 自身即一個較大的產(chǎn)品矩陣。它除了提供 MySQL、PG、MongoDB，也在字節(jié)跳動內(nèi)部研發(fā)擴(kuò)展了 Elastic Search 服務(wù)，包括自研的、用于處理 TP/AP 相關(guān)事務(wù)的產(chǎn)品 HTAP。數(shù)據(jù)庫團(tuán)隊在設(shè)計上采用了分層式架構(gòu)，由高性能網(wǎng)絡(luò)連接上層的數(shù)據(jù)庫和底層的分布式存儲引擎平臺。

整個 veDB 的架構(gòu)遵循的基本哲學(xué)是分離。

首先是計算和存儲的分離。如下圖所示，veDB 分為計算層和存儲層，其中計算層又被拆分出負(fù)責(zé)數(shù)據(jù)庫流量調(diào)度、接入、鑒權(quán)的代理層以及數(shù)據(jù)庫計算層。計算層中是數(shù)據(jù)庫的一些運行實例，它兼容 MySQL、PG 和 MongoDB 等數(shù)據(jù)庫引擎，是無狀態(tài)的，可以動態(tài)地在數(shù)據(jù)中心里做分布和調(diào)度。最下方是存儲層，我們把數(shù)據(jù)庫日志、數(shù)據(jù)庫 Page 和對應(yīng)的處理邏輯都卸載到里面，它支持 HDD、SSD、PM。

其次是日志和數(shù)據(jù)的分離。我們把數(shù)據(jù)庫的 Wal 和 Page 放到不同介質(zhì)里，來實現(xiàn)成本和性能之間的平衡。

第三是讀寫分離。我們最大可以支持一組 15 從的配比，當(dāng)讀流量比較大時，用戶可以通過彈性擴(kuò)充應(yīng)對讀的負(fù)載，這在字節(jié)跳動內(nèi)部已經(jīng)被大規(guī)模應(yīng)用了。

基于以上設(shè)計，veDB 呈現(xiàn) 6 大特點：

靈活性強：veDB 基于 shared-storage 架構(gòu)，實現(xiàn)了計算存儲分離，業(yè)務(wù)方可以按需彈性使用存儲容量，解決了存儲成本比較高的問題;

兼容性好：目前 veDB 基本上已做到 100% 兼容 MySQL 8.0 和 PostgreSQL 12，現(xiàn)已兼容 MongoDB 4.0;

高可用性：存儲層多副本，支持單 AZ/跨 3 AZ 強一致部署，既保持了靈活性，又解決了傳統(tǒng)通過 Binlog 跨多數(shù)據(jù)中心異步復(fù)制帶來的 RPO
無法等于 0 的問題;

高性能：數(shù)據(jù)庫團(tuán)隊做了大量優(yōu)化工作，使 veDB 在高并發(fā)集群模式下的吞吐量 QPS 遠(yuǎn)超傳統(tǒng)單機數(shù)據(jù)庫;

成本低：按需獨立擴(kuò)縮計算/存儲，存儲層高壓縮比，把存儲空間利用率從第一代系統(tǒng)的 20%-30% 提升到了現(xiàn)在的 70%;

超大容量：單表 64 TB，并支持 PB-level 解決方案。

業(yè)務(wù)實踐

在業(yè)務(wù)實踐層面，數(shù)據(jù)庫團(tuán)隊主要面對以下三種類型。

第一類是容量型實例，比如電商某些訂單雖然吞吐量不大，但數(shù)據(jù)量特別大，遠(yuǎn)超以往 2T-3T的單機容量?；诘诙鷶?shù)據(jù)庫系統(tǒng)，在計算存儲分級之后，存儲層可以無限擴(kuò)容，使得用戶無需擔(dān)心數(shù)據(jù)庫，只需聚焦業(yè)務(wù)開發(fā)。

第二類是 QPS 型實例。2021 年春晚，數(shù)據(jù)庫團(tuán)隊支持了某中臺的推送業(yè)務(wù)，目標(biāo)用戶量(設(shè)備)高達(dá) 10 億級。最終我們的峰值吞吐量超過了 600 萬 QPS，整體數(shù)據(jù)量也超過了 20TB?；顒咏Y(jié)束后，因為計算節(jié)點都是無狀態(tài)的，且數(shù)據(jù)都放在共享存儲層，我們輕松完成了節(jié)點下線，幫助公司節(jié)省了大量計算資源。

第三類是小型實例。字節(jié)跳動大部分線上實例都是小型實例，QPS 比較低，數(shù)據(jù)量也在 GB 級別，這類型的實例可以通過虛擬化、混部、容器等技術(shù)降低計算成本。在數(shù)據(jù)量層面，它們也可以通過共享存儲空間降低整體存儲成本。

字節(jié)跳動數(shù)據(jù)庫的“未來”

未來數(shù)據(jù)庫的情景預(yù)測

伴隨業(yè)務(wù)的發(fā)展，我們預(yù)計在 2022 年以后，字節(jié)跳動的數(shù)據(jù)庫規(guī)模會達(dá)到數(shù)萬套庫、數(shù)十萬實例。如何更好地支持業(yè)務(wù)的發(fā)展，如何建立管理這數(shù)萬套庫的實力，成了我們下一代技術(shù)重點關(guān)注的話題——如前所述，在產(chǎn)品方面，數(shù)據(jù)庫團(tuán)隊會持續(xù)推出更多產(chǎn)品和引入新技術(shù)，使得產(chǎn)品在種類和協(xié)議上能出現(xiàn)一定的融合;在運維方面，團(tuán)隊也會引入 AI 技術(shù)解決著力解決當(dāng)前的痛點。

在談及未來之前，首先我們可以回顧兩個問題：

• 數(shù)據(jù)庫服務(wù)產(chǎn)品解決的問題是什么?
• 數(shù)據(jù)庫服務(wù)產(chǎn)品面臨的新環(huán)境是什么?

對于問題一，在 2018 年，數(shù)據(jù)庫團(tuán)隊面臨的問題是業(yè)務(wù)需要多種類型的數(shù)據(jù)，但當(dāng)時的產(chǎn)品無法提供相應(yīng)支持;發(fā)展至今，現(xiàn)在字節(jié)跳動已擁有日漸豐富的數(shù)據(jù)庫產(chǎn)品矩陣，我們的新挑戰(zhàn)變成了如何幫助用戶選擇合適的數(shù)據(jù)庫。

對于問題二，早期因為數(shù)據(jù)規(guī)模不大，數(shù)據(jù)庫團(tuán)隊關(guān)注的是怎么保留一些存儲、計算資源用于構(gòu)建運營環(huán)境的運維體系;現(xiàn)在我們已經(jīng)擁有百萬級服務(wù)器規(guī)模，如何利用這些資源、在云環(huán)境下構(gòu)建數(shù)據(jù)庫產(chǎn)品的服務(wù)成了我們的新探索方向。

數(shù)據(jù)庫管理領(lǐng)域的發(fā)展概覽

如果我們回顧數(shù)據(jù)庫技術(shù)領(lǐng)域的整體發(fā)展情況，不難發(fā)現(xiàn)這樣的發(fā)展規(guī)律。

自 1980s DBMS 出現(xiàn)以來，IBM 等商業(yè)化公司在早期紛紛推出 OLTP 型數(shù)據(jù)庫，這一時期數(shù)據(jù)庫的典型特征是為了解決應(yīng)用程序開發(fā)過程中管理數(shù)據(jù)的復(fù)雜性問題。隨著時間的推移，1990s 企業(yè)開始出現(xiàn)大量數(shù)據(jù)分析型需求，比如銀行報表，這催生了一個新的分支 OLAP。

到 21 世紀(jì)初，互聯(lián)網(wǎng)行業(yè)迎來大規(guī)模爆發(fā)，OLTP 開始無法滿足企業(yè)對于在線數(shù)據(jù)的一些管理訴求，OLAP 也難以管理離線分析、作業(yè)處理系統(tǒng)上的數(shù)據(jù)，加之商業(yè)化數(shù)據(jù)庫和存儲帶來的巨大成本使企業(yè)難以承受，以 NoSQL 和 BigData 為代表的數(shù)據(jù)庫革命正式爆發(fā)，無論是 Google 開源的 HDFS、Bigtable，還是 HBase、MongoDB，它們都旨在解決 OLTP 型數(shù)據(jù)庫吞吐量、擴(kuò)展性不足的問題。

到 2010 年，Google 開始大量使用 NoSQL 和 BigData 數(shù)據(jù)庫系統(tǒng)，但很快它就發(fā)現(xiàn)了不少問題，比如 NoSQL 不支持事務(wù)且每個產(chǎn)品的 NoSQL 接口都不一樣，這給應(yīng)用程序遷移和學(xué)習(xí)帶來了極大的成本，為此它又開發(fā)了 NewSQL 這一新分支。

整體來看，數(shù)據(jù)庫在短短二三十年演進(jìn)過程出現(xiàn)了大量分支，技術(shù)和產(chǎn)品也越來越復(fù)雜。到今天，大家又覺得這些東西太復(fù)雜，開始著手去做簡化，比如 2015 年左右，AWS 結(jié)合 OLTP 和云原生發(fā)布了分布式數(shù)據(jù)庫 Aurora，結(jié)合 OLAP 與云原生發(fā)布 Redshift，包括 BigData 也正與數(shù)據(jù)湖概念結(jié)合，衍生出一些新形態(tài)。

除此之外，近幾年行業(yè)又開始流行 HTAP，把云、OLAP、BigData 做有機結(jié)合，使數(shù)據(jù)庫既能處理復(fù)雜的 query，又能支持在線業(yè)務(wù)訴求。那么這樣的三合一是不是未來的發(fā)展趨勢呢?我們不知道。

數(shù)據(jù)庫團(tuán)隊的兩個觀察和思考

數(shù)據(jù)庫領(lǐng)域的技術(shù)和產(chǎn)品經(jīng)歷了從簡單到復(fù)雜再到簡單的過程，但如果審視做數(shù)據(jù)管理的真實初衷，恐怕大家的目標(biāo)都是為了方便用戶——而各種復(fù)雜分支恰恰讓用戶更難做技術(shù)選型。

我們能不能不要選擇性地去解決一部分問題，而是構(gòu)建一個大而全的系統(tǒng)去解決問題?我們能否為用戶提供統(tǒng)一的數(shù)據(jù)管理服務(wù)?即使現(xiàn)在做不到，那我們能不能提供盡量少的數(shù)據(jù)管理服務(wù)，去簡化研發(fā)人員的研發(fā)成本，包括用戶的使用成本和學(xué)習(xí)成本?

基于以上思考，字節(jié)跳動數(shù)據(jù)庫團(tuán)隊產(chǎn)生了兩個重要的觀察思考：

• 應(yīng)用場景方面的融合：提升用戶效率，降低用戶的接入和使用成本;
• 基礎(chǔ)設(shè)施層面的分離和整合：提升系統(tǒng)層面的效率，降低系統(tǒng)層面的成本，可以為用戶讓利。

首先是橫向融合探索，簡化業(yè)務(wù)應(yīng)用數(shù)據(jù)管理體系。舉個例子，過去構(gòu)建一個微服務(wù)，數(shù)據(jù)層既要考慮在線數(shù)據(jù)，也會考慮離線數(shù)據(jù)，不可避免會涉及多種數(shù)據(jù)庫及每種數(shù)據(jù)庫下不同的表的管理，導(dǎo)致在線應(yīng)用的復(fù)雜度較高。同時從在線數(shù)據(jù)生成到離線分析，數(shù)據(jù)的可見性通常會以天、小時、分鐘級別計數(shù)。在數(shù)據(jù) ETL 過程中，數(shù)據(jù)的 integrity 如何去保證，這也是一個非常大的挑戰(zhàn)。

字節(jié)跳動數(shù)據(jù)庫團(tuán)隊一直在嘗試通過技術(shù)上的融合簡化在線應(yīng)用的數(shù)據(jù)管理，例如 veDB 正在探索把 MySQL、ES Protocols 的協(xié)議集成到數(shù)據(jù)庫里，支持事務(wù)處理、分析查詢、搜索等融合任務(wù)，使應(yīng)用側(cè)只需關(guān)注數(shù)據(jù)本身，無需關(guān)注數(shù)據(jù)和維護(hù)多種數(shù)據(jù)庫。在事務(wù)處理層面，veDB 已經(jīng)能做到數(shù)據(jù)可見性秒級，并且強一致，支持 snapshot 隔離級別。通過存儲層的技術(shù)整合，veDB 也大幅優(yōu)化了數(shù)據(jù)的存儲成本，顯著降低了數(shù)據(jù)冗余系數(shù)。

其次是縱向融合探索，重塑應(yīng)用緩存和數(shù)據(jù)庫邊界。單體和微服務(wù)時代，用戶在使用數(shù)據(jù)庫時，需要在前面掛一個 Redis，因為數(shù)據(jù)庫的吞吐量通常不能夠做得很大，容易被過高的 QPS 打掛。當(dāng)企業(yè)架構(gòu)從單體時代發(fā)展到在線微服務(wù)時代，這種做法會帶來大量緩存系統(tǒng)和數(shù)據(jù)庫類型的復(fù)雜管理難題，因此我們希望通過一套系統(tǒng)重塑應(yīng)用緩存和數(shù)據(jù)庫，為用戶帶來便捷。比如我們正在veDB 中做一些軟件和技術(shù)硬件層面的探索，盡可能減少用戶的數(shù)據(jù)管理成本和學(xué)習(xí)成本，同時消除用戶 multi-tiering 數(shù)據(jù)流動管理，讓用戶聚焦業(yè)務(wù)邏輯，也幫助他們消除了原先數(shù)據(jù)與緩存不一致性等業(yè)界難題。

第三是分離和整合：新的變量、硬件和系統(tǒng)。除了用戶層面一些應(yīng)用場景的融合，我們也在公司基礎(chǔ)架構(gòu)體系內(nèi)部看到了一些分離和整合的內(nèi)容，比如軟件、硬件和操作系統(tǒng)。下圖左側(cè)是數(shù)據(jù)庫模塊，從上到下分別是 SQL 層、事務(wù)層、緩存層和存儲層;右側(cè)則是云數(shù)據(jù)中心里應(yīng)用的運行時環(huán)境，比如公司大部分微服務(wù)都跑在 K8s 上，硬件層面的新算力、新互聯(lián)、新存儲都在與時俱進(jìn)地發(fā)生變化。

以算力為例，從只有 CPU 到發(fā)展到 CPU+GPU+DPU+FPGA，數(shù)據(jù)庫團(tuán)隊一直在嘗試把壓縮、加密解密等復(fù)雜的、需要消耗算力的作業(yè)放到 FPGA 里去。當(dāng)公司 CPU 算力從 96c 發(fā)展到 192c 甚至超過 300c，如何重塑數(shù)據(jù)庫里的索引、事務(wù)處理也是我們要提前思考的問題。

第四是分離與整合：當(dāng)前云數(shù)據(jù)中心的 building blocks。

總的來講，數(shù)據(jù)庫也是一種軟件，當(dāng)前我們能不能利用云中心里的硬件和運行時環(huán)境使數(shù)據(jù)庫變得更強大、更彈性，也是一個重要方向。

數(shù)據(jù)庫團(tuán)隊在軟件、系統(tǒng)層面做了非常多的工作，比如把數(shù)據(jù)庫 Severless 化，把數(shù)據(jù)庫里的狀態(tài)放到分布式的 Persistent Memory 構(gòu)建的高性能存儲引擎里，在存儲層實現(xiàn)自動分層分級。通過這樣，我們可以把計算層做得更加彈性。

以下圖為例，有三個租戶，其中租戶 A 需要一些 MySQL 和 PG。我們可以把這些租戶的數(shù)據(jù)庫實例運行在容器中，動態(tài)地做計算資源調(diào)配，根據(jù)業(yè)務(wù)的高峰期和低谷期提供不同大小的數(shù)據(jù)庫實例來實現(xiàn)彈性。在這種大一統(tǒng)運營模式之下，我們就可以擺脫以往獨立物理機數(shù)量不足的窘境，利用公司百萬級服務(wù)器實現(xiàn)算力復(fù)用。

未來，數(shù)據(jù)庫團(tuán)隊會圍繞應(yīng)用場景層面的融合、縱向的技術(shù)整合以及硬件和系統(tǒng)的整合，重新構(gòu)建云數(shù)據(jù)庫，使它能夠回歸用戶價值，幫助用戶提升開發(fā)效率、運行效率和運營效率，降低學(xué)習(xí)和使用等各類成本。