蚂蚁金服OceanBase挑战TPCC | 测试流程解析

蚂蚁金服自研数据库 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 团队，现从事存储引擎开发工做。