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

摘要：在前面时序列数据库武斗大会之名录我们已经介绍了一些常见的，这里我们再对剩余的一些做些简单介绍。是一个多租户的时间序列和资源数据库。是基于的时序列数据库。

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

在前面《时序列数据库武斗大会之 TSDB 名录 Part 1》我们已经介绍了一些常见的 TSDB，这里我们再对剩余的一些TSDB 做些简单介绍。

Geras 是一个专注于 IoT 的领域（当然不仅限于传感器采集到的数据）可扩展的、分布式的时序列数据库，用于帮助用户进行快速分析。Geras 是一个 SaaS 服务，但是你也可以购买软件自己部署、托管。Geras 提供了免费版，它不对数据存储的时间和数据量做任何限制，只是不提供 SLA 而已。不过他们的 SaaS 主页我却一直没打开过，貌似该 DNS 记录已经不存在了，官方相关资料也不多，真怀疑这个项目已经废弃了，该产品已经演化为新产品。

Geras 速度非常快，它支持对任何时间精度进行 Rollup，也支持保存原始数据的精度。它专门为写操作进行了优化，可以接收海量设备的数据输入。

Geras 运行在容错、分布式数据存储之上，支持水平扩展，可以在不停止服务的前提下对系统容量进行调整。

Geras 也提供了一套可视化界面，方便的对设备、传感器等进行管理，对 metric 进行图表的可视化等。

Geras 支持多种技术来进行数据存储、查询和展示，比如 HTTPS、JSON、RESTful、SenML、MQTT、HyperCat，设备数据可以通过 HTTP POST 或者轻量 MQTT 发布。

Akumuli 名称来自 accumulate，是一个数值型时间序列数据库，可以存储、处理时序列数据。

它的特点如下：

基于日志结构的存储

支持无序数据

实时压缩

基于HTTP的JSON查询支持

支持面向行和面向列的存储

将最新数据放入内存存储

通过metric和tag组织时序列数据，并且可以通过tag进行join操作。

Resampling (PAA transform)，滑动窗口

通过基于TCP或UDP的协议接收数据（支持百万数据点每秒）

Continuous queries (streaming)

Akumuli 由两部分组成：存储引擎和服务程序。目前只有存储引擎被实现了，而且存储引擎可以在没有服务程序的情况下作为嵌入式数据库多带带使用（类似sqlite），也就是说，你得通过自己编写程序使用它的 API 来实现数据读写。

Akumuli 的数据协议基于 Redis，它的数据格式也和前面看到的不太一样，比如：

每条数据由三部分组成，第一部分称为 ID，可以是数值型（以“：”开始），或者是字符串（以“+”开始），比如这个例子中，cpu host=machine1 region= europe就是 ID，它由两部分组成，cpu 是metric，host和region则被称为 key。

数据的第二部分可以是时间戳（:1418224205），这里的格式为ISO 8601（+20141210T074343.999999）

第三部分为值部分。

类似上面的数据结构，它的query也比较容易理解：

Akumuli 目前还处于开发状态，不适合在生产环境下使用。

这个和波士顿动力的机器人 Atlas，以及其他很多知名软件（HashiCorp、O"reilly）都重名了。

Atlas 用于存储带维度信息的时序列数据，由 Netflix 开发，用于实时分析。Atlas 使用了基于内存的存储，速度非常快。在 2011 年的时候，Netflix 使用自己开发的 Epic 工具来管理时序列数据，这是一个采用 perl、RRDTool 和 MySQL 构建的系统，但是随着数据量的增大（2M->1.2B），他们创建了这个新项目。

如果说商业智能（business intelligence）是从数据基于时间分析出趋势的话，那么 Atlas 可以说是一种运维智能（operational intelligence），能给用户描述出当前系统所发生的所有情况。

Atlas 的设计目标主要有3点：

通用API

可扩展

维度支持

Atlas 具备和 OpenTSDB 以及 InfluxDB 类似的metric/datapoint/tag的概念，同时它也有自己独自的特性，比如增加了步长（step-size）的概念。

Atlas 采用了类似 RRDtool 的查询语法，它们都通过一种对 URL 友好的语法来支持复杂的数据查询。

一句话点评：背靠大树好乘凉，可以试试。

Blueflood 由 Rackspace 的 Cloud Monitoring 团队创建，用于管理 Cloud Monitoring 系统产生的 metric 数据。如果你还不熟悉 Rackspace 这个公司的话，可以去网上了解一下，它也是比较大的云计算公司。

除了自己使用，Rackspace 还提供了免费的 Blueflood-as-a-Service，此外还有一些大公司也在准备使用 Blueflood。

Blueflood 特点如下：

built on top of Cassandra

基于HTTP API/JSON的数据采集（ingest）和读取

支持数值、布尔和字符串metric data

多租户

水平扩展

Blueflood 主要由以下模块构成：

Ingest - 采集/写入数据

Rollup - 聚合计算

Query - 处理用户查询

不过遗憾的是 Blueflood 现在没有一个类似 tag 的多维度方案。

一句话点评：背靠大树好乘凉，可以试试。

Gnocchi 是 OpenStack 项目的一部分，但它也能独立工作。

Gnocchi 是一个多租户的时间序列、metric 和资源（resource）数据库。它提供了一组 HTTP REST API 来创建和管理数据。

Gnocchi 以在云就算环境中存储大量 metric 信息为设计出发点，为用户提供 metric 和资源展示功能，同时它也很容易扩展。

Gnocchi 特点如下：

HTTP RES 接口

水平扩展

Metric 聚合

支持批处理

支持归档功能

按 Metric 值查找（这个在 TSDB 很少见）

多租户支持

对 Grafan 的支持

支持 Statsd 协议

Gnocchi 后端存储支持一下4种方式：

File

Swift

Ceph (推荐方式)

InfluxDB (实验功能)

前三种方式基于一个名为 Carbonara 的库，这个库负责对时间序列数据的管理，因为这三种存储方案本身并不关心数据的特点。InfluxDB 前面已经说过，本身就是一个 TSDB。

Newts 是基于 Cassandra 的时序列数据库。正如其名所示，它是一个 “New-fangled Timeseries Data Store”。它的开发者是 OpenNMS，这也是一个知名的开源网络监控和管理平台。

Newts 基于 Cassandra，对写优化、完全分布式，吞吐量非常高；通过将类似的 metric 分组存储，让写和读更高效。

SiteWhere 是一个开源的 IoT 开放平台，帮助用户快速将 IoT 应用推向市场。SiteWhere 提供了一套完整的设备管理解决方案，通过 MQTT、AMQP、Stomp 和其他协议连接设备，支持自注册、REST 和批处理方式注册设备。

SiteWhere 也提供了可扩展的大数据解决方案，底层采用经优化的 MongoDB 和 HBase，为存储设备事件提供了时序列数据库，且经过 Hortonworks 和 Cloudera 的测试。

SiteWhere 还内嵌了 Siddhi 用于 Complex Event Processing （CEP），提供了 Azure EventHub、Apache Solr 以及 Twilio 的集成，以及 Android 和 Arduino 平台开发用的 SDK。

SiteWhere 的部署方式也很灵活，支持公有云、私有机房，Ubuntu Juju 和 Docker 的部署方式。

SiteWhere 也支持多租户，不同的租户数据分开存储，还能为不同的租户提供不同的处理引擎，租户的启动、停止互不影响。

SiteWhere 的 service provider interfaces（SPIs） 提供了平台的核心对象模型，第三方可以对平台进行扩展。

一句话点评：开源、功能强大、一体化方案。作为 IoT 平台，SiteWhere 算是这几个中不错的。

建议你接着看一下它的 System Overview 和 System Architecture 以对这个系统有更深入的了解。

TempoIQ 也是一个 IoT 平台服务，它能帮助用户快速、灵活的的创建 IoT 应用，提供了实时的数据分析、报警、仪表盘、报告功能。2014 年 7 月从 TempoDB 改名为 TempoIQ，它的很多组件都有 IQ 结尾，代表智商很高？

TempoIQ 主要由以下几个部分组成：

CloudIQ

TempoIQ 采用第四代 CoDA（Context Delivery Architecture）架构，用户可以不必心系复杂的基础设施就可以部署 IoT 应用。

ConnectIQ

基于数据事件的 API，用于连接任何设备，支持灵活的事件数据模型：REST API、HTTPs 和 MQTT。它不关心设备来源，可以及时进行数据流处理，不需要提前安装和配置。

DataIQ

对所有 IoT 数据和分析报告进行安全、持久的存储，并提供报告下载功能。

AnalyzeIQ

用户可以创建分析流（custom analytics streams）来洞悉 IoT 数据实时状态，自动将数据存储到 DataIQ。并可以创建报警来持续监控分析流，当有超预期的变动或者达到致命条件时进行实时报警。

ViewIQ
用户使用 ViewIQ 可以创建实时的 IoT 仪表盘、应用和可视化组件，而且不需要任何编码工作。

Riak 作为 NoSQL 和 K/V 存储可能更有名，而 Riak TS 是一个为时序列和为存储 IoT 数据进行了优化的 NoSQL 数据库软件。

在官方主页上写道：“Riak TS is engineered to be faster than Cassandra”。

由于其非开源性，网上（包括官网）详细资料都不是特别多。

Cyanite 是一个用于接收和存储时序列数据的守护进程，它的设计目标是兼容 Graphite 生态系统。

Cyanite 默认使用 Apache Cassandra 来存储时序列数据，它的特点如下：

可扩展性

基于 Cassandra，Cyanite 可以实现高可用、具有弹性，以及低延迟的存储。

兼容性
由于 Graphite 已经成为事实上管理时序列数据的标准，不管是使用 graphite-web 还是 Grafana。Cyanite 将会尽可能的保持与这些生态系统的兼容以提供简单地交互模式。

Cyanite 是一个典型的流式处理模型，它接收数据，对数据进行标准化，然后进行输出。它的交互图如下所示：

它的工作流程如下：

每条输入都会产生规范化的 metrics，并添加到消息队列

核心引擎从队列取出数据并处理。

通过存储和索引组件进行时序列数据的存储和 metric 名的索引

API 组件用于处理引擎和其他查询、存储模块的交互

Cyanite 的输入模块支持 Carbon（Graphite组件），而 Kafka 和 Pickle 则还在计划中。

索引（Index）模块则用于对 metric 名进行索引和查询。这一模块有两种实现方式：

memory 用于在内存中存储反向索引

elasticsearch 用于在 elasticsearch 中存储 metric 名（path-names）

一句话总结：新生事物、值得关注。

这里只是简单的罗列了一些项目，及其简单说明。
在后续的文章中，我们还会选择一些常见的 TSDB 进行实例讲解。

本系列其他文章：

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

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

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

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