國(guó)產(chǎn)數(shù)據(jù)庫(kù)存儲(chǔ)引擎 X-Engine 的科研之路

時(shí)間：2023-03-13 10:32:01 | 來(lái)源：電子商務(wù)

時(shí)間：2023-03-13 10:32:01 來(lái)源：電子商務(wù)

研究背景

X-Engine 是阿里云上數(shù)據(jù)庫(kù) RDS MySQL 的存儲(chǔ)引擎，已經(jīng)廣泛應(yīng)用于阿里的各項(xiàng)業(yè)務(wù)并在阿里云上售賣(mài)。X-Engine 是基于 Log-structured Merge Tree (LSM-tree) 這種數(shù)據(jù)結(jié)構(gòu)的數(shù)據(jù)庫(kù)存儲(chǔ)引擎，和 B-tree 一族的其它存儲(chǔ)引擎而言年輕很多，所以在實(shí)踐中遇到問(wèn)題也更多，對(duì)研究的需求也更大。LSM-tree 是 1996 年由美國(guó)計(jì)算機(jī)科學(xué)家 Patrick O'Neil 等人提出的一種數(shù)據(jù)結(jié)構(gòu)，和 B-tree 相比，它擁有更快的寫(xiě)入性能和層次化的存儲(chǔ)結(jié)構(gòu)，能夠同時(shí)利用好 DRAM 內(nèi)存的高性能和持久化存儲(chǔ)的高容量。尤其是 LSM-tree 的分層存儲(chǔ)結(jié)構(gòu)，可以天然地利用數(shù)據(jù)局部性將熱數(shù)據(jù)和冷數(shù)據(jù)區(qū)別開(kāi)，方便壓縮算法有的放矢，有機(jī)會(huì)在降低整體成本的情況下，實(shí)現(xiàn)同樣優(yōu)秀的性能。但是，與幾乎所有的計(jì)算機(jī)數(shù)據(jù)結(jié)構(gòu)和系統(tǒng)設(shè)計(jì)一樣，有得必有失。LSM-tree 難以避免的在讀性能、I/O 寫(xiě)放大和空間效率上面對(duì)挑戰(zhàn)。

寫(xiě)路徑上的羅生門(mén)

首先，LSM-tree 使用了能夠支持快速寫(xiě)入的 copy-on-write （CoW）方式來(lái)存儲(chǔ)新增數(shù)據(jù)。顧名思義，假如我要使用 CoW 來(lái)更新一條記錄，我不需要定位存儲(chǔ)引擎中該條記錄的地址并將它讀取出來(lái)，只需要直接將我要更新的內(nèi)容（例如，key = 100, value = value +100）寫(xiě)入內(nèi)存和日志（直接寫(xiě)磁盤(pán)）即可。這樣整個(gè)寫(xiě)入操作就像記日記一樣，我只需要在日記本的最后一個(gè)空白頁(yè)上新增內(nèi)容即可，至于這個(gè)日記本已經(jīng)寫(xiě)了多少頁(yè)，或者以前的某頁(yè)里面寫(xiě)了什么，我都不需要管。所以，LSM-tree 的寫(xiě)入操作代價(jià)很低，而且與數(shù)據(jù)庫(kù)中的已存數(shù)據(jù)關(guān)系不大，無(wú)論這個(gè)數(shù)據(jù)庫(kù)已經(jīng)存了多少數(shù)據(jù)，運(yùn)行了多少天，寫(xiě)一條記錄在理想狀態(tài)下都可以被執(zhí)行得非?？?。同理，如果我需要?jiǎng)h除一條記錄，我只需要新插入一條反記錄即可。

那么問(wèn)題來(lái)了，讀記錄的時(shí)候我難免要去檢查一下這條記錄的原始數(shù)據(jù)在哪里，是什么，它有沒(méi)有更新，在哪里，是什么，等等等等，然后把所有這樣的碎片合并在一起，我才知道這條記錄到底是什么（例如，key == 100， value = 0 + 100 + 200 - 300 = 0）。這個(gè)過(guò)程顯然是比較費(fèi)時(shí)的，不如我直接根據(jù)索引讀一條記錄來(lái)得快。而且，絕大部分的數(shù)據(jù)庫(kù)是需要服務(wù)大量查詢的，幫用戶查數(shù)據(jù)才是數(shù)據(jù)庫(kù)的主要工作，用戶存數(shù)據(jù)就是為了有朝一日要讀取它，而 LSM-tree 卻在寫(xiě)性能上大做文章，涉嫌揀了芝麻，丟了西瓜，老老實(shí)實(shí)優(yōu)化讀操作不香嗎？為什么非要玩高難度呢？

我們也想輕松啊……可是，各位敬愛(ài)的淘寶剁手黨、天貓爸爸會(huì)員、釘釘校友們，你們知道你們給數(shù)據(jù)庫(kù)帶來(lái)了多大的寫(xiě)入流量嗎！那可是摧枯拉朽，天崩地裂，滄海桑田！比如雙 11 零點(diǎn)那一秒，阿里云數(shù)據(jù)庫(kù)要面對(duì) 100 多倍的寫(xiě)入流量海嘯（詳見(jiàn)我們的 SIGMOD'19 論文），臣妾要是不加班加點(diǎn)，那根本是做不到的……

問(wèn)題還不止于此，因?yàn)樵跀?shù)據(jù)庫(kù)中所有的數(shù)據(jù)最終都要通過(guò)落盤(pán)來(lái)實(shí)現(xiàn)持久化存儲(chǔ)的，那么我在內(nèi)存中新寫(xiě)入的記錄就需要時(shí)不時(shí)地刷入到磁盤(pán)里。刷盤(pán)時(shí)，反正都要做 I/O 寫(xiě)，我們可以把新數(shù)據(jù)與舊數(shù)據(jù)直接合并到位，這樣就減少了碎片的數(shù)量，同時(shí)保持了磁盤(pán)上數(shù)據(jù)的有序，方便讀取?？墒?，當(dāng)盤(pán)上數(shù)據(jù)越來(lái)越多時(shí)，這樣的合并會(huì)越來(lái)越昂貴，在不能按字節(jié)尋址的存儲(chǔ)器件上（注意這個(gè)限定詞，NVM 正在熱身，等待上場(chǎng)），我們必須讀入所有需要參與合并的頁(yè)，完成合并，并將這些頁(yè)寫(xiě)回。這些頁(yè)里面的很多數(shù)據(jù)其實(shí)是躺槍的，純粹是被鄰居帶下水。隨著數(shù)據(jù)增多，我們要讀的頁(yè)也會(huì)越來(lái)越多，整體代價(jià)也就越來(lái)越大。我們稱這個(gè)問(wèn)題為『寫(xiě)放大』。除了對(duì)性能的影響外，寫(xiě)放大也會(huì)給 SSD 盤(pán)本身的 endurance 帶來(lái)壓力，如果寫(xiě)放大過(guò)高，會(huì)提高云廠商的服務(wù)成本。而，云計(jì)算的最最最精華的精髓，就是『低成本、干大事』。

為了解決寫(xiě)放大問(wèn)題，LSM-tree 在磁盤(pán)上已經(jīng)進(jìn)化出了一種分層存儲(chǔ)結(jié)構(gòu)。新數(shù)據(jù)先寫(xiě)在『零層』，零層我們給他一個(gè)非常小的容量，只存剛剛刷下來(lái)的數(shù)據(jù)。因?yàn)閿?shù)據(jù)局部性的緣故，零層的數(shù)據(jù)有很大概率會(huì)被訪問(wèn)到，還是熱乎的，那么通過(guò)限制容量，無(wú)論怎么訪問(wèn)，點(diǎn)讀也好，掃描也罷，它總共就這么大點(diǎn)地方，不會(huì)慢到哪里去。當(dāng)零層容量飽和時(shí)，我們將它的內(nèi)容與『壹層』中的數(shù)據(jù)合并。壹層比零層更大，比如大10倍。那么理論上，這次合并中最多需要讀取和寫(xiě)回壹層大概十分之一左右的數(shù)據(jù)，不會(huì)更大了。寫(xiě)放大，也就被限制住了。當(dāng)『壹層』也滿了的時(shí)候，我們使用同樣的方法繼續(xù)往下刷，刷出『貳層』、『叁層』等等等等，以此類(lèi)推。每一層的容量，比上一層大 10 倍，整個(gè)存儲(chǔ)中每層的大小呈指數(shù)級(jí)增長(zhǎng)。有了層次化的存儲(chǔ)，配合這樣的合并操作，寫(xiě)放大就被控制住了。對(duì)于數(shù)據(jù)庫(kù)系統(tǒng)中的很多問(wèn)題，我們往往不太可能把它徹底解決掉，而是將其控制在一定的可接受的界限內(nèi)即可。成年人的世界就是這么殘酷，沒(méi)有歲月靜好，沒(méi)有美麗童話，只有負(fù)重前行。

分層控制住了寫(xiě)放大，但是新的問(wèn)題又來(lái)了，合并算法本身是一種數(shù)據(jù)密集型算法，它需要讀取多路數(shù)據(jù)，然后進(jìn)行相對(duì)簡(jiǎn)單的合并計(jì)算，再將合并結(jié)果寫(xiě)回去，整個(gè)過(guò)程本質(zhì)上讀寫(xiě)很多，對(duì)存儲(chǔ)帶寬的消耗非常大，也會(huì)給 CPU 流水線帶來(lái)很多的 I/O 等待、內(nèi)存等待等氣泡，降低 CPU 流水線的執(zhí)行效率，拖慢整個(gè)系統(tǒng)。單次跑一下還好，如果頻繁跑，會(huì)對(duì)系統(tǒng)性能有很大影響。而且它即不處理查詢，也不處理新增數(shù)據(jù)，完全是個(gè)看起來(lái)不必要的背景操作。這種合并操作，我們叫他『Compaction』。在 LSM-tree 引擎中，compaction 不僅肩負(fù)著層與層之間合并數(shù)據(jù)的任務(wù)，還肩負(fù)著為了刪除操作將反記錄與真實(shí)記錄合并從而實(shí)現(xiàn)刪除的任務(wù)等等，是一種多功能的重要操作，是 LSM-tree 中的『消防隊(duì)員』兼『警察叔叔』兼『快遞小哥』兼『醫(yī)生』兼……

到此為止，LSM-tree 在寫(xiě)路徑上的各個(gè)部分都已經(jīng)悉數(shù)登場(chǎng)了，而這片江湖上的恩恩怨怨才剛剛開(kāi)始。為了服務(wù)好寫(xiě)流量越來(lái)越多的 workload，LSM-tree 為了加速寫(xiě)可謂是不遺余力，基本上所有的設(shè)計(jì)都向?qū)懧窂降男阅茏隽藘A斜，讓寫(xiě)入看上去十分美好，實(shí)際上也開(kāi)了一扇羅生門(mén)，門(mén)后慘象環(huán)生。具體怎么慘，下文詳述。

讀路徑上帶著鐐銬的舞蹈

LSM-tree 上的讀路徑，從出生就帶著鐐銬。因?yàn)?CoW 的使用，讀一條記錄實(shí)際上需要把這條記錄所有的增量碎片都找到。因?yàn)闄M跨內(nèi)存和磁盤(pán)兩種介質(zhì)和有層次化的存儲(chǔ)，這些碎片可能藏在各種犄角旮旯里面。更慘的是，如果是讀一個(gè)范圍內(nèi)的記錄，俗稱 range scan，因?yàn)?LSM-tree 的每一層的 key range 是交疊的，那么一個(gè) range 內(nèi)的數(shù)據(jù)就很有可能會(huì)落在所有的層次上，為了把他們都找到，我們就需要每層都去讀，這個(gè)工作量也不小。

為了解決這個(gè)問(wèn)題，目前的 LSM-tree 引擎把各種經(jīng)典技術(shù)都用上了：各種索引、各種 cache。但是為了提高索引和 cache 的效率，讓他們一直發(fā)揮比較好的作用，難度不小。以 cache 為例，X-Engine 中使用了兩種經(jīng)典的 cache，一種是 row cache，緩存記錄級(jí)別的熱數(shù)據(jù)，一種是 block cache，緩存數(shù)據(jù)塊級(jí)別的熱數(shù)據(jù)。Row cache 可以加速點(diǎn)查詢，block cache 可以加速 range scan，一切看上去都是很完美的芭蕾舞。然而，當(dāng) compaction 被大王叫來(lái)巡山的時(shí)候，危險(xiǎn)就發(fā)生了。因?yàn)?compaction 會(huì)重新組織數(shù)據(jù)塊里面的內(nèi)容，干掉一些老的 block，生成一些新的 block，傳統(tǒng)的 cache 替換策略對(duì)老的 block 做的訪問(wèn)統(tǒng)計(jì)會(huì)失效，而新的 block 它不認(rèn)識(shí)，沒(méi)統(tǒng)計(jì)信息。此外，compaction 還會(huì)移動(dòng)數(shù)據(jù)。這兩點(diǎn)加起來(lái)，只要 compaction 巡了一次山，cache 里面緩存的記錄就有很大可能出現(xiàn)大面積失效，導(dǎo)致原本可以命中 cache 的查詢，不得不去訪問(wèn)磁盤(pán)，造成嚴(yán)重的延遲尖刺。

熱數(shù)據(jù)的麻煩還不僅僅來(lái)源于 cache，因?yàn)闊釘?shù)據(jù)經(jīng)常會(huì)被大量更新，而 X-Engine 為了實(shí)現(xiàn)一個(gè) OLTP 數(shù)據(jù)庫(kù)的 ACID 特性，使用了 MVCC 的并發(fā)控制方法，會(huì)為一條熱數(shù)據(jù)上存上非常多的版本，這樣的設(shè)計(jì)實(shí)際上造成了一條邏輯記錄可能會(huì)有特別多的物理分身。這個(gè)現(xiàn)實(shí)無(wú)論是對(duì)承接新寫(xiě)入數(shù)據(jù)的 memtable（經(jīng)常被實(shí)現(xiàn)為跳躍鏈表），還是索引，還是 compaction，都是一個(gè)很煩人的刺頭，硬生生地通過(guò)放大數(shù)據(jù)的體量來(lái)造成各種各樣的問(wèn)題。

除了上述由于 LSM-tree 或者數(shù)據(jù)庫(kù)的機(jī)制帶來(lái)的問(wèn)題以外，這些涉及到的數(shù)據(jù)結(jié)構(gòu)本身的設(shè)計(jì)和實(shí)現(xiàn)也有很大的挑戰(zhàn)，比如 cache 的分桶策略、鎖的管理、跳躍鏈表和索引的查詢效率、數(shù)據(jù)結(jié)構(gòu)針對(duì)多核處理器的并行優(yōu)化等等等等，都是風(fēng)景秀麗的坑、大坑、天坑。坑夠大，填坑才有樂(lè)趣。除了讀路徑的問(wèn)題，LSM-tree 上還有刪除效率的問(wèn)題、空間效率的問(wèn)題等等，此處不再詳述，詳見(jiàn)相關(guān)論文。

學(xué)術(shù)成果與產(chǎn)學(xué)研互動(dòng)

X-Engine 團(tuán)隊(duì)聯(lián)合其他合作伙伴，為了解決上述問(wèn)題做出了很多優(yōu)化，申請(qǐng)了大量專利，其中的很多技術(shù)也作為學(xué)術(shù)成果在數(shù)據(jù)庫(kù)和存儲(chǔ)領(lǐng)域的頂會(huì)內(nèi)完成了發(fā)表。

2019年，我們?cè)?ACM SIGMOD 的 industrial track 中發(fā)表了一篇介紹 X-Engine 來(lái)龍去脈的論文《X-Engine: An Optimized Storage Engine for Large-scale E-commerce Transaction Processing》。在這篇文章中，我們介紹了 X-Engine 這種面向?qū)懭雰?yōu)化的存儲(chǔ)引擎為什么在工業(yè)界人氣飆升，為什么阿里巴巴的電商場(chǎng)景需要這樣的引擎，主要原因就是每次電商促銷(xiāo)所帶來(lái)的富含新增數(shù)據(jù)的高流量海嘯。面對(duì)這樣的挑戰(zhàn)，我們首先將問(wèn)題拆解為了具體的數(shù)據(jù)庫(kù)技術(shù)問(wèn)題，如處理高流量所需的并行寫(xiě)入流水線、數(shù)據(jù)量海嘯快速填滿內(nèi)存對(duì)刷盤(pán)帶來(lái)的壓力、促銷(xiāo)導(dǎo)致的數(shù)據(jù)熱點(diǎn)范圍頻繁變化帶來(lái)的讀性能的挑戰(zhàn)等等。為了解決這些實(shí)際的技術(shù)問(wèn)題，我們介紹了 X-Engine 做了怎么樣的技術(shù)選型，采取了哪些優(yōu)化，以及每項(xiàng)優(yōu)化所帶來(lái)的實(shí)際效果。這篇論文是中國(guó)大陸公司首次在 SIGMOD 上發(fā)表數(shù)據(jù)庫(kù)內(nèi)核上的工作。詳情請(qǐng)見(jiàn)論文（在 ACM DL 中可免費(fèi)下載）。

2020年，與 AIS 軟硬件結(jié)合開(kāi)發(fā)團(tuán)隊(duì)合作，我們?cè)诖鎯?chǔ)領(lǐng)域的頂會(huì) USENIX FAST 2020 上發(fā)表了利用 FPGA 異構(gòu)計(jì)算技術(shù)來(lái)加速 X-Engine 中很多問(wèn)題的罪魁禍?zhǔn)住?compaction 的工作《FPGA-Accelerated Compactions for LSM-based Key-Value Store》。在這項(xiàng)工作中，我們首先系統(tǒng)研究了 compaction 對(duì) LSM-tree 存儲(chǔ)引擎在 CPU、內(nèi)存、磁盤(pán)等資源的消耗上有什么特征，分析了 compaction 的算法，發(fā)現(xiàn) compaction 算法在合并較短的記錄的時(shí)候竟然是受限于 CPU 的。其原因一方面是因?yàn)?compaction 對(duì)計(jì)算的需求，另一方面也是因?yàn)檫@些年來(lái)磁盤(pán)帶寬有了顯著的增長(zhǎng)。所以，我們提出將 compaction 算法 offload 到 FPGA 加速卡上，并在 FPGA 上設(shè)計(jì)和實(shí)現(xiàn)了一套高效的流水線，和 CPU host 實(shí)現(xiàn)了快速的交互，也實(shí)現(xiàn)了 compaction 算法的加速。這項(xiàng)工作所做的探索讓我們看到了計(jì)算型存儲(chǔ)技術(shù)的紅利。近年來(lái)，隨著 SSD 的不斷發(fā)展和處理器的微小型化，市場(chǎng)上出現(xiàn)了類(lèi)似 SmartSSD 這樣的計(jì)算型存儲(chǔ)設(shè)備，其核心優(yōu)勢(shì)是把較小的 ARM CPU 處理器或者 FPGA 芯片直接嵌入 SSD 內(nèi)部，讓部分計(jì)算任務(wù)不需要離開(kāi) SSD 就能完成，省去了 I/O 和 CPU 的開(kāi)銷(xiāo)。因?yàn)?SSD 內(nèi)部的訪存帶寬比外部的 I/O 快幾十倍，計(jì)算型存儲(chǔ)特別適合處理類(lèi)似 compaction、scan 等相對(duì)而言更加訪存密集的操作。今年阿里云數(shù)據(jù)庫(kù)團(tuán)隊(duì)在 FAST 上收獲了大豐收，投稿的 3 篇論文全部被錄用，而 FAST 是個(gè)比較小而專的會(huì)議，今年一共也僅有 23 篇論文。

除了上述已經(jīng)發(fā)表的成果，我們還探索了使用機(jī)器學(xué)習(xí)技術(shù)來(lái)預(yù)測(cè) compaction 前后的數(shù)據(jù)訪問(wèn)趨勢(shì)，以解決傳統(tǒng) cache 替換策略被干擾的問(wèn)題；我們也探索了在 X-Engine 內(nèi)部應(yīng)用細(xì)粒度、自適應(yīng)的調(diào)度算法，來(lái)改善 compaction 的執(zhí)行時(shí)機(jī)，從而提高系統(tǒng)性能的穩(wěn)定性；我們也優(yōu)化了內(nèi)存分配策略、cache 結(jié)構(gòu)和訪問(wèn)方式等等底層細(xì)節(jié)，旨在從根本上顯著提高 X-Engine 的性能與穩(wěn)定性。目前，這些工作還在進(jìn)一步的研發(fā)中。

X-Engine 自 2019 年進(jìn)入數(shù)據(jù)庫(kù)界國(guó)際頂級(jí)學(xué)術(shù)圈以來(lái)，通過(guò)向?qū)W術(shù)界介紹阿里巴巴的應(yīng)用場(chǎng)景以及技術(shù)挑戰(zhàn)，尤其是 X-Engine 引擎本身所面對(duì)的技術(shù)挑戰(zhàn)，已經(jīng)吸引了很多專家學(xué)者的目光。我們所拋出的 LSM-tree 刪除性能差的問(wèn)題，已經(jīng)吸引了來(lái)自波士頓大學(xué)和哈佛大學(xué)的研究者提出了新的優(yōu)化技術(shù)，相應(yīng)學(xué)術(shù)成果將發(fā)表在最近的學(xué)術(shù)會(huì)議中。在國(guó)內(nèi)，X-Engine 團(tuán)隊(duì)與阿里自家的達(dá)摩院數(shù)據(jù)庫(kù)存儲(chǔ)與實(shí)驗(yàn)室、浙江大學(xué) AZFT 實(shí)驗(yàn)室孫建伶教授、中科院計(jì)算所陳世敏教授等學(xué)者和研究人員長(zhǎng)期合作，共同研究 LSM-tree 相關(guān)的技術(shù)問(wèn)題，并且不斷產(chǎn)出優(yōu)質(zhì)的學(xué)術(shù)成果。通過(guò)學(xué)術(shù)合作，目前已經(jīng)發(fā)表了 FAST 一篇（FPGA 加速），VLDB 一篇（NVM 索引）。除此以外，我們追求將學(xué)術(shù)研究探索出來(lái)的新技術(shù)真正落地在 X-Engine 系統(tǒng)內(nèi)核中，為提高 X-Engine 產(chǎn)品力貢獻(xiàn)力量。

未來(lái)研究方向

未來(lái)，X-Engine 團(tuán)隊(duì)會(huì)針對(duì)生產(chǎn)實(shí)踐中遇到的各項(xiàng)技術(shù)難題展開(kāi)攻關(guān)，也會(huì)緊跟新的技術(shù)趨勢(shì)，探索新型硬件（如 NVM，F(xiàn)PGA 等）在 X-Engine 上的應(yīng)用。首先，分布式是數(shù)據(jù)庫(kù)產(chǎn)品的潮流。在未來(lái)，用戶不需要再操心數(shù)據(jù)庫(kù)擴(kuò)展性上的麻煩，而是買(mǎi)一份分布式數(shù)據(jù)庫(kù) PolarDB-X，把所有任務(wù)都交給它后就可以高枕無(wú)憂了。X-Engine 團(tuán)隊(duì)當(dāng)前正致力于 PolarDB-X 的研發(fā)，旨在為用戶提供一款高性能、低成本、伸縮性好的分布式數(shù)據(jù)庫(kù)產(chǎn)品，將阿里多年來(lái)積累的數(shù)據(jù)庫(kù)技術(shù)紅利分享給阿里云上的客戶們。在這個(gè)方向上，我們會(huì)著力于私有協(xié)議、分布式事務(wù)處理、分布式負(fù)載均衡、故障恢復(fù)等重要技術(shù)問(wèn)題。其次，我們認(rèn)為，X-Engine 的內(nèi)存部分可以看成一個(gè)內(nèi)存數(shù)據(jù)庫(kù)，應(yīng)該與處理器、DRAM 內(nèi)存等硬件深度融合，突破性能瓶頸。具體的研究方向包括 cache-conscious 的高性能內(nèi)存索引、利用 SIMID 技術(shù)（Single Instruction Multiple Data）來(lái)加速內(nèi)存數(shù)據(jù)結(jié)構(gòu)訪問(wèn)、降低內(nèi)存鎖開(kāi)銷(xiāo)等。最后，對(duì)于時(shí)下的熱點(diǎn)人工智能，我們也不會(huì)放過(guò)。目前，我們已經(jīng)探索了機(jī)器學(xué)習(xí)技術(shù)在 cache 替換上的應(yīng)用，未來(lái)我們會(huì)探索智能調(diào)參、智能 compaction 調(diào)度、智能索引等 AI for DB 技術(shù)。我們希望利用人工智能技術(shù)，將復(fù)雜的數(shù)據(jù)庫(kù)運(yùn)維轉(zhuǎn)換為十分傻瓜的簡(jiǎn)單操作，降低用戶使用和維護(hù)數(shù)據(jù)庫(kù)的難度，同時(shí)改善數(shù)據(jù)庫(kù)的性能。

作為一款重量級(jí)的數(shù)據(jù)庫(kù)基礎(chǔ)軟件，X-Engine 雖然看上去只是負(fù)責(zé)數(shù)據(jù)增、刪、改、查這樣平淡無(wú)奇的操作，但正是因?yàn)檫@些操作足夠基礎(chǔ)，X-Engine 才會(huì)被集成于 MySQL 內(nèi)核和分布式數(shù)據(jù)庫(kù) PolarDB-X 中，我們的每一項(xiàng)優(yōu)化也獲得了更大的影響力，直接決定著所有上層應(yīng)用的安全、穩(wěn)定和性能。歡迎有志于從事國(guó)產(chǎn)自研存儲(chǔ)引擎研發(fā)的同學(xué)加入我們。