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

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

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

众所周知，TPC 组织是当今国际数据库领域公认最权威的测试和评价组织，它成立的初衷就是构建最好的测试标准以及制定针对这些标准最优的审计和监测流程。数据库界的天皇巨星 Jim Gray 曾在 1985 年提出了针对事务处理能力的评价标准 DebitCredit，而 1988 年 TPC 组织成立伊始，就基于这个标准提出了 TPC 组织第一个针对 OLTP 应用的测试标准 TPC-A。但随着时代发展，TPC-A 已经慢慢无法完全体现真实应用场景，此时 TPC-C 肩负重任应运而生，接下来也一直是 TPC 组织最核心同时也是关系数据库领域最顶级的测试标准。TPC-C 标准比 TPC-A 更加复杂，压力负载模型是 16 位一线工业产业界学者一起参与制定，随着时间推移测试标准也一直在保持修订，所以其模拟大型在线商超的测试模型时至今日也仍不过时，越来越能找到和当前大型 B2C 电商网站的共通之处。

有机会挑战 TPC-C 测试相信是所有数据库内核开发人员的梦想，但 TPC-C 测试标准非常复杂，1992 年 7 月发布以来到现在已经是 v5.11.0 版本，仅 PDF 就 132 页，如果不是铁杆粉丝估计很少有人会认真通读完这个标准。这次 OceanBase 创造 TPC-C 记录引起了大家的广泛关注，但它也只是这个测试标准里体现跑分的一个评价项 MQTh(最大有效吞吐量)，隐藏在跑分下面的是 TPC-C 标准对被测数据库无数细致入微的测试验证和评价项，而正是这些才让这个标准在关系数据库领域如此权威，同时也是国产数据库之前很难入场的一大原因。

由于这是国产数据库同时也是分布式数据库第一次冲击这个榜单，为了完成这次挑战，OceanBase 团队前后准备时间超过一年，仅审计认证过程就耗时约半年，除了数据库自身性能优化同时还有大量的稳定性、合规要求相关工作，6088w tpmC 其实也只是整个测试结果中一小个展示项而已。

前期准备

作为基于 LSM-Tree、多副本 paxos 强一致的新型分布式关系数据库，如何进行 TPC-C 测试，有哪些注意事项，什么时候该做什么步骤等等诸多问题，在审计刚启动时我们无处咨询也没有任何可借鉴的资料。TPC-C 测试首先需要找到官方唯一认证的审计员来对测试进行审计监察，但面对 OceanBase 这样一个全新架构的关系数据库时，他们其实也有着诸多和我们类似的疑惑和问题，因此他们对这次 OceanBase 的审计也相当重视，全世界仅有的三个审计员这次就有两个参与到测试审计工作中。

两位审计员其中一位还是 TPC-C 标准原作者之一,他们对整个测试流程的要求异常细致和严苛，起初对待 OceanBase 还持有很大的怀疑态度，和审计员们漫长的邮件以及现场沟通过程也异常艰辛，但这也帮助我们始终坚持用规范中最严格的标准来针对每个测试子项，最终也赢得了审计员们充分的信任，审计员甚至在理解了 OceanBase 架构后帮助我们提出了多个问题解决思路。另外通过这次测试，OceanBase 也给 TPC-C 标准带来了很多新鲜的概念和测试方案。

• 如何在OceanBase特有的Incremental数据带上后续的Major Compaction机制下去做数据存储的审计；
• 如何在全部使用云服务器的测试系统中进行Durability测试；
• 分布式数据库在性能压测等测试中应当如何去评估和监控checkpoint；

测试系统

目前市面上基本找不到一个能够开箱即用的符合 TPC-C 标准的测试工具。以目前各个厂商 PoC 环境最常遇到的 benchmarksql 为例，可以说只是模拟 TPC-C 压力模型的压测工具，连最基本的数据导入都不合规，大量的字符串生成未保证全局随机，缺乏压测阶段最基本的 think time、keying time 这些基本配置导致极小的数据量就能跑出很高的 tpmC，最关键的是它将测试模型大大简化为工具直连 DB 测试，完全没有遵守 TPC-C 测试标准规范。

在标准定义中，测试系统可以分为 RTE（Remote Terminal Emulator）和 SUT 两部分，但实际上从角色上看 SUT 可以进一步拆分为两部分：WAS(web application server)和 DB Server。这其中 DB Server 是每个测试厂商的数据库服务；RTE 扮演的角色是测试模型中的客户终端，事务的触发、RT 的统计等都在这里完成；标准明确要求每一个用户 terminal 都必须保持一个长连接，显然在海量 Warehouse 时 DB 是无法承受这么多连接的，WAS 就是 RTE 和 DB 之间桥梁，标准定义可以使用连接池，在保证对应用透明的情况下它可以做所有请求的管理。

这三个角色中，WAS 和 DB 是必须商业化可购买且提供支付服务的，OceanBase 这次是使用了 OpenResty 作为 WAS 供应商。而 RTE 则一般由各个参测厂商自行根据标准实现，但所有实现代码必须经过审计的严格审计，OceanBase 这次完整的实现了一整套完全合规的 RTE，并且支持在大规模测试系统中部署。要知道在实际的 TPC-C 测试流程中，不只是对 DB 端能力的考验，RTE 端同样存在极大的资源消耗和压力。以这次 6088w tpmC 测试结果看，我们一共在 64 台 64c128G 的云服务器上运行了 960 个 RTE 客户端，来模拟总计 47942400 个用户 terminal，最后还需要基于这么多 RTE 统计结果进行一致性和持久化审计验证。

虽然只是测试客户端，但 RTE 的中同样有大量的可能导致最后测试失败的小细节，比如大家可能注意不到的所有事务都因为用了 web 端模拟终端后需要增加的 100 毫秒 rt，又比如为了模拟用户终端输出显示的 100 毫秒延时。

测试规划

TPC-C 从来都不是一个简单的测试，它很科学并没有给出强制的软硬件配置，只是给出测试规范和各种审计检查限制标准，所有数据库厂商可以根据自己的特性充分调优来拿到一个最好的性能或性价比。但这同时也对所有参测厂商提出了一个巨大的难题，如何对已有的资源进行合理规划来保证顺利完成一次对 TPC-C 榜单的冲击。

1.硬件选型，这里不仅要对数据库服务器选型，还需要对 RTE 以及 WAS 服务器选型。这之前需要先期进行大量的测试和调优，来摸出在保证性价比的前提下每个角色服务器的资源配置是多少刚好。这次 OceanBase 测试最大的优势就是全部使用了云化资源，我们不需要再关注最底层机房、机柜、布线这些细节，只需要通过快速的规格调整来拿到我们需要的机型。

2.参数选择，如何选择合适的配置参数是一个非常令人头疼的问题。举个例子，一个最典型的问题就是我们最终要跑多少个 Warehouse，每个数据库服务器上承载多少 Warehouse。TPC-C 标准为了尽可能模拟真实业务场景，通过每个事务限定不同的 think time 和 keying time 保证了一个 warehouse 的数据最多能够提供 12.86tpmC 值，因此数据库厂商想要拿到更高的成绩就必须装载更多的 warehouse，但是另一方面单机的存储空间又有预计 80%（经验值）需要预留给 60 天增量存储。在分布式数据库架构下，为了能让每个数据库服务器跑满又能充分利用本地存储空间，让每个服务器的 CPU、内存、IO 能力、存储空间的资源最大化利用，我们前后调整优化了近一个月时间。

性能压测

最受关注的性能压测部分在 TPC-C 标准中规定了以下三个状态：

1.Ramp-up，标准允许每个数据库进行一定时间的预热来达到稳定状态，但是 ramp-up 阶段的所有配置必须和最终报告配置保持一致。

2.Steady state，保证 ACID 及可串行化隔离级别前提下，数据库需要能够以最终报告 tpmC 值在稳定状态无任何人工干预前提下保持运行 8 小时以上，每隔半小时需要完成一次 checkpoint。

3.Measurement Interval，标准规定了需要能够支持 8 小时稳定运行，但性能采集阶段只需要保设置 2 小时以上即可。这个阶段还需要保证累计 tpmC 波动不能超过 2%，并且必须完成至少 4 个以上的 checkpoint。

所以之前一般数据库进行性能压测一般是以下的流程，先进行一段时间的预热到达稳态，等待稳定运行一段时间并完成一个 checkpoint 后开始进入 2 小时的性能采集阶段。

而 OceanBase 这次是使用了 TPC-C 测试迄今以来最严苛的一个流程来完成这个性能测试的，我们首先使用了 10 分钟进行预热，然后在 6088w tpmC 稳态保持运行 25 分钟并完成一个检查点，再继续跑了完整的 8 小时性能压测采集阶段，总耗时超过 8 个半小时，中间性能最大波动不到 0.5%，最终结果也让审计员异常兴奋。

整个性能测试前后，审计员还需要进行数据及事务随机分布检查，简单说来就是大量全表扫描和统计 sql，最大的一条 sql 需要访问超过万亿行的 order_line 表结果，可以算是 TPC-C 里的“TPC-H 测试”。现场审计第一次遇到这些 sql 时我们也大量的出现 sql 执行超时情况，但后续基于 OceanBase2.2 版本最新的并行执行框架我们还是很快搞定了这些大 sql，所以要顺利完成 TPC-C 测试并不能只是一个偏科生，保持自身没有短板才是真正意义上的通用关系数据库，从这点上说 Oracle 仍是 OceanBase 学习的榜样。

ACID

1.A 测试，通过提交和回滚 payment 事务来确认数据库对原子性支持，和 I 测试一样，OceanBase 的 A 测试跑了两遍，分别应对分布式事务和本地事务。

2.C 测试，标准里的 C 测试一共包含 12 个 case，前四个是必须要完成验证的，每个 case 其实都可以认为是一个复杂的大 sql，而对于分布式数据库来说重点是需要始终保证全局一致。

3.I 测试，标准要求 TPC-C 模型里 5 个事务除了 StockLevel 事务都需要满足最高的可串行化隔离级别，并构造了 9 个 case 来验证隔离性。对于分布式数据库而言，这个要求并没有那么容易实现，所幸 OceanBase 在 2.x 版本中提供了全局时间戳的支持，所以的 I 测试都在审计员的特别要求下跑完了全本地和全分布式两种模式的两轮测试，这也应该是 TPC-C 测试中首次有数据库厂商需要做两轮 I 测试跑 18 个 case 的，也许在不久后 TPC-C 标准定义也会因为 OceanBase 的这次测试而带来针对分布式数据库的相关更新。

4.D 测试，OceanBase 在这个场景其实相对传统数据库是有较大天生优势的，OceanBase 每个 Warehouse 数据有两份数据三份日志，通过 paxos 强同步，保证 RPO=0 的前提下只有秒级 RTO。面对 D 测试标准中最严格的一项-部分存储介质永久故障，OceanBase 还使用了最严苛的测试场景，在使用超出标准要求的全量 6000W tpmC 压力下，我们强行销毁了一个云服务器节点，整体 tpmC 在两分钟内恢复到 6000w 并持续跑到测试时间结束，这些表现都是远远超过 TPC-C 规范要求的，相比较而言其它传统数据库基本面对有日志的存储介质故障 D 测试场景都是依赖磁盘 RAID 来恢复，OceanBase 应该算是首个没有 raid 完全依赖数据库自身恢复机制完成全部 D 测试的数据库厂商了。同时我们在 D 测试中是连续杀掉了两台服务器节点，首先杀掉一个数据节点，等待 tpmC 恢复且稳定 5 分钟后，再次杀掉了 rootserver leader 节点，tpmC 仍然快速恢复。

作者介绍

曹晖，现任蚂蚁金服 OceanBase 团队技术专家，2017 年加入 OceanBase 团队，现从事存储引擎开发工作。