本文介绍云原生数据仓库AnalyticDB MySQL版的实时存储引擎。
背景
云原生数据仓库AnalyticDB MySQL版作为一款实时数仓产品,为了支持低延迟的写入、更新场景,在传统数仓能力基础上,设计了实时存储引擎。数据写入和更新会以Append_only的方式写入实时存储引擎,经过Compact之后构建索引以支持复杂的计算场景。
- 在一些大宽表场景下,单行的更新带来了严重的写放大问题。
- 实时存储引擎内存高频换入换出,Cache Miss高的同时,大量的压缩、解压缩带来CPU瓶颈。
- 存储格式上,在确定的I/O单位上设计行列混存格式,使得单行的I/O大小可控。
- 内存控制上,实现了基于Anti-Caching的缓冲池(Buffer Pool)。
存储格式
最初的AnalyticDB MySQL版实时存储引擎设计是一个列存实现,在宽表更新场景(游戏业务中留存率计算、零售业务中订单统计等)下,I/O放大导致的延迟问题尤为明显。


定长字段的存储会在Minipage中维护,同时每个F-minipage的分配上保证Cache Line对齐。基于PAX Layout的设计,能够确保每个Page的刷盘落到磁盘上都是确定的I/O单位。同时,同一个列的数据仍然保持在一个Minipage上连续布局,在顺序扫描的场景中仍然能够充分利用Cache的能力。

- 超过12 Byte的字段:前4 Byte存储字符串长度;中间4 Byte存储前缀;后8 Byte存储指向V-minipage中对应记录的起始地址。
- 未超过12 Byte的字段:前4 Byte存储字符串长度;后12 Byte存储字符串。
内存控制
在内存控制的演进上,AnalyticDB MySQL版实时存储引擎从最初的LRU-based Cache逐步走向以内存为中心的架构。
Anti-Caching
与传统数据库的Caching机制不同,AnalyticDB MySQL版基于Anti-Caching的设计,将内存作为主存,仅将冷数据淘汰到磁盘,磁盘扮演着备份角色。
- User-Space:使用应用层的语义优化Ad-hoc的性能。但是,在维护LRU方面会产生一定开销;如果避免维护LRU的开销,实时性会受到影响,不能完全精准地控制内存。
- Kernel-Space:针对I/O进行调度,同时充分利用硬件特性,但是缺乏应用层面的语义。
- Hybrid of User-Space and Kernel-Space:将User-Space和Kernel-Space结合在一起的实现方式。

Swizzling Pointer
当Page被序列化到磁盘后,系统需要通过逻辑ID (PID)再次访问对应的Page。老版本的AnalyticDB MySQL版采用全局的HashTable来维护逻辑ID的映射关系。这种方法在数据规模较大的场景,存在明显的性能瓶颈,产生较高的Hash开销。

- 当Page在内存中时:头部第一个bit标记为0;其余bit用来表征Page的物理地址。
- 当Page在磁盘中时:头部第一个bit标记为1;第2~7个bit记录Page的SizeClass,SizeClass用来计算Page大小;剩余的57个bit记录Page的逻辑ID。
Swizzling Pointer技术带有一定的去中心化属性,避免了全局Hash的开销;同时在新版本的实时存储引擎中,Page写盘没有采用传统的LZ4、Zstd等压缩算法,使得在CPU密集的场景下,性能有大幅的提升。