匠心之作 | 厉害了!阿里云自研存储引擎X-Engine又发顶会啦

本文涉及的产品
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
云数据库 Tair(兼容Redis),内存型 2GB
简介: X-Engine是阿里云自研OLTP数据库存储引擎,已经广泛应用于包括钉钉、核心交易、阿里妈妈在内的阿里巴巴核心业务,在提供高性能的同时大幅降低了存储开销。

1、What is X-Engine

X-Engine是阿里云自研OLTP数据库存储引擎,已经广泛应用于包括钉钉、核心交易、阿里妈妈在内的阿里巴巴核心业务,在提供高性能的同时大幅降低了存储开销。

经过阿里双十一等高压场景的考验与打磨,RDS MySQL(X-Engine)版即将在阿里云上向外部客户提供服务,将技术红利带给云上用户。

X-Engine:An Optimized Storage Engine for Large-scale E-Commerce Transaction Processing 介绍了X-Engine的系统架构以及核心设计,发表在SIGMOD'19 Industrial Track。

近日,X-Engine团队的另一项工作FPGA-Accelerated Compactions for LSM-based Key-Value Store被FAST'20 Research Track接收(USENIX Conference on File and Storage Techniques (FAST),CCF A类会议,存储领域顶会,2020年接受率16%),本文会对这项工作进行简单介绍。

X-Engine采用了LSM-tree架构,同时广泛针对现代多核,大内存,高速存储的服务器进行了优化,例如其内部大量采用无锁设计,具有良好的扩展性。

在开始论文的解读前,我们先分析下X-Engine所处时代的服务器硬件发展趋势,以及LSM-tree架构的存储引擎对服务器计算资源及存储资源的需求特点,两项结合,读者能更好的理解为何在数据库中引入CPU以外的专用计算设备会是未来的一个趋势。

2、硬件发展趋势

近年来,包括处理器和存储在内的服务器端硬件的发展非常快。CPU 方面,Intel 的 Xeon CPU 家族在 14nm 制程上完成了第一轮 "Process-Architecture-Optimization" 模型下的迭代,在 10nm 制程上也推出了最新的 Tiger Lake 微架构。

在 CPU 核数的增长已经变得司空见惯的今天,Tiger Lake 不仅拥有比 Skylake 高约 30% 的时钟频率,还拥有更大的 L1/L2 cache,更大的 cache line,使用 HBM 技术的 L4 cache 和更快的 I/O。这些突破性的进展都标志着 CPU 处理能力的跃升。放眼未来,Intel 还预计于 2021 年开启一轮新的迭代,发布其新的 7nm 制程处理器。

CPU 之外,新型 FPGA、GPU 和各类 AI 处理器层出不穷。2019年,阿里巴巴发布了峰值推理性能达到 78563 IPS的含光800处理器。传统的异构加速器在不断迭代升级之外,也发展出了日渐成熟的混合架构,如 CPU-FPGA(e.g., Intel Arria),和 FPGA-accelerated NVMe SSD (e.g., BittWare 250)。存储方面,随着比传统 NAND 闪存快近千倍的 3D XPoint 技术的发展和应用,无论是 NVM 还是 SSD 的性能都有了长足的进步。

最新的 Intel Optane SSD 的随机读、写性能都达到了 550000 IOPS,顺序读写带宽更是分别达到了 2500 MB/s 和 2200 MB/s,读写延迟 10 µs。下图则展示过去10年间,每年进入市场的 Intel SSD 的峰值 I/O 性能。我们可以看到,无论是顺序I/O,还是随机 I/O 的能力都有了非常快的进步。

在我们的工业实践中,三年前我们所使用的典型服务器,还只能提供2.4GB/S的顺序读带宽,而到了今年,在我们最新的服务器上,测试值已经达到了 12GB/S的带宽。
640-5.png

过去10年间,每年上市的 Intel SSD 的峰值 I/O 性能

新硬件趋势和底层硬件性能的变化往往会造成上层软件的性能瓶颈的迁移,尤其是像数据库存储引擎这样的直接接触存储硬件的基础软件。随着 I/O 性能的不断提高,很多传统的瓶颈在 I/O的 数据库算法逐渐转变为被计算资源所限制;反之亦然。在这项工作中,我们发现 LSM-tree 存储引擎的中的 Compaction 操作正是一个正在由 I/O 瓶颈转变为计算瓶颈的例子。具体细节,请看下文详细展开。

3、LSM-tree 的 Compaction

在LSM-tree架构中,写入操作会首先插入到内存中,当大小到达阈值后,会写到磁盘上,并和磁盘上的数据合并(类似于merge sort),而磁盘上的数据按照层级进行组织,每一层的数据达到阈值后都会和下一层的数据进行合并(图(a))。

这样做的好处主要有两点:1. 写入操作(insert/update/delete)统一转化为追加操作,不会更新原有数据,写性能要优于innodb等存储引擎;2. 分层存储,数据有序排列,每个block都是紧凑的,不存在空洞,便于压缩,存储成本优势明显。

X-Engine 的数据层次结构与LevelDB, RocksDB这些使用LSM-tree的存储引擎类似,写入首先写入到memtable中,当memtable写满后转化为immutable memtable,之后immutable memtable会刷盘持久化。

X-Engine磁盘上的数据也是按层组织,每一层一般切分成多个固定大小的有序段(X-Engine中的Extent,类似于RocksDB中的SSTable),每一个Extent再切分成多个data block,data block中的数据一般进行前缀编码存储,每一个Extent会有一个Index block来索引data block(图(b))。

640-57.jpeg

后台的flush/compaction线程负责将内存数据和磁盘上的数据进行合并,每一层的数据量到达阈值后也会触发和下层数据的合并,这个操作称之为 compaction 。

及时的compaction非常重要,LSM-tree在持续高强度写入压力下会产生形变(层数累计过多),会给读操作带来非常大的麻烦(由于多版本数据的影响,读操作需要顺序扫描各层并合并产生结果)。compaction及时合并多版本数据,删除旧版本数据,维持一个健康的读取路径长度,对存储空间释放及系统性能意义重大。

下图展示了不同KV长度的compaction执行时间分解图,在短KV情况下(value长度小于等于64B),compaction的计算时间占比在50%以上。近年来存储设备读写性能提升非常快,而CPU主频的提升则非常缓慢,compaction操作中计算时间占比越来越长。另外,X-Engine的数据块都是压缩存储的,考虑到压缩带来的额外CPU消耗,计算资源的瓶颈更加明显。

640-58.jpeg

下图展示了X-Engine长时间运行的性能以及资源利用情况(key=8B, value=32B),预热时间1个小时,观测窗口2个小时,读写比为3:1,在32个compaction线程的设置下,系统性能达到了最高水位。

640-59.jpeg

这个随着后台compaction线程数增加性能类似抛物线的变化说明了两个问题:

1.及时的compaction能让系统性能得以保持在高水位,否则LSM-tree层数的堆积增长会严重损害系统性能(32个线程配置下,X-Engine性能是8个线程配置的2倍左右)。

2.在CPU资源受限的情况下,compaction操作需要和前台的事务处理线程竞争计算资源,资源竞争对系统性能的损害在超过32个compaction 线程的设置下开始显现。

  1. 为了使compaction任务及时的被处理,我们可以设置更多的compaction线程, 但过多的compaction线程争抢计算资源又会对执行前台事务操作的线程带来负面影响,降低吞吐。前台事务产生新数据的速度和后台compaction线程消纳堆积数据的速度达到平衡时,系统达到均衡性能,但此性能一般远低于数据库可以达到的峰值性能。

Compaction需要做,但不一定非得CPU来做。一个compaction任务包含了多路数据块的读取、解码、归并排序、编码、写回等阶段,对于同一个compaction任务来说,前后阶段存在数据依赖,但是对于多个任务来说,并不存在数据依赖,完全可以通过流水线执行来提高吞吐能力。

通过将compaction offload到适合处理流水线任务的FPGA来执行,CPU可以全部服务于复杂的事务处理,从而避免了后台任务对于计算资源的侵占。如此数据库系统可以一直以峰值性能处理事务。

4、整体架构

我们所使用的FPGA加速卡是通过PCIe接口连接到服务器上,它并不能像服务器上的CPU一样方便的访问内存和磁盘。另外FPGA计算能力强大,但是单次访问的延时却更像一个IO设备。这样的特点决定了我们不能直接将之前CPU版本的compaction算法直接应用到FPGA上。

为了适配FPGA加速卡,我们首先将CPU版本的流式compaction实现改造成分批次模式。CPU负责将compaction拆分成特定大小的task,每个task可以并行执行,这样可以充分发挥FPGA加速卡上多CU的并行能力。

在X-Engine中,我们设计了一个任务队列(Task Queue)来缓存需要执行的compaction任务,通过Driver来下发给FPGA上的计算单元(compaction unit,CU)执行,执行的结果会缓存在结果队列(Result Queue)中,等待CPU写回持久化存储。
640-60.jpeg

  • 架构关键设计一:Compaction 调度器

度器负责构建compaction任务,然后分发给CU执行,并将compaction的结果写回到磁盘上,我们设计了三种线程来完成整个链路:
640-61.jpeg

Builder thread:将需要被合并的Extent按照range切分,形成compaction task。每一个compaction task结构体维护了必要的元信息,包括Task Queue指针,输入数据的起始地址(传输到FPGA需要做CRC校验保证数据正确性),compaction结果的写回地址,以及后续逻辑的回调函数指针。
此外,每一个task还包含return code,标志此次compaction任务是否执行成功,对于失败的任务,我们会调用CPU再次执行。通过线上运行的数据显示,大概只有0.03%的task会被CPU再次执行(主要是KV长度过长的case)。

640-62.jpeg

Dispatcher thread:由于FPGA上存在多个CU,需要设计相应的分发算法,目前我们采用了简单的round-robin分发策略,由于每一个下发的compaction task大小接近,实验表明不同CU的利用率比较均衡。

Driver thread:负责将数据传输至FPGA并通知CU开始工作,当CU任务执行完成后会中断Driver thread将结果传回内存,并将task入队Result Queue。

  • 架构关键设计二:Compaction Unit

Compaction Unit (CU)是CPU compaction对应的FPGA实现逻辑。一个FPGA上可以部署多个CU,由Driver进行分发调度。一个CU由Decoder、KV Ring Buffer、KV Transfer and Key Buffer、Merger、Encoder、Controller组成。
640-63.jpeg

Decoder模块的设计和LSM-tree的compaction policy相关,目前的CU采用4路Decoder设计。X-Engine采用tiering策略,因此可能会存在多路合并的情况,从实际的运行情况来看,2~4路的归并是比较常见的,而4路归并的设计比2路归并的设计更加高效(性能提升3倍,硬件资源消耗增加40%左右)。Decoder模块将前序编码的KV对解码后缓存到KV Ring Buffer中。

KV Ring Buffer 由32个8KB的slot构成,每一个slot中6KB存储KV数据,另外2KB存储KV的元信息(KV长度等)。每一个KV Ring Buffer有三种状态:FLAG_EMPTY, FLAG_HALF_FULL, FLAG_FULL,来标识Ring Buffer是处在空、半满、满,根据缓存的KV数量我们会决定是否要继续推进流水线,还是要暂时Decoder以等待下游消耗。

KV Transfer和Key Buffer主要负责KV的传输,由于归并排序并不需要比较value,因此只需要缓存Key值即可。

Merger操作负责合并 Key Buffer中的key,下图中,第二路的key值最小,Controller会通知KV Transfer将对应 KV 从 KV Ring Buffer中传输到 KV Output Buffer(和KV Ring Buffer结构类似),并将KV Ring Buffer的读指针前移得到下一个KV,Controller会通知Merger进行下一轮比较。

640-64.jpeg

Encoder模块主要负责将Merger输出的KV进行前序编码,组织成data block的格式写入到FPGA的内存中。

为了控制各个阶段的处理速度,我们引入了Controller模块,Controller模块负责维护KV Ring Buffer的读写指针,并根据KV Ring Buffer的状态感知流水线上下游处理速度的差距,通过暂停/重启相应模块来维持流水线的高效运转。

  • 架构关键设计三:容错机制

保证数据一致性是数据库引擎基本功能,引入异构计算设备,增加了额外变量,引入新风险。X-Engine在整体架构设计上考虑到了FPGA 计算设备失效,传输链路出现bit跳变等风险。容错方面X-Engine做了如下工作。

1.X-Engine可以探测到服务器是否部署FPGA加速卡,以及当前FPGA卡是否可用(有刷入compaciton/压缩解压 固件,设备是否存活)等。X-Engine的Compaction/压缩等逻辑均有CPU版本实现做备份。如果运行过程中FPGA突然失联,可以平滑的切换回CPU模式,只是峰值性能稍低,稳定性不会有任何影响。切换回CPU模式之后,X-Engine会定期探测FPGA加速卡的可用性,如有可能就立即切换到FPGA加速模式。

2.Compaction CU的每一个步骤中,均保存了CRC校验值,同时compaction任务的输入输出在FPGA卡的内存和主机内存之间传输后,均会做校验。确保传输链路中不会出现跳变。

3.X-Engine可以兼容部分compacton任务的执行失败。由于超时,内存读写错误导致的单个任务失败,X-Engine会捕获到执行结果,并将失败的任务交由CPU重新执行并获得结果。而且这个设计还给我们带来另一个好处,由于FPGA卡的compaction固件逻辑实现涉及到芯片上的寄存器分配及逻辑布线,如果需要处理key或者value特别长的记录,会导致FPGA逻辑的计算效率降低。

因此我们的FPGA实现中,只支持特定长度KV记录。遇见超长KV记录时会直接报错返回,并交由CPU处理。这样可以避免让FPGA处理一些数据库中出现的长TEXT/BLOB等字段。这样就实现了功能(长KV)和性能的兼顾. X-Engine在线上实际运行中,统计到的失败的task占比在万分之三左右, 证明我们的思路是可行的。

5、实验评估

本文的所有实验均在装有两个Intel XeonPlatinum 8163 2.5 GHz 24-core (two-way hyperthreading)的处理器上进行,内存为512GB的DDR4-2133,磁盘环境为由10块SSD构成的RAID 0阵列,Linux版本为4.9.79。FPGA板卡型号为Xilinx VU9P (200M Hz),FPGA内存大小为16GB,通过 x16 PCIe Gen 3和主机相连。FPGA上共配置了8个CU。

1.CU加速评估

我们设计单测来比较单CU和CPU单核心的compaction吞吐。load四路共计400万条记录并触发compaction,在不同的KV场景下,FPGA compaction加速比在2到5倍之间。

为了能够定量评估流水线各个模块的吞吐速度,我们还为CU的处理速度进行了建模,实际上,无论是对于FPGA Compaction还是CPU compaction,能够精准控制compaction执行时间都是非常重要的。通过理论模型,我们可以通过预估提供指定compaction吞吐所需要的CU数量。模型计算的结果和单测结果误差在20%以内。
640-65.jpeg

2.系统性能评估

性能评估工具:DbBench,workload分布采用Zipf-1.0,读写比默认设置为3:1,load 32个subtable(对应一棵LSM-Tree),每个subtable包含200000000条数据,内存设置为70GB,Key和Value的大小分别设置为8B和32B,该配置是线上的一个常见配置,所有的实验预热时间3600秒,评估时间为7200秒。

使用FPGA加速后,X-Engine的性能和32个线程的CPU版本性能提升在25%左右,CPU的利用率降低了10%左右。虽然32个线程以上的CPU compaction吞吐大于FPGA版本的compaction,但是增加了计算资源的竞争,虽然数据消解更快(数据量),但是性能也不理想。

640-66.jpeg
640-67.jpeg

6、总结

存储引擎的发展就是在应用负载不断变化、硬件环境不断革新的情况下寻找成本和性能最优平衡的过程。

LSM-tree生态的繁荣正是上述两点共同作用的结果,一方面,写操作、点查询逐渐成为了用户负载的主要部分(WPI,write and point read-intensive),数据量的爆炸增长,写操作比例的上升令LSM-tree存储引擎得以广泛应用,另一方面,存储介质技术的飞速发展,SSD,NVMe等介质将持久化层的吞吐推上了一个新的高度,存储引擎的性能瓶颈开始从IO过渡到CPU,也正在催生许多新的挑战。

运用新硬件来解决存储系统的瓶颈问题,我们只是向前迈了一小步,还有很多有意思的问题需要更好的解答:

Compaction越快越好吗?如何在及时compaction和避免compact热点数据造成cache miss之间寻找平衡,timing compaction看似显而易见,实则需要细细考量。

“专用”是把双刃剑。如何在compaction压力较小的时候提高FPGA资源的利用率,可以考虑同时支持多个实例以及不同IP共享硬件资源,哪种方案更切实可行,还需要更长时间的工业实践积累来告诉我们答案。

前路漫漫,道阻且长。

致谢

本工作由阿里巴巴数据库产品事业部X-Engine团队、基础设施事业部定制计算(AIS)团队、达摩院数据库与存储实验室以及阿里巴巴-浙江大学前沿技术联合研究中心(AZFT)合作完成。在此向参与此项工作的研究人员以及指导论文写作的老师表示感谢,相信未来还会有更多的合作成果产生。

目录
相关文章
|
7月前
|
Cloud Native 关系型数据库 分布式数据库
|
5月前
|
存储 SQL 关系型数据库
技术好文:TiDB架构及设计实现
技术好文:TiDB架构及设计实现
349 0
|
7月前
|
关系型数据库 分布式数据库 数据库
VLDB顶会论文解读 | PolarDB MySQL高性能强一致集群核心技术详解
在VLDB2023会议上,阿里云瑶池数据库团队的论文介绍了PolarDB-SCC,这是一个创新的云原生数据库系统,确保了低延迟的全局强一致读取。PolarDB-SCC解决了传统主从架构中只读节点可能返回过期数据的问题,实现了在不影响性能的情况下提供强一致性。通过重新设计的主从信息同步机制、线性Lamport时间戳和细粒度修改跟踪,以及利用RDMA优化的日志传输,PolarDB-SCC已经在PolarDB中成功应用超过一年,成为业界首个无感知全局一致性读的云原生数据库解决方案。
67171 0
|
存储 运维 关系型数据库
MySQL官方特供649页顶级笔记,凝聚社区力量深入技术内幕
但凡有职场经验的兄弟都知道,大厂的面试真是一言难尽,不光看你面试时的临场发挥能力,还要分N次考你对公司业务核心技术的熟悉度。
|
7月前
|
存储 关系型数据库 MySQL
太厉害了!华为大牛终于把MySQL讲的明明白白(基础+优化+架构)
爱因斯坦说过“耐心和恒心总会得到报酬的”,我也一直把这句话当做自己的座右铭,这句箴言在今年也彻底在“我”身上实现了。 每一个程序员都拥有一座大厂梦,我也不例外,去年面试阿里,竟然被MySQL问倒了,很多相关性的问题都没有答上来,才2面就凉凉了。为面试做了很多准备,收集很多关于MySQL面试题
|
关系型数据库 分布式数据库 数据库
VLDB顶会论文解读|PolarDB MySQL高性能强一致集群核心技术详解
论文中,PolarDB-SCC提出了一个全局强一致的主从架构的云原生数据库。目前该架构已在PolarDB架构中上线一年有余,是业内首个在业务无感知情况下实现全局一致性读的主从架构云原生数据库,解决了一直以来海量客户的一致性痛点。
|
安全 关系型数据库 分布式数据库
记SIGMOD最佳论文的诞生,由PolarDB团队的一次张榜说起
记SIGMOD最佳论文的诞生,由PolarDB团队的一次张榜说起
137 0
|
存储 弹性计算 运维
互娱NoSQL架构优化 —— 暨MongoDB“在线换引擎”技术服务指南”
XX工作室是某大客户核心游戏工作室,其核心业务是国内二次元RPG手游,采用实时开放世界对战模式,整体采用阿里云方案,本次专项攻坚主要对于玩家在游戏期间各类游戏属性交互(包含过图、物品、面板、剧情等)的核心业务模块进行优化,其中涉及NoSQL部分由于在专项优化期间存在诸多细节,特此提炼出来给各位有类似互娱业务场景进行参考。
|
存储 运维 Cloud Native
阿里云PolarDB数据库获评 “人民匠心2021年度推荐技术案例 ”
PolarDB凭借在国产自研数据库技术领域的重要创新和规模化成功应用入选
284 0
阿里云PolarDB数据库获评 “人民匠心2021年度推荐技术案例 ”
|
存储 Cloud Native NoSQL
一文详解PolarDB披荆斩棘的“秘密武器”
PolarDB由阿里巴巴自主研发的下一代关系型分布式云原生数据库。在兼容传统数据库生态的同时,突破了传统单机硬件的限制,为用户提供大容量,高性能,极致弹性的数据库服务。
679 0
一文详解PolarDB披荆斩棘的“秘密武器”
下一篇
无影云桌面