出表流程从 1 小时到 10 秒,TDengine 在柳工车联网应用中替换 MySQL

小 T 导读:在柳工的工业车联网应用 LiuGong iLink 中,由于应用层不合理的复杂查询和历史数据的高频写入,导致 MySQL 处理速度缓慢,甚至容易宕机,严重影响了用户体验。在此背景下,柳工决定改用 TDengine Database 来处理时序数据,本文分享了他们的改进效果与实践经验。

企业简介

广西柳工机械股份有限公司是中国制造业 500 强企业——柳工集团的核心企业。作为国内工程机械行业和广西第一家上市公司,柳工被誉为“中国工程机械行业的排头兵”,在全球拥有 20 多个制造基地、17000 多名员工、5 个研发基地,产品遍布 170 多个国家和地区。

项目介绍

LiuGong iLink 是柳工面向国际市场业务的一个工业车联网应用,包含 Web 端和 App 端。它可以让用户看到所有车辆设备的实时动态,例如在哪里工作、何时工作以及如何工作,也可以实现设备的远程监控,以便更有效地实施服务和维护计划。

此前,我们使用 MySQL 数据库承载了包括应用层和接入解析层的大多数业务,但由于应用层不合理的复杂查询和历史数据的高频写入,给 MySQL 造成了非常大的压力,导致其处理速度缓慢,甚至容易宕机,严重影响了用户体验。究其原因,还是因为关系型数据库并不适用于存储海量的时序数据,在海量数据聚合计算、抽稀等业务中效率很低。

为解决上述问题,我们选择以专用的时序数据库(Time-Series Database)存储处理时序数据,这样可以大大增加整个系统的吞吐能力。经过调研,我们选择了时序数据库 TDengine,原因在于,我们的业务场景与 TDengine 的“一个设备采集点一张表”的理念十分吻合,而且 TDengine 可以支持对大数据进行聚合和降采样查询这些特性,也恰好可以解决上述技术痛点。

从真实环境出发,TDengine 的写入、查询、存储效果如何?

分析架构可知,数据采集来源主要是 TBOX 等设备,通过解析层解析为 JSON 后发往 Kafka,再通过入库程序消费写入到 TDengine Database 中。

我们落地使用的是 TDengine2.4.0.16 版本,单副本模式,只用了一台 4 核 8GB+1TB 的服务器就撑起了服务,当前磁盘占用约 110G。

当前,库中总表数量达到了 55701 张,秉承着“一个采集点一张表”的原则,我们选择不同维度,共建立了 21 张超级表,如:车辆类型,设备类型,数据类型。当前总数据量大概为 4-5 亿行左右,写入规模大概是每台车每 5 分钟上报一次,TDengine 可以轻松抗住这个级别的写入。

TDengine Database

在查询方面,我们通过封装 API 的方式,可以便捷地提供查询服务,这也是针对我们业务痛点改进最为明显的地方。在决定对 MySQL 进行替换时,我们做了充分的查询对比测试。

数据库查询测试

如上图所示表格中的 API 分别代表了查询 mcu 历史数据、查询 TBOX 历史数据、查询设备轨迹、查询设备故障历史数据四个功能。可以看到,面对大批量的数据,TDengine 的查询能力是远远超过 MySQL 的。

再分享一个真实场景:在替换TDengine之前,我们每天都有一些业务报表需要展示,每一小时需统计一次下一个时区内所有设备的数据,这个流程在 MySQL 中经常需要耗时1小时以上,无法正常执行后续业务。而换到TDengine后,整个出表流程只需要10 秒左右。

实际应用时遇到的问题与经验分享

列数很多

从上图中可以看到,我们每类设备的采集点位(列数)是比较多的,动辄破百,这也给我们带来了一个潜在的问题——间接地影响了压缩率,这是后来在和 TDengine 官方人员排查别的问题时发现的。

后来我们了解到了产生此问题的原因:由于 TDengine 中的每个 Vnode 都有一块自己的缓冲区,大小由 cache * blocks 的值决定(单位 MB)。每当写满三分之一时就会触发数据落盘,并在落盘时完成压缩。列宽带来的影响是单行长度过大,每次写满三分之一的时候,并不需要多少行数据,由于样本太少,所以数据并不能很好的压缩。

通过 selct _block_dist() from 超级表的方式查看数据块的分布,可以看到小块 SmallBlocks 相当之多,在 99% 以上。

smallblock

我们的解决方案就是通过放大 blocks 参数(默认为 6),来缓解后续新数据的压缩。至于历史数据,我们计划使用 TDengine Database 提供的重整数据碎片的压缩功能来完成。

具体到操作上是比较简单的,备份数据文件后,使用 compact vgroups in (3,4,5,6) 即可(数字为 Vgroup ID)。但由于重整的过程中会对写入有一定的影响,所以我们需要选择在业务休整期来完成这个操作。这个时间点可能会在 TDengine 3.0 发布后,届时我们可以对现有场景再度完成一次质变级别的升级。

写在最后

目前,我们还在规划车辆维保相关的项目,通过车辆实时设备产生报警,提高车辆使用时长和安全率。聚焦“智慧”“电动”“智能”等关键词,柳工向世界伙伴们展示了各个行业的解决方案,未来我们也会和 TDengine 产生更多深层次的互动。