11.InfluxDB引擎原理

轉(zhuǎn)自：https://www.yisu.com/zixun/36153.html

11.1.引言

InfluxDB是一款Go語言寫的時(shí)序數(shù)據(jù)庫。時(shí)序數(shù)據(jù)庫主要用于存儲(chǔ)基于時(shí)間序列的指標(biāo)數(shù)據(jù)，例如一個(gè)Web頁面的PV、UV等指標(biāo)，將其定期采集，并打上時(shí)間戳，就是一份基于時(shí)間序列的指標(biāo)。時(shí)序數(shù)據(jù)庫通常用來配合前端頁面來展示一段時(shí)間的指標(biāo)曲線。

11.2.為什么需要時(shí)序數(shù)據(jù)庫

時(shí)序數(shù)據(jù)庫較傳統(tǒng)的關(guān)系型數(shù)據(jù)庫以及NoSQL究竟有什么優(yōu)勢，下面會(huì)結(jié)合相關(guān)模型的特性進(jìn)行分析。

11.3.LSM Tree

LSM tree是基于Google的BigTable架構(gòu)，數(shù)據(jù)以K-V方式存儲(chǔ)。

寫數(shù)據(jù)首先會(huì)插入到內(nèi)存中的樹。當(dāng)內(nèi)存中的樹中的數(shù)據(jù)超過一定閾值時(shí)，會(huì)進(jìn)行合并操作。合并操作會(huì)從左至右遍歷內(nèi)存中的樹的葉子節(jié)點(diǎn)與磁盤中的樹的葉子節(jié)點(diǎn)進(jìn)行合并，當(dāng)被合并的數(shù)據(jù)量達(dá)到磁盤的存儲(chǔ)頁的大小時(shí)，會(huì)將合并后的數(shù)據(jù)持久化到磁盤，同時(shí)更新父親節(jié)點(diǎn)對葉子節(jié)點(diǎn)的指針。

這種機(jī)制保證了寫入的效率，因?yàn)閿?shù)據(jù)會(huì)在合并后順序?qū)懭氪疟P頁。但會(huì)推遲磁盤回寫，因此為保障讀數(shù)據(jù)的一致性，會(huì)先在內(nèi)存中查詢，如果內(nèi)存中沒有，則到磁盤上查詢。

刪除數(shù)據(jù)時(shí)，在內(nèi)存（C0）中查找，如果沒有，則在內(nèi)存中新建一個(gè)索引，將鍵值設(shè)置刪除標(biāo)記（創(chuàng)建墓碑），這樣后續(xù)的滾動(dòng)合并操作時(shí)，再有查詢操作，就會(huì)被直接返回該鍵值不存在。 數(shù)據(jù)會(huì)在之后的Compaction當(dāng)中從數(shù)據(jù)文件中刪除。

11.4.Compaction

當(dāng)日志文件超過一定大小的閾值時(shí)（默認(rèn)為1MB）

建立一個(gè)新的memtable和日志文件，以后的操作都是用新的memtable和日志文件。

后臺(tái)進(jìn)行如下操作：
1、將舊的memtable寫到SSTable中（過程為先轉(zhuǎn)為immtable_table, 然后遍歷寫入）
2、廢棄舊的memtable
3、刪除舊的memtable和日志文件
4、將新的SSTable加到level 0中。

對于時(shí)序數(shù)據(jù)而言，LSM tree的讀寫效率很高。但是熱備份以及數(shù)據(jù)批量清理的效率不高。

11.5.B+ Tree

B+ Tree，很多關(guān)系型數(shù)據(jù)庫像 Berkerly DB , sqlite , mysql 數(shù)據(jù)庫都使用了B+樹算法處理索引。B+ Tree的特點(diǎn)是數(shù)據(jù)按照索引有序排放，犧牲一定寫入性能，保證了讀取效率。但數(shù)據(jù)量很大時(shí)（GB），查詢效率就會(huì)很低。因?yàn)閿?shù)據(jù)量越大，樹分叉就越多，遍歷時(shí)的開銷就越大。

11.6.TSM

InfluxDB在v0.9.5版本引入TSM引擎，該引擎修改自LSM。

11.7.預(yù)寫日志

當(dāng)前日志文件達(dá)到2MB大小后封閉，并開始寫新的日志文件

寫數(shù)據(jù)時(shí)，日志文件落盤(fsync)且數(shù)據(jù)索引加入內(nèi)存表后返回成功。這樣的設(shè)計(jì)保證了數(shù)據(jù)的一致性。同時(shí)對寫盤的吞吐性能提出要求，建議批量提交數(shù)據(jù)（influxdb提供了批量提交的API）。日志遵循TLV格式，并采用較精簡的數(shù)據(jù)結(jié)構(gòu)，來減少寫操作的開銷。

11.8.數(shù)據(jù)文件

文件中的數(shù)據(jù)按照時(shí)序進(jìn)行排列。

對照LevelDB的結(jié)構(gòu)，增加了min和max time，基于一段時(shí)間范圍的數(shù)據(jù)提取會(huì)非常簡單。

Data Block結(jié)構(gòu)
由存放的key(measurement name + tagset)以及field name進(jìn)行hash(fnv6)

4-a hash) 生成
Compressd block當(dāng)中會(huì)存儲(chǔ)metric值，數(shù)據(jù)壓縮算法后面會(huì)進(jìn)行詳述

11.9.讀取數(shù)據(jù)

首先會(huì)根據(jù)查詢請求的時(shí)間范圍，在數(shù)據(jù)文件中進(jìn)行二進(jìn)制搜索，找到符合范圍的文件。之后在內(nèi)存中的映射表根據(jù)查詢指標(biāo)項(xiàng)HASH獲取ID，并通過索引找到數(shù)據(jù)塊的起始地址。之后根據(jù)數(shù)據(jù)塊及其下一數(shù)據(jù)塊的timestamp我們可以推算出需要取出多少個(gè)數(shù)據(jù)塊，最后將數(shù)據(jù)塊中的數(shù)據(jù)解壓，得到結(jié)果。

11.10.更新數(shù)據(jù)

如果多個(gè)更新在同一個(gè)時(shí)間范圍內(nèi)，預(yù)寫日志會(huì)緩存起來一起更新。

11.11.刪除數(shù)據(jù)

兩階段式處理，第一階段，預(yù)寫日志會(huì)將其持久化在日志中，并通知索引維護(hù)內(nèi)存中的墓碑. 此時(shí)查詢數(shù)據(jù)，就會(huì)返回不存在。第二階段，預(yù)寫日志寫索引文件，會(huì)優(yōu)先處理刪除，之后再處理刪除操作之后的其他插入(包括刪除的序列以及其他序列)，并清除內(nèi)存中的墓碑。

11.12.數(shù)據(jù)壓縮

數(shù)據(jù)壓縮的目的是為了減少存儲(chǔ)空間以及降低寫磁盤的開銷

每個(gè)壓縮數(shù)據(jù)塊當(dāng)中會(huì)包含一個(gè)系列的點(diǎn)（壓縮時(shí)間戳、壓縮值），因?yàn)闀r(shí)間戳是一個(gè)單調(diào)遞增的序列，因此壓縮的填入的時(shí)間的偏移量。

11.13.總結(jié)

influxdb的數(shù)據(jù)存儲(chǔ)結(jié)構(gòu)實(shí)現(xiàn)了數(shù)據(jù)基于系列以及時(shí)間戳2個(gè)維度的有序存取。并通過壓縮數(shù)據(jù)來降低I/O開銷。在取一個(gè)系列在一定時(shí)間范圍內(nèi)的數(shù)據(jù)這個(gè)場景下，能夠提高處理速度。由于數(shù)據(jù)按時(shí)間進(jìn)行歸并，對Retention操作而言，可以以數(shù)據(jù)文件為單位進(jìn)行操作，效率會(huì)比較高。

與50位技術(shù)專家面對面20年技術(shù)見證，附贈(zèng)技術(shù)全景圖

總結(jié)

以上是生活随笔為你收集整理的11.InfluxDB引擎原理的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。