5月20日,国际事务处理性能委员TPC组织的官网显示,蚂蚁金服100%自主研发的分布式关系数据库OceanBase,以7.07亿(707,351,007)tpmC的在线事务处理性能,打破了OceanBase自己在2019年10月创造的6088万(60,880,800)tpmC的TPC-C世界纪录。
TPC-C是全球最具公信力的联机交易处理数据库的功能与性能结合的测试标准。通俗来讲,TPC-C测试是对于商业数据库想要证明自身实力的一个硬性门槛。
去年10月份OceanBase登顶TPC-C榜单,虽然成绩已经达到了之前榜首Oracle的两倍,但首次测试尚未充分发挥OceanBase分布式架构的真正实力。经过半年的准备,本次测试使用了1557台数据库服务器,不仅整体性能提升接近线性,单机性能相比一期测试也得到了大幅提升,初步展示了OceanBase作为一款真正的分布式关系数据库的实力。
一期测试 |
单机Warehouse数 |
23,500 |
单机理论最高tpmC |
300,800 |
|
数据库节点规模(台) |
207 |
|
8小时压测tpmC |
60,880,800 |
|
压测tpmC / 理论tpmC |
0.992 |
|
二期测试 |
单机Warehouse数 |
36,000 |
单机理论最高tpmC |
460,800 |
|
数据库节点规模(台) |
1557 |
|
8小时压测tpmC |
707,351,007 |
|
压测tpmC / 理论tpmC |
0.987 |
下面我们对本次OceanBase的TPC-C测试做个简单介绍。
扩展能力
对于任何分布式系统来说,系统整体的水平扩展能力都是最重要的衡量指标之一。具备线性或准线性的水平扩展能力的数据分析(OLAP)的系统,可以说比比皆是;但由于数据库事务所必需的ACID属性非同一般的困难,具备水平扩展能力的交易处理(OLTP)系统,则是凤毛麟角,更不谈线性或准线性性能的水平扩展。而TPC-Cbenchmark的前提就是通过事务的ACID测试:
- 对于总占比共计88%的“订单创建”和“订单支付”事务,TPC-C标准要求分别约10%和15%的分布式事务,单个事务最多涉及15个节点。因此对于每个分布式数据库节点来说,在TPC-C测试中机器规模越大,每个节点就需要和更多的节点交互形成分布式事务,性能衰减也更大。
- TPC-C标准里要求“订单创建”、“订单支付”、“订单配送”、“订单查询”事务之间都是可串行化隔离级别(Serializable),这个要求对于分布式关系数据库来说,要在超大规模集群中提供可串行化隔离级别的同时,又要保证高性能和高可用也变得愈发困难。
OceanBase在一期测试时使用了207台数据库服务器,而这次测试的集群规模更是达到1557台,这也是对OceanBase扩展性的一次巨大的考验和挑战。经过一段时间的优化,集群规模从一开始的200台增加到800、1000直到最后的1500多台,整体性能接近线性增长。
单机性能
除了水平扩展能力之外,OceanBase也在不断提升单机性能,包括SQL中缀表达式的计算性能,超大分区表的裁剪性能,存储过程的性能等等。
此外,优化后台资源占用也对性能提升做出了显著贡献。众所周知,OceanBase是基于LSM-Tree架构的,而TPC-C标准中又有一个对LSM-Tree架构数据库不利的限制,就是在要求8小时压测性能抖动不超过2%的前提下,还要每半个小时内完成一次checkpoint。这就意味着后台的compaction动作无时无刻不在发生,并且这次测试中OceanBase还进一步增加了单机数据量,压测期间随机读iops最高峰超过9万多,在这种压力下要让compaction对性能的影响更加平滑、对用户查询影响更小,是个不小的挑战。OceanBase本次测试在之前基础上继续改进分层转储策略和后台io调度策略,最终实现了8小时压测抖动小于1%,并且全程所有数据节点完成了至少23次checkpoint,平均两次checkpoint间隔只有23分钟,整体表现大大好于标准要求。
跟上次benchmark测试相比,这次测试中使用了全新的阿里云ECS规格i2d,单机CPU核数提升了30%(64vCPU->84vCPU,一样的CPU核),而OceanBase平均单机tpmC的提升则达到了50%。因此OceanBase不仅充分发挥了阿里云新ECS规格所带来的硬件红利,而且同等硬件条件下,OceanBase的单机性能也提升了20%。
并行查询
TPC-C虽然是面向OLTP的测试,但是其中的ACID测试流程也包含了大量的全表扫描和分析SQL。而在本次测试时,由于数据库机器规模扩大到1557台且单机仓库数增长到3.6万,总数据规模达到了近6PB,最大单表扫描数据总行数超过20万亿行(TPC-H最大的测试是100TB)。
为了应对如此之大的海量数据查询,OceanBase进一步夯实了已有的并行查询引擎,最终的测试流程中,查询使用的并行度超过4.5万,最大几张表的全表扫描都在分钟级完成,而其它sql基本都能在秒级返回。
更高的性价比
OceanBase做TPC-C测试的初衷并不仅仅是性能的提升,同时也希望在性价比上充分体现分布式数据库的优势。虽然从成本角度看OceanBase基于Paxos有多副本的天然劣势,但是在彻底摆脱了传统高端硬件的限制之后,OceanBase在一期TPC-C测试中更是创新的首次将TPC-C测试全面云化,充分享受虚拟化便利的同时,也将单tpmC成本拉到了比之前Oracle结果还要低的程度,并且OceanBase是在数据多副本的情况下达到这一成绩的,在更低性价比的同时还提供了更高的可靠性。而本次测试中,OceanBase把单个tpmC成本又降低了1/3以上,进一步加强了OceanBase作为云数据库的成本优势。通过两次的TPC-C‘云’测试,我们也能够发现:
- 全面拥抱云化实现真正的弹性,用户能够快速通过云上ECS弹性扩容,借助OceanBase真正的内置水平扩展能力,让数据库集群快速在线扩容到业务所需的规模,所有新增的资源能够在业务峰值过后,利用OceanBase自身的缩容功能快速释放,大大节省用户成本。
- OceanBase的高性能完全不依赖高端或专用硬件,两次TPC-C测试OceanBase跟随阿里云升级趋势分别使用了两种不同规格的通用ECS虚拟机。而用户在搭建自己的OceanBase集群时,同样可以丰俭由人,选取适合实际业务情况的硬件配置即可。
Oracle-RAC |
OceanBase一期 |
OceanBase二期 |
||
MQTh (tpmC) |
3025万 |
6088万 |
7.07亿 |
|
硬件配置 |
27台T3-4 Sparc工作站:13,824超线程(单机512) |
207台x86虚拟机:13,238超线程(单机64) |
1557台x86虚拟机: 130,788超线程(单机84) |
|
Price/tpmC |
USD 1.01 |
CNY 6.25 |
CNY 3.98 |
|
其它 |
97台存储机头,每个存储带一个X86服务器,1,164超线程(单机12) |
全部使用阿里云ECS i2规格 |
全部使用阿里云ECS i2d规格 |
|
从上表可以看到,TPC-C测试一直以来都是一个比较昂贵的测试,因此之前能够上榜的测试往往是以硬件厂商为主导。而OceanBase借助云测试的特点,将每次TPC-C测试的代价降低了很多,不再需要实际购买相应的硬件资源,这也给其它希望参与评测的数据库提供了借鉴和参考。例如本次测试,虽然从最终FDR可以看到测试的硬件成本约6亿人民币,但这是标准要求公开的3年总持有成本,而实际测试中我们只需要在阿里云上购买相应ECS资源很短的时间,远远低于之前榜单上其它厂商测试的花费。