蚂蚁金服自研数据库 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 榜首的数据库，在存储架构上有如下关键点：

为了保证可靠性，OceanBase 存储了两个数据副本和三个日志副本，而传统的集中式数据库测试 TPC-C 只存储一份数据；
由于 OceanBase 存储两个数据副本，再加上 OceanBase TPC-C 测试采用了和生产系统完全一样的阿里云服务器 i2 机型，SSD 硬盘的存储容量成为瓶颈。OceanBase 采用在线压缩的方式缓解这个问题，进一步增加了 CPU 使用；相应地，集中式数据库测试存储一份数据，不需要打开压缩；
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 占用，有如下三点：

对于集中式架构，除了数据库使用 CPU 之外，专用存储设备也需要使用 CPU。例如，第二名 Oracle 3000多万 tpmC 的测试中，数据库使用了 108 颗 T3 SPARC 处理器，共有 1728 个物理核心和 13824 个执行线程，同时存储设备使用的是 Intel 服务器作为机头，总共使用了 97 台服务器，194 颗 Intel X5670 CPU，2328 个物理核心；
集中式数据库使用高可靠硬件，只需要存储一个副本，而 OceanBase 通过软件层面容错，虽然硬件成本更低但需要两个数据副本和三个日志副本，维护多个副本需要耗费大量 CPU；
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计算。

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