简介:本文部分 TPC 观点,使用 ChatGPT 生成。拉到最后,可扫码入群体验与 ChatGPT 机器人对话
阿里巴巴的 OceanBase 数据库,性能超过 Oracle 100倍,号称世界第一。大家可还记得年年的 OB 打榜赛?
阿里 OceanBase 数据库又拿下世界第一,性能超越Oracle 23 倍!
不论真假,我还是对衡量标准,很感兴趣。尤其是数据仓库的标准TPC-H.
TPC-H测试标准,以8张表,22个查询作为基础,在一定时间内(通常是1小时),通过7个并发查询,衡量数据库的每秒处理事务数,作为数据库性能度量标准。用一个公式来描述整个过程,就是 QphH@Size.
2018 年,惠普使用 microsoft sql server on linux 作为测试对象,向 TPC 组织, 提交了一次TPC-H性能报告。
在1T的数据量下,花费近47万美金,达到了每小时100万的查询数,即每秒可完成280查询。公式表达,1009065.5 QphH@1000GB.
后台回复:惠普,即可得这份《报告》以及相应的表和查询脚本
当然,这还没考虑到查询性能的可接受程度,以27.6s这样的平均速,其实很多用户是会不满意的。
image
这份报告虽然说明一定的问题,比如 Throughput 度量,性价比,但缺少对服务器的性能监控。比如7个并发,1小时连续压测下,服务器的性能监控图。
再者,数据库的最终吞吐量,是否可以再扩大,也没有具体说明白。如果降低并发,是不是能够获得较好的性能?
为了模拟惠普的这次测试,我通读了TPC-H的测试标准,惠普的这份测试报告,还有几篇来自维普的论文。最终找到了模拟的方法。
以下是详细的测试步骤:
1)下载 HammerDB 软件 2)准备 SQL Server 测试环境 3)复现 Power Test 4) 复现 Throughput Test
1) 下载 HammerDB
解压缩后,直接打开,就可以使用
image
2)准备 SQL Server 测试环境
这就要自己准备了,到微软的官方网站下载180天的试用版,即可
3)复现 Power Test
由于这次模拟的是 SQL Server TPC-H 测试标准,所以在 HammerDB 中,我们需要预先配置:
第一次打开 HammerDB 是这样的,以 Oracle TPC-C 为默认选中状态:
image
通过菜单 Options, 配置 SQL Server TPC-H 测试标准:
image
image
在 TPC-H 整套测试方案中,指定了8张表,22个查询,配备相应的数据生成程序与查询生成程序,但这两个程序都是使用c/c++写的,必须先通过编译,再通过调用接口来用在自己的测试方案中,我尝试了下,放弃!不仅源码复杂,有些环境还需要额外配置。
在搜索了 n 篇论文以及博文之后,我发现 HammerDB 已经替我们把这些环境配置都搞定了,于是就它了。
有了 HammerDB,我们唯一要做的事情,就是指定一个可用的测试数据库就可以。
image
这里需要说明的是 Scale Factor,也就是扩展因子。说人话,就是数据库大小配置。总共可以分为6级,1GB,10GB,30GB,100GB,300GB,1000GB.
那么既然是自己测试,选择1,即1GB,就可以了
image
点一下 Build,就完成了数据库环境配置。
通过 SQL Server Profiler, 我们可以看到数据库正在发生的一切:
image
通过 HammerDB 的Build界面,可以看到执行状态:
image
当然,时间会很久,我们可以去喝一杯咖啡再来,HammerDB会自动报告,数据装载是否完成:
image
由于装载时间非常长,所以一旦数据库建立成功,我们就要对它进行备份:
image
接下来,我们就要试着运行一次 Power Test:
首先配置 Driver Script:
image
Driver Script 做的事情,就是为测试中的虚拟用户,配置执行的操作。比如配置一组22个查询组成的查询流,让虚拟用户在登录数据库,依次执行这22个查询。
配置完 Driver Script, 我们就可以生成指定数量的并发用户。这些用户,可以执行刚才配置的 Driver Script.
Power Test 测试目的,是察看是否有明显的响应时间缺陷,所以设置单个用户:
image
一旦配置完成,就可以双击 Create 来生成虚拟用户的配置信息:
image
接着,我们点击运行单用户的单次执行:
image
耐心等待测试完成:
image
单轮测试用了124秒,似乎不够理想。但这是我可怜的笔记本虚拟机服务器啊。
然后,肯定会有读者说,这是数据仓库啊,不能没有写入的操作啊。是的,这个写入,我们也可以模拟,通过开启 Refresh Function:
image
然后再重复新建用户,并开启测试。
4)复现 Throughput Testing
Throughput 是吞吐量的意思,这个概念很有意思。
首先来说说并发用户。当同时有10个用户访问数据库时,假设他们同时执行1条 SELECT 语句。此时,并发数是10,Throughput 也是10,但你能不能说数据库并发度不够呢?不能。因为此时这并发的10个用户,都对速度感到满意,说明完全可以再容纳更多的人来数据库查询。
于是,增加了100个人来,还是运行 一条SELECT语句。那么此时,如果大家还是对响应很满意,说明数据库非常棒,还可以吸纳更多的人。
好,加20倍流量,来了200人。于是,有用户反映,速度慢了,明显慢了一倍以上,当有50%的人都说慢了的时候,显然数据库的吞吐量,要小于 200.
我们往下调调,来150人吧。此时90%以上的人,对速度满意,那么就可以说,数据库的吞吐量在 150左右了。
这,就是 TPC-H 测试标准报告中,要体现的内容了。不过,人家更标准,使用的是 QphH@Size.
所以,我们要使用 hammerDB来模拟这个操作:
首先设置4个并发用户,第一个用户会模拟写入的操作:
image
开启 QphH@Size 的统计功能:
image
等待测试完成
image
理论上,测试时间越长,测试的准确度越高,但我们只是模拟,所以运行一组 Query Set, 让 HammerDB 帮我们预估就可以了:
image
image
image
image
可以看到,4个并发测试下来,大概可以得到每小时近20000个事务处理。也就是每秒钟处理6个事务。
那么是不是 Throughput 为6,就是我的数据库极限了呢,我怀疑,可以更高。于是我调高了用户并发数,加了2个,再来看 QphH:
image
image
发现,最高的 QphH 虽然比4个用户那次高,但明显已经影响了用户的响应时间,普遍从原来的100s 延长到了160s 以上。说明,已经不能再增加并发查询了,6事务/秒已经是我这台数据库的极限。
很可惜的是,HammerDB 并不能动态增加用户数,导致测试不流畅,不得不说是个遗憾。我看到 oracle 厂商在 demo 他们的系统时,并发用户数,是动态可加的,想加就加,相减就减,操作随意地令人发指。提高了测试的准确度。
说Oracle是世界,乃至宇宙第一,还不得不服。
以上是 TPC-H 即数据仓库类的测试实验。TPC-C 即 OLTP 类的测试,又有哪些不同的知识点呢?作为开发,我们该怎么切入 TPC-C的实验
首先,与 TPC-H 一样,先要了解 TPC-C 测试标准:
TPC-C 标准是一种用于测试数据库系统性能的标准,它定义了一个标准的数据库访问模型,用来评估数据库系统性能。TPC-C 标准定义了 9 种不同的事务类型,它们涉及到数据库中的增删改查等操作,以及数据库的其他功能,比如锁定、事务隔离等。这些事务的执行结果将被记录,以便计算数据库系统的性能指标。 ChatGPT@SAM
TPC-C 9种不同的事务类型,各有哪些?
TPC-C 标准定义的 9 种事务类型包括:
ChatGPT@SAM
TPC-C 测试的步骤有哪些?
Github 上开源的 TPC-C 测试软件有哪些
1. TPC-C Benchmark Tool;2. TPCC-MySQL;3. TPC-C-PostgreSQL;4. tpcc-mysql-extended;5. TPCC-C;6. tpcc-mysql-graphite;7. tpcc-mysql-haproxy;8. tpcc-mysql-memcached。 ChatGPT@SAM
是的,你没看错,上述问题答案,都来自我部署的一个对话机器人 SAM