大数据量下的分组聚合导致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 节点做计算的。