小 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 上查看相干源代码。