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

本文涉及的产品
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
全局流量管理 GTM,标准版 1个月
云解析 DNS,旗舰版 1个月
简介: 蚂蚁金服自研数据库 OceanBase 登顶 TPC-C 引起业内广泛关注,为了更清楚的展示其中的技术细节,我们特意邀请 OceanBase 核心研发人员对本次测试进行技术解读。

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

相关文章
|
22天前
|
运维 测试技术
拆分软件测试流程,一张图秒杀所有面试
本文主要介绍了软件测试流程的核心内容,包括需求分析、测试用例编写、测试执行、缺陷提交及回归测试等关键步骤。以迭代测试为例,详细说明了每个环节的具体操作和注意事项,并提供了一张测试流程图以便理解。测试流程确保了软件质量,是面试中常见的考察点。
35 7
拆分软件测试流程,一张图秒杀所有面试
|
3天前
|
安全 测试技术 UED
软件测试的艺术:从代码审查到用户体验的全方位解析
在软件开发的宇宙中,测试是那颗最耀眼的星辰。它不仅仅是一种技术活动,更是一门艺术。本文将带你领略这门艺术的魅力,从细微的代码审查到宏大的用户体验设计,揭示软件测试如何塑造出更加完美的数字世界。
|
14天前
|
机器学习/深度学习 人工智能 算法
软件测试的艺术:从代码审查到用户体验的全方位解析
在软件开发过程中,一个经常被低估的环节就是软件测试。许多人认为测试仅仅是“点击几下鼠标,看看是否有错误”。然而,真正的软件测试是一门集技术深度、策略规划和细致观察于一体的艺术。它不仅关系到产品的质量和稳定性,更直接影响到最终用户的满意度。本文将从多个角度深入探讨软件测试的重要性、方法和最佳实践,帮助你理解为什么说软件测试是一种艺术。
|
16天前
|
设计模式 人工智能 算法
PHP中的设计模式:策略模式的深入解析与实践软件测试中的人工智能革命:提升效率与准确性的新篇章
在PHP开发中,理解并运用设计模式是提升代码质量和可维护性的重要途径。本文聚焦于策略模式(Strategy Pattern),一种行为型设计模式,它允许在运行时选择算法或业务规则。通过本文,我们将深入探讨策略模式的定义、结构、使用场景以及如何在PHP项目中有效地实现和利用策略模式。不同于性能优化等技术性摘要,本文着重于提供对策略模式全面而实用的理解,助力开发者编写出更加灵活和可扩展的应用程序。 本文深入探讨了人工智能在软件测试领域的应用,揭示了其如何显著提高测试过程的效率和准确性。通过实际案例分析,展示了AI技术在自动化测试、缺陷检测及结果分析中的关键作用,并讨论了实施AI测试策略时面临的挑
17 3
|
16天前
|
敏捷开发 安全 测试技术
软件测试的艺术:从代码到用户体验的全方位解析
本文将深入探讨软件测试的重要性和实施策略,通过分析不同类型的测试方法和工具,展示如何有效地提升软件质量和用户满意度。我们将从单元测试、集成测试到性能测试等多个角度出发,详细解释每种测试方法的实施步骤和最佳实践。此外,文章还将讨论如何通过持续集成和自动化测试来优化测试流程,以及如何建立有效的测试团队来应对快速变化的市场需求。通过实际案例的分析,本文旨在为读者提供一套系统而实用的软件测试策略,帮助读者在软件开发过程中做出更明智的决策。
|
7天前
|
测试技术 UED 开发者
软件测试的艺术:从代码审查到用户反馈的全景探索在软件开发的宇宙中,测试是那颗确保星系正常运转的暗物质。它或许不总是站在聚光灯下,但无疑是支撑整个系统稳定性与可靠性的基石。《软件测试的艺术:从代码审查到用户反馈的全景探索》一文,旨在揭开软件测试这一神秘面纱,通过深入浅出的方式,引领读者穿梭于测试的各个环节,从细微处着眼,至宏观视角俯瞰,全方位解析如何打造无懈可击的软件产品。
本文以“软件测试的艺术”为核心,创新性地将技术深度与通俗易懂的语言风格相结合,绘制了一幅从代码审查到用户反馈全过程的测试蓝图。不同于常规摘要的枯燥概述,这里更像是一段旅程的预告片,承诺带领读者经历一场从微观世界到宏观视野的探索之旅,揭示每一个测试环节背后的哲学与实践智慧,让即便是非专业人士也能领略到软件测试的魅力所在,并从中获取实用的启示。
|
19天前
|
运维 测试技术 持续交付
软件测试的艺术:从代码审查到用户体验的全方位解析
本文将探讨如何通过高效、全面的软件测试策略,确保产品质量和用户体验。我们将深入分析不同类型的测试方法,包括单元测试、集成测试、系统测试、性能测试和用户验收测试(UAT),并介绍每种方法的具体实施步骤和最佳实践。此外,我们还将讨论测试自动化的重要性及其在现代软件开发流程中的应用。通过阅读本文,您将获得一套完整的软件测试解决方案,帮助您提升产品质量和用户满意度。
27 0
|
2月前
|
存储 SQL 分布式数据库
OceanBase 入门:分布式数据库的基础概念
【8月更文第31天】在当今的大数据时代,随着业务规模的不断扩大,传统的单机数据库已经难以满足高并发、大数据量的应用需求。分布式数据库应运而生,成为解决这一问题的有效方案之一。本文将介绍一款由阿里巴巴集团自主研发的分布式数据库——OceanBase,并通过一些基础概念和实际代码示例来帮助读者理解其工作原理。
117 0
|
2月前
|
Oracle 架构师 分布式数据库
OceanBase数据库的发展历程是什么?
【8月更文挑战第11天】OceanBase数据库的发展历程是什么?
146 63
|
2月前
|
Oracle 关系型数据库 MySQL
OceanBase数据库简介
【8月更文挑战第9天】OceanBase数据库简介
275 60

推荐镜像

更多
下一篇
无影云桌面