做數(shù)據(jù)庫有一段時間了。最近有一些在校的同學(xué)問到舆声，在實(shí)際中花沉，分布式數(shù)據(jù)庫中存儲層工作內(nèi)容是什么樣的？簡單回答了下媳握，想到其他人可能也有類似問題碱屁，于是來這里總結(jié)下、拋個磚頭蛾找。經(jīng)驗(yàn)所限娩脾，難免有誤，歡迎交流打毛。

注：限定下討論范圍柿赊，分布式數(shù)據(jù)庫，存儲計(jì)算分離隘冲，share-noting 架構(gòu)闹瞧，僅討論存儲層。

存儲層涉及的東西很龐雜展辞，想說清楚奥邮，需要有一個合適的切入角度。數(shù)據(jù)庫最本質(zhì)的功能罗珍，是存儲數(shù)據(jù)洽腺，以對外提供數(shù)據(jù)的查詢和寫入接口。不妨覆旱，就首先以這兩條線串一下各個模塊蘸朋，然后再補(bǔ)充下不能歸到這兩條線中的一些組件。

作者：木鳥雜記 https://www.qtmuniao.com/2022/05/04/distributed-database-storage-components 轉(zhuǎn)載請注明出處

查詢

查詢請求進(jìn)到存儲層扣唱，一般表現(xiàn)為下推的執(zhí)行計(jì)劃藕坯，進(jìn)而轉(zhuǎn)化為對底層存儲引擎的單點(diǎn)查詢和范圍查詢，為了加速查詢噪沙，一般會給存儲引擎配備緩存層炼彪。對于每個存儲節(jié)點(diǎn)來說，為了應(yīng)對大量的并發(fā)請求正歼，需要做 IO 優(yōu)化辐马。

執(zhí)行計(jì)劃

這是存儲層的入口，是存儲層向查詢層暴露的接口局义。

一個查詢語句經(jīng)過查詢層的語法分析（Parser）喜爷、語義檢查（Validator）冗疮、生成計(jì)劃（Planner）、計(jì)劃優(yōu)化（Optimizer）檩帐、執(zhí)行計(jì)劃（Executor）幾個步驟之后术幔，會將需要下推給存儲層的算子下發(fā)到存儲層對應(yīng)的分片（ Partition）所在節(jié)點(diǎn)。

對于火山模型來說轿塔，我們可以將執(zhí)行計(jì)劃理解為一個由基本算子（Executor）組成的 DAG特愿，甚至再簡化一些可以想象成一棵樹。樹中下層的一些小子樹勾缭，是可以直接推到存儲層對應(yīng)的節(jié)點(diǎn)去執(zhí)行的，這些可以下推的算子通常包括：TableScan目养，F(xiàn)ilter俩由，Project，Limit癌蚁，TopN 等等幻梯。

存儲層拿到這些執(zhí)行計(jì)劃后，反序列化努释，組織成內(nèi)存中的執(zhí)行計(jì)劃碘梢，以迭代模型[1]或者向量模型，來對數(shù)據(jù)進(jìn)行掃描伐蒂、過濾煞躬、排序、投影逸邦、聚合等操作后恩沛，將結(jié)果集返回給查詢層。

結(jié)果集可以有幾種返回方式：

1. 一次全量返回
2. 流式返回
3. 分頁返回

計(jì)算下推有諸多好處：

1. 充分利用存儲層的分布式節(jié)點(diǎn)進(jìn)行預(yù)計(jì)算缕减。
2. 減少存儲層到查詢層的數(shù)據(jù)傳輸帶寬消耗雷客。
3. 提高查詢層的處理速度和數(shù)據(jù)集上限。

緩存

為了對查詢進(jìn)行優(yōu)化桥狡，對于讀多寫少的場景搅裙，一般會在存儲引擎之上罩一個緩存層。如果是共享存儲層的架構(gòu)裹芝，比如存儲層在云上部逮，那么緩存層就必不可少。

緩存在設(shè)計(jì)時局雄，主要需要考慮緩存粒度和生命周期兩方面甥啄。

1. 緩存粒度。為了保持緩存和后端的數(shù)據(jù)一致性炬搭，勢必需要加鎖蜈漓，而緩存粒度和加鎖粒度息息相關(guān)穆桂。一個節(jié)點(diǎn)上的不同 Partition 的緩存要不要共享一個緩存池，也是緩存粒度需要考慮的問題融虽。
2. 生命周期享完。何時寫入后端，何時讓緩存失效有额，這涉及到緩存控制策略般又，是同步讀寫穿透，還是異步更新巍佑，都是需要根據(jù)實(shí)際情況考量的問題茴迁。

RPC IO 優(yōu)化

任何服務(wù)都是類似的，大量請求過來時萤衰，得用線程池堕义、異步、協(xié)程等各種手段優(yōu)化脆栋，提高并發(fā)倦卖，從而提高吞吐，減小延遲椿争。

有的 RPC 框架能解決這些問題怕膛，比如有些 RPC 框架內(nèi)置協(xié)程模型，支持 M 比 N 模型秦踪、協(xié)程竊取等等褐捻。如果 RPC 框架不管，就需要用額外的線程池庫洋侨、異步庫（promise舍扰、future）、協(xié)程庫來手動控制請求的執(zhí)行流并發(fā)執(zhí)行希坚。

寫入

分布式系統(tǒng)中边苹，一般會使用多副本來存儲數(shù)據(jù)。在寫入時裁僧，為了維持所有副本看到一致的寫入順序个束，會引入共識算法。共識算法通常都是維持一個邏輯上 endless 的邏輯操作日志聊疲，然后每個副本將邏輯日志應(yīng)用到自己本地的狀態(tài)機(jī)——存儲引擎茬底。在寫入數(shù)據(jù)時，需要對用戶數(shù)據(jù)進(jìn)行數(shù)據(jù)編碼获洲，轉(zhuǎn)化為二進(jìn)制串阱表，從而寫入存儲引擎。對于一些一致性（區(qū)別于多副本間的一致，此處是多語句間并發(fā)執(zhí)行的一致）要求嚴(yán)苛的場景最爬，數(shù)據(jù)庫需要對用戶提供多個語句原子化執(zhí)行的保證涉馁，即分布式事務(wù)。

共識算法

對于 share-nothing 架構(gòu)爱致，為了保證高可用烤送，都會使用多副本（Replication），并放到容錯閾不同的多臺機(jī)器上糠悯。使用多副本帮坚，就自然會引入多副本數(shù)據(jù)一致性的問題，一般我們會使用共識算法（Raft互艾、MultiPaxos）來解決试和。

使用共識算法，對于每個數(shù)據(jù)分片（Partition）忘朝，可以維護(hù)一個多機(jī)一致的操作日志（operation log灰署，WAL）：即所有寫入操作，都會序列化成操作日志記錄局嘁，并在所有的副本按唯一的順序進(jìn)行追加寫。有了一致的操作日志晦墙，我們再將其各種應(yīng)用到本地的狀態(tài)機(jī)（也就是存儲引擎）悦昵，輔以 log id，就可以對外提供一致的讀寫視圖晌畅。

存儲引擎

這里指的是單機(jī)存儲引擎但指，也就是上文所說的狀態(tài)機(jī)。它解決的問題是抗楔，如何將數(shù)據(jù)組織在單機(jī)的存儲體系中棋凳，以最少的空間，應(yīng)對特定場景的高效的寫入和讀取连躏。一般分為數(shù)據(jù)編碼剩岳、索引組織、并發(fā)控制等等幾個子模塊入热。

存儲引擎主要分為兩個流派：原地更新的 B-Tree 流派和基于追加的 LSM-Tree 流派拍棕。這里推薦兩個個學(xué)習(xí)的項(xiàng)目，B-Tree 的可以看看 BoltDB[2]勺良；LSM-Tree 可以看看 LevelDB[3]绰播。但實(shí)際使用中會用更復(fù)雜強(qiáng)大一點(diǎn)的變種，比如 RocksDB尚困。

對于 AP 場景來說蠢箩，一般使用列式存儲，可以更方便的進(jìn)行數(shù)據(jù)壓縮和進(jìn)行向量化計(jì)算。

數(shù)據(jù)編碼

數(shù)據(jù)編解碼解決的問題是谬泌，如何將邏輯上的一個記錄（如關(guān)系型數(shù)據(jù)庫中的 Row）滔韵，高效（耗時少、占空間少）的編碼為二進(jìn)制串呵萨，寫入存儲引擎奏属。

在編碼時，需要考慮和 Schema （該行有哪些字段潮峦，字段的類型是什么）的對應(yīng)關(guān)系囱皿，也要考慮在 Schema 變化時（加字段，刪字段忱嘹，改字段類型）嘱腥，如何保證數(shù)據(jù)讀取的兼容性。

分布式事務(wù)

數(shù)據(jù)庫的一大重要功能就是對事務(wù)的保證拘悦，利用事務(wù)模型的諸多保證（ACID）齿兔，可以大大減小用戶側(cè)使用數(shù)據(jù)庫的復(fù)雜度。當(dāng)然础米，這通常是以損失性能為代價的分苇，在分布式數(shù)據(jù)庫中這點(diǎn)尤為明顯。

如何保證分布式事務(wù)間的原子性和隔離性屁桑，業(yè)界有諸多方案医寿。最基本的框架是兩階段提交配合全局時鐘（有物理時鐘、邏輯時鐘蘑斧、混合時鐘和 TSO 等多種解決方案靖秩，又是一個比較大的話題），比較經(jīng)典的是有谷歌的 Percolator 模型竖瘾。

其他模塊

除了能直接歸到讀寫流程相關(guān)的組件沟突，還有一些其他存儲層交互比較頻繁的模塊和一些后臺運(yùn)行的常駐進(jìn)程。

Schema 管理

如何劃分命名空間捕传，組織不同的 Schema惠拭，就涉及到 Schema 的邏輯管理，如使用樹形組織乐横。

另外求橄，還需要維護(hù) Schema 和數(shù)據(jù)的對應(yīng)關(guān)系，但在分布式系統(tǒng)中葡公，如何非阻塞的修改 Schema罐农， 而不影響并發(fā)的數(shù)據(jù)寫入，是一個非常費(fèi)勁的事情催什。常見的解決方案有谷歌 F1 的 online DDL涵亏。

集群元信息

集群元信息主要分兩大塊：

1. 邏輯上。邏輯上的數(shù)據(jù)集組織與劃分，比如 Database气筋、Table拆内。即以合適的粒度，對數(shù)據(jù)集按命名空間進(jìn)行劃分宠默，進(jìn)而針對不同的數(shù)據(jù)集進(jìn)行不同的配置以及相應(yīng)的多租戶隔離和權(quán)限控制麸恍。
2. 物理上。物理上的節(jié)點(diǎn)的組織與劃分搀矫，比如 Zone抹沪，Node。即以合適的容錯閾瓤球，對不同節(jié)點(diǎn)進(jìn)行物理組織融欧，進(jìn)而在不同節(jié)點(diǎn)和容錯閾間處理宕機(jī)、均衡數(shù)據(jù)卦羡。

管理邏輯數(shù)據(jù)到物理節(jié)點(diǎn)的映射噪馏，即是分布式系統(tǒng)中最重要的一個方面：調(diào)度。

調(diào)度通常發(fā)生在兩個大時刻绿饵，一是數(shù)據(jù)集創(chuàng)建時欠肾，一是副本再均衡時（rebalancing，包括機(jī)器宕機(jī)拟赊、新增節(jié)點(diǎn)引起的數(shù)據(jù)再均衡）董济。

我們會依據(jù)節(jié)點(diǎn)的不同屬性（容錯閾、剩余容量）等對數(shù)據(jù)集的不同分片進(jìn)行調(diào)度要门。在進(jìn)行數(shù)據(jù)移動時，會涉及分片的多個副本的增刪廓啊，為了保證一致性欢搜，也需要通過共識協(xié)議來完成。

數(shù)據(jù)導(dǎo)入導(dǎo)出

數(shù)據(jù)庫最重要的周邊工具就是支持?jǐn)?shù)據(jù)以豐富的格式谴轮、較高的速度進(jìn)行導(dǎo)入和導(dǎo)出炒瘟。

這又可以細(xì)分為幾類：

1. 數(shù)據(jù)備份與恢復(fù)。即數(shù)據(jù)生產(chǎn)者和消費(fèi)者都是本數(shù)據(jù)庫第步，此時不用考慮支持不同的的數(shù)據(jù)格式（即可以自定義編碼疮装，只需要自己認(rèn)識即可，因此可以怎么高效怎么來）粘都，而是要考慮支持不同的數(shù)據(jù)后端：本地廓推、云上、共享文件系統(tǒng)中等等翩隧。同時樊展，也要考慮同時支持全量備份和增量備份。
2. 其他系統(tǒng)導(dǎo)入。需要考慮支持多種數(shù)據(jù)源以及不同數(shù)據(jù)格式专缠，最好能使用一些計(jì)算框架（如 Spark雷酪、Flink、Kafka）分布式的導(dǎo)入涝婉；也最好能夠支持主流的數(shù)據(jù)庫接入哥力，比如 MySQL、Postgres 等等墩弯。
3. 數(shù)據(jù)導(dǎo)出吩跋。將數(shù)據(jù)導(dǎo)出為多種通用的數(shù)據(jù)格式，如 csv最住、json钞澳、sql 語句 等等。

倉促成文涨缚，遺漏之處轧粟，歡迎在評論區(qū)補(bǔ)充。如果覺得寫的還不錯脓魏，歡迎分享給更多的同學(xué)兰吟。

我是青藤木鳥，一個喜歡攝影的分布式系統(tǒng)程序員茂翔，歡迎關(guān)注我的公眾號：“木鳥雜記”混蔼，獲取更多分布式系統(tǒng)文章和資料。

參考資料

題圖故事