時間序列數據庫(TSDB)初識與選擇

時間序列數據庫(TSDB)初識與選擇

本文作者由 MageByte 團隊的 「借來方向」編寫,關注公衆號 給你更多硬核技術

背景

這兩年互聯網行業掀着一股新風,總是聽着各種高大上的新名詞。大數據、人工智能、物聯網、機器學習、商業智能、智能預警啊等等。

以前的系統,做數據可視化,信息管理,流程控制。現在業務已經不僅僅滿足於這種簡單的管理和控制了。數據可視化分析,大數據信息挖掘,統計預測,建模仿真,智能控制成了各種業務的追求。

“所有一切如淚水般消失在時間之中,時間正在死去“,以前我們利用互聯網解決現實的問題。現在我們已經不滿足於現實,數據將連接成時間序列,往前可以觀其歷史,揭示其規律性,往後可以把握其趨勢性,預測其走勢。

我們開始存儲大量的數據,並總結出這些數據的結構特點和常見使用場景,不斷改進和優化,創造了一種新型的數據庫分類——時間序列數據庫(time series database).

時間序列模型

時間序列數據庫主要用於處理帶時間標籤(按照時間的順序變化,即時間序列化)的數據,帶時間標籤的數據也稱爲時間序列數據。

每個時序點結構如下:

  • timestamp: 數據點的時間,表示數據發生的時間。
  • metric: 指標名,當前數據的標識,有些系統中也稱爲 name。
  • value: 值,數據的數值,一般爲 double 類型,如 cpu 使用率,訪問量等數值,有些系統一個數據點只能有一個 value,多個 value 就是多條時間序列。有些系統可以有多個 value 值,用不同的 key 表示
  • tag: 附屬屬性。
tsdb
tsdb

實現

假如我想記錄一系列傳感器的時間序列數據。數據結構如下:

* 標識符:device_id,時間戳
* 元數據:location_id,dev_type,firmware_version,customer_id
* 設備指標:cpu_1m_avg,free_mem,used_mem,net_rssi,net_loss,電池
* 傳感器指標:溫度,溼度,壓力,CO,NO2,PM10

如果使用傳統 RDBMS 存儲,建一張如下結構的表即可: table 如此便是一個最簡單的時間序列庫了。但這只是滿足了時間序列數據模型的需要。我們還需要在性能,高效存儲,高可用,分佈式和易用性上做更多的事情。

大家可以思考思考,如果讓我們自己來實現一個時間序列數據庫,你會怎麼設計,你會考慮哪些性能上的優化,又如何做到高可用,怎樣做到簡單易用。

Timescale

這個數據庫其實就是一個基於傳統關係型數據庫 postgresql 改造的時間序列數據庫。瞭解 postgresql 的同學都知道,postgresql 是一個強大的,開源的,可擴展性特別強的一個數據庫系統。

於是 timescale.inc 在 postgresql 架構上開發了 Timescale,一款兼容 sql 的時序數據庫。 作爲一個 postgresql 的擴展提供服務。其特點如下:

基礎:

  • 支持所有 PostgreSQL 原生 SQL,包含完整 SQL 接口(包括輔助索引,非時間聚合,子查詢,JOIN,窗口函數)。
  • 用 PostgreSQL 的客戶端或工具,可以直接應用到該數據庫,不需要更改。
  • 時間爲導向的特性,API 功能和相應的優化。
  • 可靠的數據存儲。

擴展:

  • 透明時間/空間分區,用於放大(單個節點)和擴展。
  • 高數據寫入速率(包括批量提交,內存中索引,事務支持,數據備份支持)。
  • 單個節點上的大小合適的塊(二維數據分區),以確保即使在大數據量時也可快速讀取。
  • 塊之間和服務器之間的並行操作。

劣勢:

  • 因爲 TimescaleDB 沒有使用列存技術,它對時序數據的壓縮效果不太好,壓縮比最高在 4X 左右
  • 目前暫時不完全支持分佈式的擴展(正在開發相關功能),所以會對服務器單機性能要求較高

其實大家都可以去深入瞭解一下這個數據庫。對 RDBMS 我們都很熟悉,瞭解這個可以讓我們對 RDBMS 有更深入的見解,瞭解其實現機制,存儲機制。在對時間序列的特殊化處理之中,我們又可以學到時間序列數據的特點,並學習到如何針對時間序列模型去優化 RDBMS。

之後我們也可以寫一篇文章來深入的瞭解一下這個數據庫的特點。

Influxdb

Influxdb 是業界比較流行的一個時間序列數據庫,特別是在 IOT 和監控領域十分常見。其使用 go 語言開發,突出特點是性能。 特性:

  • 高效的時間序列數據寫入性能。自定義 TSM 引擎,快速數據寫入和高效數據壓縮。
  • 無額外存儲依賴。
  • 簡單,高性能的 HTTP 查詢和寫入 API。
  • 以插件方式支持許多不同協議的數據攝入,如:graphite,collectd,和 openTSDB
  • SQL-like 查詢語言,簡化查詢和聚合操作。
  • 索引 Tags,支持快速有效的查詢時間序列。
  • 保留策略有效去除過期數據。
  • 連續查詢自動計算聚合數據,使頻繁查詢更有效。

Influxdb 已經將分佈式版本轉爲閉源。所以在分佈式集羣這塊是一個弱點,需要自己實現。

OpenTSDB

The Scalable Time Series Database. 打開 OpenTSDB 官網,第一眼看到的就是這句話。可見其將 Scalable 作爲自己重要的”賣點“。OpenTSDB 運行在 Hadoop 和 HBase 上,其充分利用 HBase 的特性。通過獨立的 Time Series Demon(TSD)提供服務,所以它可以通過增減服務節點來輕鬆擴縮容。

tsdb-architecture
tsdb-architecture
  • Opentsdb 是一個基於 Hbase 的時間序列數據庫(新版也支持 Cassandra)。

    其基於 Hbase 的分佈式列存儲特性實現了數據高可用,高性能寫的特性。受限於 Hbase,存儲空間較大,壓縮不足。依賴整套 HBase, ZooKeeper

  • 採用無模式的 tagset 數據結構(sys.cpu.user 1436333416 23 host=web01 user=10001)

    結構簡單,多 value 查詢不友好

  • HTTP-DSL 查詢

OpenTSDB 在 HBase 上針對 TSDB 的表設計和 RowKey 設計值得我們深入學習的一個特點。有興趣的同學可以找一些詳細的資料學習學習。

Druid

Druid 是一個實時在線分析系統(LOAP)。其架構融合了實時在線數據分析,全文檢索系統和時間序列系統的特點,使其可以滿足不同使用場景的數據存儲。

  • 採用列式存儲:支持高效掃描和聚合,易於壓縮數據。
  • 可伸縮的分佈式系統:Druid 自身實現可伸縮,可容錯的分佈式集羣架構。部署簡單。
  • 強大的並行能力:Druid 各集羣節點可以並行地提供查詢服務。
  • 實時和批量數據攝入:Druid 可以實時攝入數據,如通過 Kafka。也可以批量攝入數據,如通過 Hadoop 導入數據。
  • 自恢復,自平衡,易於運維:Druid 自身架構即實現了容錯和高可用。不同的服務節點可以根據負載需求添加或減少節點。
  • 容錯架構,保證數據不丟失:Druid 數據可以保留多副本。另外可以採用 HDFS 作爲深度存儲,來保證數據不丟失。
  • 索引:Druid 對 String 列實現反向編碼和 Bitmap 索引,所以支持高效的 filter 和 groupby。
  • 基於時間分區:Druid 對原始數據基於時間做分區存儲,所以 Druid 對基於時間的範圍查詢將更高效。
  • 自動預聚合:Druid 支持在數據攝入期就對數據進行預聚合處理。

Druid 架構蠻複雜的。其按功能將整個系統細分爲多種服務,query、data、master 不同職責的系統獨立部署,對外提供統一的存儲和查詢服務。其以分佈式集羣服務的方式提供了一個底層數據存儲的服務。

druid-architecture
druid-architecture

Druid 在架構上的設計很值得我們學習。如果你不僅僅對時間序列存儲感興趣,對分佈式集羣架構也有興趣,不妨看看 Druid 的架構。另外 Druid 在 segment(Druid 的數據存儲結構)的設計上也是一大亮點,即實現了列式存儲,又實現了反向索引。

Elasticsearch

Elasticsearch 是一個分佈式的開源搜索和分析引擎,適用於所有類型的數據,包括文本、數字、地理空間、結構化和非結構化數據。Elasticsearch 在 Apache Lucene 的基礎上開發而成,由 Elasticsearch N.V.(即現在的 Elastic)於 2010 年首次發佈。Elasticsearch 以其簡單的 REST 風格 API、分佈式特性、速度和可擴展性而聞名。

Elasticsearch 以 ELK stack 被人所熟知。許多公司基於 ELK 搭建日誌分析系統和實時搜索系統。之前我所在團隊在 ELK 的基礎上開始開發 metric 監控系統。即想到了使用 Elasticsearch 來存儲時間序列數據庫。對 Elasticserach 的 mapping 做相應的優化,使其更適合存儲時間序列數據模型,收穫了不錯的效果,完全滿足了業務的需求。後期發現 Elasticsearch 新版本竟然也開始發佈 Metrics 組件和 APM 組件,並大量的推廣其全文檢索外,對時間序列的存儲能力。真是和我們當時的想法不謀而合。

Elasticsearch 的時序優化可以參考一下這篇文章:《elasticsearch-as-a-time-series-data-store》

也可以去了解一下 Elasticsearch 的 Metric 組件Elastic Metrics

Beringei

Beringei 是 Facebook 在 2017 年最新開源的一個高性能內存時序數據存儲引擎。其具有快速讀寫和高壓縮比等特性。

2015 年 Facebook 發表了一篇論文《Gorilla: A Fast, Scalable, In-Memory Time Series Database 》,Beringei 正是基於此想法實現的一個時間序列數據庫。

Beringei 使用 Delta-of-Delta 算法存儲數據,使用 XOR 編碼壓縮數值。使其可以用很少的內存即可存儲下大量的數據。

如何選擇一個適合自己的時間序列數據庫

  • Data model

    時間序列數據模型一般有兩種,一種無 schema,具有多 tag 的模型,還有一種 name、timestamp、value 型。前者適合多值模式,對複雜業務模型更適合。後者更適合單維數據模型。

  • Query language

    目前大部分 TSDB 都支持基於 HTTP 的 SQL-like 查詢。

  • Reliability

    可用性主要體現在系統的穩定高可用上,以及數據的高可用存儲上。一個優秀的系統,應該有一個優雅而高可用的架構設計。簡約而穩定。

  • Performance

    性能是我們必須考慮的因素。當我們開始考慮更細分領域的數據存儲時,除了數據模型的需求之外,很大的原因都是通用的數據庫系統在性能上無法滿足我們的需求。大部分時間序列庫傾向寫多讀少場景,用戶需要平衡自身的需求。下面會有一份各庫的性能對比,大家可以做一個參考。

  • Ecosystem

    我一直認爲生態是我們選擇一個開源組件必須認真考慮的一個問題。一個生態優秀的系統,使用的人多了,未被發現的坑也將少了。另外在使用中遇到問題,求助於社區,往往可以得到一些比較好的解決方案。另外好的生態,其周邊邊界系統將十分成熟,這讓我們在對接其他系統時會有更多成熟的方案。

  • Operational management

    易於運維,易於操作。

  • Company and support

    一個系統其背後的支持公司也是比較重要的。背後有一個強大的公司或組織,這在項目可用性保證和後期維護更新上都會有較大的體驗。

性能對比

Timescale InfluxDB OpenTSDB Druid Elasticsearch Beringei
write(single node) 15K/sec 470k/sec 32k/sec 25k/sec 30k/sec 10m/sec
write(5 node) 128k/sec 100k/sec 120k/sec

總結

最後總結一下:

  • 如果你想要一個極限性能的系統可以考慮 Beringei 和 InfluxDB,在數據高可用方面,可以採用客戶端雙寫模式來對數據做一個副本,保證數據的可用性。
  • 如果你數據量不大,性能要求也不是特別高,卻又點查詢,刪除和關聯查詢等需求,不妨考慮一下 Timescale。
  • 如果你間距索引和時間序列的需求。那麼 Druid 和 Elasticsearch 是最好的選擇。其性能都不差,並且都是高可用容錯架構。

最後

之後我們可以來深入瞭解一兩個 TSDB,比如 Influxdb,Druid,Elasticsearch 等。並可以學習一下行存儲與列存儲的不同,LSM 的實現原理,數值數據的壓縮,MMap 提升讀寫性能的知識等。

關注公衆號,掌握更多硬核技術

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章