【編者按】
劉斌，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 進行實例講解。
本系列其他文章：
