大数据量下的分组聚合导致db节点内存耗光,无法提供服务

为提高效率,提问时请提供以下信息,问题描述清晰可优先响应。

  • 【TiDB 版本】:tidb 3.0 GA
  • 【问题描述】:

1.针对大数据量数据的分组、聚合 导致db节点内存耗光,引起db节点不能正常提供服务。 2.具体描述如下

  • 2.1 参数计算的数据量

参与计算的数据量为1500万。

  • 2.2 计算的sql

SELECT concat(BillID,concat(’-’,DATE_FORMAT(CONVERT_TZ(UptTime,’+00:00’,’+8:00’),’%Y%m%d%H%i’))) as rowkey, DATE_FORMAT(CONVERT_TZ(UptTime,’+00:00’,’+8:00’),’%Y%m%d%H%i’) as UptTime , BillID , max(VIN) as VIN , DATE_FORMAT(CONVERT_TZ(UptTime,’+00:00’,’+8:00’),’%Y%m%d’) as RptDate , case max(StartTime) when ‘0001-01-01 00:00:00’ then ‘2000-01-01 00:00:00’ else DATE_FORMAT(max(StartTime),’%Y-%m-%d %H:%i:%s’) end as StartTime , max(CtrlAddress) as CtrlAddress , max(CanSN) as CanSN , max(CityCode) as CityCode , max(CityName) as CityName , max(StationId) as StationId , max(DirectPower) as DirectPower , max(DemandVoltage) as DemandVoltage , max(DemandCurrent) as DemandCurrent , max(DirectVoltage) as DirectVoltage , max(DirectCurrent) as DirectCurrent , max(SOC)*100 as SOC , max(HighestVoltage) as HighestVoltage , max(LowestVoltage) as LowestVoltage , max(HighestTemperature) as HighestTemperature , max(LowestTemperature) as LowestTemperature , max(Power) as Power , max(MinutePower) as MinutePower , max(V3RemainTime) as V3RemainTime , max(BdpRemainTime) as BdpRemainTime , max(StaType) as StaType , max(StaTypeNames) as StaTypeNames , max(PileQuickType) as PileQuickType , max(PileQuickName) as PileQuickName , max(OperType) as OperType , max(OperTypeName) as OperTypeName , max(Industry) as Industry , max(IndustryName) as IndustryName , max(BillInitElectricMeter) as BillInitElectricMeter , max(CurrentElectricMeter) as CurrentElectricMeter FROM ETL_SingleCharging

WHERE upttime>=DATE_FORMAT(DATE_ADD(current_date(),INTERVAL -2 DAY),’%Y-%m-%d 16:00:00’) AND upttime<DATE_FORMAT(DATE_ADD(current_date(),INTERVAL -1 DAY),’%Y-%m-%d 16:00:00’) group by BillID,UptTime

2.3 问题

tidb节点内存耗光。

2.4 疑问 1.针对这种大数据量的分组聚合,所有的数据从各个节点,汇总到db节点,然后在分组聚合,这种是无法使用分布式资源, 这种情况应该如何处理

可以 explain 一下这条 SQL 看一下执行计划吗?

这条SQL应该是可以在 TiKV 分担一些计算的。最终的数据集是不是很大呢?

这个最后的数据集合1500万左右

看这个执行计划 group by 需要在 TiKV 先进行过滤,group by 然后在 TiDB 节点再对接收到的数据再经过一次group by 。 这个 SQL 是单独执行一条的时候就会导致 OOM吗?

这个sql 我执行limit 1000 没有问题。感觉和突变似的,使用内存突然达到了40多个G,以前没有使用这么大, 和这个表删除数据有关系吗

limit 1000 数据量小,,在 tikv 层就limit 过滤了,内存不会用那么大,最后的数据结果 1500w 是结果有 1500w行? 那数据还是很大的。

是的,对于这种需要分组的sql,目前这种架构是不是必须需要到db节点进行分组聚合对吧

不是全部传到 tidb 节点计算的,执行计划中 task 中 cop 类型的那一步就是在 TiKV 节点去计算的。但是 group by 这种sql 在 TiKV 算完之后,最终还是要在 TiDB 节点做计算的。