时序列数据库 OpenTSDB （学习整理）

下载官网：http://opentsdb.net/

官网用户指南：http://opentsdb.net/docs/build/html/index.html

学习时遇到的问题：

1、opentsdb总是被打挂？

我所遇到的问题原因和解决办法：

     打到opentsdb中的数据量很大，队列满了还在往里面打，就挂了。

优化:在opentsdb和数据之间加了一层qbus，用来作为缓冲队列，既不会导致opentsdb短时间内接收到过多的数据而被打挂。

看到文章https://blog.csdn.net/wyfk2013/article/details/53212337中也遇到过类似的原因：

       因为opentsdb是根据查询条件把所有的符合条件的数据都查到内存再聚合，时间范围太大容易导致内存不足。

优化：

        ①可能是访问量过大造成的，就部署了两个opentsdb，读写分离。运行一段时间后发现，写数据的opentsdb运行稳定，但是读数的opentsdb依然经常假死。

        ②又写了一个调度任务，先把全量的数据按1s,1min,5min,10min等聚合。这样极大的减少了查询数据点,提升查询效率（ 按实际使用情况，opentsdb查询的速度取决于查询的数据量。你可以按1s ,1min这样做二次聚合放在另外一个指标里，如原始指标host.cpu.二次聚合后指标host.cpu.1s。查询速度有几个数量级的提升。而且不容易出现OOM异常）

       OOM异常：溢出   https://www.cnblogs.com/mibloom/p/9244906.html

        ③如果需要个比较大的监控集群，建议建多个hbaes集群，一个hbase集群专门存储原始的监控数据，另外一个存储聚合后的监控数据。可以极大提高查询效率。

1. 什么是时序列数据库（Time series database）？

一听到时序列数据库，如果只是稍有耳闻的人，可能立刻会联想到运维和监控系统。

没错，确实是很多运维、监控系统都采用了 TSDB 作为数据库系统来存储海量的、严格按时间递增的、在一定程度来说结构非常简单的各种指标（英文可能为 metric、measurement 或者类似的其他单词）数据。

1.1 给TSDB一个定义

这是维基百科上的解释：

A time series database (TSDB) is a software system that is optimized for handling time series data, arrays of numbers indexed by time (a datetime or a datetime range).

翻译过来就是“时序列数据库用来存储时序列（time-series）数据并以时间（点或区间）建立索引的软件。”

其中，时序列数据可以定义如下：

• 可以唯一标识的序列名/ID（比如 cpu.load.1）及 meta-data；
• 一组数据点{timestamp, value}。timestamp 是一个 Unix 时间戳，一般精度会比较高，比如 influxdb 里面是 nano 秒。一般来说这个精度都会在秒以上。

一般时序列数据都具备如下两个特点：

• 数据结构简单
• 数据量大

所谓的结构简单，可以理解为某一度量指标在某一时间点只会有一个值，没有复杂的结构（嵌套、层次等）和关系（关联、主外键等）。

数据量大则是另一个重要特点，这是由于时序列数据由所监控的大量数据源来产生、收集和发送，比如主机、IoT设备、终端或App等。

2. TSDB数据库特点

TSDB 作为一种专为时序列数据优化而设计的数据库，在很多方面都和传统的 RDBMS 和 NoSQL 数据库不太一样，比如它不关心范式和事务。

其他方面 TSDB 的特点主要有以下几点，这里简单罗列了一下。

2.1 数据写入

TSDB 在数据写入方面，具有如下特点：

• 写多于读：95%-99%的操作都是写操作
• 顺序写：由于是时间序列数据，因此数据多为追加式写入，而且几乎都是实时写入，很少会写入几天前的数据。
• 很少更新：数据写入之后，不会更新
• 区块（bulk）删除：基本没有随机删除，多数是从一个时间点开始到某一时间点结束的整段数据删除。比如删除上个月，或者7天前的数据。很少出现删除单独某个指标的数据，或者跳跃时间段的数据。

区块删除很容易进行优化，比如可以按区块来分开存储到不同的文件，这样删除一个区块只需要删除一个文件就可以了，成本会比较低。

2.2 数据读取（查询）

相对于写入操作，TSDB 的读取操作特点如下：

• 顺序读：基本都是按照时间顺序读取一段时间内的数据。
• 基数大：基本数据大，超过内存大小，要选取的只是其一小部分，且没有规律，缓存几乎不起任何作用。

即使读取操作相对写来说较少，但是读操作的响应时间要求很高，除非你是只做后台报表生成，否则一旦有交互性操作，必须要求快速响应。

为了提高读取的响应时间，有两种策略：

• 一是以写性能优先，不为读取做存储优化，但是通过分布式和并发读，来提高读取的速度。
• 二就是在写入的时候就考虑到读的性能问题，将统一指标、时间段的数据写入到同一数据块中，为读取进行写入优化。

2.3 分布式（集群）

TSDB 应该天生就要考虑到分布式和分区等特性，将存储和查询分发到不同的服务器，以支撑大规模的数据采集和查询请求。

同时，它也应该是能扩展和自动失败切换（Fault-tolerant）的。随着数据量的增长，所需服务器的台数也会增加，能动态的增减服务器则是一个基本要求。同时，随着服务器的增多，各种服务器软件或者网络故障发生的概率也会增大，这时候失败切换也显得很重要，不能因为一台机器的失效而导致整个集群不可工作。

2.4 基本数据分析支持

TSDB 的数据是用来分析的，所以 TSDB 还会提供做数据分析所必须的各种运算、变换函数。比如可以方便的对时序列数据进行求和、求平均值等操作，就像传统的 RDBMS 一样。

参考文献：https://www.jianshu.com/p/01500b90b41e    來源：简书