veDB 計算存儲分離架構(gòu)
● 完全兼容 MySQL ：計算層基于 Percona Sever 8.0 版本打造，完全兼容字節(jié)線上的 MySQL 生態(tài)，字節(jié)的應(yīng)用遷移到 veDB 上不需要任何改造；
● 計算存儲分離：云原生架構(gòu)，計算引擎能力和存儲能力均可以獨(dú)立擴(kuò)展；
● 超大實例容量：數(shù)據(jù)庫容量不受單機(jī)磁盤容量限制，存儲層容量可以按需擴(kuò)展；
● 只讀線性擴(kuò)展：添加只讀節(jié)點(diǎn)無需拷貝數(shù)據(jù)，并且只讀節(jié)點(diǎn)支持頁面級別 REDO 并行回放技術(shù)，提供低讀延遲（~10ms）；
● 閃速備份恢復(fù)：存儲層支持快照備份，通過 PITR 技術(shù)快速恢復(fù)至歷史任意時間點(diǎn)。
開發(fā)歷史
veDB（for MySQL) 具體的發(fā)展歷程如下圖所示：
目前，在字節(jié)跳動內(nèi)部，veDB 已大規(guī)模接入線上業(yè)務(wù)，包括在國內(nèi)預(yù)生產(chǎn)環(huán)境已完成了對 RDS MySQL 的全量替代，已接入國內(nèi)生產(chǎn)環(huán)境 ~40% 的業(yè)務(wù)庫，基本覆蓋所有業(yè)務(wù)門類。預(yù)計到 2022 年底，veDB 將替代內(nèi)部 RDS MySQL 約 80% 的國內(nèi)業(yè)務(wù)，并使綜合成本下降約 30%。同時，veDB 也已亮相字節(jié)跳動云服務(wù)平臺火山引擎，對外提供 NewSQL 類 DBaaS 服務(wù)。
veDB（for MySQL）技術(shù)挑戰(zhàn)
在構(gòu)建 veDB（for MySQL）的過程中，團(tuán)隊遇到了以下三方面的技術(shù)挑戰(zhàn)：
● 相比于本地的 NVME SSD 磁盤，計算存儲分離架構(gòu)會帶來時延的增加；
● 在只讀節(jié)點(diǎn)讀延遲方面，如何做到比較低的讀延遲；
● 由于業(yè)務(wù)會有各式各樣的個性化訴求，需要對其個性化的數(shù)據(jù)進(jìn)行優(yōu)化。
對于這些技術(shù)問題，下面是一些針對性的解決方案。
如何克服時延挑戰(zhàn)？
雖然計算存儲分離架構(gòu)帶來了一定的靈活性，但是相對于傳統(tǒng)的單機(jī)主備架構(gòu)，也帶來了寫日志和讀頁面的時延增加。具體來說，比如傳統(tǒng)單機(jī)主備架構(gòu)的讀寫時延大概是十微秒，但是計算存儲分離架構(gòu)由于經(jīng)過一層網(wǎng)絡(luò) TCP/IP，時延大概是 1 毫秒左右，這會造成部分時延敏感性業(yè)務(wù)體驗受損。
解決方案
針對上述問題，團(tuán)隊提出了以下三種解決方式：
● 共享內(nèi)存寫緩存/NVME SSD 讀緩存：首先，Redo 日志在寫入遠(yuǎn)端 Log Store 之前，會寫入一個共享內(nèi)存，然后再批量寫入遠(yuǎn)端，這樣做雖然類似于原生 MySQL 異步提交，但效率上要比異步提交高很多；其次，團(tuán)隊提供了二級讀緩存的特性，雖然本地盤比較小，但是也有一部分存儲空間，團(tuán)隊利用這部分存儲空間來實施 Buffer Pool 的擴(kuò)展，大大減少對遠(yuǎn)端 Page Store 的讀取操作；
● 頁面預(yù)取/計算下推：團(tuán)隊面對部分業(yè)務(wù)場景可以針對性地進(jìn)行頁面預(yù)取優(yōu)化，提前從 Page Store 讀取頁面到緩沖區(qū)，可以避免在有需求時臨時讀取；
● RDMA/AEP Store：這個其實類似于 PolarDB 讀寫 Polar FX ，但是 RDMA 部署會受到一些條件限制，團(tuán)隊目前是在有部署條件的場景下推行使用 RDMA 網(wǎng)絡(luò)，并且結(jié)合 AEP Store 優(yōu)化讀寫時延。
通過以上解決方案，總體而言，veDB（for MySQL）與本地 NVME SSD 磁盤相比，在延時敏感型業(yè)務(wù)體驗上變化不大，在部分場景有更優(yōu)表現(xiàn)，因為veDB去除了許多操作，比如不用刷臟頁、沒有 Checkpoint。
只讀節(jié)點(diǎn)如何做到超低讀延遲？
什么是讀延遲？主備架構(gòu)中的主機(jī)寫完數(shù)據(jù)之后，備機(jī)不能立刻讀取數(shù)據(jù)，這其中的延遲被稱為讀延遲。
這其中面臨的問題是什么呢？首先是傳統(tǒng)的主備架構(gòu)，比如 MySQL 基于 Binlog 同步，只讀節(jié)點(diǎn)延時受業(yè)務(wù)負(fù)載影響比較大，雖然它在 v5.7 版本引入并行回放機(jī)制改善了讀延遲，但是并沒有完全克服問題；另外計算存儲分離之后，團(tuán)隊并不是基于 Binglog 構(gòu)造數(shù)據(jù)，而是基于 Redo 日志構(gòu)造數(shù)據(jù)，那么 RO 節(jié)點(diǎn)如何同步數(shù)據(jù)呢？團(tuán)隊提供了以下技術(shù)解決方案。
解決方案
● 頁面（Page）級別并行回放機(jī)制：首先只讀節(jié)點(diǎn)啟動后，veDB會基于最新快照，持續(xù)從共享存儲去拉取物理日志并行解析回放，值得注意的是，veDB可以根據(jù)不同的規(guī)格選擇不同的并行機(jī)制：
● Redo 日志拉?。≒ull）模式：這種模式下的計算節(jié)點(diǎn)讀寫，RW 節(jié)點(diǎn)和 RO 節(jié)點(diǎn)之間并沒有直接的網(wǎng)絡(luò)交互（如上圖所示），只讀節(jié)點(diǎn)從存儲池拉取 Redo 日志。
● Redo 日志推送（Push）模式： Push 模式是指在 RW 節(jié)點(diǎn)完成日志持久化之后，直接把 Redo 日志推到只讀節(jié)點(diǎn)。
為什么會有 Pull 和 Push 兩種模式呢？兩種模式效果并不相同，在 Pull 模式下，veDB能夠支持 30+ RO 節(jié)點(diǎn)，但此時讀延時較高，大約在 100 毫秒左右。在 Push 模式下，veDB能夠支持 15 個左右的 RO 節(jié)點(diǎn)，此時讀延時較低，大約在 10 毫秒左右。
數(shù)據(jù)導(dǎo)入能力優(yōu)化
對于如何更快從 MySQL 遷移數(shù)據(jù)，傳統(tǒng)方式是 MySQL 本身支持 Dump、Restore， 或者第三方工具支持 Myloader Mydumper ，但由于存儲計算分離，這種邏輯轉(zhuǎn)換方式的性能表現(xiàn)并不佳。
解決方案
首先，考慮到 InnoDB 存儲層物理頁格式是一致的，veDB引入 Fastloader 工具直接把頁面批量寫入到存儲層（Page store），其中，有些信息需要更新，比如 InnoDB 表的 Space ID 、索引的 ID 、 LSN等。同時，veDB目前支持 MySQL 5.6/5.7/8.0 去導(dǎo)入數(shù)據(jù)。
優(yōu)化效果如何呢？總體而言，對于24G（1億條）數(shù)據(jù)，用時從 1637s 降到 32s，性能提升了 51 倍；對于 69G（3 億條）數(shù)據(jù)，用時從 21585s 降到 95s，性能提升了 227 倍。
大表 DDL 處理優(yōu)化
原生 MySQL V8.0 版本支持 Instant 的 DDL 特性，雖然比較快，但是它適合的場景有限。另外，MySQL 備機(jī)回放 DDL 的 Binlog 時，它會引入一個較大的主備時延，只有 DDL 執(zhí)行完成，它才能執(zhí)行其它進(jìn)程，這會造成較大的問題。目前各大互聯(lián)網(wǎng)公司包主要運(yùn)用兩個第三方工具 Ghost 和 Pity online schema change ，來解決主備延時的問題，不過執(zhí)行效率較低。尤其對veDB來說，存儲計算分離之后，表變得更大，延時問題更加凸顯。
解決方案
veDB引入了 FastDDL 來解決以上問題，具體而言：
● 主鍵索引（源表）頁面預(yù)?。?/strong>DDL 分為兩個階段，第一個階段是對原表主鍵索引進(jìn)行全表掃描，然后在這一階段進(jìn)行精準(zhǔn)的頁面預(yù)??；
● 并行構(gòu)建（按索引，多機(jī)房）：第二個階段就是并行構(gòu)建，比如按照索引并行構(gòu)建，團(tuán)隊要重新構(gòu)建表，其中包含 10 個索引，那么會有 10 個并發(fā)；同時，如果機(jī)房之間通過 Binlog 去同步，團(tuán)隊可以多機(jī)房一起執(zhí)行；
● 存儲層 Write-Through：veDB 架構(gòu)的特點(diǎn)是 Log is Database。為了優(yōu)化 DDL，團(tuán)隊直接寫入 Page store，Bypass 了 Log store，起到一定的加速作用。
關(guān)于優(yōu)化效果，主要有以下三點(diǎn)：
● 普適：基本上 MySQL 能夠支持任何 Online DDL的操作；
● 快：它作為一個內(nèi)部實現(xiàn)工具，是 gh-ost 速度的十分之一；
● 靜：團(tuán)隊不引入 Binlog 主備延時，比如機(jī)房分別執(zhí)行 DDL，等待它們執(zhí)行差不多，最后 relay 就能完成。
復(fù)雜查詢下推處理優(yōu)化
在 MySQL 里面，復(fù)雜查詢基本都是單線程執(zhí)行，而單線程的任務(wù)一般比較重，包括解析、優(yōu)化、數(shù)據(jù)讀取和執(zhí)行，計算存儲分離會導(dǎo)致跨網(wǎng)絡(luò)讀取頁面的時延大大增加。如果復(fù)雜查詢出現(xiàn) catch miss，即在緩沖區(qū)找不到數(shù)據(jù)，就需要從存儲區(qū)拉取數(shù)據(jù)。這種情況頻繁發(fā)生，性能會變差。另外，單庫容量也大大增加了，數(shù)據(jù)容量從原來的幾T 變成了現(xiàn)在的幾十T，也加大了復(fù)雜查詢的負(fù)擔(dān)。
解決方案
● 計算操作（部分）直接下推存儲層：當(dāng)執(zhí)行任務(wù)時，團(tuán)隊會去查詢 B+ 數(shù)的倒數(shù)第二層節(jié)點(diǎn)，得到需要分發(fā)的頁面 ID 情況，并且把任務(wù)并行分發(fā)給存儲層；
● 并行任務(wù)分發(fā)：團(tuán)隊引入了并行執(zhí)行查詢算子， SQL 層完成分發(fā)之后，可以通過算子收集結(jié)果，匯聚并返回給計算層；
● 回表查詢頁面精準(zhǔn)預(yù)?。?/strong>對于回表查詢，比如查完二級索引之后，需要去主鍵索引上查詢，團(tuán)隊會做預(yù)取。
基于以上方案，veDB也取得了不錯的效果。比如對于 count(*) 操作，在不增加計算層 CPU 負(fù)擔(dān)的情況下，veDB實現(xiàn)了 5 倍 到 100 倍左右的提升；同時，以 TPCH (100G) 的數(shù)據(jù)集測試為例，對于緩沖區(qū)命中率低和命中率高的兩種情況而言，從最壞到最好的情況，會有 2 倍到 10倍的提升。
秒殺場景優(yōu)化
在類似于秒殺、限時搶購、搶紅包等場景下，大量用戶需要在極短時間內(nèi)請求商品或者紅包，此時數(shù)據(jù)庫將面臨單行記錄大并發(fā)更新的老大難問題。通常，這會導(dǎo)致系統(tǒng)活躍線程增加、 TPS 降低、時延增加、系統(tǒng)吞吐降低。針對這種情況，目前有兩種解決方案，其一是不依靠數(shù)據(jù)庫，在應(yīng)用層進(jìn)行處理，但是這種方案較為復(fù)雜；其二就是依靠數(shù)據(jù)庫來解決問題。
解決方案
● SQL 語句更新列熱點(diǎn)標(biāo)識：對于帶有熱點(diǎn)更新標(biāo)識的 SQL ，團(tuán)隊會在數(shù)據(jù)庫內(nèi)部維護(hù)一個哈希表，會將相同數(shù)據(jù)的 SQL 放在哈希表的一個隊列里；
● 批量處理：經(jīng)過一段時間之后，團(tuán)隊會針對隊列里的 SQL 進(jìn)行合并處理；
● 語法糖：為了更好地滿足業(yè)務(wù)需求，veDB支持打開 Binlog ，以及語法糖，比如：Auto_Logic_Commit_Rollback hint，是指成功就自動提交，否則 Rollback；另外veDB擴(kuò)展 Update.returning，支持語句返回。
基于以上操作，實施效果如何呢？以一個 20c 的虛擬機(jī)為例，單行更新性能能夠達(dá)到 9.3w QPS，多行更新性能能夠達(dá)到 14.7w QPS。同時，團(tuán)隊目前已經(jīng)上線了電商直播、抖音的本地生活，在業(yè)務(wù)直播帶貨過程中，即使熱點(diǎn)商品 QPS 突然猛增到 1.5 萬，veDB數(shù)據(jù)庫也能夠提供足夠的支持。
計算引擎寫能力如何擴(kuò)縮容？
對于一寫多讀的架構(gòu)，是如何做到多寫呢？團(tuán)隊結(jié)合了字節(jié)內(nèi)部的分庫分表的中間件與 veDB，提供 Multimaster 支持。但是分庫分表的 Multimaster 在寫流量較大的場景時（例如 618 或雙 11 活動）會面臨集群擴(kuò)容的問題，活動結(jié)束后又會面臨集群縮容的問題。傳統(tǒng)基于中間件的分庫分表方案擴(kuò)容需要復(fù)制數(shù)據(jù)，會面臨兩個問題：其一是耗時與數(shù)據(jù)量成正比，其二是還需要一倍的冗余空間，因此需要擴(kuò)容。另外，分庫分表目前沒有一個有效的在線縮容方案，會導(dǎo)致在大型網(wǎng)絡(luò)活動結(jié)束后，沒有辦法及時縮容。
解決方案
由于計算存儲架構(gòu)分離，數(shù)據(jù)都在存儲層。veDB引入共享表的概念，共享表可以在不同的數(shù)據(jù)庫實例之間進(jìn)行共享，而不同的實例在 MySQL 都有相同的 space ID。同時，共享表的所有權(quán)（包括讀和寫）在任何時候都屬于一個實例，它可以在實例之間動態(tài)切換，團(tuán)隊僅需要變更元數(shù)據(jù)的信息，無需移動數(shù)據(jù)。
其實施效果如何呢？首先是擴(kuò)容效果：假如分庫分表有 1000 partitions，并且 1000 partitions 都在一個實例上，而要擴(kuò)展成兩個實例，此時擴(kuò)容只需要在 1min 內(nèi)就能完成 。這樣做的好處是拆分過程與數(shù)據(jù)量無關(guān)，只需要提前準(zhǔn)備好計算節(jié)點(diǎn)資源（虛機(jī) 或 容器），即可迅速完成拆分。其次是縮容效果：縮容的方式與擴(kuò)容的方式是一致的，它也是變更元數(shù)據(jù)，因此縮容與擴(kuò)容的效率基本相同。
veDB（for MySQL） 字節(jié)業(yè)務(wù)實踐
首先來了解一下 veDB(for MySQL) 在字節(jié)的部署情況，主要包含高可用和高可靠兩種部署方案。
高可用部署方案
目前 veDB (for MySQL)是三機(jī)房部署，對于高可用部署方案，團(tuán)隊分別在每個機(jī)房部署了存儲池，如下圖所示。第一個存儲池用于存儲 Redo 日志，第二個存儲池用于存儲 Binlog，第三個存儲池是 Pagestore。
為什么要將 Redo 和 Binlog 分開存儲？因為 Redo 的存儲實現(xiàn)與 Binlog 不同，Redo 只需要存儲兩個小時，而 Binlog 需要存儲一周左右，因此它們所需的容量是完全不同的。如果將二者都放入 SSD，會對 SSD 造成極大的容量負(fù)擔(dān)，因此需要兩個存儲池。其次團(tuán)隊會在主機(jī)房（DC1）部署三個計算節(jié)點(diǎn)，在副機(jī)房（DC2、DC3）部署兩個計算節(jié)點(diǎn)。 DC1、 DC2 和 DC3 通過 Binlog 同步，但是在機(jī)房內(nèi)是通過 Redo log 同步。
該部署方案的優(yōu)點(diǎn)：一是保證最大服務(wù)可用性（RTO ~= 0），通過 Binlog 方式同步，無論哪一個機(jī)房出現(xiàn)問題，DC1 依舊可以提供服務(wù)；二是性能好/時延低，因為事務(wù)提交沒有跨機(jī)房延遲，技術(shù)團(tuán)隊利用 RDMA + AEP Store 能夠提供進(jìn)一步加速。
該部署方案的缺點(diǎn)：比如跨機(jī)房不能保證 RPO=0、副機(jī)房只讀節(jié)點(diǎn)的讀延遲會較高。如上圖所示，在 DC2 中，第一個只讀節(jié)點(diǎn)的延遲是 Binlog 延遲，第二個只讀節(jié)點(diǎn)的延遲是 Binlog 的延遲 + Redo log 的延遲。在主機(jī)房 DC1 中只有 Redo log 的延遲。
因此，該部署方案適用于對可用性和性能要求較高的業(yè)務(wù)場景，同時在極端情況下，比如機(jī)房整體故障，可能會損失一點(diǎn)數(shù)據(jù)。
高可靠部署方案
該部署方案也可以被稱為三機(jī)房六副本，它是存儲層跨機(jī)房部署，只包含兩個存儲池：LogStore SSD for redo&binlog，和 PageStore。由于它不需要依靠 Binlog 在機(jī)房間同步數(shù)據(jù)，所以可以不需要 Binlog 或者保留時間可以比較短，因此無需專門的 HDD 存儲池來存儲 Binlog。
該部署方案的優(yōu)點(diǎn)：一是保證最大數(shù)據(jù)可靠性：它依靠存儲層通過 column 協(xié)議保證數(shù)據(jù)可靠，因此如果機(jī)房出現(xiàn)問題，其中的數(shù)據(jù)也不會消失；二是只讀節(jié)點(diǎn)都延遲低：該方案中只有 Redo 日志延遲，比如 DC1 延遲是10毫秒左右，DC2 的延遲大概是 20毫秒左右。
該部署方案的缺點(diǎn)：一是性能相對較差：如果要保證 RPO = 0，事務(wù)性能相對會較差；二是時延相對較高：因為事務(wù)提交時需要寫三副本或者兩副本，這個過程中必然會存在跨機(jī)房的 RPC 延遲。
該部署方案適用于對數(shù)據(jù)可靠性要求比較高的業(yè)務(wù)，比如支付業(yè)務(wù)場景；同時它也適用于 QPS 不高，但是對備機(jī)讀延遲敏感的業(yè)務(wù)。
典型業(yè)務(wù)實踐
veDB(for MySQL) 主要被應(yīng)用于以下四類業(yè)務(wù)實踐：
小微庫
該庫的特點(diǎn)是數(shù)據(jù)量較小，QPS 較低。100% 預(yù)生產(chǎn)環(huán)境實例和部分生產(chǎn)環(huán)境實例都屬于這類情況，使用 veDB 可以顯著地提升資源利用效率。
歷史庫
該庫的特點(diǎn)是數(shù)據(jù)量超大，QPS 較低，有復(fù)雜查詢。錢包歷史數(shù)據(jù)，財經(jīng)歷史數(shù)據(jù)都屬于這類。以往的歷史數(shù)據(jù)都是導(dǎo)出到 Hive 或者其它的分析系統(tǒng)，需要經(jīng)過一個 ETL 過程。另外基于 MySQL 開發(fā)的一些應(yīng)用，在 Hive 上需要重新開發(fā)。如果通過 veDB 來做歷史庫，就不會有以上問題，上層應(yīng)用無需二次開發(fā)適應(yīng)異構(gòu)類型的歷史庫。
單體大庫
單體庫無法對分庫分表進(jìn)行拆分，該庫的特點(diǎn)是數(shù)據(jù)量大，QPS 較高，時延較低。廣告庫和財經(jīng)庫都屬于這類情況。此時，團(tuán)隊會通過 基于 RDMA 的 AEP Store 或者本地的二級讀緩存，來應(yīng)對該庫的問題與挑戰(zhàn)。
分片庫
該庫的特點(diǎn)是數(shù)據(jù)量超大，QPS 較高，時延較低，同時它能夠分庫。目前，團(tuán)隊上線了激勵中臺和 Ad-Hoc 節(jié)假日活動。
veDB（for MySQL）下一步發(fā)展方向
veDB目前往以下方向發(fā)展：
多寫架構(gòu)——Multi Master 2.0
Multi Master 2.0 的架構(gòu)如下圖所示，一共包含三層，分別是接入層、計算層、存儲層。veDB主要提供了以下三方面的支持：
● DDL ：團(tuán)隊會提供一套完整的 DDL 語法（包括表、索引），之前采用分庫分表的方式時，DDL 通常是通過DBA提交工單的方式去執(zhí)行的，對外肯定是不行的；同時，也會提供 Online 操作，允許并發(fā) DML；
● 增強(qiáng)分布式事務(wù)/查詢：支持分布式一致性讀/寫，以及支持全局二級索引；
● 其它：還會進(jìn)行一致性備份/恢復(fù)，融入 Quick Resharding。
復(fù)雜查詢：列存儲索引和向量化引擎
MySQL 的查詢能力是比較弱的，通常會把 MySQL 的數(shù)據(jù)導(dǎo)入到其它系統(tǒng)中去做查詢，這會產(chǎn)生額外的部署成本。因此團(tuán)隊希望增強(qiáng) MySQL 的查詢能力，具體來說，會引入列存儲索引、向量化引擎和一些其它的優(yōu)化支持，以此來解決部分的 OLAP 場景需要的復(fù)雜查詢能力。
內(nèi)存優(yōu)化表
在這個方向上，veDB 主要提供了以下三方面的支持：
● MM 事務(wù)引擎：MemTable 本質(zhì)上是一個單獨(dú)的存儲引擎，獨(dú)立于 InnoDB 之外，與 InnoDB 實現(xiàn)方式完全不同，但是能夠達(dá)到 10 倍的 InnoDB 性能；另外，veDB 提供了完整的 ACID 能力；
● MＭ 存儲引擎：深度融合了 RDMA/AEP，另外，日志和數(shù)據(jù)一體化；
● 編譯執(zhí)行：在 SQL 語句上執(zhí)行了預(yù)編譯優(yōu)化，大幅減少了 CPU 執(zhí)行指令數(shù)。
除了上述外，團(tuán)隊下一步還會在新硬件、無服務(wù)器方面對 veDB 進(jìn)行迭代。新硬件方面，veDB 會融合 RDMA/AEP/DPU；無服務(wù)器方面，veDB 會開展自主擴(kuò)縮容、“自動駕駛”等。
目前，veDB 正對外開放邀測，企業(yè)可通過火山引擎官網(wǎng)注冊賬號，聯(lián)系工作人員參與。
大模型時代AI應(yīng)用生存法則：以數(shù)據(jù)和RAG構(gòu)建核心壁壘
公有云大模型調(diào)用量達(dá)114.2萬億Tokens，誰在主導(dǎo)市場？
2024公有云大模型調(diào)用量，火山引擎中國第一！
15家云平臺上線DeepSeek，推薦個人嘗鮮的有這7家
豆包大模型重磅升級，視覺理解模型邁進(jìn) “厘時代”
火山引擎數(shù)智平臺：A/B測試個性化配置能力發(fā)布，拓展多場景策略最優(yōu)解
火山引擎攜零售巨頭成立大模型聯(lián)盟，抖音電商及生活服務(wù)加盟助陣
萬億數(shù)據(jù)規(guī)模下，火山引擎ByteHouse助力銀行日志數(shù)據(jù)高效分析