資料庫的儲存引擎最佳化是一個揚長避短的過程

這兩天要和一個資料庫廠商交流關於儲存引擎的事情，這些天這方面考慮的多一些，今天就來聊聊資料庫儲存引擎的事情。一說到儲存引擎，可能很多朋友就會說，某某儲存引擎技術比較先進，比傳統資料庫的好。實際上再先進的儲存引擎也有其缺點，可能先進只是指出現的較晚而已，並不是後出現的儲存引擎一定全面優於老的儲存引擎。資料庫的儲存引擎經過數十年的發展，實際上到現在為止也並沒有出現特別多的流派。大體上歸納起來還是B樹(含HEAP)和基於日誌結構的儲存引擎這兩大類(最著名的是LSM-TREE)。雖然LSM-TREE的出現比B樹儲存引擎晚了二十多年，不過其出現並不是作為替代B樹引擎的，而是有著特定的目的的。

LSM-TREE的出現是在記憶體成本第一次大幅下降之後的，因此基於memtab可以大幅最佳化高併發寫入的效能，同時SSTABLE可以更加充分的利用儲存，更加有利於資料壓縮。LSM-TREE被大規模應用到關係型資料庫上則是SSD逐漸普及後才出現的，因為開銷巨大甚至可能導致系統不穩定的後臺壓縮讓對於延時十分敏感的OLTP系統無法承受。而SSD可以緩解這種問題。

B樹儲存引擎一般採用IN-PLACE-REPLACE，所以其效能相對穩定，雖然會因為PAGE的碎片而導致一些浪費，但是總體來說是較為均衡的。與LSM-TREE相比，因為B樹儲存引擎的這個特點導致併發寫入的效能是會遇到瓶頸的。幾年前我們測試過一個每隔5分鐘有數億條資料併發寫入，並需要進行實時統計分析的場景，在Oracle資料庫上在每秒寫入1000萬條以後明顯就很難提升了，而在LSM-TREE引擎的分散式系統中，很輕鬆就超過2000萬/秒。雖然在寫入上B樹儲存引擎的效能無法與LSM-TREE相媲美，不過B樹儲存引擎在資料讀取上有著明顯的優勢。在MVCC的實現上，以及對資料的複雜查詢上面，B樹儲存引擎都比LSM-TREE有明顯的優勢。雖然LSM-TREE儲存引擎在查詢資料上也透過布魯姆過濾器以及記憶體主範圍索引等方式進行最佳化，但是其開銷還是會比B樹儲存引擎要大的多。目前很多基於LSM-TREE的分散式資料庫往往都是依靠並行掃描的方法，以眾敵寡，勉強和B樹結構的集中式資料庫打個平手。

實際上兩種儲存引擎的一些優缺點也並不容易區分清楚，如果站在某個立場上，就會有不同的分析結論。比如寫放大的問題上，LSM-TREE的支持者會說LSM-TREE結構更加緊湊，資料沒有碎片，而B樹儲存引擎經常會出現某個PAGE中只寫了很少一部分資料，導致寫被放大了。實際上LSM-TREE雖然不存在這種寫放大，但是一個KEY會被多處儲存，也會造成另外一個意義上的寫放大。再加上現代硬體對於寫IO的能力已經極大提高了，這個問題其實並不會對絕大多數場景造成影響。

從上面的分析來看，確實沒有完美的儲存引擎，每個引擎都有其優點，也同時必然有其缺點。我們要做的實際上是利用現代硬體的特點，儘可能地彌補其缺點，發揚其優點。隨著IO越來越好，CPU越來越便宜，LSM-TREE儲存引擎被越來越廣泛地使用也是一個很好的例子。

前些年我和INTEL合作研究傲騰記憶體的使用場景的時候，曾經考慮過是不是把沒有壓縮的sstable先儲存到傲騰記憶體裡，在傲騰記憶體裡做壓縮後，逐漸把歷史資料下沉到效能相對較差的持久儲存上。這樣可以大大降低壓縮帶來的負面影響。再用CGROUP隔離後臺壓縮排程，這樣就可以避免壓縮給資料庫帶來的抖動。

前些天我看到一篇北京大學Baoyue Yan的論文，他們提出了一種利用傲騰記憶體最佳化LSM-TREE儲存引擎的演算法，在實踐中獲得了很好的效果，在TPCC基準測試中獲得了2倍的提升。

左邊的圖是基於傳統的LSM-TREE儲存引擎的資料庫，而右邊是他們最佳化過的方案。實際上這張圖並不完整，還缺少了一個傳統記憶體的區域。在傳統記憶體區域裡，他們放置了可丟失的半持久化索引資料，傳統寫入memtab的資料被寫入非易失性記憶體中的sp-m，sp-m寫滿後被鎖定為sp-im，然後在非易失性記憶體中進行壓縮，寫入SSD的持久化儲存系統中。

因為主資料被寫入非易失性記憶體，因此透過WAL來保證資料庫的一致性需求也沒那麼強烈了，因此可以使用更為輕量級的Recorder Ring來替換WAL，保證事務一致性。這種利用非易失性記憶體這種現代的硬體來最佳化資料庫架構，甚至顛覆傳統資料庫架構的嘗試是十分值得肯定的，也是十分有價值的。

可能有朋友要說了，非易失性記憶體那麼貴，不是任何使用者用得起的，所以這種資料庫是不是很難普及啊。實際上說這句話的時候想想十年前，當時大家都在說SSD那麼貴，不是任何人都用得起的。而現在，好像不是那麼回事了吧。