1.概述
时序列数据库（Time series database）：用来存储时序列（time-series）数据并以时间（点或区间）建立索引的软件一般时序列数据都具备
数据结构简单：某一度量指标在某一时间点只会有一个值，没有复杂的结构（嵌套、层次等）和关系（关联、主外键等）
数据量大：由于时序列数据由所监控的大量数据源来产生、收集和发送，比如主机、IoT设备、终端或App等
2.时序数据的几个特点
（1）基本上都是插入，没有更新的需求。
（2）数据基本上都有时间属性，随着时间的推移不断产生新的数据。
（3）数据量大，每秒钟需要写入成千万上亿条数据
3.业务方常见需求
（1）获取最新状态，查询最近的数据(例如传感器最新的状态)
（2）展示区间统计，指定时间范围，查询统计信息，例如平均值，最大值，最小值，计数等。。。
（3）获取异常数据，根据指定条件，筛选异常数据
4.常见业务场景监控软件系统：
（1）虚拟机、容器、服务、应用监
（2）控物理系统： 水文监控、工厂的设备监控、国家安全相关的数据监控、通讯监控、传感器数据、血糖仪、血压变化、心率等
（3）资产跟踪应用： 汽车、卡车、物理容器、运货托盘
（4）金融交易系统： 传统证券、新兴的加密数字货币
（5）事件应用程序： 跟踪用户、客户的交互数据
（6）商业智能工具： 跟踪关键指标和业务的总体健康情况
在互联网行业中，也有着非常多的时序数据，例如用户访问网站的行为轨迹，应用程序产生的日志数据等等。
5.一些基本概念(不同的时序数据库称呼略有不同)
（1）Metric: 度量，相当于关系型数据库中的 table。
（2）Data point: 数据点，相当于关系型数据库中的 row。
（3）Timestamp：时间戳，代表数据点产生的时间。
（4）Field: 度量下的不同字段。比如位置这个度量具有经度和纬度两个 field。一般情况下存放的是随时间戳而变化的数据。
（5）Tag: 标签。一般存放的是不随时间戳变化的信息。timestamp 加上所有的 tags 可以视为 table 的 primary key。
例如采集有关风的数据，度量为 Wind，每条数据都有时间戳timestamp，两个字段 field：direction(风向)、speed(风速)，两个tag：sensor(传感器编号)、city(城市)。第一行和第三行，存放的都是 sensor 编号为86F-2RT8的设备，城市是深圳。随着时间的变化，风向和风速发生了改变，风向从56.4变为45.6，风速从2.9变为3.6。
6.时序数据库遇到的挑战
很多人可能认为在传统关系型数据库上加上时间戳一列就能作为时序数据库。数据量少的时候确实也没问题，但少量数据是展现的纬度有限，细节少，可置信低，更加不能用来做大数据分析。很明显时序数据库是为了解决海量数据场景而设计的。
可以看到时序数据库需要解决以下几个问题
l 时序数据的写入：如何支持每秒钟上千万上亿数据点的写入。
l 时序数据的读取：又如何支持在秒级对上亿数据的分组聚合运算。
l 成本敏感：由海量数据存储带来的是成本问题。如何更低成本的存储这些数据，将成为时序数据库需要解决的重中之重。
这些问题不是用一篇文章就能含盖的，同时每个问题都可以从多个角度去优化解决。在这里只从数据存储这个角度来尝试回答如何解决大数据量的写入和读取。
7.常见时序数据库
时序数据库出现的时间较晚，目前较成熟的时序数据库都仅有1、2年的历史。
InfluxDB(单机版免费，集群版收费)最成熟，Kairosdb(底层使用Cassandra)，OpenTsdb(底层使用Hbase)，beringei(FB开源)，TimeScaleDB(底层基于PostgreSQL)，TSDB(百度开源)，HiTSDB(阿里开源，底层是PostgreSQL)。
8.如何去选择时序列数据库
时序数据库有很多 请查看：https://db-engines.com/en/ranking/time+series+dbms
选择时可以从以下方面综合考虑
性能、存储方案、集群功能、API（HTTP API和Client Library）、SQL-like Query Language、部署体验、成熟度、可视化和报警功能、所采用技术栈、保留策略（Retention Policies，或自动删除、压缩）、背后主导公司、License、安全性等等。