数据库主要分为关系型数据库和非关系型数据库，大家所熟悉的数据库中，属Oracle、MySQL和Microsoft SQL Server最出名，使用人数最多，这三种都属于关系型数据库，之所以使用人数这么多，是因为关系型数据库符合大部分应用场景，但有些特定的场景就未必适用，需要根据情况选择不同的数据库，比如在物联网（IoT）领域就需要用到非关系型数据库中的时序数据库，全称时间序列数据库，时间序列数据库指主要用于处理带时间标签（按照时间的顺序变化，即时间序列化）的数据，带时间标签的数据也称为时间序列数据。而时序数据库中排第一的要属InfluxDB，有着使用人数多、开源等特点，从这方面看身份地位在时序数据库中类似关系型数据库中的MySQL。
1.InfluxDB时序数据库的起源与特点
InfluxDB是开源数据库，发布于2013年，但时序数据库真正发展是2015年开始，各种时序数据库争奇斗艳的出现，有Kdb+、Graphite、TimescaleDB、OpenTSDB等，而在人气上InfluxDB远远的把他们甩在了后面，从那时到现在都是排名第一，且人气还在增长。
有了MySQL等关系型数据库，为什么还要用时序数据库呢？对比MySQL，InfluxDB时序数据库有以下特点：
优点：
- 同MySQL一样开源免费，单体存储超过10亿级别的时间序列数据，TB或者PB级，在如今大数据背景下起到重要作用。
- 插入性能高，飞一般的聚合查询速度，这是MySQL远远不能企及的。
- 数据压缩存储，减少服务器存储压力，同样数量的数据，比MySQL的存储小了数倍。
- 提供了保存策略，使数据存放具有时效性
- 内置持续查询功能，定时计算指定时间段的数据，插入到指定表中，可以理解为定时归集数据。
- 1.0版本支持类似SQL的查询语法（2.0版本以后不再支持，改为了flux语法）。
- 基于 Go 语言编写的无环境依赖，提供了Http Api直接访问。
- 水平扩展，支持集群模式（收费）。
缺点：
- 不支持事务。
- 不支持多表关联查询。
- 不支持直接删除和修改数据功能，删除只能用数据保存策略。
- 2.0版本不支持SQL语法，而是用flux语法，增加了学习难度。
- 国内用户少，资料也少，需要查阅英文文档。
2.InfluxDB时序数据库的技术及应用现状
时序数据，就是以时间排序的一系列数据，每一条数据都有唯一的时间作为主键，时间精度到纳秒级别，数据增长比较快，基本不会去修改。比如某地的温度测量仪，每隔几秒就要测量一次温度，而且有很多个这样的测量仪，在不停的测量上传数据，这么多数据要放到MySQL压力是非常大的，由于MySQL的存储机制，不说能不能存储下这么多数据，数据量一旦大了查询速度就会非常慢，严重影响使用体验，而InfluxDB在存储时自动为数据以时间分片压缩存储，在有时间范围条件下，即使数据量很大，查询速度依然很快。
InfluxDB还有着优秀的插入性能，没有像MySQL那样的索引存在，在写入的同时不会对查询造成影响，这在物联网领域是迫切需要的。但是时序数据库弱化了关系，所以通常不作为项目中唯一的数据库，需要配合MySQL这样的关系型数据库一起使用，MySQL存储一些需要关联查询并且数据量不会增长到很大的数据，InfluxDB存储有时间序列的大数据。
从以上这些特点可以看出，时序数据库就是为了解决关系型数据库在大数据处理和存储上不能有效解决的问题，关系型数据库因为天生的劣势，导致其无法进行高效的存储和数据的查询，时序数据库采用了特殊的存储方式，以达到高效存储和快速处理海量时序大数据，是解决海量数据处理的一项重要技术。该技术采用特殊数据存储方式，极大提高了时间相关数据的处理能力，相对于关系型数据库它的存储空间减半，查询速度极大的提高，时间序列函数优越的查询性能远超过关系型数据库。
近年来，时序数据库发展十分迅猛，各大互联网企业包括 Google、阿里、Amazon 都推出自己的时序数据库，DB-Engines从2014年起也把时序数据库作为独立的目录进行分类统计。
3.InfluxDB时序数据库的发展趋势
InfluxDB 1.0版本是类SQL语法，上手很快，但至2.0版本开始，InfluxDB不再支持类SQL语法，而是推出了自己创立的新Flux语法，InfluxDB 之所以创造 Flux 语法，而不使用 SQL，主要有两个原因：更强的查询功能，SQL 无法轻松完成时序查询；时间序列的查询需要基于流的函数模型，而不是 SQL 的代数模型。对于国内用户来说，这种改变对1.0版本支持SQL建立起来的优势有一定冲击，用户需要更多学习成本，而且由于国内用户少，新版的资料非常少，需要自己查阅官方英文文档。
2.0版本还对一些概念做了更改，比如：Organization (组织)，简称org，跟1.0版本中的database概念一致（在关系型数据库中也是database）；Bucket (桶)，融合了1.0版本中存储策略和库的概念；Measurement相当于表；token(令牌)，在1.0版本中是用账号密码作为凭证跟InfluxDB进行连接交互，2.0版本改为用令牌。如此大的改动，就算是从1.0版本升级到2.0版本，学习成本也接近一种新的数据库，实属劝退之举啊，当然对于大部分开发者来说这点难度不算什么。建议1.0版本的用户不是刚需而且时间充足的话，不用急着升级，等市场稳定有较多资料后再做升级，初次使用者可以直接用2.0版本，也可以用别的优秀数据库代替。
经过了这些年，现在国内已经有些很优秀的时序数据库了，比如浙江智臾科技的DolphinDB和北京涛思数据科技的TDengine。
TDengine：性能远超InfluxDB，写入性能比InfluxDB快约为5倍，读取性能约为35倍，聚合函数性能约为140倍，按标签分组查询性能约为250倍，按时间分组查询性能约为12倍，压缩比约为1.8倍，数据存储压缩比可以降到4%，大大减少服务器存储压力，开源（包括集群），目前只支持linux系统，采用类SQL语法，目前时序数据库排行榜第9位（截至2023年6月），请参考：DB-Engines Ranking - popularity ranking of time Series DBMS。
DolphinDB：性能优于InfluxDB 1至2个数量级（10-100倍），导出速度为InfluxDB的2倍，写入速度约为12倍，性能还要优于TDengine，但是不开源，需要收费，国内更多的是应用在金融领域，同样是采用类SQL语法，目前时序数据库排行榜第6位（截至2023年6月），请参考：DB-Engines Ranking - popularity ranking of time Series DBMS。
虽然从测试数据上看都比InfluxDB性能要好，但使用人数不是很多，都发布于2018年，发布时间不长，稳定性仍欠缺，在实际生产环境中表现怎么样还需要市场长期验证。当然DolphinDB和TDengine对于国内用户会更加友好，而且目前还是用的类SQL语法，从关系型数据库切换过来学习成本要低一些，有问题也可以随时联系开发公司解决。
时序数据库正处于高速发展阶段，时序数据技术逐步走向成熟，但是这绝不是终点，时序数据技术还面临各种新的需求和挑战。各大厂商在提高时序数据库性能的同时，针对新需求正在提出更多解决方案：
1.云服务，除了单机版本，许多厂商还发布了分布式版本、云服务版本，特别是云服务，已经成为必不可挡的发展趋势。
2.可视化服务，随着万物互联的到来，用户对信息的全面掌握的需求在增长，时序数据的可视化展示成为一大趋势，这就对时序数据库的查询能力提出更高的要求。
3.边缘计算服务，在万物互联的时代，更多的传感器带来的庞大数据量是集中化处理方式难以负荷的，这就使得数据计算向边缘化发展，设备将数据通过边缘设备进行实时处理分析反馈后再集中存储，能够提高设备的实时响应能力，提升时效性数据的价值，因此，时序数据库对边缘计算的支持将成为其一个重要的功能。
面对这些挑战与机遇，相信时序数据库将会有更深的发展，未来可期，而InfluxDB是否还能保持其霸主的地位，让我们拭目以待。
4.总结
在如今处处都是大数据的时代，传统关系型数据库已经满足不了多元的市场需求了，更多的是要结合项目，选用合适的数据库，像我工作中碰到的需求就是要采集生产过程中每个环节的一系列数据，以便进行追溯，在经过层层筛选后，选用了InfluxDB为主，MySQL为辅，各司其职，相辅相成，以建立稳健的系统。
在挑选时序数据库时，追求开源和稳定性的话，InfluxDB仍是首选，毕竟经历了众多生产环境的验证，同时因为2.0版本采用了新的flux语法，需要考虑团队的学习成本；业务更偏向金融的大公司，可以考虑DolphinDB，它有完善的中文技术文档，而且是在国内，有专业的技术团队提供服务，解决问题速度会比较快；喜欢尝试的也可以用TDengine，它除了时序数据库功能外，还提供缓存、数据订阅、流式计算等功能，可以省去比如Redis、RabbitMQ这样的一些中间件，并且对于用惯了MySQL、Oracle等sql语法数据库的程序员，相较InfluxDB来说更容易上手。
