數據庫存儲引擎是一個有歷史的技術，經過數十年的發展，已經出現很多優秀成熟的產品。阿里巴巴 X-Engine 團隊撰寫的論文 "X-Engine: An Optimized Storage Engine for Large-scale E-Commerce Transaction Processing"，詳細講述了團隊在數據庫存儲引擎上所做的原創性工作，今年早些時候已經被 SIGMOD'19 Industrial Track 接收(SIGMOD 是數據庫領域最重要也是最有影響力的會議之一)。本文將對這篇論文做一個前導性分析。

[[268792]]

背景

X-Engine 是阿里數據庫產品事業部自研的 OLTP 數據庫存儲引擎，作為自研數據庫POLARDB X 的存儲引擎，已經廣泛應用在阿里集團內部諸多業務系統中，其中包括交易歷史庫，釘釘歷史庫等核心應用，為業務大幅縮減了成本，同時也作為雙十一大促的關鍵數據庫技術，挺過了數百倍平時流量的沖擊。

數據庫存儲引擎是一個有歷史的技術，經過數十年的發展，已經出現很多優秀成熟的產品。各式存儲引擎已經在索引組織，緩存管理，事務處理，查詢優化方方面面都做過細致的研究。即便如此，這個領域的演進仍在持續，每年都會涌現很多的新技術。

近年來，LSM (Log-Structured Merge-Tree)結構受到越來越多的關注，雖然這個技術本身出現很多年了，不算什么新事物，不過早先在 KV 存儲系統中被應用的更多一些，近年開始在數據庫存儲引擎領域嶄露頭角，RocksDB 即是典型代表。

LSM 之所以變得流行，一是因為其簡單，二是特點鮮明。寫入模型是簡單的追加，不會更新既有的數據，數據組織為簡單的邏輯排序，由此帶來的特點是寫強而讀弱，持久化數據只讀的特點便于壓縮。但是大多數數據庫的應用場景其實都是讀多寫少的，直接使用 LSM 結構未必合適，想要另辟蹊徑，須得揚長辟短。

架構

X-Engine 使用了 LSM 作為基礎架構，目標是作為一個通用的高性能低成本存儲引擎，追求讀寫性能更為均衡，因此在其上做了大量的改進，主要圍繞幾個方向進行：

1. 利用先天優勢，持續優化寫性能。

2. 優化 compaction 降低對系統性能的沖擊，使得系統性能表現趨于平穩。

3. 利用持久化數據層只讀特點，發揮壓縮優勢降低成本。

4. 利用天然分層結構，結合硬件能力使用冷熱分層結構，降低綜合成本。

5. 利用精細化訪問機制和緩存技術，彌補讀性能短板。

X-Engine 的整體架構如下圖，根據數據冷熱進行分層代替 LSM 本身的持久化數據分層，熱數據層和數據更新使用內存存儲，利用了大量內存數據庫的技術(Lock-Free index structure/append only)提高事務處理的性能，設計了一套事務處理流水線處理機制，把事務處理的幾個階段并行起來，提升吞吐。而訪問頻度低的冷(溫)數據逐漸淘汰或是合并到持久化的存儲層次中，結合當前豐富的存儲設備層次體系(NVM/SSD/HDD)進行存儲。

我們對性能影響比較大的 compaction 過程做了大量優化，主要是拆分數據存儲粒度，利用數據更新熱點較為集中的特征，盡可能的在合并過程中復用數據，精細化控制 LSM 的形狀，減少 I/O 和計算代價，并同時極大的減少了合并過程中的空間放大。同時使用更細粒度的訪問控制和緩存機制，優化讀的性能。

既然 X-Engine 是以 LSM 為基礎架構的，所以一切還要從 LSM 本身說起。

LSM基本邏輯

一條數據在 LSM 結構中的旅程，從寫入 WAL(Write Ahead Log) 開始，然后進入MemTable，這是 Ta 整個生命周期的第一處落腳點。隨后，flush 操作將 Ta 刻在更穩固的介質上，compaction 操作將Ta帶往更深遠的去處，或是在途中丟棄，取決于 Ta 的繼任者何時到來。

LSM 的本質是，所有寫入操作并不做原地更新，而是以追加的方式寫入內存。每次寫到一定程度，即凍結為一層(Level)，寫入持久化存儲。所有寫入的行，都以主鍵(Key)排序好后存放，無論是在內存中，還是持久化存儲中。在內存中即為一個排序的內存數據結構(Skiplist, B-Tree, etc.)，在持久化存儲也作為一個只讀的全排序持久化存儲結構。

普通的存儲系統若要支持事務處理，尤其是ACI，需要加入一個時間維度，借此為每個事務構造出一個不受并發干擾的獨立視域。存儲引擎會對每個事務定序并賦予一個全局單調遞增的事務版本號(SN)，每個事務中的記錄會存儲這個 SN 以判斷獨立事務之間的可見性，從而實現事務的隔離機制。

如果 LSM 存儲結構持續寫入，不做其他的動作，那么最終會成為如下結構：

注意這里每一層的 SN 范圍標識了事務寫入的先后順序，已經持久化的數據不再會被修改。每一層數據按 Key 排序，層與層之間的 Key range 會交疊。

這種結構對于寫入是非常友好的，只要追加到最新的內存表中即完成，為實現 crash recovery，只需記錄 WAL(Redo Log)，因為新數據不會覆蓋舊版本，追加記錄會形成天然的多版本結構。

可以想見，如此累積凍結的持久化層次越來越多，會對查詢會產生不利的影響，對同一個 key 不同事務提交產生的多版本記錄會散落在各個層次中，不同的 key 也會散落在不同層次中，讀操作諸如順序掃描便需要查找各個層并合并產生最終結果。

LSM 引入了一個 compaction 的操作解決這個問題，這個操作不斷的把相鄰層次的數據合并，并寫入這個更低層次。而合并的過程實際上就是把要合并的相鄰兩層(或是多層)數據讀出來，按 key 排序，相同的 key 如果有多個版本，只保留新(比當前正在執行的活躍事務中最小版本號新)的版本，丟掉舊版本數據，然后寫入新的層。可以想見這個操作非常耗費資源。

LSM compaction 操作，有幾種作用，一是為了丟棄不再被使用的舊版本數據，二是為了控制 LSM 層次形狀，一般的 LSM 形狀都是層次越低，數據量越大(倍數關系)，這樣放置的目的主要是為了提升讀性能。

一般來講，任何存儲系統的數據訪問都有局部性，大量的訪問都集中在少部分數據上，這也是緩存系統能有效工作的基本前提，在 LSM 存儲結構中，如果我們把訪問頻率高的數據盡可能放在較高的層次上，保持這部分數據量規模，可以存放在快速存儲設備中(比如 NVM,DRAM)，而把訪問頻率低的數據放在較低層次中，使用廉價慢速存儲設備存儲。這就是 X-Engine 的根據冷熱分層概念。

要達到這種效果，核心問題是如何挑選合適的數據合并到更低的層次，這是compaction 調度策略首先要解決的問題，根據冷熱分層的邏輯，就是優先合并冷數據(訪問頻率相對低)。

識別冷數據有很多方法，對于不同的業務不盡然相同，對于很多流水型業務(如交易，日志系統)，新近寫入的數據會有更多的概率被讀到，冷熱按寫入時間順序即可區分，也有很多應用的訪問特征跟寫入的時間不一定有關系，這個就要根據實際的訪問頻率去識別冷數據或是熱數據。

除了數據熱度以外，挑選合并數據還有其他一些維度，會對讀性能產生影響，比如數據的更新頻率，大量的多版本數據在查詢的時候會浪費更多的I/O和CPU，因此需要優先進行合并以減少記錄的版本數量，X-Engine 綜合考慮了各種策略形成自己的compaction 調度機制。

Refined LSM

上面是 LSM 宏觀邏輯結構，如果具體來論讀寫操作和 compaction 如何進行，就需要探討每一層的數據組織方式, 每個 LSM 變種的實現各不相同。

X-Engine 的 memtable 使用了 Locked-free SkipList. 求的是簡單，而且并發讀寫的性能都比較高。當然有更高效的數據結構，或者同時使用多種索引技術。這個部分X-Engine 沒有做過多優化，原因在事務處理的邏輯比較復雜，寫入內存表還沒有成為其瓶頸。

持久化層如何組織更顯高效，這就需要討論每層的細微結構。

數據組織

簡單來說，X-Engine 的每層都劃分成固定大小的 Extent，存放每個層次中的數據的一個連續片段(Key Range). 為了快速定位 Extent，為每層 Extents 建立了一套索引(Meta Index)，所有這些索引，加上所有的 memory tables(active/immutable)一起組成了一個元數據樹(Metadata Tree)，root 節點為"Metadata Snapshot", 這個樹結構類似于 B-Tree，當然不盡相同。

需要注意的是，X-Engine 中除了當前的正在寫入的 active memtable 以外，其他結構都是只讀的，不會被修改。給定某個時間點, 比如 LSN=1000, 上圖中的 "Metadata Snapshot1" 引用到的結構即包含了(LSN=1000)時刻的所有的數據的快照(這也是為什么這個結構被稱為 Snapshot 的原因)。

即便是 Metadata 結構本身，也是一旦生成就不會修改。所有的讀都是以這個" Snapshot "結構為入口，這個是 X-Engine 實現 SI 隔離級別的基礎。之前講過隨著數據寫入，累積數據越多，需要對 memtable 凍結，flush, 以及層與層的compaction. 這些操作都會修改每層的數據存儲結構，所有這些操作，都是用 copy-on-write 來實現，方法就是每次都將修改(switch/flush/compaction)產生的結果寫入新的 Extent，然后依次生成新的"Meta Index"結構，乃至新的"Metadata Snapshot"，以一次 compaction 操作為例：

可以看到"Metadata Snapshot 2"相對于"Metadata Snapshot 1"并沒有太多的變化，僅僅修改了發生變更的一些葉子節點以及索引節點。這個技術頗有些類似"B-trees, Shadowing, and Clones"(https://liw.fi/larch/ohad-btrees-shadowing-clones.pdf)，如果你讀過那篇論文，會對理解這個過程有所幫助。

事務處理

得益于 LSM 輕量化寫機制，寫入操作固然是其明顯的優勢，但是事務處理遠不只是把更新的數據寫入系統那么簡單，這里要保證 ACID，涉及到一整套復雜的流程。X-Engine 將整個事務處理過程分為兩個階段：讀寫階段和提交階段。

讀寫階段需要校驗事務的寫寫沖突，讀寫沖突，判斷事務是否可以執行或回滾重試，或是等鎖。如果事務沖突校驗通過，則把修改的所有數據寫入"Transaction Buffer", 提交階段包括寫 WAL，寫內存表，以及提交并返回給用戶結果的整個過程，這里面既有 I/O 操作(寫日志，返回消息)，也有 CPU 操作(拷貝日志，寫內存表)。

為了提高事務處理吞吐，系統內會有大量事務并發執行，單個I/O操作比較昂貴，大部分存儲引擎會傾向于聚集一批事務一起提交，稱為"Group Commit"，能夠合并I/O操作，但是一組事務提交的過程中，還是有大量等待過程的，比如寫入日志到磁盤過程中，除了等待落盤無所事事。

X-Engine 為了進一步提升事務處理的吞吐，采用了一種流水線的技術：把提交階段分為四個獨立的更細的階段：拷貝日志到緩沖區(Log Buffer)，日志落盤(Log Flush)，寫內存表(Write memtable)，提交返回(Commit)。我們的事務提交線程到了處理階段，都可以自由選擇執行流水線中任意一個階段，這樣每個階段都可以并行起來，只要流水線任務的大小劃分得當，就能充分并行起來，流水線處于接近滿載狀態。

另外，利用的是事務處理的線程，而非后臺線程，每個線程在執行的時候，要么選擇了流水線中的一個階段干活，要么逛了一圈發現無事可做，干脆回去接收更多的請求，這里沒有等待，也無需切換，充分的調動了每個線程的能力。

讀操作

LSM 在處理多版本數據的方式是新版本數據記錄會追加在老版本數據后面，從物理上看，一條記錄不同的版本可能存放在不同的層，在查詢的時候需要找到合適的版本(根據事務的隔離級別定義的可見性規則)，一般查詢都是查找最新的數據，總是由新的層次(最新寫入)往老的層次方向找。

對于單條記錄的查找而言，一旦找到便可終止，如果記錄還在比較靠上的層次，比如memtable，很快便返回;如果記錄不幸已經落入了很低的層次(可能是很隨機的讀)，那就得經歷逐層查找的漫漫旅途，也許 bloomfilter 可以跳過某些層次加快這個旅程，但畢竟還是有更多的I/O操作。

X-Engine 針對單記錄查詢引入了 Row Cache，在所有持久化的層次的數據之上做了一個緩存，在 memtable 中沒有命中的單行查詢，在 Row Cache 之中也會被捕獲。Row Cache 需要保證緩存了所有持久化層次中最新版本的記錄，而這個記錄是可能發生變化的，比如每次 flush 將只讀的 memtable 寫入持久化層次時，就需要恰當的更新 Row Cache 中的緩存記錄，這個操作比較微妙，需要小心的設計。

范圍掃描的操作就沒這么幸運了。因為沒法確定一個范圍的key在哪個層次中有數據，也許是每層都有，只能掃描所有的層次做合并之后才能返回最終的結果。X- Engine 同樣采用了一系列的手段：比如 Surf(SIGMOD'18 best paper)提供 range scan filter 減少掃描層數;還有異步 I/O 與預取對大范圍掃描也有顯著的提升。

讀操作中最核心的是緩存設計，Row Cache 來應付單行查詢，Block Cache 負責Row Cache miss 的漏網之魚，也用來應付 scan;由于 LSM 的 compaction 操作會一次大批量更新大量的 Data Block，導致 Block Cache 中大量數據短時間內失效，帶來性能的急劇抖動。

X-Engine 同樣做了很多的處理：

1. 減少 Compaction 的粒度;

2. 減少 compaction 過程中改動的數據(見稍后章節) ;

3. compaction 過程中針對已有的cache數據做定點更新，由此可以基本將 cache 失效帶來的抖動降到最低的水平。

X-Engine 中的緩存比較多樣，memtable 也可算做其中一種。以有限的內存，如何恰當的分配給每一種緩存，才能實現價值最大化，是一個還未被妥善解決的問題，X-Engine 也在探索當中。

當然，LSM 對讀帶來的也并非全是壞處，除了 memtable 以外的只讀的結構，在讀取路徑上可以做到完全無鎖( memtable 也可設計成讀無鎖)。

Compaction

compaction 操作是比較重的。需要把相鄰層次交叉的 key range 數據讀出來，合并，然后寫到新的位置。這是為前面簡單的寫入操作不得不付出的代價。X-Engine 為優化這個操作重新設計了存儲結構。

如前所述，X-Engine 將每一層的數據劃分為固定大小的" Extent"，一個 Extent 相當于一個小的完整的 SSTable, 存儲了一個層次中的一個連續片段，其中又會被進一步劃分一個個連續的更小的片段"Data Block"，相當于傳統數據庫中的"Page"，只不過是只讀的，而且是不定長的。

回看數據組織一節中"合并操作對元數據的改變", 對比"Metadata Snapshot2"和"Metadata Snapshot1"的區別，可以發現 Extent 的設計意圖。是的，每次修改對結構的調整并不是全部來過，而是只需要修改少部分有交疊的數據，以及涉及到的"Meta Index"節點。

兩個"Metadata Snapshot"結構實際上共用了大量的數據結構。這個被稱為數據復用技術(Data Reuse)，而 Extent 大小正是影響數據復用率的關鍵，Extent 作為一個完整的被復用的物理結構，需要盡可能的小，這樣與其他 Extent 數據交叉點會變少，但又不能非常小，否則需要索引過多，管理成本太大。

X-Engine 中 compaction 的數據復用是非常徹底的，假設選取兩個相鄰層次(Level1, Level2)中的交叉的 Key Range 所涵蓋的 Extents 進行合并，合并算法會逐行進行掃描，只要發現任意的"物理結構"(包括 Data Block 和 Extent )與其他層中的數據沒有交疊，則可以進行復用。只不過，Extent的復用可以修改 Meta Index，而 Data Block 的復用只能拷貝，即便如此也可以節省大量的 CPU.

一個典型的數據復用在 compaction 中的過程可以參考下圖：

可以看出，對于數據復用的過程是在逐行迭代的過程中完成的，不過這種精細的數據復用帶來另一個副作用，即數據的碎片化，所以在實際操作的過程中也需要根據實際情況進行折中。

數據復用不僅給 compaction 操作本身帶來了好處，降低操作過程中的 I/O 與 CPU消耗，更對系統的綜合性能產生了一系列的影響。比如 compaction 過程中數據不用完全重寫，大大減少了寫入空間放大;更因為大部分數據保持原樣，數據緩存不會因為數據更新而失效，減少合并過程中因緩存失效帶來的讀性能抖動。

實際上，優化 compaction 的過程只是 X-Engine 工作的一部分，還有更重要的，就是優化 compaction 調度的策略，選什么樣的 Extent，定義 compaction 任務的粒度，執行的優先級，都會對整個系統性能產生影響，可惜并不存在什么完美的策略，X-Engine 積累了一些經驗，定義了很多規則，而探索如何合理的調度策略是未來一個重要方向。

后記

X-Engine 是阿里云智能事業群-數據庫產品事業部的重要核心技術之一。

作為兼容 MySQL 的數據庫 POLARDB X 的存儲引擎，之前是在服務阿里集團業務中逐漸打磨成熟，今年下半年，我們將在阿里云平臺上推出 MySQL(X-Engine) 的RDS 公有云服務，為阿里云上的公有云客戶提供低成本高性能的數據庫服務。