由于工作上的关系，最近看了一些关于时序列数据库的东西，当然，我所看的也都是以开源方案为主。

趁着这股热劲还没退，希望能整理一些资料出来。如果正好你也有这方面的需求，那么希望这一系列的介绍能够帮助到你。

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

2.4. 基本数据分析支持

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

3. 如何去选择开源时序列数据库

虽然每个人的场景不太一样，不过我觉得以下的大部分因素，都值得大家好好考量一下。除了功能上能满足、性能上撑得住，运（售）维（后）等也是我们准备长期使用所必须面临的问题。

我自己总结的评价因素主要有如下几点：

3.1. 性能

主要就是读和写的性能，在前面TSDB的特点中我们已经讲过了。

通过前面的说明，我们也知道TSDB 99.9%都是读少写多，因此写入性能必须能跟得上、无延时，并且不能阻塞读操作，且读操作能快速返回最新的数据。

还有一点必须注意的是，现在很多用户的数据都跑在云主机上，那么IOPS则是一个你必须要注意的因素，超了Plan限制的话很难找出问题原因。

3.2. 存储方案（或引擎）

存储方案主要会影响到读写性能、集群扩展容易程度、以及运维的复杂度。典型的存储方案有HDFS、HBase、Cassandra、LevelDB等。

3.3. 集群功能

一般来说，集群主要集中为存储和查询的集群功能，也代表其可扩展性，因为时序列数据库的数据量很可能很大，并且增长趋势不可预测，尤其是随着大数据和物联网的兴起，GB已经算入门，TB也是刚起步。

3.4. API（HTTP API和Client Library）

如果你需要定制，或者只是使用TSDB做存储，自己写入数据并通过查询接口进行数据展示，那么API的完善程度将是一个很重要的评判因素。

还好大部分TSDB都提供了HTTP API，除了简单的文本格式，有很多还支持JSON格式的输入、输出。

Client Library也是一个加分项，有一个好用的、你熟悉的语言的SDK包的话应该会更方便你做开发。

3.5. SQL-like Query Language

如果能通过类似传统SQL的select mean(value) from metric where role=‘user‘ and time >= xxx and time <= yyy group by dc来查询metric的话，是不是刚接触到TSDB的人更容易上手和理解呢？

可能这看起来比较酷，不过对我来说这只能算是个加分项而已。因为我们只会通过API来读写数据，而且查询模式非常固定、数量不多。

但是很多经常出报表的人，可能更喜欢这一特点了，因为老板、运营可能会定期或者随时找他们出统计数据。

DB-Engines中时序列数据库排名

我们先来看一下DB-Engines中关于时序列数据库的排名

这是当前（2016年2月的）排名情况：

摘自：http://liubin.org/blog/2016/02/18/tsdb-intro/