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

重要

X-Engine引擎已進入下線階段，詳情參見【停售/下線】2024年11月1日存儲引擎類型為X-Engine的云數據庫RDS MySQL版實例停止新購。

為什么設計一個新的存儲引擎

X-Engine的誕生是為了應對阿里內部業務的挑戰，早在2010年，阿里內部就大規模部署了MySQL數據庫，但是業務量的逐年爆炸式增長，數據庫面臨著極大的挑戰：

這兩個問題雖然可以通過擴展數據庫節點的分布式方案解決，但是堆機器不是一個高效的手段，我們更想用技術的手段將數據庫性價比提升，實現以少量資源換取性能大幅提高的目的。

傳統數據庫架構的性能已經被仔細的研究過，數據庫領域的泰斗，圖靈獎得主Michael 就此寫過一篇論文 《OLTP Through the Looking Glass, and What We Found There》，指出傳統關系型數據庫，僅有不到10%的時間是在做真正有效的數據處理工作，剩下的時間都浪費在其它工作上，例如加鎖等待、緩沖管理、日志同步等。

造成這種現象的原因是近年來我們所依賴的硬件體系發生了巨大的變化，例如多核（眾核）CPU、新的處理器架構（Cache/NUMA）、各種異構計算設備（GPU/FPGA）等，而架構在這些硬件之上的數據庫軟件卻沒有太大的改變，例如使用B-Tree索引的固定大小的數據頁（Page）、使用ARIES算法的事務處理與數據恢復機制、基于獨立鎖管理器的并發控制等，這些都是為了慢速磁盤而設計，很難發揮出現有硬件體系應有的性能。

基于以上原因，阿里開發了適合當前硬件體系的存儲引擎，即X-Engine。

X-Engine架構

全新架構的X-Engine存儲引擎不僅可以無縫對接兼容MySQL（得益于MySQL Storage Engine特性），同時X-Engine使用分層存儲架構。

因為目標是面向大規模的海量數據存儲，提供高并發事務處理能力和降低存儲成本，在大部分大數據量場景下，數據被訪問的機會是不均等的，訪問頻繁的熱數據實際上占比很少，X-Engine根據數據訪問頻度的不同將數據劃分為多個層次，針對每個層次數據的訪問特點，設計對應的存儲結構，寫入合適的存儲設備。

X-Engine使用了作為分層存儲的架構基礎，并進行了重新設計：

同時使用更細粒度的訪問控制和緩存機制，優化讀的性能。

說明

X-Engine的架構和優化技術已經被總結成論文 《X-Engine: An Storage Engine for Large-scale E- 》，在數據管理國際會議SIGMOD'19發表，這是中國內地公司首次在國際性學術會議上發表OLTP數據庫內核相關的技術成果。

技術特點

LSM基本邏輯

LSM的本質是所有寫入操作直接以追加的方式寫入內存。每次寫到一定程度，即凍結為一層（Level），并寫入持久化存儲。所有寫入的行，都以主鍵（Key）排序好后存放，無論是在內存中，還是持久化存儲中。在內存中即為一個排序的內存數據結構（、B-Tree等），在持久化存儲也作為一個只讀的全排序持久化存儲結構。

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

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

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

但是如此累積，凍結的持久化層次越來越多，會對查詢產生不利的影響。例如對同一個key，不同事務提交產生的多版本記錄會散落在各個層次中；不同的key也會散落在不同層次中。讀操作需要查找各個層并合并才能得到最終結果。

因此LSM引入了操作解決這個問題，操作有2種作用：

高度優化的LSM

X-Engine的memory tables使用了無鎖跳表（Locked-free ），并發讀寫的性能較高。在持久化層如何實現高效，就需要討論每層的細微結構。

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

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

回看并對比 1和 2，可以發現Extent的設計意圖。每次修改只需要修改少部分有交疊的數據，以及涉及到的Meta Index節點。兩個 結構實際上共用了大量的數據結構，這被稱為數據復用技術（Data Reuse），而Extent大小正是影響數據復用率的關鍵，Extent作為一個完整的被復用的物理結構，需要盡可能的小，這樣與其他Extent數據交叉點會變少，但又不能非常小，否則需要索引過多，管理成本太大。

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

一個典型的數據復用在中的過程可以參見下圖。

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

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

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

適用場景

請參見。

如何使用X-Engine

請參見。

后續發展

作為MySQL的存儲引擎，持續地提升MySQL系統的兼容能力是一個重要目標，后續會根據需求的迫切程度逐步加強原本取消的一些功能，例如外鍵，以及對一些數據結構、索引類型的支持。

X-Engine作為存儲引擎，核心的價值還在于性價比，持續提升性能降低成本，是一個長期的根本目標，X-Engine還在調度、緩存管理與優化、數據壓縮、事務處理等方向上進行深層次的探索。