【数据库】TiDB 5.3 TPCH 100G测试及思考

一、环境

tpc-H 100G数据 2.8版本
22个场景sql：
<https://github.com/pingcap/tidb-bench/tree/master/tpch/queries>

官方：

节点数量：3
CPU：Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz，40 核
内存：189 GB
磁盘：NVMe 3TB * 2

华为云：

kc1.4xlarge.4
节点数量：6
CPU：16vCPUs（kunpeng 920）
内存：64 GB
磁盘：极速SSD（fio bs=1M job=10 w=8783MiB/s,8782 IOPS）
布局：tikv和tiflash同一主机*3，tidb和pd在同一主机*3，绑2node

普通SSD：

TaiShan
节点数量：6
CPU：128 CPU（kunpeng 920）
内存：512 GB
磁盘：普通SSD（fio bs=16k w=250MB/s）
布局：
1、每台主机4块数据SSD，共同加到一个tiflash中
2、24*TiDB，3*PD，24Tikv，6Tiflash，每个server端单独绑一个node（一个node 32CPU）

二、参数设置

tiup cluster edit-config t1
tiflash：
   profiles.default.max_memory_usage = 10000000000000

set global tidb_allow_mpp=1;
set @@tidb_isolation_read_engines='tiflash';
set @@tidb_mem_quota_query = 10 << 30;

因为tidb_isolation_read_engines只能session级别，通过mysql客户端登陆调用本地脚本方式执行
mysql -h127.0.0.1 -uroot -P4000 -D tpch <<!
\\. 1.sql
!
执行多次，直到sql执行时间趋于稳定

三、测试结果

	官方数据	华为云3副本Tiflash	华为云3副本tikv+tiflash	普通SSD 6副本tikv+tiflash
Q1	8.08	6.6		1.68
Q2	2.53	2.48		3.09
Q3	4.84	4.649		15.76
Q4	10.94	5.589	19.1	8.27
Q5	12.27	11.02		6.97
Q6	1.32	1		0.55
Q7	5.91	4.0666		7.59
Q8	6.71	7.1		14.91
Q9	44.19	30.334		12.87
Q10	7.13	4.4		41.04
Q11	2.18	1.771		3.03
Q12	2.88	2.885		2.47
Q13	6.84	4.9		72.62
Q14	1.69	1.5		1.51
Q15	3.29	2.5-2.7	2.5-2.9	13.75
Q16	5.04	1.1		2.07
Q17	11.7	7.9		24.89
Q18	12.87	11.1		14.17
Q19	4.75	3.05		1.38
Q20	8.89	2.4		24.62
Q21	24.44	12.4		15.47
Q22	1.23	1.167		1.4

四、结果说明及一些猜想

Q4：

select
	o_orderpriority,count(*) as order_count
from
	orders
where
	o_orderdate >= '1995-01-01'
	and o_orderdate < date_add('1995-01-01', interval '3' month)
	and exists (
		select * from lineitem
		where 
      l_orderkey = o_orderkey 
      and l_commitdate < l_receiptdate
	)
group by o_orderpriority
order by o_orderpriority;

tiflash：5.589s
tikv+tiflash+tidb（默认配置）：19.1s

explain analyze执行计划，默认配置下表lineitem走了cache：

Selection_24(Probe)          | 3.98         | 14185840  | cop[tikv]    |                                             |time:5m56.6s, **loops:16883**, 
cop_task: {num: 3827, max: 697.5ms, min: 585.8µs, avg: 133ms, p95: 340ms, max_proc_keys: 17867, p95_proc_keys: 15901, tot_proc: 7m13.6s, tot_wait: 1m6.1s, rpc_num: 3827, rpc_time: 8m29s, copr_cache_hit_ratio: 0.24}, tikv_task:{proc max:530ms, min:0s, p80:180ms, p95:280ms, iters:39261, tasks:3827}, scan_detail: {total_process_keys: 21217578, total_process_keys_size: 4216268171, total_keys: 25622316, rocksdb: {delete_skipped_count: 0, key_skipped_count: 20513898, 
block: {**cache_hit_count: 32099284, read_count: 1750183, read_byte: 29.1 GB**}}}   
| lt(tpch.lineitem.l_commitdate, tpch.lineitem.l_receiptdate)
 

在强制tiflash下，优化器重组了sql，两张表直接做hashjoin

HashJoin_42 | 4471364.76 | batchCop[tiflash] || semi join, equal:[eq(tpch.orders.o_orderkey, tpch.lineitem.l_orderkey)]

一些猜想：

1、TiDB优化器中cache hit权重更高？
2、TiDB优化器之后是否会像Oracle加入硬件性能参数计算代价？（参考aux_stats$）

Q9：

tiflash和tikv+tiflash差距不大；表supplier在tikv中走的点查，非常快
耗时上，默认配置总时间更短

其他：

AP还是看存储，多盘在某些场景下貌似不能弥补性能上的差距