当数据库遇见FPGA：X-DB异构计算如何实现百万级TPS？

阿里妹导读：X-Engine 是集团数据库事业部研发的新一代存储引擎，也是新一代分布式数据库X-DB的根基。在线事务处理的数据库存储引擎中，如何有效率的回收多版本的旧数据一直是一个难题，尤其在write intensive的应用中，事务处理无可避免受到后台任务的干扰(compaction or vacuum)，引入异构计算设备来offloading这些任务的想法由来已久，但是真正想要应用起来确有难度。

今天，我们将为大家详细介绍带有FPGA加速的X-Engine存储引擎。这篇文章不仅仅讲述如何设计并实现出更高效的FPGA逻辑，还有如何提升I/O，做好混合负载调度、容错等。"平稳"二字，看似波澜不惊，实则暗藏巨浪。

前言

X-Engine 是集团数据库事业部研发的新一代存储引擎，是新一代分布式数据库X-DB的根基。为了达到10倍MySQL性能，1/10存储成本的目标，X-DB从一开始就使用了软硬件结合的设计思路， 以充分发挥当前软件和硬件领域最前沿的技术优势。而引入FPGA加速是我们在定制计算领域做出的第一个尝试。目前FPGA加速版本的X-DB已经在线上开始小规模灰度，在今年6.18，双11大促中，FPGA将助力X-DB， 将在不增加成本的前提下，满足阿里业务对数据库更高的性能要求。

背景介绍

作为世界上最大的在线交易网站，阿里巴巴的 OLTP （online transaction processing） 数据库系统需要满足高吞吐的业务需求。根据统计，每天 OLTP 数据库系统的记录写入量达到了几十亿，在2017年的双十一，系统的峰值吞吐达到了千万级TPS (transactions per second)。阿里巴巴的业务数据库系统主要有以下几个特点：

• 事务高吞吐并且读操作和写操作的低延时；

• 写操作占比相对较高，传统的数据库workload，读写比一般在 10:1 以上，而阿里巴巴的交易系统，在双十一当天读写比达到了 3:1；

• 数据访问热点比较集中，一条新写入的数据，在接下来7天内的访问次数占整体访问次数的99%，超过7天之后的被访问概率极低。

为了满足阿里的业务对性能和成本近乎苛刻的要求，我们重新设计开发了一个存储引擎称为X-Engine。在X-Engine中，我们引入了诸多数据库领域的前沿技术，包括高效的内存索引结构，写入异步流水线处理机制，内存数据库中使用的乐观并发控制等。

为了达到极致的写性能水平，并且方便分离冷热数据以实现分层存储，X-Engine借鉴了LSM-Tree的设计思想。其在内存中会维护多个 memtable，所有新写入的数据都会追加到 memtable ，而不是直接替换掉现有的记录。由于需要存储的数据量较大，将所有数据存储在内存中是不可能的。

当内存中的数据达到一定量之后，会flush到持久化存储中形成 SSTable。为了降低读操作的延时，X-Engine通过调度 compaction 任务来定期 compact持久化存储中的 SSTable，merge多个 SSTable 中的键值对，对于多版本的键值对只保留最新的一个版本（所有当前被事务引用的键值对版本也需要保留）。

根据数据访问的特点，X-Engine会将持久化数据分层，较为活跃的数据停留在较高的数据层，而相对不活跃(访问较少)的数据将会与底层数据进行合并，并存放在底层数据中，这些底层数据采用高度压缩的方式存储，并且会迁移到在容量较大，相对廉价的存储介质 (比如SATA HDD) 中，达到使用较低成本存储大量数据的目的。

如此分层存储带来一个新的问题：即整个系统必须频繁的进行compaction，写入量越大，Compaction的过程越频繁。而compaction是一个compare & merge的过程，非常消耗CPU和存储IO，在高吞吐的写入情形下，大量的compaction操作占用大量系统资源，必然带来整个系统性能断崖式下跌，对应用系统产生巨大影响。

而完全重新设计开发的X-Engine有着非常优越的多核扩展性，能达到非常高的性能，仅仅前台事务处理就几乎能完全消耗所有的CPU资源，其对资源的使用效率对比InnoDB,如下图所示：

在如此性能水平下，系统没有多余的计算资源进行compaction操作，否则将承受性能下跌的代价。

经测试，在 DbBench benchmark 的 write-only 场景下，系统会发生周期性的性能抖动，在 compaction 发生时，系统性能下跌超过40%，当 compaction 结束时，系统性能又恢复到正常水位。如下图所示：

但是如果 compaction 进行的不及时，多版本数据的累积又会严重影响读操作。

为了解决 compaction 的抖动问题，学术界提出了诸如 VT-tree、bLSM、PE、PCP、dCompaction 等结构。尽管这些算法通过不同方法优化了 compaction 性能，但是 compaction 本身消耗的 CPU 资源是无法避免的。据相关研究统计，在使用SSD存储设备时，系统中compaction的计算操作占据了60%的计算资源。因此，无论在软件层面针对 compaction 做了何种优化，对于所有基于 LSM-tree 的存储引擎而言，compaction造成的性能抖动都会是阿喀琉斯之踵。

幸运的是，专用硬件的出现为解决compaction导致的性能抖动提供了一个新的思路。实际上，使用专用硬件解决传统数据库的性能瓶颈已经成为了一个趋势，目前数据库中的select、where操作已经offload到FPGA上，而更为复杂的 group by 等操作也进行了相关的研究。但是目前的FPGA加速解决方案存在以下两点不足：

• 目前的加速方案基本上都是为SQL层设计，FPGA也通常放置在存储和host之间作为一个filter。虽然在FPGA加速OLAP系统方面已经有了许多尝试，但是对于OLTP系统而言，FPGA加速的设计仍然是一个挑战；

• 随着FPGA的芯片尺寸越来越小，FPGA内部的错误诸如单粒子翻转（SEU）正在成为FPGA可靠性的越来越大的威胁，对于单一芯片而言，发生内部错误的概率大概是3-5年，对于大规模的可用性系统，容错机制的设计显得尤为重要。

为了缓解compaction对X-Engine系统性能的影响，我们引入了异构硬件设备FPGA来代替CPU完成compaction操作，使系统整体性能维持在高水位并避免抖动，是存储引擎得以服务业务苛刻要求的关键。本文的贡献如下：

• FPGA compaction 的高效设计和实现。通过流水化compaction操作，FPGA compaction取得了十倍于CPU单线程的处理性能；

• 混合存储引擎的异步调度逻辑设计。由于一次FPGA compaction的链路请求在ms级别，使用传统的同步调度方式会阻塞大量的compaction线程并且带来很多线程切换的代价。通过异步调度，我们减少了线程切换的代价，提高了系统在工程方面的可用性。

• 容错机制的设计。由于输入数据的限制和FPGA内部错误，都会造成某个compaction 任务的回滚，为了保证数据的完整性ÿ