从具体的案例看时间序列数据的存储问题

业内人应该都知道,Time Series Database 是近几年随着物联网等技术的发展才逐渐流行起来的,在此之前,各行各业的企业可选的数据库方案都十分有限,以车联网企业为例,行业中最普遍的选择就是 MongoDB、HBase 一类的传统大数据解决方案。

但随着业务的发展,大量的时间序列数据产生了,这些企业或多或少都遭遇了数据架构危机,甚至阻碍了业务的发展,不得不考虑进行数据架构的迭代和迁移。下文将从 MySQL、MongoDB、HBase 三个 database 维度列举企业案例,进行说明。

MySQL

在柳工的工业车联网应用 LiuGong iLink 中,由于应用层不合理的复杂查询和历史数据的高频写入,导致 MySQL 处理速度缓慢,甚至容易宕机,严重影响用户体验。在分析原因后,他们得出了一个结论:关系型数据库并不适用于存储海量的时间序列数据,在海量数据聚合计算、抽稀等业务中效率很低。从这个结论出发,他们开始针对 Time Series Database 进行选型。

由于其业务场景与 TDengine 的“一个设备采集点一张表”的理念十分吻合,且 TDengine 可以支持对大数据进行聚合和降采样查询等操作,能够经有效改善 MySQL 的数据痛点问题,又经过严谨的调研和测试,最终他们决定迁移至 TDengine。
以一个真实场景看一下迁移效果:在替换 TDengine 之前,该项目每天都有一些业务报表需要展示,每一小时需统计一次下一个时区内所有设备产生的 时间序列数据,这个流程在 MySQL 中经常需要耗时1小时以上,无法正常执行后续业务。而换到 TDengine 后,整个出表流程只需要 10 秒左右。

查询对比如下图所示:

TDengine Database

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

MongoDB & HBase

对于这两大数据库的应用坑点,零跑汽车可以说是相当有发言权了。作为一家典型的新能源车企,零跑汽车在时间序列数据的存储选择上一直都是 MongoDB 和 HBase,随着业务的加速扩张,出现了写入速度太慢、支撑成本过高等问题。

用 MongoDB 存储时间序列数据会全部存储在内存中,过高的存储成本导致只能存储一段时间内的数据,且存储的数据格式需要经过业务组织处理,不仅业务变更不灵活,可以做的业务也非常有限,而 HBase 本身就是一个很重的数据库,搭建 HBase 需要整套 HDFS 做支撑,使用、运维、人力等成本都很高。

在应用 TDengine 进行架构升级后,压缩性能直接提升了 10 到 20 倍,降低存储压力的同时解决了时间序列数据存储成本高的问题,也解决了以前 HBase 入库不及时的问题,可以用更少的服务器资源入库更多的时间序列数据,节省更多成本。同时业务灵活性也有了极大提升,不用再像 MongoDB 一样,在查询前还需要根据业务加工出需求数据,TDengine 的列式存储,直接以 SQL 计算即可。

诸多企业实践证明,如果你面对的也是时间序列数据的处理场景,Time Series Database 才是最正确、最合理的选择。