02月06, 2017

时间序列数据库浅析

最近看了一些时间序列数据库(TSDB)相关的资料,和大家分享一下。
时间序列数据库对于我们并不陌生,最早的RRDTool就可以认为是一种时间序列数据库,因为它的功能比较简单,无法满足复杂查询要求,而且随着大数据,IOT兴起,对于时间序列数据需求越来越多,所以时间序列数据库开始“热”了起来,很多大厂也开源了自己的TSDB。

什么是时间序列数据库

时间序列数据库简称TSDB,首先它是一个比较特殊的数据库,它主要存放时间序列数据,那么什么是“时间序列数据”?

最简单的定义就是数据格式里包含timestamp字段的数据。比如股票市场的价格,环境中的温度,主机的CPU使用率等。但是又有什么数据是不包含timestamp的呢?几乎所有的数据都可以打上一个timestamp字段。时间序列数据更重要的一个属性是如何去查询它。在查询的时候,对于时间序列我们总是会带上一个时间范围去过滤数据。同时查询的结果里也总是会包含timestamp字段。

比如这种图表
alt

数据的横轴永远是时间 。
时间序列数据不同于传统数据,有一些自身的特点:

  1. 数据结构简单
  2. 数据量大

因为时间序列数据自身的特点,传统的数据库有些显得力不从心,所以今年涌现了很多优秀的时间序列数据库。 Baron Schwartz概述了一些专用时间序列数据库的典型特征应包括:
  数据库90%以上的工作量是高频高容量的写入
  写操作通常是随着时间追加到现有的表中
  这些写操作通常是按一定时序的,例如:每秒或者每分钟
  如果时间序列数据库中获取受限资源,这通常是因为它是I / O绑定
  更新单个点数据的操作很少
  删除数据几乎总是跨越大的时间范围(日,月或年)进行,几乎从不到一个特定的点
  数据库查询操作通常是在某序列中有序的,可能是按时间排序或者按某功能排序 ,执行并行读取或者多组读取是常见的

TSDB其实在自动化,石油,化工等其它行业早已经普及使用,比如企业级的Pi,性能非常非常好,但是价钱也是很贵。

对于我们来讲,大部分TSDB是使用在监控上,将监控数据存放到TSDB中,便于分析和报警。
以下会对常见TSDB做一些评价,因能力有限(个人喜好),评价不一定客观和准确.

常见TSDB

首先我们看看DB-engines中关于TSDB的排名情况: alt

InfluxDB

InfluxDB由golang编写,也是golang社区中比较著名的一个,目前在TSDB中排名第一。最新的版本是1.2,之前的版本之间变动很大,很多网上资料都已失效,文档要以官方为准。
做为最火的TSDB,可靠性和稳定性有一定保障。
支持类SQL查询语言,使用方便。
丰富数据类型支持。
事件数据全量存储。 比较让人诟病的是新版将“集群模式”闭源了,开源只能使用单机模式,官方提供relay工具来进行HA,但是实现的很不优雅。
设计理念更关注数据一致性(CP),这点和Prometheus正相反。

Opentsdb

opentsdb使用java编写,后端存储使用hbase或者cassandra,之所以使用java编写,作者说是想和hbase社区保持一致性,从中可以看出opentsdb是想作为hbase生态的一种补充,如果你的公司已经有一套完成hbase生态,接入opentsdb是非常方便的。

Prometheus

Prometheus是由社交音乐平台 SoundCloud 在2012年开发,作者之前的google工程师,参考了google内部borgmon的设计,属于CNCF孵化产品,CNCF另一个产品是k8s。
Prometheus原生对容器化支持很好。
Prometheus是一套完整的监控系统,提供数据收集,报警通知等一系列功能。
没有存储完整事件数据,数据占用量小,据说是influxdb的1/10.
数据类型只支持float64。
目前数据存放到本机,没有集群方案。
数据先存入内存再定期刷入磁盘,查询性能很好,数据有丢失风险。 内存管理模型是基于facebook的论文Gorilla: A Fast, Scalable, In-Memory Time Series Database

提供PromQL,比SQL强大可组合各种查询结果。
它是一个监控系统,所以设计理念更加关注AP,即性能和报警及时性优先,数据一致性不是优先考虑的。

Beringei

facebook刚刚开源了自家的TSDB,Beringei也是基于[Gorilla: A Fast, Scalable, In-Memory Time Series Database]这篇论文,所以我理解和Prometheus实现大致是一样的,但是有分片服务实现,避免了单点风险。

一些思考

TSDB成熟的开源方案已经有很多,使用上会面临选型的问题,有的性能好,有的高可用,其实归根结底还是“CAP”原理。
如果你对数据一致性要求很高,不能容忍数据丢失,那就选用一致性做得好的TSDB,那会损失一定的性能,并且在数据维护上耗费一些精力。
如果你可以容忍一定的数据丢失,想要高效的查询性能,实时返回结果,用于监控告警,那么就选用性能优先的产品。
还是那句话“there is no silver bullet.”

本文链接:https://www.opsdev.cn/post/tsdb-elementary-analysis.html

-- EOF --

Comments

评论加载中...

注:如果长时间无法加载,请针对 disq.us | disquscdn.com | disqus.com 启用代理。