【问题描述】:
TiDB开窗函数,如lead,lag函数,执行缓慢。我是用三台阿里云服务器测试的,每台节点8核32G。数据源表的数据量在500w左右,SQL的执行时间达到了1分钟,不满足我们的实时需求所要求的时效性了。我希望能降调秒级。正常如果不开窗,仅仅是做聚合,排序的话,时间在几秒钟左右。
以及,是否TiDB已经对lag,lead,row_number等开窗函数作了优化?或者以后会做优化吗?或者我可以调整什么参数来解决这个问题?
sql:
select
lead(a.is_circle, 1, 0) over (partition by a.hp_date, a.guid order by a.createtime, a.opentime) as next_status,
lag(a.is_circle, 1, 0) over (partition by a.hp_date, a.guid order by a.createtime, a.opentime) as last_status
from (
select hp_stat_date,
guid,
opentime,
createtime,
id
from db_test.web_log – 500w 数据量
where hp_stat_date = to_date(now())
) a
) a
order by 去掉的话,目前看就不太符合业务逻辑了。我试试改写下SQL。
请问能不能通过水平扩展节点,以及加资源的方式来加速执行呢?我目前只是测试,是在3台阿里云服务器上,8核32G,而且tidb,tikv,tispark,tiflash都部署在这三台节点的同一目录下。
如果生产集群优化的话,我可能会部署5台左右的节点。请问是tidb,tikv分界点部署呢,还是可以部署同一个节点,但是不同的磁盘?
目前延迟时间长的地方是在单个 tidb server 的 order by 排序的计算上面,因为数据量比较大,所以 order by 时间会很长。但通过增加水平扩展是不能加速的。如果可以尝试 tidb server 升配, 8 core 32 GB 调整为 16 core 32 GB,看看是否可以增加处理速度。
好的,还想请教下。
1、我之前测的SQL,做group by 和order by都挺快的,为什么开窗函数里面的order by 和partition by这么慢呢?同样都是几百万的数据量。
2、order by 排序是把数据全部汇总到tidb节点来排序的吗?还是会在tikv做一下预排序? 开窗的排序,是不是因为窗口特别多,所以要做很多次排序?
3、如果使用tispark来完成lead和lag这些开创操作的话,会不会比tidb要快?