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