蚂蚁金服OceanBase挑战TPCC | TPC-C基准测试之存储优化

蚂蚁金服自研数据库 OceanBase 登顶 TPC-C 引发业内普遍关注，为了更清楚的展现其中的技术细节，咱们特地邀请 OceanBase 核心研发人员对本次测试进行技术解读，共包括五篇：

1）TPC-C基准测试介绍
2）OceanBase如何作TPC-C测试
3）TPC-C基准测试之SQL优化
4）TPC-C基准测试之数据库事务引擎的挑战
5）TPC-C基准测试之存储优化

本文为第五篇，其它文章已同步发布，详情请在“蚂蚁金服科技”公众号查看。

---

TPC-C 规范要求被测数据库的性能（tpmC）与数据量成正比。TPC-C 的基本数据单元是仓库（warehouse），每一个仓库的数据量一般在 70MB 左右（与具体实现有关）。TPC-C 规定每一个仓库所得到的 tpmC 上限是 12.86（假设数据库响应时间为0）。假设某系统得到 150万 tpmC，大约对应 12万个仓库，按照 70MB/仓库计算，数据量约为 8.4TB。某些厂商采用修改过的不符合审计要求的 TPC-C 测试，不限制单个 warehouse 的 tpmC 上限，测试几百到几千个 warehouse 所有装载到内存的性能，这是没有意义的，也不可能经过审计。在真实的 TPC-C 测试中，存储的消耗占了很大一部分。OceanBase 做为第一款基于 shared nothing 架构登上 TPC-C 榜首的数据库，同时也做为第一款使用 LSM Tree 存储引擎架构登上 TPC-C 榜首的数据库，在存储架构上有以下关键点：

1. 为了保证可靠性，OceanBase 存储了两个数据副本和三个日志副本，而传统的集中式数据库测试 TPC-C 只存储一份数据；
2. 因为 OceanBase 存储两个数据副本，再加上 OceanBase TPC-C 测试采用了和生产系统彻底同样的阿里云服务器 i2 机型，SSD 硬盘的存储容量成为瓶颈。OceanBase 采用在线压缩的方式缓解这个问题，进一步增长了 CPU 使用；相应地，集中式数据库测试存储一份数据，不须要打开压缩；
3. OceanBase LSM 引擎按期须要在后台作 compaction 操做，而 TPC-C 要求测试至少运行 8 小时且 2 小时以内抖动小于 2%，所以，OceanBase 存储须要解决 LSM 引擎后台操做致使的抖动问题；

两份数据

为了保证可靠性和不丢数据（RPO=0），有两种不一样的方案：一种方案是在硬件层面容错，另外一种方案是在软件层面容错。OceanBase 选择在软件层面容错，优点是硬件成本更低，带来的问题是须要冗余存储多个副本的数据。OceanBase 使用 Paxos 协议保证在单机故障下数据的强一致。在 Paxos 协议中，一份数据须要被同步到多数派（超过一半），才被认为是写入成功，因此通常来讲副本个数老是奇数，出于成本考虑最多见的部署规格是三副本。

三副本带来的首要问题就是存储成本的上升，以前商业数据库的 TPC-C 测试大多基于磁盘阵列，而 TPC-C 规范中明确对磁盘阵列不作容灾要求，使用相对于传统数据库三倍的存储空间进行 TPC-C 测试显然难以接受。咱们注意到这样一个事实，经过 Paxos 协议同步的只是日志，日志须要写三份，但数据不是，数据只须要有两份就能够完成单机故障的容灾了，当一份数据因为服务器宕机不可用时，另外一份数据只要经过日志把数据补齐，就能够继续对外提供访问。和数据存储相比，日志的存储量比较小。咱们将数据与日志分开，定义了三种不一样的副本类型：F 副本既包含数据又同步日志，并对外提供读写服务；D 副本既包含数据又同步日志，但对外不提供读写服务；L 副本只同步日志，不存储数据。当 F 副本出现故障时，D 副本能够转换为 F 副本，补齐数据后对外提供服务。在 TPC-C 测试中咱们使用 FDL 模式进行部署（一个 F 副本，一个 D 副本，一个 L 副本），使用了两倍数据副本的存储空间。不管是 D 副本仍是 L 副本，都须要回放日志，D 副本还须要同步数据，这些都是都会消耗网络和 CPU。

在线压缩

在 shared nothing 架构下，OceanBase 至少须要存储两份数据才能够知足容灾的要求，这意味着 OceanBase 须要比传统数据库多耗费一倍的存储空间。为了缓解这个问题，OceanBase TPC-C 测试选择对数据进行在线压缩，Oracle 数据库中一个 warehouse 的存储容量接近 70MB，而 OceanBase 压缩后存储容量只有 50MB 左右，大幅下降了存储空间。TPC-C 规范要求磁盘空间可以知足 60 天数据量的存储，对于 OceanBase，因为须要保存两份数据，虽然可靠性更好，但须要保存至关于 120 天的数据量，这些存储成本都要计入整体价格。OceanBase 使用了 204 台 ECS i2 云服务器存储数据，服务器规格和线上真实业务应用保持一致。每台服务器的日志盘 1TB，数据盘接近 13TB。计算两份压缩后的数据 60 天的存储空间以后，服务器的数据盘基本没有太多余量,从服务器的资源成本消耗来看，已经达到了比较好的平衡。若是 OceanBase 的单机性能 tpmC 进一步提高，磁盘容量将成为瓶颈。OceanBase LSM 引擎是 append-only 的，它的优点是没有随机修改，可以在线压缩。不管是 TPC-C 测试，仍是最核心的 OLTP 生产系统（例如支付宝交易支付），OceanBase 都会打开在线压缩，经过 CPU 换存储空间。

存储性能平滑

TPC-C 测试很大的挑战在于在整个压测过程当中性能曲线要求是绝对平滑的，曲线上的波动幅度不能超过 2%，这对于传统数据库来讲都是一件困难的事情，由于这要求对于全部后台任务的精细控制，不能因为某个后台任务的资源过分使用致使前台请求的阻塞积压。而对于 OceanBase 而言，事情变得更为困难，由于 OceanBase 的存储引擎是基于 LSM Tree 的，在 LSM Tree 要按期执行 compaction 操做。Compaction 是个很是重的后台操做，会占用大量 CPU 和磁盘 IO 资源，这对前台的用户查询和写入自然就会形成影响。咱们作了一些优化，来平滑后台任务对性能的影响，从最终的测试结果来看，性能曲线在整个 8 小时压测过程当中的抖动小于 0.5%。

分层转储

在 LSM Tree 中，数据首先被写入内存中的 MemTable，在必定时候为了释放内存，MemTable 中的数据须要与磁盘中的 SSTable 进行合并，这个过程被称为 compaction。在不少基于 LSM Tree 的存储系统中，为了解决写入的性能问题，一般会将 SSTable 分为多层，当一层的 SSTable 个数或者大小达到某个阈值时，合并入下一层 SSTable。多层 SSTable 解决了写入的问题，可是 SSTable 的个数过多，会极大拖慢查询的性能。OceanBase 一样借鉴了分层的思路，但同时使用了更加灵活的 compaction 策略，确保 SSTable 总数不会太多，从而在读取和写入性能之间作了更好的平衡。

资源隔离

Compaction 等后台任务须要消耗大量的服务器资源，为了减小后台任务对用户查询和写入的影响，咱们在 CPU、内存、磁盘 IO 和网络 IO 四个方面对先后台任务作了资源隔离。在 CPU 方面，咱们将后台任务和用户请求分为不一样的线程池，并按照 CPU 亲和性作了隔离。在内存方面，对先后台请求作了不一样的内存管理。在磁盘 IO 方面，咱们控制后台任务 IO 请求的 IOPS，使用 deadline 算法进行流控。在网络 IO 方面，咱们将后台任务 RPC 和用户请求 RPC 分为不一样队列，并对后台任务 RPC 的带宽使用进行流控。

存储CPU占用

TPC-C 基准测试主要考察总体性能 tpmC，不少人也会关注单核的 tpmC。然而，这个指标只有在相同架构下才有意义。对于存储模块的 CPU 占用，有以下三点：

1. 对于集中式架构，除了数据库使用 CPU 以外，专用存储设备也须要使用 CPU。例如，第二名 Oracle 3000多万 tpmC 的测试中，数据库使用了 108 颗 T3 SPARC 处理器，共有 1728 个物理核心和 13824 个执行线程，同时存储设备使用的是 Intel 服务器做为机头，总共使用了 97 台服务器，194 颗 Intel X5670 CPU，2328 个物理核心；
2. 集中式数据库使用高可靠硬件，只须要存储一个副本，而 OceanBase 经过软件层面容错，虽然硬件成本更低但须要两个数据副本和三个日志副本，维护多个副本须要耗费大量 CPU；
3. OceanBase 在 TPC-C 测试和生产系统中都打开了在线压缩，进一步增长了 CPU 使用；

所以，简单地对比OceanBase和Oracle的CPU核是不科学的，还须要算上共享存储设备的CPU核，以及OceanBase存储多副本和在线压缩带来的CPU开销。TPC-C推荐的方案是不关注具体的软件架构和硬件架构，关注硬件整体成本。在OceanBase的测试中，硬件成本只占总体成本的18%左右，只考虑硬件的性价比大幅优于集中式数据库。

后续发展

OceanBase的优点在于采用分布式架构，硬件成本更低，可用性更好且可以作到线性扩展，可是，OceanBase单机的性能离Oracle、DB2还有不小的差距，后续须要重点优化单机存储性能。另外，OceanBase的定位是在同一套引擎同时支持OLTP业务和OLAP业务，而目前OceanBase的OLAP处理能力还不如Oracle，后续须要增强存储模块对大查询的处理能力，支持将OLAP算子下压到存储层甚至在压缩后的数据上直接作OLAP计算。

做者介绍

赵裕众，现任蚂蚁金服 OceanBase 团队高级技术专家，2010 年加入支付宝后从事分布式事务框架的研发，2013 年加入 OceanBase 团队，目前负责存储引擎相关的研发工做。

 

阅读原文

本文为云栖社区原创内容，未经容许不得转载。