時(shí)間序列數(shù)據(jù)庫(kù)是什么？應(yīng)該如何選擇

時(shí)間序列數(shù)據(jù)庫(kù)是什么？應(yīng)該如何選擇，讓我們一起來(lái)看看吧。

背景

這兩年互聯(lián)網(wǎng)行業(yè)掀著一股新風(fēng)，總是聽著各種高大上的新名詞。大數(shù)據(jù)、人工智能、物聯(lián)網(wǎng)、機(jī)器學(xué)習(xí)、商業(yè)智能、智能預(yù)警啊等等。

站在用戶的角度思考問(wèn)題，與客戶深入溝通，找到武城網(wǎng)站設(shè)計(jì)與武城網(wǎng)站推廣的解決方案，憑借多年的經(jīng)驗(yàn)，讓設(shè)計(jì)與互聯(lián)網(wǎng)技術(shù)結(jié)合，創(chuàng)造個(gè)性化、用戶體驗(yàn)好的作品，建站類型包括：網(wǎng)站建設(shè)、做網(wǎng)站、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣、域名與空間、網(wǎng)頁(yè)空間、企業(yè)郵箱。業(yè)務(wù)覆蓋武城地區(qū)。

以前的系統(tǒng)，做數(shù)據(jù)可視化，信息管理，流程控制?，F(xiàn)在業(yè)務(wù)已經(jīng)不僅僅滿足于這種簡(jiǎn)單的管理和控制了。數(shù)據(jù)可視化分析，大數(shù)據(jù)信息挖掘，統(tǒng)計(jì)預(yù)測(cè)，建模仿真，智能控制成了各種業(yè)務(wù)的追求。

“所有一切如淚水般消失在時(shí)間之中，時(shí)間正在死去“，以前我們利用互聯(lián)網(wǎng)解決現(xiàn)實(shí)的問(wèn)題。現(xiàn)在我們已經(jīng)不滿足于現(xiàn)實(shí)，數(shù)據(jù)將連接成時(shí)間序列，可以往前可以觀其歷史，揭示其規(guī)律性，往后可以把握其趨勢(shì)性，預(yù)測(cè)其走勢(shì)。

于是，我們開始存儲(chǔ)大量時(shí)間相關(guān)的數(shù)據(jù)(如日志，用戶行為等)，并總結(jié)出這些數(shù)據(jù)的結(jié)構(gòu)特點(diǎn)和常見使用場(chǎng)景，不斷改進(jìn)和優(yōu)化，創(chuàng)造了一種新型的數(shù)據(jù)庫(kù)分類——時(shí)間序列數(shù)據(jù)庫(kù)(Time Series Database).

時(shí)間序列模型

時(shí)間序列數(shù)據(jù)庫(kù)主要用于指處理帶時(shí)間標(biāo)簽（按照時(shí)間的順序變化，即時(shí)間序列化）的數(shù)據(jù)，帶時(shí)間標(biāo)簽的數(shù)據(jù)也稱為時(shí)間序列數(shù)據(jù)。

每個(gè)時(shí)序點(diǎn)結(jié)構(gòu)如下：

• timestamp:數(shù)據(jù)點(diǎn)的時(shí)間，表示數(shù)據(jù)發(fā)生的時(shí)間。
• metric:指標(biāo)名，當(dāng)前數(shù)據(jù)的標(biāo)識(shí)，有些系統(tǒng)中也稱為name。
• value:值，數(shù)據(jù)的數(shù)值，一般為double類型，如cpu使用率，訪問(wèn)量等數(shù)值，有些系統(tǒng)一個(gè)數(shù)據(jù)點(diǎn)只能有一個(gè)value，多個(gè)value就是多條時(shí)間序列。有些系統(tǒng)可以有多個(gè)value值，用不同的key表示
• tag:附屬屬性。
  

實(shí)現(xiàn)

比如我想記錄一系列傳感器的時(shí)間序列數(shù)據(jù)。數(shù)據(jù)結(jié)構(gòu)如下：

* 標(biāo)識(shí)符：device_id，時(shí)間戳
* 元數(shù)據(jù)：location_id，dev_type，firmware_version，customer_id
* 設(shè)備指標(biāo)：cpu_1m_avg，free_mem，used_mem，net_rssi，net_loss，電池
* 傳感器指標(biāo)：溫度，濕度，壓力，CO，NO2，PM10

如果使用傳統(tǒng)RDBMS存儲(chǔ)，建一張如下結(jié)構(gòu)的表即可：

如此便是一個(gè)最簡(jiǎn)單的時(shí)間序列庫(kù)了。但這只是滿足了數(shù)據(jù)模型的需要。我們還需要在性能，高效存儲(chǔ)，高可用，分布式和易用性上做更多的事情。

大家可以思考思考，如果讓你自己來(lái)實(shí)現(xiàn)一個(gè)時(shí)間序列數(shù)據(jù)庫(kù)，你會(huì)怎么設(shè)計(jì)，你會(huì)考慮哪些性能上的優(yōu)化，又如何做到高可用，怎樣做到簡(jiǎn)單易用。

Timescale

這個(gè)數(shù)據(jù)庫(kù)其實(shí)就是一個(gè)基于傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)postgresql改造的時(shí)間序列數(shù)據(jù)庫(kù)。了解postgresql的同學(xué)都知道，postgresql是一個(gè)強(qiáng)大的，開源的，可擴(kuò)展性特別強(qiáng)的一個(gè)數(shù)據(jù)庫(kù)系統(tǒng)。

于是timescale.inc開發(fā)了Timescale，一款兼容sql的時(shí)序數(shù)據(jù)庫(kù)， 底層存儲(chǔ)架構(gòu)在postgresql上。 作為一個(gè)postgresql的擴(kuò)展提供服務(wù)。其特點(diǎn)如下：

基礎(chǔ)：

• PostgreSQL原生支持的所有SQL,包含完整SQL接口（包括輔助索引，非時(shí)間聚合，子查詢，JOIN，窗口函數(shù)）
• 用PostgreSQL的客戶端或工具，可以直接應(yīng)用到該數(shù)據(jù)庫(kù)，不需要更改。
• 時(shí)間為導(dǎo)向的特性，API功能和相應(yīng)的優(yōu)化。
• 可靠的數(shù)據(jù)存儲(chǔ)。

擴(kuò)展：

• 透明時(shí)間/空間分區(qū)，用于放大（單個(gè)節(jié)點(diǎn)）和擴(kuò)展
• 高數(shù)據(jù)寫入速率（包括批量提交，內(nèi)存中索引，事務(wù)支持，數(shù)據(jù)備份支持)
• 單個(gè)節(jié)點(diǎn)上的大小合適的塊（二維數(shù)據(jù)分區(qū)），以確保即使在大數(shù)據(jù)量時(shí)即可快速讀取。
• 塊之間和服務(wù)器之間的并行操作

劣勢(shì)：

• 因?yàn)門imescaleDB沒有使用列存技術(shù)，它對(duì)時(shí)序數(shù)據(jù)的壓縮效果不太好，壓縮比最高在4X左右
• 目前暫時(shí)不完全支持分布式的擴(kuò)展（正在開發(fā)相關(guān)功能），所以會(huì)對(duì)服務(wù)器單機(jī)性能要求較高

其實(shí)大家都可以去深入了解一下這個(gè)數(shù)據(jù)庫(kù)。對(duì)RDBMS我們都很熟悉，了解這個(gè)可以讓我們對(duì)RDBMS有更深入的了解，了解其實(shí)現(xiàn)機(jī)制，存儲(chǔ)機(jī)制。在對(duì)時(shí)間序列的特殊化處理之中，我們又可以學(xué)到時(shí)間序列數(shù)據(jù)的特點(diǎn)，并學(xué)習(xí)到如何針對(duì)時(shí)間序列模型去優(yōu)化RDBMS。

之后我們也可以寫一篇文章來(lái)深入的了解一下這個(gè)數(shù)據(jù)庫(kù)的特點(diǎn)和實(shí)現(xiàn)。

Influxdb

Influxdb是業(yè)界比較流行的一個(gè)時(shí)間序列數(shù)據(jù)庫(kù)，特別是在IOT和監(jiān)控領(lǐng)域十分常見。其使用go語(yǔ)言開發(fā)，突出特點(diǎn)是性能。

特性：

• 高效的時(shí)間序列數(shù)據(jù)寫入性能。自定義TSM引擎，快速數(shù)據(jù)寫入和高效數(shù)據(jù)壓縮。
• 無(wú)額外存儲(chǔ)依賴。
• 簡(jiǎn)單，高性能的HTTP查詢和寫入API。
• 以插件方式支持許多不同協(xié)議的數(shù)據(jù)攝入，如：graphite，collectd，和openTSDB
• SQL-like查詢語(yǔ)言，簡(jiǎn)化查詢和聚合操作。
• 索引Tags，支持快速有效的查詢時(shí)間序列。
• 保留策略有效去除過(guò)期數(shù)據(jù)。
• 連續(xù)查詢自動(dòng)計(jì)算聚合數(shù)據(jù)，使頻繁查詢更有效。

Influxdb已經(jīng)將分布式版本轉(zhuǎn)為閉源。所以在分布式集群這塊是一個(gè)弱點(diǎn)，需要自己實(shí)現(xiàn)。

OpenTSDB

The Scalable Time Series Database. 打開OpenTSDB官網(wǎng)，第一眼看到的就是這句話。其將Scalable作為其重要的特點(diǎn)。OpenTSDB運(yùn)行在Hadoop和HBase上，其充分利用HBase的特性。通過(guò)獨(dú)立的Time Series Demon(TSD)提供服務(wù)，所以它可以通過(guò)增減服務(wù)節(jié)點(diǎn)來(lái)輕松擴(kuò)縮容。

• Opentsdb是一個(gè)基于Hbase的時(shí)間序列數(shù)據(jù)庫(kù)（新版也支持Cassandra）。

  其基于Hbase的分布式列存儲(chǔ)特性實(shí)現(xiàn)了數(shù)據(jù)高可用，高性能寫的特性。受限于Hbase，存儲(chǔ)空間較大，壓縮不足。依賴整套HBase, ZooKeeper

• 采用無(wú)模式的tagset數(shù)據(jù)結(jié)構(gòu)(sys.cpu.user 1436333416 23 host=web01 user=10001)

  結(jié)構(gòu)簡(jiǎn)單，多value查詢不友好

• HTTP-DSL查詢

OpenTSDB在HBase上針對(duì)TSDB的表設(shè)計(jì)和RowKey設(shè)計(jì)是值得我們深入學(xué)習(xí)的一個(gè)特點(diǎn)。有興趣的同學(xué)可以找一些詳細(xì)的資料學(xué)習(xí)學(xué)習(xí)。

Druid

Druid是一個(gè)實(shí)時(shí)在線分析系統(tǒng)(LOAP)。其架構(gòu)融合了實(shí)時(shí)在線數(shù)據(jù)分析，全文檢索系統(tǒng)和時(shí)間序列系統(tǒng)的特點(diǎn)，使其可以滿足不同使用場(chǎng)景的數(shù)據(jù)存儲(chǔ)需求。

• 采用列式存儲(chǔ)：支持高效掃描和聚合，易于壓縮數(shù)據(jù)。
• 可伸縮的分布式系統(tǒng)：Druid自身實(shí)現(xiàn)可伸縮，可容錯(cuò)的分布式集群架構(gòu)。部署簡(jiǎn)單。
• 強(qiáng)大的并行能力：Druid各集群節(jié)點(diǎn)可以并行地提供查詢服務(wù)。
• 實(shí)時(shí)和批量數(shù)據(jù)攝入：Druid可以實(shí)時(shí)攝入數(shù)據(jù)，如通過(guò)Kafka。也可以批量攝入數(shù)據(jù)，如通過(guò)Hadoop導(dǎo)入數(shù)據(jù)。
• 自恢復(fù)，自平衡，易于運(yùn)維：Druid自身架構(gòu)即實(shí)現(xiàn)了容錯(cuò)和高可用。不同的服務(wù)節(jié)點(diǎn)可以根據(jù)響應(yīng)需求添加或減少節(jié)點(diǎn)。
• 容錯(cuò)架構(gòu)，保證數(shù)據(jù)不丟失：Druid數(shù)據(jù)可以保留多副本。另外可以采用HDFS作為深度存儲(chǔ)，來(lái)保證數(shù)據(jù)不丟失。
• 索引：Druid對(duì)String列實(shí)現(xiàn)反向編碼和Bitmap索引，所以支持高效的filter和groupby。
• 基于時(shí)間分區(qū)：Druid對(duì)原始數(shù)據(jù)基于時(shí)間做分區(qū)存儲(chǔ)，所以Druid對(duì)基于時(shí)間的范圍查詢將更高效。
• 自動(dòng)預(yù)聚合：Druid支持在數(shù)據(jù)攝入期就對(duì)數(shù)據(jù)進(jìn)行預(yù)聚合處理。

Druid架構(gòu)蠻復(fù)雜的。其按功能將整個(gè)系統(tǒng)細(xì)分為多種服務(wù)，query、data、master不同職責(zé)的系統(tǒng)獨(dú)立部署，對(duì)外提供統(tǒng)一的存儲(chǔ)和查詢服務(wù)。其以分布式集群服務(wù)的方式提供了一個(gè)底層數(shù)據(jù)存儲(chǔ)的服務(wù)。

Druid在架構(gòu)上的設(shè)計(jì)很值得我們學(xué)習(xí)。如果你不僅僅對(duì)時(shí)間序列存儲(chǔ)感興趣，對(duì)分布式集群架構(gòu)也有興趣，不妨看看Druid的架構(gòu)。另外Druid在segment(Druid的數(shù)據(jù)存儲(chǔ)結(jié)構(gòu))的設(shè)計(jì)也是一大亮點(diǎn)，既實(shí)現(xiàn)了列式存儲(chǔ)，又實(shí)現(xiàn)了反向索引。

Elasticsearch

Elasticsearch 是一個(gè)分布式的開源搜索和分析引擎，適用于所有類型的數(shù)據(jù)，包括文本、數(shù)字、地理空間、結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)。Elasticsearch 在 Apache Lucene 的基礎(chǔ)上開發(fā)而成，由 Elasticsearch N.V.（即現(xiàn)在的 Elastic）于 2010 年首次發(fā)布。Elasticsearch 以其簡(jiǎn)單的 REST 風(fēng)格 API、分布式特性、速度和可擴(kuò)展性而聞名。

Elasticsearch以ELK stack被人所熟知。許多公司基于ELK搭建日志分析系統(tǒng)和實(shí)時(shí)搜索系統(tǒng)。之前我們?cè)贓LK的基礎(chǔ)上開始開發(fā)metric監(jiān)控系統(tǒng)。即想到了使用Elasticsearch來(lái)存儲(chǔ)時(shí)間序列數(shù)據(jù)庫(kù)。對(duì)Elasticserach的mapping做相應(yīng)的優(yōu)化，使其更適合存儲(chǔ)時(shí)間序列數(shù)據(jù)模型，收獲了不錯(cuò)的效果，完全滿足了業(yè)務(wù)的需求。后期發(fā)現(xiàn)Elasticsearch新版本竟然也開始發(fā)布Metrics組件和APM組件，并大量的推廣其全文檢索外，對(duì)時(shí)間序列的存儲(chǔ)能力。真是和我們當(dāng)時(shí)的想法不謀而合。

Elasticsearch的時(shí)序優(yōu)化可以參考一下這篇文章:《elasticsearch-as-a-time-series-data-store》

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

Beringei

Beringei是Facebook在2017年最新開源的一個(gè)高性能內(nèi)存時(shí)序數(shù)據(jù)存儲(chǔ)引擎。其具有快速讀寫和高壓縮比等特性。

2015年Facebook發(fā)表了一篇論文《Gorilla: A Fast, Scalable, In-Memory Time Series Database 》，Beringei正是基于此想法實(shí)現(xiàn)的一個(gè)時(shí)間序列數(shù)據(jù)庫(kù)。

Beringei使用Delta-of-Delta算法存儲(chǔ)數(shù)據(jù)，使用XOR編碼壓縮數(shù)值。使其可以用很少的內(nèi)存即可存儲(chǔ)下大量的數(shù)據(jù)。

如何選擇一個(gè)適合自己的時(shí)間序列數(shù)據(jù)庫(kù)

• Data model

  時(shí)間序列數(shù)據(jù)模型一般有兩種，一種無(wú)schema，具有多tag的模型，還有一種name、timestamp、value型。前者適合多值模式，對(duì)復(fù)雜業(yè)務(wù)模型更適合。后者更適合單維數(shù)據(jù)模型。

• Query language

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

• Reliability

  可用性主要體現(xiàn)在系統(tǒng)的穩(wěn)定高可用上，以及數(shù)據(jù)的高可用存儲(chǔ)上。一個(gè)優(yōu)秀的系統(tǒng)，應(yīng)該有一個(gè)優(yōu)雅而高可用的架構(gòu)設(shè)計(jì)。簡(jiǎn)約而穩(wěn)定。

• Performance

  性能是我們必須考慮的因素。當(dāng)我們開始考慮更細(xì)分領(lǐng)域的數(shù)據(jù)存儲(chǔ)時(shí)，除了數(shù)據(jù)模型的需求之外，很大的原因都是通用的數(shù)據(jù)庫(kù)系統(tǒng)在性能上無(wú)法滿足我們的需求。大部分時(shí)間序列庫(kù)傾向?qū)懚嘧x少場(chǎng)景，用戶需要平衡自身的需求。下面會(huì)有一份各庫(kù)的性能對(duì)比，大家可以做一個(gè)參考。

• Ecosystem

  我一直認(rèn)為生態(tài)是我們選擇一個(gè)開源組件必須認(rèn)真考慮的問(wèn)題。一個(gè)生態(tài)優(yōu)秀的系統(tǒng)，使用的人多了，未被發(fā)現(xiàn)的坑也將少了。另外在使用中遇到問(wèn)題，求助于社區(qū)，往往可以得到一些比較好的解決方案。另外好的生態(tài)，其周邊邊界系統(tǒng)將十分成熟，這讓我們?cè)趯?duì)接其他系統(tǒng)時(shí)會(huì)有更多成熟的方案。

• Operational management

  易于運(yùn)維，易于操作。

• Company and support

  一個(gè)系統(tǒng)其背后的支持公司也是比較重要的。背后有一個(gè)強(qiáng)大的公司或組織，這在項(xiàng)目可用性保證和后期維護(hù)更新上都會(huì)有較大的體驗(yàn)。

性能對(duì)比

	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

總結(jié)

可以按照以下需求自行選擇合適的存儲(chǔ)：

• 小而精，性能高，數(shù)據(jù)量較小(億級(jí)): InfluxDB
• 簡(jiǎn)單，數(shù)據(jù)量不大（千萬(wàn)級(jí)），有聯(lián)合查詢、關(guān)系型數(shù)據(jù)庫(kù)基礎(chǔ)：timescales
• 數(shù)據(jù)量較大，大數(shù)據(jù)服務(wù)基礎(chǔ)，分布式集群需求： opentsdb、KairosDB
• 分布式集群需求，olap實(shí)時(shí)在線分析，資源較充足：druid
• 性能極致追求，數(shù)據(jù)冷熱差異大：Beringei
• 兼顧檢索加載，分布式聚合計(jì)算： elsaticsearch
• 如果你兼具索引和時(shí)間序列的需求。那么Druid和Elasticsearch是最好的選擇。其性能都不差，同時(shí)滿足檢索和時(shí)間序列的特性，并且都是高可用容錯(cuò)架構(gòu)。

最后

之后我們可以來(lái)深入了解一兩個(gè)TSDB，比如Influxdb，OpenTSDB，Druid，Elasticsearch等。并可以基于此學(xué)習(xí)一下行存儲(chǔ)與列存儲(chǔ)的不同，LSM的實(shí)現(xiàn)原理，數(shù)值數(shù)據(jù)的壓縮，MMap提升讀寫性能的知識(shí)等。

看完上訴內(nèi)容，你們對(duì)時(shí)間序列數(shù)據(jù)庫(kù)是什么？應(yīng)該如何選擇大概了解了嗎？如果想了解更多，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道哦！

網(wǎng)站名稱：時(shí)間序列數(shù)據(jù)庫(kù)是什么？應(yīng)該如何選擇
轉(zhuǎn)載注明：http://bm7419.com/article0/igceio.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供全網(wǎng)營(yíng)銷推廣、企業(yè)建站、網(wǎng)站設(shè)計(jì)公司、搜索引擎優(yōu)化、動(dòng)態(tài)網(wǎng)站、網(wǎng)站策劃

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)