后端的你，使用的数据库能撑起多少并发，有数吗？
阿里巴巴的 OceanBase 数据库，性能超过 Oracle 100倍，号称世界第一。大家可还记得今年的 OB 打榜赛？
不论真假，我还是对衡量标准，很感兴趣。尤其是数据仓库的标准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
公众号后台回复 HammerDB，即可得到 zip 版本的 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是世界，乃至宇宙第一，还不得不服。