作者 ｜ 馬浩翔

日前，字節(jié)跳動(dòng)技術(shù)社區(qū) ByteTech 舉辦的第四期字節(jié)跳動(dòng)技術(shù)沙龍圓滿(mǎn)落幕，本期沙龍以《字節(jié)云數(shù)據(jù)庫(kù)架構(gòu)設(shè)計(jì)與實(shí)戰(zhàn)》為主題。在沙龍中，字節(jié)跳動(dòng)基礎(chǔ)架構(gòu)數(shù)據(jù)庫(kù)開(kāi)發(fā)工程師馬浩翔，跟大家探討了 《從單機(jī)到分布式數(shù)據(jù)庫(kù)存儲(chǔ)系統(tǒng)的演進(jìn)》，本文根據(jù)分享整理而成。

存儲(chǔ)系統(tǒng)概覽

存儲(chǔ)系統(tǒng)是指能高效存儲(chǔ)，持久化用戶(hù)數(shù)據(jù)的一系列系統(tǒng)軟件。在眾多的存儲(chǔ)系統(tǒng)中，以下是三類(lèi)比較主流的存儲(chǔ)產(chǎn)品及其特點(diǎn)分析：

塊存儲(chǔ)

• 底層語(yǔ)義，基于 block 編程；
• 接口樸素：在 Linux 的 IO 軟件棧中，要直接使用塊存儲(chǔ)的話(huà)就要基于 LBA 編程，因此接口較為簡(jiǎn)單樸素，再加上塊存儲(chǔ)本身處于整個(gè)存儲(chǔ)軟件棧的底層，這導(dǎo)致塊存儲(chǔ)使用起來(lái)并不十分友好；
• 追求低時(shí)延、高吞吐：研發(fā)一個(gè)塊存儲(chǔ)系統(tǒng)，在設(shè)計(jì)目標(biāo)上我們往往會(huì)追求超高的性能，體現(xiàn)在超低的時(shí)延和超高的吞吐。但考慮到塊存儲(chǔ)的接口確實(shí)過(guò)于樸素，往往只有一些追求超高性能的系統(tǒng)才會(huì)直接基于塊存儲(chǔ)構(gòu)建，然后自建應(yīng)用層 cache。

對(duì)象存儲(chǔ)

• 公有云上的王牌存儲(chǔ)產(chǎn)品：在 IT 時(shí)代，“Everything is data”的趨勢(shì)迅速催化了對(duì)象存儲(chǔ)系統(tǒng)。尤其對(duì)于字節(jié)跳動(dòng)的業(yè)務(wù)而言，使用對(duì)象存儲(chǔ)系統(tǒng)來(lái)處理視頻、圖片、音頻等非結(jié)構(gòu)化的數(shù)據(jù)，語(yǔ)義最為自然；
• 非結(jié)構(gòu)化數(shù)據(jù)，提供 immutable 語(yǔ)義：一旦圖片或視頻等非結(jié)構(gòu)化數(shù)據(jù)上傳至對(duì)象存儲(chǔ)系統(tǒng)成功，則無(wú)法對(duì)其進(jìn)行原地修改，只能通過(guò)刪除舊數(shù)據(jù)，重新上傳新數(shù)據(jù)的方式完成“修改”邏輯；
• 成本優(yōu)先：一般不苛求單次操作的時(shí)延，但是非常注重系統(tǒng)吞吐 & 存儲(chǔ)成本。

文件系統(tǒng)

• 接口語(yǔ)義豐富，普適性強(qiáng)：遵循 POSIX/弱 POSIX 語(yǔ)義，諸如 Open、Write、Read 等許多操作數(shù)據(jù)的接口都能在文件系統(tǒng)中被找到。
• 擁有較多開(kāi)源的分布式實(shí)現(xiàn)，生態(tài)良好。
• 一般也不苛求時(shí)延，注重系統(tǒng)吞吐 & 存儲(chǔ)成本。

單機(jī)數(shù)據(jù)庫(kù)存儲(chǔ)解析

單機(jī)數(shù)據(jù)庫(kù)存儲(chǔ)，要從內(nèi)存層和持久化層兩個(gè)方面來(lái)解析。在內(nèi)存層，僅說(shuō)關(guān)系型數(shù)據(jù)庫(kù)，其內(nèi)存數(shù)據(jù)結(jié)構(gòu)特點(diǎn)可以總結(jié)為：一切都是“樹(shù)”。我們以最常見(jiàn)的 B+ 樹(shù)為例，B+ 樹(shù)具有以下突出的特點(diǎn)：

• In memory 操作效率非常高：B+ 樹(shù)搜索時(shí)間復(fù)雜度是 log 級(jí)別；并且 B+ 樹(shù)的葉子節(jié)點(diǎn)構(gòu)成鏈表，非常有利于在內(nèi)存中對(duì)數(shù)據(jù)進(jìn)行 scan 操作。
• 磁盤(pán)操作效率高：B+ 樹(shù)的 Fanout 足夠大，樹(shù)的層級(jí)較少，呈矮胖狀，可以減少磁盤(pán) IO 數(shù)；同時(shí) B+ 樹(shù)的非葉子節(jié)點(diǎn)只存索引數(shù)據(jù)，葉子節(jié)點(diǎn)存實(shí)際數(shù)據(jù)，能大大壓縮樹(shù)高，進(jìn)一步減少磁盤(pán) IO 數(shù)。
• 數(shù)據(jù)結(jié)構(gòu)高度統(tǒng)一：數(shù)據(jù) & 索引都可以直接組織成 B+ 樹(shù)，因此代碼的可維護(hù)性、可讀性和開(kāi)發(fā)效率都比較好。

僅有內(nèi)存數(shù)據(jù)結(jié)構(gòu)當(dāng)然是不夠的，我們還需要設(shè)計(jì)高效的磁盤(pán)數(shù)據(jù)結(jié)構(gòu)，下圖展示了從內(nèi)存數(shù)據(jù)結(jié)構(gòu)到磁盤(pán)數(shù)據(jù)結(jié)構(gòu)的數(shù)據(jù)持久化過(guò)程：

左邊虛線(xiàn)框描繪的是 In Memory 結(jié)構(gòu)示意圖。舉個(gè)例子，如果我們要修改 Page A 的某一行數(shù)據(jù)，對(duì)其中的一個(gè)字段進(jìn)行自增，自增值是 2。自然而然會(huì)產(chǎn)生一個(gè)數(shù)據(jù)庫(kù)的物理操作日志，即 Redo Log，用來(lái)描述我們對(duì) Page A 的修改。同時(shí)，在數(shù)據(jù)庫(kù)的事務(wù)執(zhí)行過(guò)程中，可能還會(huì)產(chǎn)生大量臨時(shí)數(shù)據(jù)（圖里的 Temp data），當(dāng)內(nèi)存不夠用的時(shí)候也需要將其持久化。

右邊虛線(xiàn)框描繪的是 In Persistent Layer 的示意圖。假設(shè)我們使用比較友好的文件系統(tǒng)來(lái)將內(nèi)存數(shù)據(jù)持久化，我們需要設(shè)置不同的文件，讓它們各司其職。例如圖里的藍(lán)色文件存儲(chǔ) Page，綠色文件存儲(chǔ) Redo Log，粉色文件存儲(chǔ)臨時(shí)數(shù)據(jù)。如果數(shù)據(jù)庫(kù)發(fā)生 crash ，在恢復(fù)階段我們就在各類(lèi)文件中進(jìn)行數(shù)據(jù)定位，結(jié)合 Redo Log File 和 Page File ，進(jìn)行數(shù)據(jù)庫(kù)的數(shù)據(jù)恢復(fù)。除此之外，如果直接基于塊存儲(chǔ)進(jìn)行持久化，就需要數(shù)據(jù)庫(kù)本身的存儲(chǔ)引擎管理好 LBA，需要在用戶(hù)態(tài)里面實(shí)現(xiàn) buffer cache 等邏輯，這也是可行的。

那么基于單機(jī)的 FS / 塊存儲(chǔ)去做持久化，我們會(huì)遇到哪些問(wèn)題呢？通過(guò)下面的單機(jī)數(shù)據(jù)庫(kù)系統(tǒng)的典型架構(gòu)圖，我們可以發(fā)現(xiàn)三個(gè)問(wèn)題：

• 單機(jī)容量瓶頸：在 Database 層的單機(jī)服務(wù)器上運(yùn)行著 database 進(jìn)程，服務(wù)器上掛載了大量本地磁盤(pán)用作數(shù)據(jù)持久化。但一臺(tái)物理服務(wù)器能掛載的磁盤(pán)容量總是有限的，這就導(dǎo)致了單機(jī)的容量瓶頸問(wèn)題。
• 擴(kuò)縮容困難：當(dāng)容量、CPU 或者內(nèi)存等資源不夠時(shí)，我們需要進(jìn)行擴(kuò)容。在單機(jī)時(shí)代，擴(kuò)容意味著將數(shù)據(jù)從這個(gè)磁盤(pán)搬遷到另一個(gè)磁盤(pán)。但不管我們是通過(guò)網(wǎng)絡(luò)還是有線(xiàn)連接手段，都需要花費(fèi)一定的時(shí)間，這可能導(dǎo)致業(yè)務(wù)較長(zhǎng)時(shí)間的停寫(xiě)（不可用），因此擴(kuò)縮容是非常困難的。
• 多份獨(dú)立數(shù)據(jù)，成本高：如果我們要在“復(fù)制集”之間或者主備機(jī)之間去做數(shù)據(jù)冗余或數(shù)據(jù)同步，那么每新增一分計(jì)算能力（新增一個(gè)計(jì)算節(jié)點(diǎn)），就要新增一分存儲(chǔ)冗余，就會(huì)導(dǎo)致存儲(chǔ)成本提高。

分布式數(shù)據(jù)庫(kù)存儲(chǔ)解析

為了解決單機(jī)數(shù)據(jù)庫(kù)存儲(chǔ)系統(tǒng)面臨的問(wèn)題和挑戰(zhàn)，字節(jié)跳動(dòng)的數(shù)據(jù)庫(kù)團(tuán)隊(duì)調(diào)研了一些業(yè)界主流的分布式數(shù)據(jù)庫(kù)方案。

MyRocks: MySQL + RocksDB

需要說(shuō)明的是，MyRocks 不是分布式數(shù)據(jù)庫(kù)或者分布式解決方案，它是單機(jī) SQL over kv 的典型代表。

• 核心理念：用 RocksDB 替換 InnoDB 。使用 RocksDB 能夠有效緩解單機(jī)容量瓶頸的問(wèn)題；
• 特點(diǎn)：一是：數(shù)據(jù)可壓縮比例較高。RocksDB 實(shí)現(xiàn)了一種比較優(yōu)秀的壓縮算法，根據(jù)實(shí)際調(diào)研結(jié)果顯示，在關(guān)系型數(shù)據(jù)庫(kù)場(chǎng)景，基本上它能實(shí)現(xiàn) 2-4 倍的壓縮比，能有效緩解單機(jī)的容量瓶頸問(wèn)題。例如，單機(jī)原本掛載了 10 塊磁盤(pán)，只能承載 10 TB 數(shù)據(jù)，使用 RocksDB 就能在不改變硬件條件下幫助單機(jī)承載 20 TB 或 30 TB 等更多的數(shù)據(jù)；二是，順序?qū)懶阅茌^好，這也是 LSM-Tree 這種數(shù)據(jù)結(jié)構(gòu)在 HDD 年代出現(xiàn)的核心原因。
• 難點(diǎn)：Compaction 會(huì)導(dǎo)致性能抖動(dòng)，且兼容性一般。眾所周知，RocksDB 基于 LSM-Tree 構(gòu)建，必然會(huì)遇到一些典型的 LSM-Tree-based 系統(tǒng)的問(wèn)題。雖然 RocksDB 對(duì)順序?qū)懱貏e友好，但它一定程度上犧牲了讀性能—— RocksDB 在讀的過(guò)程中會(huì)觸發(fā) Compaction，可能引發(fā)性能抖動(dòng)，導(dǎo)致前臺(tái)的寫(xiě)出現(xiàn)卡頓現(xiàn)象；同時(shí)，這一類(lèi) SQL over kv 解決方案的兼容性能表現(xiàn)較為一般。

Amazon Aurora: 計(jì)算存儲(chǔ)分離

• 核心理念：計(jì)算存儲(chǔ)分離，Log is Database。
• 特點(diǎn)：架構(gòu)靈活，存儲(chǔ)層帶有特定的數(shù)據(jù)庫(kù)計(jì)算邏輯，除了具備存儲(chǔ)能力之外，還具備 Redo Log 解析、回放生成數(shù)據(jù)庫(kù) Page、維護(hù)多版本數(shù)據(jù)的能力。
• 優(yōu)勢(shì)：兼容性強(qiáng)、讀擴(kuò)展能力較優(yōu)。基于共享存儲(chǔ)系統(tǒng)的特點(diǎn)，Amazon Aurora 的讀計(jì)算節(jié)點(diǎn)具備較好的擴(kuò)展性，能夠?qū)崿F(xiàn)一主 15 備的部署形態(tài)，其兼容性、讀擴(kuò)展性表現(xiàn)較好。

Spanner 系: Shared-Nothing

• 核心理念：計(jì)算存儲(chǔ)分離，且 Share-Nothing。
• 特點(diǎn)：Spanner 系的數(shù)據(jù)庫(kù)系統(tǒng)一般基于分布式 k-v 存儲(chǔ)構(gòu)建，由存儲(chǔ)層保證事務(wù)特性，計(jì)算層做成純計(jì)算的無(wú)狀態(tài)節(jié)點(diǎn)。
• 難點(diǎn)：要解決當(dāng)前數(shù)據(jù)庫(kù)生態(tài)兼容性問(wèn)題 & 分布式 k-v 系統(tǒng)的 hotspot 問(wèn)題比較麻煩。

最佳實(shí)踐：veDB 分布式存儲(chǔ)系統(tǒng)

基于上述字節(jié)數(shù)據(jù)庫(kù)團(tuán)隊(duì)的調(diào)研結(jié)果，我們?cè)O(shè)計(jì)了 veDB 分布式存儲(chǔ)系統(tǒng)以解決單機(jī)數(shù)據(jù)庫(kù)存儲(chǔ)系統(tǒng)面臨的問(wèn)題與挑戰(zhàn)，本節(jié)將主要介紹 veDB 分布式存儲(chǔ)系統(tǒng)的系統(tǒng)目標(biāo)與核心技術(shù)特點(diǎn)。

系統(tǒng)目標(biāo)

在設(shè)計(jì)理念上，我們期望存儲(chǔ)系統(tǒng)能夠?qū)崿F(xiàn)以下四個(gè)主要目標(biāo)：

• 極致彈性：存儲(chǔ)節(jié)點(diǎn)與計(jì)算節(jié)點(diǎn)解耦，隨時(shí)彈性擴(kuò)縮容；
• 極致易用性：構(gòu)建 one-size-fits-all 的存儲(chǔ)系統(tǒng)，而非專(zhuān)用存儲(chǔ)，要能兼容多個(gè)主流數(shù)據(jù)庫(kù)（MySQL & PostgreSQL & Mongo……）；
• 極致性?xún)r(jià)比：低時(shí)延、低成本；
• 極致可靠性：具備高性能、高可靠的備份恢復(fù)能力。

基于以上系統(tǒng)目標(biāo)，數(shù)據(jù)庫(kù)團(tuán)隊(duì)設(shè)計(jì)并開(kāi)發(fā)了 veDB 分布式存儲(chǔ)系統(tǒng)，如下圖所示：

從圖中可以看出，分布式存儲(chǔ)層基于 LogStore 和 PageStore 這兩個(gè)子系統(tǒng)構(gòu)建，其系統(tǒng)特點(diǎn)與我們的設(shè)計(jì)目標(biāo)相互呼應(yīng)。

• 高彈性：存儲(chǔ)層可獨(dú)立擴(kuò)縮容，計(jì)算層完全不感知；
• 高性?xún)r(jià)比：在 LogStore 實(shí)現(xiàn)了高性能 Log 存儲(chǔ) & 在 PageStore 實(shí)現(xiàn)了低成本 Page 存儲(chǔ)；
• 兼容性好：LogStore 和 PageStore 都支持多 DB Engine 插件化；
• 高可靠：PageStore 側(cè)支持 Segment 級(jí)別的 PITR 功能。

核心技術(shù)

以下主要從研發(fā)背景（Problem）、解決思路（Solution）、解決成效（Outcome）三個(gè)方面來(lái)分別介紹 veDB 分布式存儲(chǔ)系統(tǒng)的五個(gè)核心技術(shù)。

Distributed Data Model

Problem：從單機(jī) FS 到分布式存儲(chǔ)，需要有高效的數(shù)據(jù)布局模型?；趩螜C(jī)的文件系統(tǒng)或塊存儲(chǔ)系統(tǒng)去實(shí)現(xiàn)數(shù)據(jù)持久化是比較簡(jiǎn)單的，我們可以直接通過(guò)申請(qǐng)一批 LBA 或者一批文件來(lái)存儲(chǔ)數(shù)據(jù)，然后控制并發(fā)即可，但是這對(duì)于分布式存儲(chǔ)并不容易。從上面的示意圖可以看到，最上層的 Tablespace 代表一張數(shù)據(jù)庫(kù)表，里面可能包含上百萬(wàn)甚至上千萬(wàn)的 Page data（數(shù)據(jù)庫(kù)的基礎(chǔ)管理單元）。然而存儲(chǔ)系統(tǒng)的管理單元，卻不可能是 Page —— Page 的粒度過(guò)小，往往只有 KB 級(jí)別，如果存儲(chǔ)層以過(guò)小的粒度去管理數(shù)據(jù)，可能會(huì)造成元數(shù)據(jù)膨脹，增加管理成本。

Solution：Tablespace -> Segement 分布式映射?；谏鲜鰡?wèn)題，我們可以在存儲(chǔ)層利用相對(duì)大的管理單元 Segment 去進(jìn)行數(shù)據(jù)管理。此時(shí)，數(shù)據(jù)庫(kù)的管理單元是 Page，存儲(chǔ)系統(tǒng)的管理單元是 Segement。Tablespace 和 Segement 之間必然要存在一層映射關(guān)系，該映射關(guān)系可以根據(jù)不同數(shù)據(jù)庫(kù)引擎的數(shù)據(jù)管理空間大小要求進(jìn)行設(shè)置，可能 MySQL 和 PostgreSQL 的映射規(guī)則就大不相同。上述示意圖展示了最簡(jiǎn)單的模 2 規(guī)則，我們也可以發(fā)展出其他更加復(fù)雜的打散規(guī)則，此處不進(jìn)行贅述。當(dāng)我們將 Page 打散到對(duì)應(yīng)的 Segement 之后，數(shù)據(jù)庫(kù)就不需要管數(shù)據(jù) Replication 的邏輯，不管底層存儲(chǔ)是多副本還是 EC 策略，可以完全由存儲(chǔ)系統(tǒng)來(lái)做透明的 Replication ，數(shù)據(jù)庫(kù)就像在使用單機(jī)文件系統(tǒng)一樣簡(jiǎn)單。

Outcome

• 天然負(fù)載均衡；
• 分布式打散，可最大程度實(shí)現(xiàn)并行計(jì)算；
• Scale in/out 簡(jiǎn)單，僅需部分 Segement 數(shù)據(jù) rebalance，摒棄了將整個(gè)數(shù)據(jù)庫(kù)表的 TB 級(jí)數(shù)據(jù)在硬盤(pán)間搬遷的繁雜流程。

Log-Only Segement

Problem：數(shù)據(jù)冗余成本高，需要降低存儲(chǔ)成本。

Solution：開(kāi)發(fā) Log-Only Segement，節(jié)省非必要的 Page 副本空間。什么是 Log-only segement? 關(guān)系型數(shù)據(jù)庫(kù)中往往都包含 Log 數(shù)據(jù)和 Page 數(shù)據(jù)。在存儲(chǔ)層中，存了多副本的 Log 數(shù)據(jù)后，我們可以選擇性地只回放一部分 Log 數(shù)據(jù)來(lái)生成 Page，讓另一部分 Log 數(shù)據(jù)保持不動(dòng)，不要生成任何 Page 數(shù)據(jù)。以上面的示意圖為例，Rep_0 和 Rep_1 都是 Log 數(shù)據(jù)生成的各種版本 Page 數(shù)據(jù)，然而 Rep_2 是一個(gè)空的 Page 數(shù)據(jù)副本，它里面只有 Redo log。我們都知道 Redo log 和 Page data 的數(shù)據(jù)大小比例是比較夸張的，Page data 的大小可能是 Redo log 的幾倍甚至十幾倍，因此通過(guò)以上方法能夠較大的節(jié)省單機(jī)的 Page 存儲(chǔ)空間。

Outcome：結(jié)合單機(jī)引擎的壓縮算法，能將存儲(chǔ)空間放大倍數(shù)從 3.x -> 1.x，較好緩解成本問(wèn)題。

高性能 IO 引擎

Problem：存儲(chǔ)層寫(xiě)性能容易成為系統(tǒng)性能瓶頸，如何解決？

Solution：全異步 IO + 無(wú)鎖結(jié)構(gòu) +并發(fā)打散。當(dāng)數(shù)據(jù)庫(kù)提交了一個(gè) Redo log 到 Log Storage 之后，Log Storage 中會(huì)有一個(gè)無(wú)鎖的 Ring buffer 去對(duì) Redo log 進(jìn)行有序組織，然后我們將 Redo Log 的 Ring buffer 進(jìn)行線(xiàn)性的定長(zhǎng)切割，并發(fā)打散到底層存儲(chǔ)的 Blob 單元。

Outcome：4KB + depth 8，write latency ~100+us，較好支撐了數(shù)據(jù)庫(kù)下發(fā)日志的性能剛需。

PITR

PITR（Point-in-time Recovery）是指我們都可以迅速地恢復(fù)在過(guò)去一段時(shí)間內(nèi)某個(gè)時(shí)間點(diǎn)的數(shù)據(jù)庫(kù)快照。

Problem：如何快速備份恢復(fù)，且降低對(duì)前臺(tái)業(yè)務(wù)影響？

Solution：基于 Segement 的高并發(fā) PITR 機(jī)制，Segement 間互不影響。之前提到存儲(chǔ)層的管理單元是 Segement ，我們也可以基于 Segement 做備份恢復(fù)。這樣做有兩個(gè)好處：首先計(jì)算層是完全透明的，計(jì)算層完全不會(huì)感知，并且計(jì)算層的性能不會(huì)抖動(dòng)。其次基于 Segment 可以做到天然的并發(fā)打散，因此備份恢復(fù)也可以做到并發(fā)恢復(fù)。

Outcome

• 性能優(yōu)秀，恢復(fù) 1TB 數(shù)據(jù) ~15min；
• 擴(kuò)展性強(qiáng)，不受數(shù)據(jù)大小影響，性能與數(shù)據(jù)大小呈近常數(shù)關(guān)系：因?yàn)榛?Segment 單元去做并發(fā)備份恢復(fù)，每個(gè) Segment 都是獨(dú)立的，其性能能夠與數(shù)據(jù)大小解耦開(kāi)來(lái)。因此不管數(shù)據(jù)大小是多少，只要備份恢復(fù)資源足夠，都能做到常數(shù)級(jí)的備份恢復(fù)性能。

多計(jì)算引擎插件化

Problem：數(shù)據(jù)庫(kù)團(tuán)隊(duì)希望統(tǒng)一的存儲(chǔ)層能夠支持不同的數(shù)據(jù)庫(kù)引擎，做到 100% 兼容和快速接入。

Solution：Write Ahead Log + Log Replay = 任意 Page Data?；诒镜卮鎯?chǔ)引擎的 k-v 結(jié)構(gòu)，或者基于裸的塊設(shè)備抽象出一種相對(duì)通用的數(shù)據(jù)結(jié)構(gòu)，從而高效地存儲(chǔ) Page data。同時(shí)，我們?cè)?SDK 側(cè)和 Server 側(cè)都做了 Log parse 的插件化，要接入新的數(shù)據(jù)庫(kù)引擎只需要其提供適配存儲(chǔ)接口的日志插件，從而可以快速接入各式各樣的數(shù)據(jù)庫(kù)計(jì)算引擎。

Outcome：

• 基于統(tǒng)一接口，計(jì)算引擎僅需提供 Log parse + Replay lib 即可接入 veDB 存儲(chǔ)層。
• 統(tǒng)一存儲(chǔ)層已支持 MySQL、PostgreSQL、MongoDB 計(jì)算引擎，目前仍在持續(xù)拓展。

數(shù)據(jù)庫(kù)存儲(chǔ)系統(tǒng)：What's Next

在談及數(shù)據(jù)庫(kù)存儲(chǔ)的未來(lái)演進(jìn)時(shí)，首先我們可以思考一下哪些因素會(huì)觸發(fā)數(shù)據(jù)庫(kù)存儲(chǔ)架構(gòu)的變革和演進(jìn)？答案可能包含：存儲(chǔ)架構(gòu)自身的革命、數(shù)據(jù)庫(kù)理論的突破、或者新硬件沖擊引發(fā)存儲(chǔ)系統(tǒng)架構(gòu)迭代。基于這三個(gè)方向的思考，我們總結(jié)了以下幾個(gè)數(shù)據(jù)庫(kù)存儲(chǔ)系統(tǒng)的演進(jìn)趨勢(shì)：

HTAP/HSAP

我們總結(jié)的第一個(gè)趨勢(shì)即 HTAP/HSAP 系統(tǒng)將會(huì)逐漸爆發(fā)。在 HTAP/HSAP 系統(tǒng)中，“實(shí)時(shí)”是第一關(guān)鍵詞。為了支持實(shí)時(shí)，存儲(chǔ)系統(tǒng)可能會(huì)發(fā)生架構(gòu)演進(jìn)和變革，因此我們需要探索：

• 行列存 All-in-one：既要存儲(chǔ)行式的數(shù)據(jù)，又要存儲(chǔ)列式的數(shù)據(jù)。
• 近實(shí)時(shí)，寫(xiě)時(shí)計(jì)算：我們需要在存儲(chǔ)層實(shí)現(xiàn)寫(xiě)時(shí)計(jì)算的邏輯來(lái)支持實(shí)時(shí)性。

AI Enhancement

AI 技術(shù)運(yùn)用領(lǐng)域廣泛，具體在數(shù)據(jù)庫(kù)存儲(chǔ)領(lǐng)域，我們可以利用 AI 技術(shù)進(jìn)行以下工作：

• 存儲(chǔ)參數(shù)調(diào)優(yōu)；
• 智能存儲(chǔ)格式：利用 AI 技術(shù)進(jìn)行智能的行存和列存格式轉(zhuǎn)換，AI 可以提醒我們什么時(shí)間進(jìn)行轉(zhuǎn)換，什么時(shí)候絕對(duì)不能轉(zhuǎn)換，從而避免格式轉(zhuǎn)換為前臺(tái)業(yè)務(wù)帶來(lái)的性能 overhead。

Hardware Revolution

在硬件變革趨勢(shì)上，我們總結(jié)了三個(gè)變革方向：

• 存儲(chǔ)介質(zhì)變革：前幾年，我們可能更多關(guān)注 SSD、HDD。目前我們處于 SSD 往 persistent memory 轉(zhuǎn)變的風(fēng)口，那么如何利用 persistent memory 去定制軟件架構(gòu)？目前看在文件系統(tǒng)側(cè)已經(jīng)有一些研究，但是在數(shù)據(jù)庫(kù)側(cè)并沒(méi)有太多公開(kāi)實(shí)踐。
• 計(jì)算單元變革：CPU 產(chǎn)品已經(jīng)從 multi-core 變成了 many-core （從 96c 變成了 192c、384c）。要怎么利用多核的能力？對(duì)于非計(jì)算密集型的存儲(chǔ)系統(tǒng)而言，多余的算力能否用來(lái)加速數(shù)據(jù)庫(kù)算子？一些無(wú)鎖的數(shù)據(jù)結(jié)構(gòu)是不是需要要重新設(shè)計(jì)？以上都需要我們認(rèn)真考慮。
• 網(wǎng)絡(luò)設(shè)施變革：例如 RDMA ，以及可編程的 P4 交換機(jī)這類(lèi)全新的一些網(wǎng)絡(luò)設(shè)施，可能會(huì)對(duì)我們的軟件架構(gòu)特別是分布式存儲(chǔ)架構(gòu)造成較大的沖擊。相應(yīng)地，我們需要在存儲(chǔ)側(cè)做出調(diào)整。

文章名稱(chēng)：從單機(jī)到分布式數(shù)據(jù)庫(kù)存儲(chǔ)系統(tǒng)的演進(jìn)
鏈接地址：http://uogjgqi.cn/article/coioech.html