时序列数据库武斗大会之 TSDB 名录 Part 1

【编者按】
刘斌，OneAPM后端研发工程师，拥有10多年编程经验，参与过大型金融、通讯以及Android手机操做系的开发，熟悉Linux及后台开发技术。曾参与翻译过《第一本Docker书》、《GitHub入门与实践》、《Web应用安全权威指南》、《WEB+DB PRESS》、《Software Design》等书籍，也是Docker入门与实践课程主讲人。本文所阐述的「时间序列数据库」，系笔者所负责产品 Cloud Insight 对性能指标进行聚合、分组、过滤过程当中的梳理和总结。

经过上一章《时序列数据库武斗大会之什么是TSDB》的介绍，相信你们已经知道了什么是时序列数据库，以及对它能干什么，具备什么特色。

那么在这一篇文章中，咱们将介绍一下目前都有哪些 TSDB，以及它们各自的特色，并基于我的观点，给出必定的（喜爱）评判。

因为我的能力所限，有些地方调查可能不到位，再加上必定的我的主观因素，跟其余人的结论可能不同，不过这应该也正常。没有调查过就没有发言权，只有真正的深度用户的发言，才具备说服务力，你权当这里就是我抛砖了。

虽然也有人用 ElasticSearch 或者 MongoDB 来存储时序列数据，做为更适合分类为 NOSQL 的这两个数据库软件，咱们这里就不对它们作介绍了。

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

咱们先来看一下DB-Engines中关于时序列数据库的排名，这是当前（2016年2月的）排名状况：

下面，咱们就按照这个排名的顺序，简单介绍一下这些时序列数据库中的一些。下面要介绍的 TSDB 以开源的为主，若是是商业或者 SaaS 服务，也简单介绍一下其特色，让你们能对其余领域的事物也有所了解。

这里有一个例外，就是 Pinot 并不在这个排名里，可是我也把它列在了这里。

1. InfluxDB

InfluxDB 由 Golang 语言编写，也是由 Golang 编写的软件中比较著名的一个，在不少 Golang 的沙龙或者文章中可能都会把 InfluxDB 当标杆来介绍，这也间接帮助 InfluxDB 提升了知名度。

InfluxDB的主要特色包括下面这些：

• schemaless(无结构)，能够是任意数量的列

• 可扩展（集群）

• 方便、强大的查询语言

• Native HTTP API

• 集成了数据采集、存储、可视化功能

• 实时数据 Downsampling

• 高效存储，使用高压缩比算法，支持retention polices

InfluxDB 是 TSDB 中为数很少的进行了用户和角色方面实现的，提供了 Cluster Admin、Database Admin 和 Database User 三种角色。

InfluxDB 的数据采集系统也支持多种协议和插件： - 行文本 - UDP - Graphite - CollectD - OpenTSDB

不过 InfluxDB 每次变更都较大，尤为是在存储和集群方面，追求平平安过日子，不想瞎折腾的能够考虑下。

注意：因为InfluxDB开发太活跃了，极可能你在网上搜到的资料都是老的，会害到你，因此你须要以官方文档为主。

一句话总结：欣欣向荣、值得一试。

2. RRDtool

RRDtool 全称为 Round Robin Database Tool，也就是用于操做 RRD 的工具，简单明了的软件名。

什么是 RRD 呢？简单来讲它就是一个循环使用的固定大小的数据库文件（其实也不太像典型的数据库）。

大致来讲，RRDtool 提供的主要工具以下：

• 建立RRD（rrdtool create）

• 更新RRD（rrdtool update）

• 画图（rrdtool graph）

这其中，画图功能是最复杂也是最强大的，甚至支持下面这些图形，这是其余 TSDB 中少见的：

• 指标比较，对两个指标值进行计算，描画出知足条件的区域

• 移动平均线

• 和历史数据进行对比

• 基于最小二乘法的线性预测

• 曲线预测

• 总之，它的画图功能太丰富了。

一句话总结：老牌经典、艺多不压身。

3. Graphite

Graphite 由 Orbitz, LLC 的 Chris Davis 创立于 2006 年，它主要有两个功能：

• 存储数值型时序列数据

• 根据请求对数据进行可视化（画图）

相应的，它的特色为：

• 分布式时序列数据存储，容易扩展

• 功能强大的画图Web API，提供了大量的函数和输出方式

• Graphite自己不带数据采集功能，可是你能够选择不少第三方插件，好比适用于* collectd、Ganglia或Sensu的插件等。同时，Graphite也支持Plaintext、Pickle和AMQP这些数据输入方式。

Graphite主要由三个模块组成：

• whisper：建立、更新RRD文件

• carbon：以守护进程的形式运行，接收数据写入请求

  • carbon-cache：数据存储

  • carbon-relay：分区和复制，位于carbon-cache以前，相似carbon-cache的负载均衡

  • carbon-aggregator：数据集计，用于减轻carbon-cache的负载

• graphite-web：用于读取、展现数据的Web应用

whisper 使用了相似 RRDtool 的 RRD 文件格式，它也不像 C/S 结构的软件同样，没有服务进程，只是做为 Python library 使用，提供对数据的 create/update/fetch 操做。

若是你对它的性能比较在乎，这里有一份老的数据可供参考。

Google、Etsy、GitHub、豆瓣、Instagram、Evernote 和 Uber 等不少知名公司都是 Graphite 的用户。有此背景，其可信度又加一层，并且网上的资料也至关的多，值得评估一下。

一句话总结：群众基础好、能够参考。

4. OpenTSDB

OpenTSDB 是一个分布式、可伸缩的时间序列数据库。它支持豪秒级数据采集全部 metrics，支持永久存储（不须要 downsampling），和 InfluxDB 相似，它也是无模式，以 tag 来实现维度的概念。

好比，这就是它的一个metric例子：

mysql.bytes_received 1287333217 66666666 schema=foo host=db1

OpenTSDB 的节点称为 TSD（Time Series Daemon (TSD)），它没有主、从之分，消除了单点隐患，很是容易扩展。它主要以HBase做为存储系统，如今也增长了对 Cassandra 和 Bigtable（非云端）。

OpenTSDB 以数据存储和查询为主，附带了一个简单地图形界面（依赖Gnuplot），共开发、调试使用。

一句话总结：好用，咱们的产品Cloud Insight 也在用这项技术来实现对性能指标进行聚合、分组、过滤。

5.KDB+

全部 TSDB 中，估计就数这个最酷了，我说的是域名，只有两个字母，猥琐地想一下，域名就值不少钱 ：-）。

kdb+是一个面向列的时序列数据库，以及专门为其设计的查询语言q（和他们的域名同样简短）。Kdb+ 混合使用了流、内存和实时分析，速度很快，支持分析 10 亿级别的记录以及快速访问TB级别的历史数据。

不过这是一个商业产品，可是也提供了免费版本（貌似还限制在32位）。

6.KairosDB

KairosDB 是一个 OpenTSDB 的 fork，不过是基于 Cassandra 存储的。因为 Cassandra 的行比 HBase 宽，因此 KairosDB 的 Cassandra 的默认行大小为 3 星期，而 OpenTSDB 的 HBase 则为 1 小时。

KairosDB 支持经过 Telnet、Rest、Graphite 等协议写入数据，你也能够经过编写插件本身实现数据写入。

KairosDB 也提供了基于 Web API 的查询接口，支持数据聚合、持过滤和分组等功能。

同时 KairosDB 提供了一个供开发用的 Web UI，图形绘制引擎使用了 Flot。

和 OpenTSDB 相似，KairosDB 也提供了插件机制，你可使用插件完成以下工做：

• 添加数据点（data point）监听器

• 添加新的数据存储服务

• 添加新的协议处理程序

• 添加自定义系统监视服务

7.Druid

Druid 是一个快速、近实时的海量数据 OLAP 系统，而且是开源的。Druid 诞生于 Metamarkets，后来一些核心人员创立了 IMPLY 公司，进行 Druid 相关的产品开发。

Druid 会按时间来进行分区（segment），而且是面向列存储的。它的主要特性以下：

• 支持嵌套数据的列式存储

• 层级查询

• 二级索引

• 实时数据摄取

• 分布式容错架构

根据去年末 druid.io 的白皮书，如今生产环境下最大的集群规模以下：

• 3M EVENTS / SECOND SUSTAINED (200B+ EVENTS/DAY)

• 10 – 100K EVENTS / SECOND / CORE

• 500TB OF SEGMENTS (>50 TRILLION RAW EVENTS)

• 5000 CORES (>400 NODES, >100TB RAM)

• QUERY LATENCY (500MS AVERAGE)

• 90% < 1S 95% < 2S 99% < 10S

• 3+ trillion events/month

• 3M+ events/sec through Druid’s real-time ingestion

• 100+ PB of raw data

• 50+ trillion events

Druid 企业用户比较多，好比 OneAPM、Netflix 和 Paypal 等。具体能够参考 http://druid.io/druid-powered.html 。

Druid 架构比较复杂，所以对部署和运维也有必定的负担，好比须要的机器多、机器配置要高（尤为是内存）。

一句话总结：好用，咱们在用。

8.Prometheus

Prometheus 是一个开源的服务监控系统和时序列数据库，由社交音乐平台 SoundCloud 在2012年开发，最近也变得很流行，最新版本为 0.17.0rc2。

Prometheus 从各类输入源采集 metric，进行计算后显示结果，或者根据指定条件出发报警。

和其余监控系统相比，Prometheus 的特色包括：

• 多维数据模型（时序列数据由metric名和一组key/value组成）

• 灵活的查询语言

• 不依赖分布式存储，单台服务器便可工做

• 经过基于HTTP的pull方式采集是序列数据

• 能够经过中间网关进行时序列数据推送

• 多种可视化和仪表盘支持

因为 Prometheus 采用了相似 OpenTSDB 和 InfluxDB 的 key/value 维度机制，因此若是你对任一种 TSDB 有了解的话，学习起来会简单些。

一句话总结：貌似比较火，何不试一试？

9.Pinot

Pinot 是一个开源的实时、分布式 OLAP 数据存储方案。它来自 Linkedin，虽然 Linkedin 最近估价表现不好，可是他们建立的各类软件、中间件实在太多了。这一点咱们作软件的都应该向 Linkedin 表示感谢。

Pinot 就像是一个 Druid 的 copy，不过二者的灵感都来源于SenseiDB（Sensei 在日语里为老师的意思，写成汉字为“先生”）。

Pinot 也像 Druid 同样，能加载 offline 数据（Hadoop 文件）和实时数据（Kafka）。Pinot 从设计上就面向水平扩展。

Pinot 主要特色：

• 面向列

• 插拔式索引引擎：排序索引、位图索引和反向索引

• 根据查询语句和segment信息对查询/执行计划进行优化

• 从 Kafka 实时数据摄取（ingestion）

• 从 Hadoop 进行批量摄取

• 相似 SQL 的查询语言，支持聚合、过滤、分组、排序和惟一处理。

• 支持多值字段

• 水平扩展和容错

Pinot 的特色和 Druid 很像，二者可互为参考。

一句话总结：背靠大树好乘凉。

小结

这里咱们为你们介绍了几种常见 TSDB，如不出意外，你可能会在这里选择某一种来使用。

尽管如此，咱们仍是会为你们介绍更多一些的项目，让你们能更多的了解一些不一样的 TSDB 及其特色，也能帮助读者深刻了解 TSDB 的各类场景，开阔思路。

在下一篇文章中，咱们将会为各位再介绍几种时序列数据库。

这是本系列文章的其余部分：

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

• 时序列数据库武斗大会之 OpenTSDB 篇

• 时序列数据库武斗大会之 TSDB 名录 Part 2

本文转自 OneAPM 官方博客