TPC-C解析系列02_OceanBase如何做TPC-C测试

2020-06-30 00:00:00 数据库 分布式 测试 标准 审计

导语：

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

相关文章