OceanBase如何获得TPC-C测试第1名？

阿里妹导读：TPC-C是TPC组织（国际事务性能委员会）制定的关于商品销售的订单创建和订单支付等的基准测试标准，是数据库联机交易处理系统的权威基准测试标准。

蚂蚁金服自研的分布式关系数据库OceanBase获得TPC-C测试第一名后，引起了大量关注，今天，我们邀请了OceanBase的核心研发人员对本次测试做专业的技术解读。

一、OceanBase如何做TPC-C测试

 

有机会挑战TPC-C测试相信是所有数据库内核开发人员的梦想，但TPC-C测试标准非常复杂。 由于这是国产数据库同时也是分布式数据库第一次冲击这个榜单，为了完成这次挑战，OceanBase团队前后准备时间超过一年。

前期准备

TPC-C测试首先需要找到官方唯一认证的审计员来对测试进行审计监察，他们对这次OceanBase的审计也相当重视，全世界仅有的三个审计员这次就有两个参与到测试审计工作中。

 

测试系统

目前市面上基本找不到一个能够开箱即用的符合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