众所周知,TPC 组织是当今国际数据库领域公认最权威的测试和评价组织,它成立的初衷就是构建最好的测试标准以及制定针对这些标准最优的审计和监测流程。数据库界的天皇巨星 Jim Gray 曾在 1985 年提出了针对事务处理能力的评价标准 DebitCredit,而 1988 年 TPC 组织成立伊始,就基于这个标准提出了 TPC 组织第一个针对 OLTP 应用的测试标准 TPC-A。但随着时代发展,TPC-A 已经慢慢无法完全体现真实应用场景,此时 TPC-C 肩负重任应运而生,接下来也一直是 TPC 组织最核心同时也是关系数据库领域最顶级的测试标准。TPC-C 标准比 TPC-A 更加复杂,压力负载模型是 16 位一线工业产业界学者一起参与制定,随着时间推移测试标准也一直在保持修订,所以其模拟大型在线商超的测试模型时至今日也仍不过时,越来越能找到和当前大型 B2C 电商网站的共通之处。
由于这是国产数据库同时也是分布式数据库第一次冲击这个榜单,为了完成这次挑战,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 扮演的角色是测试模型中的客户终端( terminal ),事务的触发、RT 的统计等都在这里完成;标准明确要求每一个用户终端都必须保持一个长连接,显然在海量 Warehouse 时 DB 是无法承受这么多连接的,WAS 就是 RTE 和 DB 之间桥梁,标准定义可以使用连接池,在保证对应用透明的情况下它可以做所有请求的管理。
这三个角色中,WAS 和 DB 是必须商业化可购买且提供支付服务的,OceanBase 这次是使用了 OpenResty 作为 WAS 供应商。而 RTE 则一般由各个参测厂商自行根据标准实现,但所有实现代码必须经过严格的审计,OceanBase 这次完整地实现了一整套完全合规的 RTE,并且支持在大规模测试系统中部署。要知道,在实际的 TPC-C 测试流程中,不只是对 DB 端能力的考验,RTE 端同样存在极大的资源消耗和压力。以这次 6088w tpmC 测试结果看,我们一共在 64 台 64c128G 的云服务器上运行了 960 个 RTE 客户端,来模拟总计 47942400 个用户终端,最后还需要基于这么多 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 学习的榜样。