聊聊TPC那些事儿

网络 网络管理
就先从TPC-H聊起吧,我们可以看到各个主流传统数据库厂商,在近些年早已经不再发表TPC-H的审计报告了,从而近年TPC-H越来越成为硬件设备厂商展示自己服务器处理能力的宣传指标之一了。

[[403151]]

最近几天OceanBase TPC-H勇夺世界第一的PR宣传被中文自媒体先后报道,兴奋之余,笔者也想到,根据这些年对TPC机构以其审计师们的接触,对TPC benchmark及其审计和发布流程有了一些了解,也听到一些坊间的逸闻趣事,所以在恭喜OceanBase荣耀夺冠的时候,今天咱们也换个角度随便聊聊关于TPC这个基准测试的事情。

1.谁在做TPC-H测试?

就先从TPC-H聊起吧,我们可以看到各个主流传统数据库厂商,在近些年早已经不再发表TPC-H的审计报告了,从而近年TPC-H越来越成为硬件设备厂商展示自己服务器处理能力的宣传指标之一了。所以我们今天在TPC的官方网页 [1] 就会看到很“有趣”的一幕,明明是数据库性能的基准测试,但结果列表(所谓的“榜单”)一眼望去几乎都是硬件厂商:系统 (System) 一栏几乎都是服务器型号,测试赞助商 (Company/Sponsor) 几乎都是设备厂商,除了OceanBase和Alibaba Cloud AnalyticDB是例外。而列表上不同的设备商往往会选用相同的数据库产品做基准测试,例如在TPC-H中近些年测试使用最多的就是微软的SQL Server Enterprise Edition。看到这里,我们大概会对TPC-H在业界中的作用解读开始有了一些不一样的想法了。

那为什么会这样呢?首先我们来看看TPC-H这个benchmark。TPC-H 这个benchmark包含了非常严苛的ACID测试以及查询性能测试,但严格来讲并不是HTAP的TP和AP并存高并发的场景,而是在验证ACID基础上的一些相对简单(对比TPC-DS)的OLAP查询的性能测试。其中AP的并发查询根据测试数据量 (scale factor) 不同,一般只有2-11个并发(在TPC-H中每个并发被称为一个stream),在每个stream内22个查询顺序执行。而整个测试中TP只有一个并发 (stream),且这个TP的stream只包含对Order和Lineitem两张表的千分之一左右数据的写入和删除,一般情况下只占每个AP stream执行耗时的很短时间,例如就以OceanBase这次公开发表的审计结果看,Performance RUN1的AP stream1耗时为1382秒,而TP的耗时仅不到7秒就结束了,对AP workload中的大部分查询几乎影响很小。并且由于TPC-H的数据模型过于简单,数据分布单一,对于传统数据库系统的挑战并不是很大。再加上各个数据库厂商及学术界对于TPC-H这个benchmark已经研究的非常透了,哪个查询该做什么优化,甚至多年前就有专门的论文来讨论 [2],所以总体来看,TPC-H对于传统数据库系统来说没有什么挑战,对其宣传作用也有限。而对以OceanBase为代表的数据库“新势力”来说,TPC-H难度适中,又比较全面地评测包括ACID在内的数据库系统能力,发表测试结果可以为其带来一定的可信度(我们后面再说为什么是“一定的”而不是“绝对的”),可以来作为商业推广宣传之一。

2.TPC-H的参考价值有多大?

这里再说说基准测试结果的可信度。首先TPC有严格的第三方审计制度,是常年与TPC合作的审计组织,这个组织里的审计师 (auditor) 都是数据库领域有几十年经验的老专家,有些更是直接参与到benchmark的制定和修改中。整个审计流程非常严格,据说甚至连审计需要提供的日志输出的格式都有严格要求。按理说在这样严格的审计流程下,审计结果一定非常可信。Yes and No!

审计流程的严格没有问题,但这里TPC对包括TPC-H, TPC-DS, TPC-C在内的TPC绝大数benchmark结果都要求是公开可测的,是公开发布的产品版本。此外TPC对哪些特殊优化是允许还是不允许都有要求,传统数据库厂商也都曾针对这些benchmark做了很多有针对性的优化,而个别优化无法在系统中默认打开,需要开关控制,而这样的特殊优化是不能被TPC认可接受的,所以听说也曾经出现过个别传统数据库厂商不得不撤回并重新发表某个TPC结果。回到大型分布式的数据库系统,审计师现在一般不会直接登录来亲自测试验证产品,往往会审查测试流程和脚本,并让各个厂商自己提供证明,这些证明包括测试流程的审计日志,测试结果,正式版本的证明,所用硬件系统的价格证明,公开发售或提供服务(云产品)的证明等。有些时候这些证明并不能完全被证实,所以每次结果发布后,会有三个月的公示期,来让公众(包括竞争对手)来验证。但是对于超大集群的测试结果,一般很少有人会有资源去验证的,而对于云上产品,各个厂商也可以有方法来规避限制。所以总体来说,这个结果的可信度从技术角度一般没有问题,但从TPC公开可测产品的要求来看,有时又无法完全保证。

再来看看TPC-DS。这项基准测试的第一家“上榜”厂商是国内星环,这也是TPC-DS基准推出后做的第一次官方审计测试,所以当时其实是星环帮助TPC一起解决了很多审计流程细节问题,这也是为什么星环当年的审计花费了很长时间。之后的阿里云的Cloud AnalyticDB和Cloud E-MapReduce两个产品,得益于星环审计结果的公开测试脚本和文档,在测试流程上可以少走一些弯路。这里也八卦一下,听说阿里云这两个产品有内部竞争所以在TPC-DS上时有PK,两年内多次的审计测试让TPC-DS的第三方审计公司这两年的业务非常红火,中国公司对于打榜的热情应该着实让TPC和其审计组织感动,据说每次审计的费用不菲,想来这也让审计公司这两年的业务更繁忙收益更好了,甚至听说很多时候要提前很久来预约审计师的档期时间。

3.云时代我们还要刷榜TPC吗?

目前为止,我们看到TPC-DS的测试成绩列表上基本上都是被中国公司占据,而国外特别是美国公司很少,这里面有不同的原因。首先像AWS Redshift,其TPC-DS默认开箱性能就非常优秀了,而且其产品本身的市场知名度和地位,不需要再借助TPC-DS来宣传,就像传统数据库厂商已经很少去搞审计测试TPC-H这件事一样了。而像Snowflake这样的新兴云数仓厂商,之前一直对于被公开(特别是被竞争对手)测试非常敏感,其TPC-DS性能一直比较“神秘”,期待以后可以看到其标准审计结果数据。国内某厂商据说在2019年也曾经联系TPC来做审计,但由于上了美国实体限制名单,TPC只得退回其审计费用没有再继续。所以现在除了阿里云的两个产品外,后来星环和华三也分别做过审计测试,其结果在TPC官网上都可以看到,其中星环第二次提交的成绩还是非常不错的,超过了阿里云两款产品第一次“刷榜”的成绩,但最近有一年的时间没有再看到阿里云这两个产品发表最新结果了。在某中文自媒体对OceanBase产品负责人的采访文章中,文章作者也很期待OceanBase的TPC-DS审计结果发表,不知道是不是会再次掀起阿里云和OceanBase以及其它国内数据库“新势力”的新一轮“刷榜”热情,让我们拭目以待。

最后再来看TPC-C,这个基准测试的难度和“含金量”笔者个人认为要远高于TPC-H,这是真正衡量一个TP系统的综合能力。但是和TPC-H一样,大多数传统数据库厂商因为各种原因已经几乎不再审计和发表这项基准测试的结果了,更多的是一些设备商或集成商。而传统厂商不再“刷榜”的另一个原因是其架构的扩展性达到相对瓶颈了,而这也是OceanBase可以利用其水平扩展的能力来“称霸”榜首的一个重要原因。

好了,笔者今天就简单地随想随写了一些关于TPC的事情,个人认为,TPC-H打榜有意义,但从技术上来看意义有限,而TPC-C和TPC-DS相对的技术挑战会更高一些。另一方面,现在国内新兴数据库技术及产品越来越多,作为国家重点发展的基础系统软件,对于中国的数据库技术发展是非常好的一件事,但我们也要看到数据库技术需要长期的积累沉淀和创新,要小心不要为了打榜出名而打榜,造成国内厂商的“打榜内卷”,而是真正能研发出对国家对民生有实际意义和技术突破的新技术新产品。

References:

[1]TPC,"TPC-H official results," [Online]. Available: http://tpc.org/tpch/results/tpch_last_ten_results5.asp?version=3 .

[2]T. N. a. O. E. Peter Boncz, "TPC-H Analyzed: Hidden Messages and Lessons Learned from an Influential Benchmark," [Online]. Available: https://homepages.cwi.nl/~boncz/snb-challenge/chokepoints-tpctc.pdf.

本文转载自微信公众号「杨建荣的学习笔记」,可以通过以下二维码关注。转载本文请联系杨建荣的学习笔记公众号。

 

责任编辑:武晓燕 来源: 杨建荣的学习笔记
相关推荐

2022-05-23 08:34:08

微前端微服务开发

2022-04-14 11:50:39

函数组件hook

2013-01-11 16:05:41

求职招聘

2021-05-10 08:58:09

Harbor架构Registry 服务

2021-01-13 11:11:29

TCP连接耗时网络协议

2022-06-02 08:42:15

Redis数据库

2020-09-17 13:43:03

等保2.0网络安全漏洞

2018-04-24 09:05:09

容器存储接口

2021-03-02 11:06:17

工业互联网

2019-10-30 14:31:47

Vue 3.0数组响应

2022-03-03 08:01:41

阻塞与非阻塞同步与异步Netty

2011-02-25 14:35:00

2018-09-26 06:50:19

2022-02-08 17:39:04

MySQL服务器存储

2013-12-26 14:23:03

定位系统GPS监测

2021-06-09 13:28:40

密码安全身份认证数据安全

2017-06-02 17:15:20

2022-03-04 08:10:35

NettyIO模型Reactor

2017-10-17 18:06:08

2016-03-02 09:34:03

runtime消息ios开发
点赞
收藏

51CTO技术栈公众号