本文為您介紹RDS的X-Engine引擎如何在成本方面支撐DingTalk業務，協助企業快速實現線上協同辦公。
背景資訊
DingTalk作為中國領先的企業IM工具，在中國有數以億計使用者，從DingTalk專案群、DingTalk視訊通話、DingTalk視頻會議、DingTalk日報等基礎功能，再到DingTalk平台上演化出來的各種辦公室自動化（Office Automation）應用，方便了人與人之間的交流，可以協助企業快速實現線上協同辦公。
2020年新型冠狀病毒肺炎疫情爆發，為了規避集中辦公帶來的感染風險，大量企業員工選擇了在家辦公，企業辦公協同工具需求瞬間爆發。DingTalk迅速衝上了AppStore下載榜單的第一位，導致DingTalk訪問流量迅速增長，藉助於阿里雲提供的彈性基礎設施，DingTalk平穩地渡過了每一次流量洪峰。
如此龐大使用者量，DingTalk的訊息系統除了要保證訊息及時正確傳遞，還要保證已讀、未讀等特有功能，而且不同於微信這樣的使用者級IM工具，企業IM需要實現聊天記錄永久儲存，並且提供多端漫遊功能。由於使用者量持續爆炸性增長，聊天記錄永久儲存給DingTalk業務帶來巨大成本壓力，同時還要保證聊天記錄的讀寫效能不會降低。
面對這些挑戰，DingTalk業務選用了X-Engine作為DingTalk訊息的最終儲存引擎，實現了效能和成本平衡。使用X-Engine有如下優勢：
- 儲存空間比InnoDB引擎減少了約62%。
- 保留對事務以及二級索引等資料庫特性的支援。
- 業務代碼不需要修改就可以遷移到X-Engine引擎執行個體上。
- X-Engine的冷熱分離能力能夠對最新訊息有著最快的處理速度，而對歷史訊息有著最高壓縮比。
在Link-Bench和阿里巴巴內部交易業務兩個資料集上測試了X-Engine的儲存空間效率。在測試中，對比開啟壓縮的InnoDB引擎，X-Engine有著2倍空間優勢；對比未開啟壓縮的InnoDB，X-Engine則有著3~5倍空間優勢。
X-Engine如何?低成本
X-Engine可以實現低成本是因為有以下幾個特殊技術：
- 緊湊資料頁格式
X-Engine使用Copy-on-write技術，避免原地更新資料頁，新資料會寫入到新資料頁中。由於既有資料不可更新，可以對唯讀資料頁進行緊湊儲存並使用首碼編碼等方式進行資料壓縮，提升頁面空間使用效率。而已經失效的記錄版本則由Compaction操作清理，保證有效記錄都緊湊排列。相對於傳統儲存引擎（例如InnoDB），使用X-Engine可以將儲存空間降低至10%~50%。
- 資料壓縮及無效記錄清理
編碼之後的資料頁，可以使用通用壓縮演算法（zlib、zstd、snappy等）進行壓縮，所有處在LSM-tree低層次的資料都會預設壓縮。
資料壓縮是以計算資源換儲存空間的技術，因此選用一個壓縮率小及壓縮/解壓速度快的壓縮演算法也非常關鍵，經過大量對比測試，X-Engine預設選用ZSTD壓縮演算法，但同時也支援其他演算法。
除了使用壓縮之外，Compaction操作會對無效記錄進行刪除，只保留有效記錄，Compaction執行越頻繁則無效記錄佔比越低，空間使用效率越高，因此保證合適的Compaction頻率也是提升空間使用效率的關鍵。
為了減少Compaction操作對計算資源的消耗，X-Engine團隊研發了FPGA Compaction技術，使用異構計算硬體來加速Compaction過程，實現了在一個FPGA硬體流水線內同時完成Compaction和壓縮操作。即使在沒有FPGA硬體的主機上，藉助合理調度演算法，X-Engine也能以較小的效能代價節省儲存空間。
- 智能冷熱分離
通常儲存系統訪問資料都有局部性，大量訪問都集中在少部分資料上，這也是緩衝系統能有效工作的基本前提。在LSM儲存結構中，如果把訪問頻率高的資料儘可能放在較高層次上，存放在快速存放裝置中（例如NVM、DRAM），而把訪問頻率低的資料放在較低層次中，存放在廉價慢速存放裝置中，這就是X-Engine冷熱分層概念。
X-Engine中冷熱分離演算法主要完成如下幾個任務：
- 在Compaction操作中，挑選出未來最不可能被訪問到的資料頁和記錄，移動到LSM-tree底層。
- 挑選當前熱點資料，在Compaction或者轉儲過程中回填到記憶體中（BlockCache/RowCache），避免快取命中率抖動導致影響效能。
- AI演算法會識別出未來可能被訪問到的資料，並提前預讀到記憶體中，減少首次訪問緩衝未命中率。
準確識別出資料冷熱，可以避免無效壓縮或解壓帶來的計算資源浪費，提升系統吞吐。
更多詳細說明請參見X-Engine簡介。