众所周知，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 标准带来了很多新鲜的概念和测试方案。
测试系统
目前市面上基本找不到一个能够开箱即用的符合 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 榜单的冲击。
性能压测
最受关注的性能压测部分在 TPC-C 标准中规定了以下三个状态：
所以之前一般数据库进行性能压测一般是以下的流程，先进行一段时间的预热到达稳态，等待稳定运行一段时间并完成一个 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 学习的榜样。
作者介绍：
曹晖，现任蚂蚁金服 OceanBase 团队技术专家，2017 年加入 OceanBase 团队，现从事存储引擎开发工作。
原文链接：
