时序列数据库选型

时序列数据库武斗大会之什么是TSDB

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

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

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/

posted @ 2016-12-30 11:14  bonelee  阅读(2834)  评论(0编辑  收藏  举报