您好,登錄后才能下訂單哦!
本篇文章給大家分享的是有關如何進行時序數(shù)據(jù)庫InfluxDB的存儲機制解析,小編覺得挺實用的,因此分享給大家學習,希望大家閱讀完這篇文章后可以有所收獲,話不多說,跟著小編一起來看看吧。
下面介紹了InfluxDB對于時序數(shù)據(jù)的存儲/索引的設計。由于InfluxDB的集群版已在0.12版就不再開源,因此如無特殊說明,所介紹對象都是指 InfluxDB 單機版
盡管InfluxDB自發(fā)布以來歷時三年多,其存儲引擎的技術架構已經(jīng)做過幾次重大的改動, 以下將簡要介紹一下InfluxDB的存儲引擎演進的過程。
版本0.9.0之前
**基于 LevelDB的LSMTree方案**
版本0.9.0~0.9.4
**基于BoltDB的mmap COW B+tree方案**
版本0.9.5~1.2
**基于自研的 WAL + TSMFile 方案**(TSMFile方案是0.9.6版本正式啟用,0.9.5只是提供了原型)
版本1.3~至今
**基于自研的 WAL + TSMFile + TSIFile 方案**
InfluxDB的存儲引擎先后嘗試過包括LevelDB, BoltDB在內(nèi)的多種方案。但是對于InfluxDB的下述訴求終不能完美地支持:
時序數(shù)據(jù)在降采樣后會存在大批量的數(shù)據(jù)刪除
=> *LevelDB的LSMTree刪除代價過高*
單機環(huán)境存放大量數(shù)據(jù)時不能占用過多文件句柄
=> *LevelDB會隨著時間增長產(chǎn)生大量小文件*
數(shù)據(jù)存儲需要熱備份
=> *LevelDB只能冷備*
大數(shù)據(jù)場景下寫吞吐量要跟得上
=> *BoltDB的B+tree寫操作吞吐量成瓶頸*
存儲需具備良好的壓縮性能
=> *BoltDB不支持壓縮*
此外,出于技術棧的一致性以及部署的簡易性考慮(面向容器部署),InfluxDB團隊希望存儲引擎 與 其上層的TSDB引擎一樣都是用GO編寫,因此潛在的RocksDB選項被排除
基于上述痛點,InfluxDB團隊決定自己做一個存儲引擎的實現(xiàn)。
在解析InfluxDB的存儲引擎之前,先回顧一下InfluxDB中的數(shù)據(jù)模型。
在InfluxDB中,時序數(shù)據(jù)支持多值模型,它的一條典型的時間點數(shù)據(jù)如下所示:
圖 1
cdn.com/bceda83d3c4545a140d99a319188448dfe2193f6.png">
measurement:
指標對象,也即一個數(shù)據(jù)源對象。每個measurement可以擁有一個或多個指標值,也即下文所述的**field**。在實際運用中,可以把一個現(xiàn)實中被檢測的對象(如:“cpu”)定義為一個measurement
tags:
概念等同于大多數(shù)時序數(shù)據(jù)庫中的tags, 通常通過tags可以唯一標示數(shù)據(jù)源。每個tag的key和value必須都是字符串。
field:
數(shù)據(jù)源記錄的具體指標值。每一種指標被稱作一個“field”,指標值就是 “field”對應的“value”
timestamp:
數(shù)據(jù)的時間戳。在InfluxDB中,理論上時間戳可以精確到 **納秒**(ns)級別
此外,在InfluxDB中,measurement的概念之上還有一個對標傳統(tǒng)DBMS的 Database 的概念,邏輯上每個Database下面可以有多個measurement。在單機版的InfluxDB實現(xiàn)中,每個Database實際對應了一個文件系統(tǒng)的 目錄。
InfluxDB中的SeriesKey的概念就是通常在時序數(shù)據(jù)庫領域被稱為 時間線 的概念, 一個SeriesKey在內(nèi)存中的表示即為下述字符串(逗號和空格被轉(zhuǎn)義)的 字節(jié)數(shù)組(github.com/influxdata/influxdb/model#MakeKey())
{measurement名}{tagK1}={tagV1},{tagK2}={tagV2},...
其中,SeriesKey的長度不能超過 65535 字節(jié)
InfluxDB的Field值支持以下數(shù)據(jù)類型:
Datatype | Size in Mem | Value Range |
---|---|---|
Float | 8 bytes | 1.797693134862315708145274237317043567981e+308 ~ 4.940656458412465441765687928682213723651e-324 |
Integer | 8 bytes | -9223372036854775808 ~ 9223372036854775807 |
String | 0~64KB | String with length less than 64KB |
Boolean | 1 byte | true 或 false |
在InfluxDB中,F(xiàn)ield的數(shù)據(jù)類型在以下范圍內(nèi)必須保持不變,否則寫數(shù)據(jù)時會報錯 類型沖突。
同一Serieskey + 同一field + 同一shard
在InfluxDB中, 能且只能 對一個Database指定一個 Retention Policy (簡稱:RP)。通過RP可以對指定的Database中保存的時序數(shù)據(jù)的留存時間(duration)進行設置。而 Shard 的概念就是由duration衍生而來。一旦一個Database的duration確定后, 那么在該Database的時序數(shù)據(jù)將會在這個duration范圍內(nèi)進一步按時間進行分片從而時數(shù)據(jù)分成以一個一個的shard為單位進行保存。
shard分片的時間 與 duration之間的關系如下
Duration of RP | Shard Duration |
---|---|
< 2 Hours | 1 Hour |
>= 2 Hours 且 <= 6 Months | 1 Day |
> 6 Months | 7 Days |
新建的Database在未顯式指定RC的情況下,默認的RC為 數(shù)據(jù)的Duration為永久,Shard分片時間為7天
注: 在閉源的集群版Influxdb中,用戶可以通過RC規(guī)則指定數(shù)據(jù)在基于時間分片的基礎上再按SeriesKey為單位進行進一步分片
時序數(shù)據(jù)庫的存儲引擎主要需滿足以下三個主要場景的性能需求
大批量的時序數(shù)據(jù)寫入的高性能
直接根據(jù)時間線(即Influxdb中的 Serieskey )在指定時間戳范圍內(nèi)掃描數(shù)據(jù)的高性能
間接通過measurement和部分tag查詢指定時間戳范圍內(nèi)所有滿足條件的時序數(shù)據(jù)的高性能
InfluxDB在結合了1.2所述考量的基礎上推出了他們的解決方案,即下面要介紹的 WAL + TSMFile + TSIFile的方案
InfluxDB寫入時序數(shù)據(jù)時為了確保數(shù)據(jù)完整性和可用性,與大部分數(shù)據(jù)庫產(chǎn)品一樣,都是會先寫WAL,再寫入緩存,最后刷盤。對于InfluxDB而言,寫入時序數(shù)據(jù)的主要流程如同下圖所示:
圖 2
由于InfluxDB對于時序數(shù)據(jù)的寫操作永遠只有單純寫入,因此它的Entry不需要區(qū)分操作種類,直接記錄寫入的數(shù)據(jù)即可
圖 4
其特點是在一個TSMFile中將 時序數(shù)據(jù)(i.e Timestamp + Field value)保存在數(shù)據(jù)區(qū);將Serieskey 和 Field Name的信息保存在索引區(qū),通過一個基于 Serieskey + Fieldkey構建的形似B+tree的文件內(nèi)索引快速定位時序數(shù)據(jù)所在的 數(shù)據(jù)塊
注: 在當前版本中,單個TSMFile的最大長度為2GB,超過時即使是同一個Shard,也會繼續(xù)新開一個TSMFile保存數(shù)據(jù)。本文的介紹出于簡單化考慮,以下內(nèi)容不考慮同一個Shard的TSMFile分裂的場景
索引塊的構成
上文的索引塊的構成,如下所示: *圖 6*
其中 **索引條目** 在InfluxDB的源碼中被稱為`directIndex`。在TSMFile中,索引塊是按照 Serieskey + Fieldkey **排序** 后組織在一起的。 明白了TSMFile的索引區(qū)的構成,就可以很自然地理解InfluxDB如何高性能地在TSMFile掃描時序數(shù)據(jù)了: 1. 根據(jù)用戶指定的時間線(Serieskey)以及Field名 在 **索引區(qū)** 利用二分查找找到指定的Serieskey+FieldKey所處的 **索引數(shù)據(jù)塊** 2. 根據(jù)用戶指定的時間戳范圍在 **索引數(shù)據(jù)塊** 中查找數(shù)據(jù)落在哪個(*或哪幾個*)**索引條目** 3. 將找到的 **索引條目** 對應的 **時序數(shù)據(jù)塊** 加載到內(nèi)存中進行進一步的Scan *注:上述的1,2,3只是簡單化地介紹了查詢機制,實際的實現(xiàn)中還有類似掃描的時間范圍跨索引塊等一系列復雜場景* <br>
時序數(shù)據(jù)的存儲
在圖 2中介紹了時序數(shù)據(jù)塊的結構:即同一個 Serieskey + Fieldkey 的 所有時間戳 - Field值
對被拆分開,分成兩個區(qū):Timestamps區(qū)和Value區(qū)分別進行存儲。它的目的是:實際存儲時可以分別對時間戳和Field值按不同的壓縮算法進行存儲以減少時序數(shù)據(jù)塊的大小
采用的壓縮算法如下所示:
做查詢時,當利用TSMFile的索引找到文件中的時序數(shù)據(jù)塊時,將數(shù)據(jù)塊載入內(nèi)存并對Timestamp以及Field Value進行解壓縮后以便繼續(xù)后續(xù)的查詢操作。
Float類: Gorrila's Float Commpression
Integer類型: Delta Encoding + Zigzag Conversion + RLE / Simple8b / None
String類型: Snappy Compression
Boolean類型: Bit packing
Timestamp: Delta-of-delta encoding
Field Value:由于單個數(shù)據(jù)塊的Field Value必然數(shù)據(jù)類型相同,因此可以集中按數(shù)據(jù)類型采用不同的壓縮算法
有了TSMFile,第3章開頭所說的三個主要場景中的場景1和場景2都可以得到很好的解決。但是如果查詢時用戶并沒有按預期按照Serieskey來指定查詢條件,而是指定了更加復雜的條件,該如何確保它的查詢性能?通常情況下,這個問題的解決方案是依賴倒排索引(Inverted Index)。
InfluxDB的倒排索引依賴于下述兩個數(shù)據(jù)結構
map<SeriesID, SeriesKey>
map<tagkey, map<tagvalue, List<SeriesID>>>
它們在內(nèi)存中展現(xiàn)如下:
圖 7
圖 8
但是在實際生產(chǎn)環(huán)境中,由于用戶的時間線規(guī)模會變得很大,因此會造成倒排索引使用的內(nèi)存過多,所以后來InfluxDB又引入了 TSIFile
TSIFile的整體存儲機制與TSMFile相似,也是以 Shard 為單位生成一個TSIFile。
以上就是如何進行時序數(shù)據(jù)庫InfluxDB的存儲機制解析,小編相信有部分知識點可能是我們?nèi)粘9ぷ鲿姷交蛴玫降摹OM隳芡ㄟ^這篇文章學到更多知識。更多詳情敬請關注億速云行業(yè)資訊頻道。
免責聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權內(nèi)容。