1.1.11　X-Engine

MySQL经过多年发展，一直以支持事务的InnoDB B+树作为自己的主力引擎，尤其到了8.0版本后，对元数据进行了重构，使用数据字典（Data Dictionary，DD）代替了之前MyISAM的.frm文件，彻底变成了InnoDB的天下。InnoDB的优点毋庸置疑，它是目前版本中最稳定、最平衡的事务存储引擎。

但随着数据的增长，我们不得不面对数据膨胀的问题。比如某些业务表，随着业务的增长，不断有新增写入，导致数据文件大小不断攀升。关于这个问题，有一个非常重要的解决思路就是做数据压缩。

当前InnoDB的数据压缩，主要是基于zlib的压缩，但有时候zlib压缩会遇到问题。此外，InnoDB自带压缩的性能和压缩率，因为B+树本身的结构设计，都很难再有提高。Percona曾推出过一个TokuDB引擎，但它已于2020年结束维护。

目前AliSQL提供了除InnoDB以外的另一个选择，就是允许在RDS for MySQL 8.0版本中使用X-Engine压缩引擎。这个压缩引擎究竟是什么来头？其实现原理是什么？

首先在阿里巴巴内部，尤其是在淘系生产线上，X-Engine从MySQL 5.5版本开始就已经投入使用，经过多年的实际使用和重大场景磨炼，引擎本身已经十分成熟。在2019年的SIGMOD会议上，AliSQL还发表了相关论文——“X-Engine: An Optimized Storage Engine for Large-scale E-commerce Transaction Processing”。

X-Engine的核心原理是，依赖LSM树做多层压缩，冷热数据分离，在内存中不断地进行数据筛选，将热数据留在内存，将冷数据通过分层即L0、L1、L2进行刷盘——将暖数据（Warm Data）存储到NVM/SSD上，将冷数据（Cold Data）存储到SSD/HDD上，如图1-10所示。这个引擎甚至可以支持物理硬件FPGA的加速，不过目前的公共云上没有提供这个版本。

图1-10　X-Engine LSM实现方式

LSM树的刷新是一个非常复杂且持续的过程，因此控制好刷新频率，既能有效进行数据分层，又能控制分层本身对CPU的开销。所以在实际执行时，我们会使用流控（Flow Control）的方式。

刷新本身是先刷新日志，后刷新Memtables。为了保证并发性，X-Engine允许多版本刷新，如图1-11所示。

图1-11　LSM多场景管道（Multi-staged Pipeline）

我们知道，InnoDB的文件本身是一个稀疏文件（Sparse File），这和大部分数据库存储引擎一样，稀疏文件非常适合堆（Heap）和B+树的存储，只需要维护少量的Metadata即可。但考虑到磁盘空间有限，使用稀疏文件是一件非常奢侈的事情，一边要进行压缩，一边还在使用稀疏文件写入数据，则有些矛盾。因此，X-Engine抛弃了传统的稀疏文件，改用紧凑文件写入方式，减少了文件碎片，如图1-12所示。

图1-12　稀疏文件和X-Engine的紧凑文件

我们对InnoDB引擎和X-Engine引擎做了测试，发现X-Engine引擎的写入速度远高于InnoDB引擎，如图1-13所示；而在压缩率上，X-Engine引擎的压缩率大约是InnoDB zlib压缩的2倍。

图1-13　X-Engine TPS

后续X-Engine还会被投入分布式引擎中，目前还处于开发阶段，如果有磁盘空间压缩需求，则可以考虑使用X-Engine。