tiflash 怎么调优,我这个建表是最佳方式吗?

我想测试下tiflash的性能,版本v5.3,目前有四台机器,每台16核,64G内存。具体拓扑如下图:

表里有3亿数据,目前开启配置参数如下:

set @@session.tidb_allow_mpp=1;
set @@session.tidb_isolation_read_engines = "tiflash";
set @@tidb_mem_quota_query = 20 << 30;
set @@tidb_distsql_scan_concurrency = 15;
set @@tidb_opt_distinct_agg_push_down = 1;
set @@tidb_opt_agg_push_down = 1;
set @@tidb_allow_batch_cop = 1;

【建表语句】
powercurve_guard:每一个月做一个分区,数据每10分钟一条。

CREATE TABLE IF NOT EXISTS doris.powercurve_guard
(
  `wtid` INT NOT NULL,
  `wfid` INT NOT NULL,
  `windspeedarea` SMALLINT NOT NULL COMMENT '风速区间',
  `dimday` DATE NOT NULL,
  `dimmonth` DATE NOT NULL,
  `dimyear` SMALLINT NOT NULL,
  `starttime` DATETIME NOT NULL COMMENT '发生时间',
  `windspeed` DECIMAL(4,2) NOT NULL COMMENT '风速',
  `tbpower` DECIMAL(8,2) NOT NULL COMMENT '理论功率',
  `guardpower` DECIMAL(8,2) NOT NULL COMMENT '担保功率',
  `powergap` DECIMAL(8,2) NOT NULL COMMENT '担保功率-理论功率',
  `localwindspeed` DECIMAL(4,2) NOT NULL COMMENT '本地风速',
  `localpower` DECIMAL(6,2) NOT NULL COMMENT '本地理论功率',
  `stdwindspeed` DECIMAL(4,2) NOT NULL COMMENT '标准风速',
  `stdpower` DECIMAL(6,2) NOT NULL COMMENT '标准理论功率',
  `powersum` DECIMAL(12,2) NOT NULL COMMENT '理论功率合计',
  `guardpowersum` DECIMAL(12,2) NOT NULL COMMENT '担保功率合计',
  `powercount` INT NOT NULL DEFAULT '1',
  UNIQUE KEY (`wtid`, `starttime`)
)
PARTITION BY RANGE(to_days(starttime))
(
PARTITION p201712 VALUES LESS THAN (to_days('2018-01-01 00:00:00')),
PARTITION p201801 VALUES LESS THAN (to_days('2018-02-01 00:00:00')),
...
PARTITION p202112 VALUES LESS THAN (to_days('2022-01-01 00:00:00'))
);

【相关说明】
powercurve_guard 表 ,开启同步tiflash,并创建了1个副本。

【测试SQL】
2018-01-01 到 2018-02-05 大概1000万数据量,
2018-01-01 到 2019-01-01 大概一亿数据量
由于查询条件是一亿太慢,改为1000万测试

-- Q2.1 查询列
SELECT wtid, wfid, windspeedarea
FROM powercurve_guard
WHERE starttime >= '2018-01-01 00:00:00' and starttime <'2018-02-05 00:00:00'
ORDER BY wtid, wfid, windspeedarea;

-- Q5.2 2个AVG函数
SELECT wtid, wfid, windspeedarea , AVG(powergap) avg1, AVG(guardpower) avg2
FROM powercurve_guard
WHERE starttime >= '2018-01-01 00:00:00' and starttime <'2018-02-05 00:00:00'
GROUP BY wtid, wfid, windspeedarea
ORDER BY wtid, wfid, windspeedarea;

-- Q5.3 4个AVG函数
SELECT wtid, wfid, windspeedarea , AVG(powergap) avg1, AVG(guardpower) avg2, AVG(localpower) avg3, AVG(tbpower) avg4
FROM powercurve_guard
WHERE starttime >= '2018-01-01 00:00:00' and starttime <'2018-02-05 00:00:00'
GROUP BY wtid, wfid, windspeedarea
ORDER BY wtid, wfid, windspeedarea;

【执行计划】

见附件

Q2.1执行计划.html (2.9 KB)
Q5.2执行计划.html (7.1 KB)
Q5.3执行计划.html (6.8 KB)

【我的疑问】

  1. Q2.1 查询多列,返回1000万数据,耗时很长,是否正常?

  2. Q5.2 耗时2秒,但是Q5.3耗时22秒,差距很大,两条sql返回数据条数都是一致的

  3. 目前powercurve_guard表只有一个副本,是不是3个副本会更快点?

  4. 我这种部署方式tikv和tiflash在同一台服务器上,实际更多的是AP业务,而且tikv可以只部署一个实例吗?

  5. tidb_distsql_scan_concurrency 并行多少合适呢?

1赞
  1. 麻烦提供一下 3 个查询的 explain analyze 的结果。
  2. 2018-01-01 到 2019-01-01 大概一亿数据量 ,Q2.1 的查询 where 条件是 1 个月左右也是 1 亿数据嘛?基于 Q2.1 的场景如果行存这边有 starttime,wtid , wfid , windspeedarea 的索引的话应该能够加速。
  3. 多个 Tiflash 使用 mpp 会有提升。

已上传执行计划

我说的意思是,要保持比较高的统计信息健康度,这样,执行计划会更好的选择合适的方式去执行sql。如果表的健康度很低,执行计划可能会选择比较慢的方式去执行sql,比如不走索引。
tikv必须得是三个以上的。
image
你的执行计划里面显示,统计信息过期了。可以用 ANALYZE TABLE 加表名来重新收集一下
https://docs.pingcap.com/zh/tidb/stable/sql-statement-analyze-table/#analyze

我直接设置了用tiflash ,因为我想做ap查询测试

虽然你可以强制使用tiflash,但是统计信息不准确的话,会影响算子的选择。从执行计划看,5.3先TableReader扫描(效率非常低),然后再做的聚合,所以慢。5.2是先聚合,再TableReader扫描,扫描的数量少,速度快

1、读取千万数据返回客户端会耗时很长、正常,应用一般就是分页取数
2、虽然返回数据一致,但是Q5.3返回更多的列和更多的计算在tidb节点完成,所需时间更长
3、分区表用不到MPP
4、TiKV是多副本raft协议,tiflash只是learner不参与投票只是异步同步数据,TiKV目前必须3个实例以上
5、调优建议里面建议80 https://docs.pingcap.com/zh/tidb/stable/tune-tiflash-performance/#tidb-相关参数调优

  1. 分区表用不到MPP
    这个不知道新版是不是已经支持了
  2. 80并发度
    这个是建立在cpu 核总数上的吧

使用了 analyze 语法,确实 提升了速度,顺便问下 ,这个并发度 怎么选择,还有tiflash副本的建议

并发度这块,我没有太好的建议。
对于tiflash的副本建议,我个人觉得一副本就够了

确实,并发度 我改为1 也测试了下,相差不是很大

可能是因为你的sql的并发太小了。你可以写个脚本,疯狂执行sql,再试试

我设置的是tidb_distsql_scan_concurrency这个参数
https://docs.pingcap.com/zh/tidb/stable/tune-tiflash-performance/#tidb-相关参数调优