前言
不管是使用polaris监控还是grafana监控都有用到一个特殊的数据库–TSDB

详见：Polaris文档、http://bigdata-grafana.**.net/

概念
TSDB（Time Series Database）：一系列数据点按照时间顺序排列；时间序列数据就是历史烙印，具有不变性、时间排序性

（基于时间的一系列数据，在有时间的坐标中将这些数据点连成线，往过去看可以做成多维度报表，揭示其趋势性、规律性、异常性；往未来看可以做大数据分析、机器学校、实现预测和预警

时序数据库就是存放时序数据的数据库，并且需要支持时序数据的快速写入、持久化、多维度的聚合查询等基本功能）

开源的时间序列数据库
1999/07/16 RRDTool First release：自带画图功能
2009/12/30 Graphite 0.9.5：用python写的RRD数据库，有画图功能和聚合能力，但是很难水平扩展
2011/12/23 OpenTSDB 1.0.0：使用HBase解决了水平扩展的问题，新的OpenTSDB也支持Cassandra
2013/05/24 KairosDB 1.0.0-beta：基于OpenTSDB修改，但是作者认为兼容HBase导致他们不能使用很多Cassandra独有的特性，于是就抛弃了HBase仅支持Cassandra
2013/10/24 InfluxDB 0.0.1：
2014/08/25 Heroic 0.3.0：
2017/03/27 TimescaleDB 0.0.1-beta
等等
我司grafana支持OpenTSDB,polaris使用InfluxDB

技术实现、原理
在工业物联网环境监控方向，百度天工的客户就遇到了这么一个难题，由于工业上面的要求，需要将工况数据存储起来。客户每个厂区具有20000个监测点，500毫秒一个采集周期，一共20个厂区。这样算起来一年将产生惊人的26万亿个数据点。假设每个点50Byte，数据总量将达1P（如果每台服务器10T的硬盘，那么总共需要100多台服务器）。这些数据不只是要实时生成，写入存储；还要支持快速查询，做可视化的展示，帮助管理者分析决策；并且也能够用来做大数据分析，发现深层次的问题，帮助企业节能减排，增加效益。终客户采用了百度天工的时序数据库方案，帮助他解决了难题。

那么是怎么解决难题的呢：

很多人认为在传统关系型数据库上加上时间戳一列就能作为时序数据库；少量数据时确实可以这样做，然而在上述的例子中，使用传统关系型数据库是会耗费大量资源的，并且读写速度很难满足，那么要解决这些问题，时序数据库要具备哪些特点呢：

数十亿个数据点
高吞吐量的写入
高吞吐量的读取
大量删除（数据到期）
以InfluxDB为例，来看看TSDB是如何拥有这些特点的：

一、时序数据库InfluxDB的写入：
1、采用TSM（Timestamp-Structure Merge Tree，InfluxDB独自开发）结构：数据先写入内存，当内存容量达到一定阈值后刷flush到文件，避免随机操作使用顺序写数据，提高写的速度

2、数据模型设计方面提出：seriesKey（measurement+datasource（tags）），再采用map< SeriesId,SeriesKey>的方式保存seriesKey，节省空间



如上图所示的内容被保存为：

seriesId seriesKey
1 name=census,location=1,scientist=langstroth
2 name=census,location=1,scientist=perpetua
3 name=census,location=2,scientist=langstroth
4 name=census,location=2,scientist=perpetua
seriesId time butterflies honeybees
1 2015-08-18T00:00:00Z 12 23
1 2015-08-18T00:06:00Z 11 28
2 2015-08-18T00:00:00Z 1 30
2 2015-08-18T00:06:00Z 3 28
3 2015-08-18T05:54:00Z 2 11
3 2015-08-18T06:00:00Z 1 10
4 2015-08-18T06:06:00Z 8 23
4 2015-08-18T06:12:00Z 7 22
同时，相同的seriesKey在内存中按照时间分区顺序存储，一般按照配置的shardgroup（指定的时间跨度）来分区存储

这样做的好处：

1、同一数据源的tags不再冗余存储：一个Block内的数据都共用一个SeriesKey，只需要将这个SeriesKey写入这个block的Trailer部分就可以，大大降低了时序数据的存储量

2、时间序列和value可以在同一个Block内分开独立存储，独立存储就可以对时间列以及数值列分别进行压缩。InfluxDB对时间列的存储借鉴了Beringei的压缩方式，使用delta-delta压缩方式极大的提高了压缩效率。而对Value的压缩可以针对不同的数据类型采用相同的压缩效率。

3、对于给定数据源以及时间范围的数据查找，可以非常高效的进行查找

二、时序数据库InfluxDB的读取
1、InfluxDB允许用户使用类SQL语句执行查询分析聚合

2、采用顺序读取的方式读取数据（速度远高于随机读取）

三、数据清理
InfluxDB提供数据保存策略policies，用于指定数据的保留时间，超过指定时间就会删除这部分数据；

删除数据时根据shardgroup的粒度来删除，加快删除的效率，如果创建数据库时不指定shardgroup时间，系统将通过policies时间来计算shardgroup

policies设置的时间

shardgroup的时间

<2d
1h

>=2d and <=6d 24h
>6 months 168h
总结
1、采用TSM的方式将数据先写入内存，存够一定的量之后在flush到内存，采用顺序存储的方式写数据，加快读写的数据

2、设计seriesKey存储数据，减少数据的存储量，同时可以非常高效的查询数据

3、定期根据shardgroup来清理数据，加快删除的效率

综上，TSDB（InfluxDB）具有高吞吐量的写入和读取，可以用较少的空间存储大量的数据点，定期高效删除数据；具有这些特点的TSDB可以较好的在监控场景应用

序号

优点

缺点

1
提高了读写性能
删除功能受到了很大限制（支持系统删除旧数据）
更新功能受到了很大限制
服务启重启后数据恢复较慢
2
按时间递增的顺序写入数据更高效
随机时间写入的性能要低很多
3
多个客户端可以在高负载的情况下完成查询和写入操作
如果负载过高，查询结果可能不包含近的点
4
InfluxDB 具有非常强大的工具去处理聚合数据和大数据集
不能存储重复数据，可能会在极少数情况下覆盖数据
问题
1、kafka+流处理框架也可以使数据按照时间排序，为什么还要出现TSDB

流系统是存储消息，消息只需要短暂存储，区分维度较少（时间戳、topic）。而时间序列数据库的数据可以像传统关系库一样提供表、字段等多个维度，按照不同维度的聚合统计。流系统的数据存储格式是append-only的log方式的，没有索引，数据不支持按照非时间戳以外的key进行排序存储；tsdb一般是LSM-tree，数据可以按照需要的维度排序存储，如有必要，也可以建索引，甚至可以考虑物化视图的方式支持聚合查询，这在流处理系统就不存在。
————————————————
版权声明：本文为CSDN博主「超级三足乌鸦」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_35604947/article/details/105716079