摘要：在前面時序列數(shù)據(jù)庫武斗大會之名錄我們已經(jīng)介紹了一些常見的，這里我們再對剩余的一些做些簡單介紹。是一個多租戶的時間序列和資源數(shù)據(jù)庫。是基于的時序列數(shù)據(jù)庫。

【編者按】
劉斌，OneAPM后端研發(fā)工程師，擁有10多年編程經(jīng)驗，參與過大型金融、通信以及Android手機操作系的開發(fā)，熟悉Linux及后臺開發(fā)技術(shù)。曾參與翻譯過《第一本Docker書》、《GitHub入門與實踐》、《Web應(yīng)用安全權(quán)威指南》、《WEB+DB PRESS》、《Software Design》等書籍，也是Docker入門與實踐課程主講人。本文所闡述的「時間序列數(shù)據(jù)庫」，系筆者所負責(zé)產(chǎn)品 Cloud Insight 對性能指標進行聚合、分組、過濾過程中的梳理和總結(jié)。

在前面《時序列數(shù)據(jù)庫武斗大會之 TSDB 名錄 Part 1》我們已經(jīng)介紹了一些常見的 TSDB，這里我們再對剩余的一些TSDB 做些簡單介紹。

Geras 是一個專注于 IoT 的領(lǐng)域（當(dāng)然不僅限于傳感器采集到的數(shù)據(jù)）可擴展的、分布式的時序列數(shù)據(jù)庫，用于幫助用戶進行快速分析。Geras 是一個 SaaS 服務(wù)，但是你也可以購買軟件自己部署、托管。Geras 提供了免費版，它不對數(shù)據(jù)存儲的時間和數(shù)據(jù)量做任何限制，只是不提供 SLA 而已。不過他們的 SaaS 主頁我卻一直沒打開過，貌似該 DNS 記錄已經(jīng)不存在了，官方相關(guān)資料也不多，真懷疑這個項目已經(jīng)廢棄了，該產(chǎn)品已經(jīng)演化為新產(chǎn)品。

Geras 速度非?？欤С謱θ魏螘r間精度進行 Rollup，也支持保存原始數(shù)據(jù)的精度。它專門為寫操作進行了優(yōu)化，可以接收海量設(shè)備的數(shù)據(jù)輸入。

Geras 運行在容錯、分布式數(shù)據(jù)存儲之上，支持水平擴展，可以在不停止服務(wù)的前提下對系統(tǒng)容量進行調(diào)整。

Geras 也提供了一套可視化界面，方便的對設(shè)備、傳感器等進行管理，對 metric 進行圖表的可視化等。

Geras 支持多種技術(shù)來進行數(shù)據(jù)存儲、查詢和展示，比如 HTTPS、JSON、RESTful、SenML、MQTT、HyperCat，設(shè)備數(shù)據(jù)可以通過 HTTP POST 或者輕量 MQTT 發(fā)布。

Akumuli 名稱來自 accumulate，是一個數(shù)值型時間序列數(shù)據(jù)庫，可以存儲、處理時序列數(shù)據(jù)。

它的特點如下：

基于日志結(jié)構(gòu)的存儲

支持無序數(shù)據(jù)

實時壓縮

基于HTTP的JSON查詢支持

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

將最新數(shù)據(jù)放入內(nèi)存存儲

通過metric和tag組織時序列數(shù)據(jù)，并且可以通過tag進行join操作。

Resampling (PAA transform)，滑動窗口

通過基于TCP或UDP的協(xié)議接收數(shù)據(jù)（支持百萬數(shù)據(jù)點每秒）

Continuous queries (streaming)

Akumuli 由兩部分組成：存儲引擎和服務(wù)程序。目前只有存儲引擎被實現(xiàn)了，而且存儲引擎可以在沒有服務(wù)程序的情況下作為嵌入式數(shù)據(jù)庫多帶帶使用（類似sqlite），也就是說，你得通過自己編寫程序使用它的 API 來實現(xiàn)數(shù)據(jù)讀寫。

Akumuli 的數(shù)據(jù)協(xié)議基于 Redis，它的數(shù)據(jù)格式也和前面看到的不太一樣，比如：

每條數(shù)據(jù)由三部分組成，第一部分稱為 ID，可以是數(shù)值型（以“：”開始），或者是字符串（以“+”開始），比如這個例子中，cpu host=machine1 region= europe就是 ID，它由兩部分組成，cpu 是metric，host和region則被稱為 key。

數(shù)據(jù)的第二部分可以是時間戳（:1418224205），這里的格式為ISO 8601（+20141210T074343.999999）

第三部分為值部分。

類似上面的數(shù)據(jù)結(jié)構(gòu)，它的query也比較容易理解：

Akumuli 目前還處于開發(fā)狀態(tài)，不適合在生產(chǎn)環(huán)境下使用。

這個和波士頓動力的機器人 Atlas，以及其他很多知名軟件（HashiCorp、O"reilly）都重名了。

Atlas 用于存儲帶維度信息的時序列數(shù)據(jù)，由 Netflix 開發(fā)，用于實時分析。Atlas 使用了基于內(nèi)存的存儲，速度非?？?。在 2011 年的時候，Netflix 使用自己開發(fā)的 Epic 工具來管理時序列數(shù)據(jù)，這是一個采用 perl、RRDTool 和 MySQL 構(gòu)建的系統(tǒng)，但是隨著數(shù)據(jù)量的增大（2M->1.2B），他們創(chuàng)建了這個新項目。

如果說商業(yè)智能（business intelligence）是從數(shù)據(jù)基于時間分析出趨勢的話，那么 Atlas 可以說是一種運維智能（operational intelligence），能給用戶描述出當(dāng)前系統(tǒng)所發(fā)生的所有情況。

Atlas 的設(shè)計目標主要有3點：

通用API

可擴展

維度支持

Atlas 具備和 OpenTSDB 以及 InfluxDB 類似的metric/datapoint/tag的概念，同時它也有自己獨自的特性，比如增加了步長（step-size）的概念。

Atlas 采用了類似 RRDtool 的查詢語法，它們都通過一種對 URL 友好的語法來支持復(fù)雜的數(shù)據(jù)查詢。

一句話點評：背靠大樹好乘涼，可以試試。

Blueflood 由 Rackspace 的 Cloud Monitoring 團隊創(chuàng)建，用于管理 Cloud Monitoring 系統(tǒng)產(chǎn)生的 metric 數(shù)據(jù)。如果你還不熟悉 Rackspace 這個公司的話，可以去網(wǎng)上了解一下，它也是比較大的云計算公司。

除了自己使用，Rackspace 還提供了免費的 Blueflood-as-a-Service，此外還有一些大公司也在準備使用 Blueflood。

Blueflood 特點如下：

built on top of Cassandra

基于HTTP API/JSON的數(shù)據(jù)采集（ingest）和讀取

支持數(shù)值、布爾和字符串metric data

多租戶

水平擴展

Blueflood 主要由以下模塊構(gòu)成：

Ingest - 采集/寫入數(shù)據(jù)

Rollup - 聚合計算

Query - 處理用戶查詢

不過遺憾的是 Blueflood 現(xiàn)在沒有一個類似 tag 的多維度方案。

一句話點評：背靠大樹好乘涼，可以試試。

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

Gnocchi 是一個多租戶的時間序列、metric 和資源（resource）數(shù)據(jù)庫。它提供了一組 HTTP REST API 來創(chuàng)建和管理數(shù)據(jù)。

Gnocchi 以在云就算環(huán)境中存儲大量 metric 信息為設(shè)計出發(fā)點，為用戶提供 metric 和資源展示功能，同時它也很容易擴展。

Gnocchi 特點如下：

HTTP RES 接口

水平擴展

Metric 聚合

支持批處理

支持歸檔功能

按 Metric 值查找（這個在 TSDB 很少見）

多租戶支持

對 Grafan 的支持

支持 Statsd 協(xié)議

Gnocchi 后端存儲支持一下4種方式：

File

Swift

Ceph (推薦方式)

InfluxDB (實驗功能)

前三種方式基于一個名為 Carbonara 的庫，這個庫負責(zé)對時間序列數(shù)據(jù)的管理，因為這三種存儲方案本身并不關(guān)心數(shù)據(jù)的特點。InfluxDB 前面已經(jīng)說過，本身就是一個 TSDB。

Newts 是基于 Cassandra 的時序列數(shù)據(jù)庫。正如其名所示，它是一個 “New-fangled Timeseries Data Store”。它的開發(fā)者是 OpenNMS，這也是一個知名的開源網(wǎng)絡(luò)監(jiān)控和管理平臺。

Newts 基于 Cassandra，對寫優(yōu)化、完全分布式，吞吐量非常高；通過將類似的 metric 分組存儲，讓寫和讀更高效。

SiteWhere 是一個開源的 IoT 開放平臺，幫助用戶快速將 IoT 應(yīng)用推向市場。SiteWhere 提供了一套完整的設(shè)備管理解決方案，通過 MQTT、AMQP、Stomp 和其他協(xié)議連接設(shè)備，支持自注冊、REST 和批處理方式注冊設(shè)備。

SiteWhere 也提供了可擴展的大數(shù)據(jù)解決方案，底層采用經(jīng)優(yōu)化的 MongoDB 和 HBase，為存儲設(shè)備事件提供了時序列數(shù)據(jù)庫，且經(jīng)過 Hortonworks 和 Cloudera 的測試。

SiteWhere 還內(nèi)嵌了 Siddhi 用于 Complex Event Processing （CEP），提供了 Azure EventHub、Apache Solr 以及 Twilio 的集成，以及 Android 和 Arduino 平臺開發(fā)用的 SDK。

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

SiteWhere 也支持多租戶，不同的租戶數(shù)據(jù)分開存儲，還能為不同的租戶提供不同的處理引擎，租戶的啟動、停止互不影響。

SiteWhere 的 service provider interfaces（SPIs） 提供了平臺的核心對象模型，第三方可以對平臺進行擴展。

一句話點評：開源、功能強大、一體化方案。作為 IoT 平臺，SiteWhere 算是這幾個中不錯的。

建議你接著看一下它的 System Overview 和 System Architecture 以對這個系統(tǒng)有更深入的了解。

TempoIQ 也是一個 IoT 平臺服務(wù)，它能幫助用戶快速、靈活的的創(chuàng)建 IoT 應(yīng)用，提供了實時的數(shù)據(jù)分析、報警、儀表盤、報告功能。2014 年 7 月從 TempoDB 改名為 TempoIQ，它的很多組件都有 IQ 結(jié)尾，代表智商很高？

TempoIQ 主要由以下幾個部分組成：

CloudIQ

TempoIQ 采用第四代 CoDA（Context Delivery Architecture）架構(gòu)，用戶可以不必心系復(fù)雜的基礎(chǔ)設(shè)施就可以部署 IoT 應(yīng)用。

ConnectIQ

基于數(shù)據(jù)事件的 API，用于連接任何設(shè)備，支持靈活的事件數(shù)據(jù)模型：REST API、HTTPs 和 MQTT。它不關(guān)心設(shè)備來源，可以及時進行數(shù)據(jù)流處理，不需要提前安裝和配置。

DataIQ

對所有 IoT 數(shù)據(jù)和分析報告進行安全、持久的存儲，并提供報告下載功能。

AnalyzeIQ

用戶可以創(chuàng)建分析流（custom analytics streams）來洞悉 IoT 數(shù)據(jù)實時狀態(tài)，自動將數(shù)據(jù)存儲到 DataIQ。并可以創(chuàng)建報警來持續(xù)監(jiān)控分析流，當(dāng)有超預(yù)期的變動或者達到致命條件時進行實時報警。

ViewIQ
用戶使用 ViewIQ 可以創(chuàng)建實時的 IoT 儀表盤、應(yīng)用和可視化組件，而且不需要任何編碼工作。

Riak 作為 NoSQL 和 K/V 存儲可能更有名，而 Riak TS 是一個為時序列和為存儲 IoT 數(shù)據(jù)進行了優(yōu)化的 NoSQL 數(shù)據(jù)庫軟件。

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

由于其非開源性，網(wǎng)上（包括官網(wǎng)）詳細資料都不是特別多。

Cyanite 是一個用于接收和存儲時序列數(shù)據(jù)的守護進程，它的設(shè)計目標是兼容 Graphite 生態(tài)系統(tǒng)。

Cyanite 默認使用 Apache Cassandra 來存儲時序列數(shù)據(jù)，它的特點如下：

可擴展性

基于 Cassandra，Cyanite 可以實現(xiàn)高可用、具有彈性，以及低延遲的存儲。

兼容性
由于 Graphite 已經(jīng)成為事實上管理時序列數(shù)據(jù)的標準，不管是使用 graphite-web 還是 Grafana。Cyanite 將會盡可能的保持與這些生態(tài)系統(tǒng)的兼容以提供簡單地交互模式。

Cyanite 是一個典型的流式處理模型，它接收數(shù)據(jù)，對數(shù)據(jù)進行標準化，然后進行輸出。它的交互圖如下所示：

它的工作流程如下：

每條輸入都會產(chǎn)生規(guī)范化的 metrics，并添加到消息隊列

核心引擎從隊列取出數(shù)據(jù)并處理。

通過存儲和索引組件進行時序列數(shù)據(jù)的存儲和 metric 名的索引

API 組件用于處理引擎和其他查詢、存儲模塊的交互

Cyanite 的輸入模塊支持 Carbon（Graphite組件），而 Kafka 和 Pickle 則還在計劃中。

索引（Index）模塊則用于對 metric 名進行索引和查詢。這一模塊有兩種實現(xiàn)方式：

memory 用于在內(nèi)存中存儲反向索引

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

一句話總結(jié)：新生事物、值得關(guān)注。

這里只是簡單的羅列了一些項目，及其簡單說明。
在后續(xù)的文章中，我們還會選擇一些常見的 TSDB 進行實例講解。

本系列其他文章：

時序列數(shù)據(jù)庫武斗大會之TSDB名錄 Part 1

時序列數(shù)據(jù)庫武斗大會之TSDB名錄 Part 2

時序列數(shù)據(jù)庫武斗大會之 OpenTSDB 篇

時序列數(shù)據(jù)庫武斗大會之 KairosDB 篇