业内人应该都知道，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 秒左右。
查询对比如下图所示：
参考资料：出表流程从 1 小时到 10 秒，TDengine 在柳工车联网应用中替换 MySQL
MongoDB & HBase
对于这两大数据库的应用坑点，零跑汽车可以说是相当有发言权了。作为一家典型的新能源车企，零跑汽车在时间序列数据的存储选择上一直都是 MongoDB 和 HBase，随着业务的加速扩张，出现了写入速度太慢、支撑成本过高等问题。
用 MongoDB 存储时间序列数据会全部存储在内存中，过高的存储成本导致只能存储一段时间内的数据，且存储的数据格式需要经过业务组织处理，不仅业务变更不灵活，可以做的业务也非常有限，而 HBase 本身就是一个很重的数据库，搭建 HBase 需要整套 HDFS 做支撑，使用、运维、人力等成本都很高。
在应用 TDengine 进行架构升级后，压缩性能直接提升了 10 到 20 倍，降低存储压力的同时解决了时间序列数据存储成本高的问题，也解决了以前 HBase 入库不及时的问题，可以用更少的服务器资源入库更多的时间序列数据，节省更多成本。同时业务灵活性也有了极大提升，不用再像 MongoDB 一样，在查询前还需要根据业务加工出需求数据，TDengine 的列式存储，直接以 SQL 计算即可。
诸多企业实践证明，如果你面对的也是时间序列数据的处理场景，Time Series Database 才是最正确、最合理的选择。
