一，时序数据库
时间序列数据库简称时序数据库(Time Series Database)，用于处理带时间标签(按照时间的顺序变化，即时间序列化)的数据，带时间标签的数据也称为时间序列数据。
时序数据的几个特点
1. 基本上都是插入，没有更新的需求。
2. 数据基本上都有时间属性，随着时间的推移不断产生新的数据。
3. 数据量大，每秒钟需要写入千万、上亿条数据
业务方常见需求
1. 获取最新状态，查询最近的数据(例如传感器最新的状态)
2. 展示区间统计，指定时间范围，查询统计信息，例如平均值，最大值，最小值，计数等。。。
3. 获取异常数据，根据指定条件，筛选异常数据
常见业务场景
监控软件系统： 虚拟机、容器、服务、应用
监控物理系统： 水文监控、制造业工厂中的设备监控、国家安全相关的数据监控、通讯监控、传感器数据、血糖仪、血压变化、心率等
资产跟踪应用： 汽车、卡车、物理容器、运货托盘
金融交易系统： 传统证券、新兴的加密数字货币
事件应用程序： 跟踪用户、客户的交互数据
商业智能工具： 跟踪关键指标和业务的总体健康情况
在互联网行业中，也有着非常多的时序数据，例如用户访问网站的行为轨迹，应用程序产生的日志数据等等。
一些基本概念(不同的时序数据库称呼略有不同)
Metric: 度量，相当于关系型数据库中的 table。
Data point: 数据点，相当于关系型数据库中的 row。
Timestamp：时间戳，代表数据点产生的时间。
Field: 度量下的不同字段。比如位置这个度量具有经度和纬度两个 field。一般情况下存放的是随时间戳而变化的数据。
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。
需要解决的几个问题
时序数据的写入：如何支持每秒钟成千上亿条数据的写入。
时序数据的读取：如何支持在秒级对上亿条数据的分组聚合运算。
成本敏感：海量数据存储带来的成本问题。如何以更低成本存储数据，将成为时序数据库需要解决的重中之重。
常见时序数据库
时序数据库出现的时间较晚，目前较成熟的时序数据库都仅有2、3年的历史。
InfluxDB(单机版免费，集群版收费)最成熟，
Kairosdb(底层使用Cassandra)，
OpenTsdb(底层使用HBase)，
beringei(Facebook开源)，
TimeScaleDB(底层基于PostgreSQL)，
TSDB(百度开源)，
HiTSDB(阿里开源，底层是PostgreSQL)。
Prometheus、Influxdb和opentsdb是三款业内比较知名且实际生产使用的时序数据库了，总的来说三款各有优缺点，这里不谈它们的性能，主要谈谈使用和生态。
Influxdb：目前开源排名最高的时序数据库，是单独的数据库，主要就是用来写入和查询数据。目前集群版已经闭源商业化，开源版仅支持单机模式。数据采集使用push模式（数据源主动将数据写入influxdb）。优势是提供类SQL的查询引擎。
Prometheus：提供了一整套的监控体系，包括数据的采集存储报警等。仅支持单机，数据写入本地。数据采集使用的是pull模式。
opentsdb：基于hbase做的时序数据库，最大的特点是由hbase带来的横向扩展能力，最大的缺点是hbase带来的笨拙感，一旦集群扩大，运维可能会烦死人。
二、时序数据库要解决的痛点
公司内部团队曾经用mysql+中间件做过一款伪时序数据库，但是由于mysql底层的存储形式导致其天然不适应时序数据的场景。且其写入能力也完全无法满足时序数据大量写入的要求。
那么时序数据的特点是什么呢？
1、数据随着时间增长，根据维度取值，而数据纬度几乎不变。
2、持续高并发写入，设备越多，写入数量越大，而且由于定期采样，写入量平稳。但是几乎不会有更新操作（一个设备在某个时间点产生的数据不会变动）以及单独数据点的删除（通常只会删除过期时间范围内所有的数据）
3、查询一般都是查最近产生的数据，很少会去查询过期的数据。
4、设备之间的数据关联性小，同种类设备A和设备B产生的数据互相并不依赖。你并不需要join。
由上述特点结合我与iot行业相关人员的探讨，我总结出以下时序数据库要解决的痛点
1、海量设备带来的写入压力
2、如何高效存储大量纬度相同仅值和时间戳不同的数据
3、能够方便的剔除过期数据，或者能够把数据冷热分离以降低存储成本
4、传统企业it人员专业素质不高带来的对整个时序数据库体系的易用性要求
三、现有产品已经满足的和缺失的
假如你要问我写多读少的场景适合什么算法？显然那就是LSM Tree。更妙的是，时序数据很少有更新、删除操作，对事物的需求也不高，这很好的规避了LSMT对于update和delete上的缺陷。市面上的时序数据库基本都是采用LSM Tree的架构。
关于数据的压缩，很容易的能想到同纬度的数据压缩，时间戳前缀压缩等想法，这些在各家数据库都有体现。当然opentsdb似乎由于底层的hbase无法更好的针对时序数据的特点进行压缩，与之类似的问题是opentsdb必须手动去根据时间段来管理数据，而Influxdb、Prometheus包括Graphite等都是可以自己根据时间段来分割数据的。这样当你要删除过期数据时，只要删除对应的block就行。
对于数据查询，经常有人吐槽SQL不太行，所以有后面的NO-SQL出现。但是当大家真的想去做些分析时，还是不由自主的想念SQL，想在KV上用上SQL（new sql），哈哈哈，SQL真香。所以好的内置的针对时序数据的sql引擎也是让人感到愉悦、不可缺少的东西。目前Influxdb在这一块大大领先。
如果你想长时间保存数据，一个比较麻烦的问题是单机总是有容量上限的，即使你做一个上层中间件来搞一个所谓的集群。另外关于高可用，坏盘、数据迁移等等是真实的让人头痛的东西，我个人比较反感简单的双写，毕竟你要浪费两倍的CPU和内存，LSMT的Compaction带来的写放大本来就让人头疼，你还要对你的数据做两次，OMG！（李佳琦脸）真让人接受不能。
遗憾的是目前除了opentsdb似乎都落本地，麻烦事儿。
四、时序数据库架构
在数据库领域，只要你上生产，你就得考虑HA、数据可靠性，你就得考虑你的运维难度和成本，否则性能再高，也只是个PPT产物。
在时序数据库这一块，我讨厌简单的双写，同时我对于上层弄个一致性协议去搞所谓的分布式不是很感冒：只要数据要同时处理（解压，压缩）多次的，都挺浪费的。
你也可以选择分库分表分设备，但是底层似乎也是单点的，且单点上也要做主备，emmm。
我认为计算存储分离是个好方向。底层存储像hdfs一样，数据写（解压、压缩）一次，剩下两份直接副本传输（或者做EC）,美妙。
上层是时序数据库引擎，下层是分布式文件/块存储。
显著的好处是对同一份数据的compaction肯定只要做一次（读取-compaction-写入文件-副本拷贝），而且免去了坏盘，物理机down等的烦恼。数据扩容/冷热分离也较为方便。同时对于一写多读相对友好（类似阿里的Polardb）
缺点嘛，多个计算节点写同一份数据比较麻烦，需要分布式锁来同步，不过在iot下设备天然可分割，设备区1的设备数据无需与设备区2的监控等数据做join等，那么为什么不能把无瓜葛的设备数据写在不同的实例里呢？这样似乎能较好的缓解写入的压力。（另一种形式的分库分表？）
这里希望有人能探讨一下。
五，总结
时序数据库确实在iot/监控这一方面是专精的，其在时序数据写入/查询/数据压缩方面有巨大的优势，能够解决许多用户痛点。而现有的时序数据库在存储方面还有所不足，要么是单机的，要么难以维护（opentsdb)。可改造的地方还有很多。
不过更高的查询性能，更快的写入速度，更方便低成本的运维，人人想要。一旦业务规模上来，各方面的需求都应该且会被考虑到，却并不可能都被满足。做工程本质上还是不断地做Trade Off。如何取舍还是要在实际生产应用中去选择。