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

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

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

10.Geras

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

Geras 速度很是快，它支持对任什么时候间精度进行 Rollup，也支持保存原始数据的精度。它专门为写操做进行了优化，能够接收海量设备的数据输入。

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

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

Geras 支持多种技术来进行数据存储、查询和展现，好比 HTTPS、JSON、RESTful、SenML、MQTT、HyperCat，设备数据能够经过 HTTP POST 或者轻量 MQTT 发布。

11.Akumuli

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 目前还处于开发状态，不适合在生产环境下使用。

12.Atlas

这个和波士顿动力的机器人 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 友好的语法来支持复杂的数据查询。

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

13.Blueflood

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 的多维度方案。

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

14.Gnocchi

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。

15.Newts

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

Newts 基于 Cassandra，对写优化、彻底分布式，吞吐量很是高；经过将相似的 metric 分组存储，让写和读更高效。

16.SiteWhere

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 以对这个系统有更深刻的了解。

17.TempoIQ

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 仪表盘、应用和可视化组件，并且不须要任何编码工做。

18.Riak TS

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

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

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

19.Cyanite

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）

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

20.总结

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

本系列其余文章：

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