为什么不建议你用MongoDB这类产品替代时序数据库？

小 T 导读：此前有人在某问答网站上发布了这样一个问题：既然部分时序数据库如 InfluxDB、TimescaleDB 是基于关系型、非时序数据库 PostgreSQL 开发而来，那在时序数据场景下，能否用 MySQL/MongoDB 这类数据库去代替时序数据库（Time-Series Database）使用？对于此问题，涛思数据资深研发工程师试图从原理和实践出发为同样有此疑问的朋友作出解答。

从数据库的定义来看，数据库就是一个数据管理系统，是用来存放数据文件的一个软件，它能够支持用户的添加、修改、删除、查询等操作。因此从定义上讲，时序数据库和关系/非关系型数据库是一样的，都是用来存放数据的。但因为存储的数据特点不同，这两类数据库的应用场景也不尽相同：

• 关系型数据库：主要用来存储结构化数据，使用实物保证数据一致性，使用 SQL 语言来进行查询操作。这类数据库的典型代表主要包括 MySQL、Oracle、SQL Server 等。
• 非关系型数据库：主要用来存储非结构化数据，数据可以不通过验证进行存储，使用 JSON 数据对象进行查询操作。其典型代表主要有 MongoDB、Redis 等。

而时序数据库主要用于存储实时数据，最明显的特点就是每条数据都会带有时间戳属性，在电力、石化、冶金、智能汽车、监控等领域应用较为广泛。这类 Database 的典型代表主要包括 TDengine、InfluxDB、TimescaleDB 等。下面直切主题，我们来讨论一下关系/非关系型数据库是否能替代时序数据库。

能否用关系/非关系型数据库代替时序数据库 ？

事实上，如果数据采集频率少，数据量不大的话，使用关系/非关系型数据库代替时序数据库是完全没有问题的。但如果从长远角度来看，这种做法却存在着很大的风险，具体原因还要从时序数据库的特点讲起。

时序数据具备采集频率高、数据量大、写操作为主读操作为辅、很少有更新或删除操作、却有统计聚合等实时计算操作等特点，关系/非关系型数据库很难满足这样高的性能需求。在大数据场景下，如果性能达不到要求，数据没有办法被有效存储的话，那么这样的数据库是无法代替时序数据库的。

举一个简单的例子，在相同的测试环境（16 核 64G 内存）下，以传统的关系型数据库 MySQL 和时序数据库 TDengine 为例，做一下 benchmark 的对比测试 ：

分别使用 MySQL 自带的 benchmark 工具 mysqlslap 和 TDengine 自带的 benchmark 工具taosbenchmark，设置 16 个线程，写入单表 10 万条记录，表结构为 1 个 timestamp 类型，2 个 int 类型，2 个字符串类型，测试结果如下：

MySQL——

mysqlslap -uroot -p1234 --cOncurrency=16 --number-of-queries=100000 --create-sc 
hema=tests --query="INSERT INTO meters(c0, c1, c2, c3) VALUES (RAND() * 100, RAND() * 100, uuid(), uuid())" 

TDengine——

从以上对比测试结果可以看出在同样写入 10 万条记录的情况下，MySQL 使用自带的 mysqlslap 工具需要 75 秒完成，而 TDengine 使用自带的 taosBenchmark 只需要不到 1 秒。在差距如此巨大的结果中，我们可以得出一个结论——使用 MySQL 代替时序数据库处理时序数据是比较困难的。当然由于测试工具不同，这里只是做一个示例，测试本身算不上严谨。下面我会从一些具体的企业案例出发，再为大家做下分析。

从具体的案例看大数据的存储问题

其实，想要回答这个问题，具体的企业案例实践才是最好、最真实的答案。业内人应该都知道，时序数据库是近几年随着物联网等技术的发展才逐渐流行起来的，在此之前，各行各业的企业可选的数据库方案都十分有限，以车联网企业为例，行业中最普遍的选择就是 MongoDB、HBase 一类的传统大数据解决方案。

但随着业务的发展，数据量的不断攀升，这些企业或多或少都遭遇了数据架构危机，甚至阻碍了业务的发展，不得不考虑进行数据架构的迭代和迁移。下面我从 MySQL、MongoDB、HBase 三个 database 维度列举企业案例，进行说明。

MySQL

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

由于其业务场景与 TDengine 的“一个设备采集点一张表”的理念十分吻合，且 TDengine 可以支持对大数据进行聚合和降采样查询等操作，能够经有效改善 MySQL 的数据痛点问题，又经过严谨的调研和测试，最终他们决定迁移至 TDengine。

以一个真实场景看一下迁移效果：在替换 TDengine 之前，该项目每天都有一些业务报表需要展示，每一小时需统计一次下一个时区内所有设备的数据，这个流程在 MySQL 中经常需要耗时1小时以上，无法正常执行后续业务。而换到TDengine后，整个出表流程只需要 10 秒左右。

查询对比如下图所示：

参考资料：https://www.taosdata.com/blog...

MongoDB & HBase

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

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

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

写在最后

从上面的诸多论证中我们可以得出最终结论，如果你面对的也是时序大数据场景，时序数据库才是最正确、最合理的选择，如果因为数据量尚小就选择通用数据库，那后面各种棘手问题也会接踵而至，包括开发效率慢、运行效率低、运维成本高、应用推出慢、小数据量场景下私有化部署太重等诸多问题。在数据库的选型上，“对症下药”才是有利于业务发展的良策。

想了解更多 TDengine Database的具体细节，欢迎大家在GitHub上查看相关源代码。