00

前言

InfluxDB是一款 Go語言 寫的時序資料庫。時序資料庫主要用於儲存 基於時間序列的指標資料 ，例如一個Web頁面的PV、UV等指標，將其定期採集，並打上時間戳，就是一份基於時間序列的指標。時序資料庫通常用來配合前端頁面來展示一段時間的指標曲線。

0 2

為什麼需要時序資料庫

時序資料庫較傳統的關係型資料庫以及NoSQL究竟有什麼優勢，下面會結合相關模型的特性進行分析

0 3

LSM Tree

LSM tree是基於Google的BigTable架構，資料以K-V方式儲存。

寫資料首先會插入到記憶體中的樹。當記憶體中的樹中的資料超過一定閾值時，會進行合併操作。合併操作會從左至右遍歷記憶體中的樹的葉子節點與磁碟中的樹的葉子節點進行合併，當被合併的資料量達到磁碟的儲存頁的大小時，會將合併後的資料持久化到磁碟，同時更新父親節點對葉子節點的指標。

這種機制保證了 寫入的效率 ，因為資料會在合併後順序寫入磁碟頁。但會推遲磁盤迴寫，因此為保障讀資料的一致性，會先在記憶體中查詢，如果記憶體中沒有，則到磁碟上查詢。

0 4

Compaction

當日志文件超過一定大小的閾值是 (預設為 1MB):

建立一個新的memtable和日誌檔案，以後的操作都是用新的memtable和日誌檔案

後臺進行如下操作:

將舊的 memtable寫到SSTable中（過程為先轉為immtable_table，然後遍歷寫入)廢棄舊的 memtable刪除舊的 memtable和日誌檔案將新的SSTable加到level 0中.

對於時序資料而言， LSM tree的讀寫效率很高 。但是熱備份以及資料批次清理的效率不高。

0 5

B+ Tree

B+ Tree，很多關係型資料庫像 Berkerly DB , sqlite , mysql 資料庫都使用了B+樹演算法處理索引。B+ Tree的特點是資料按照索引有序排放，犧牲一定寫入效能，保證了讀取效率。但資料量很大時（GB），查詢效率就會很低。因為資料量越大，樹分叉就越多，遍歷時的開銷就越大。

0 6

TSM

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

0 7

預寫日誌

當前日誌檔案達到2MB大小後封閉，並開始寫新的日誌檔案

寫資料時，日誌檔案落盤(fsync)且資料索引加入記憶體表後返回成功。這樣的設計保證了資料的一致性。同時對寫盤的吞吐效能提出要求，建議批次提交資料（influxdb提供了批次提交的API）。日誌遵循TLV格式，並採用較精簡的資料結構，來減少寫操作的開銷。

0 8

資料檔案

檔案結構一個檔案的中資料塊按照時序進行排列

對照LevelDB的結構，增加了min和max time, 基於一段時間範圍的資料提取會非常簡單

Data Block結構

ID由存放的key (measurement name + tagset) 以及 field name進行hash(fnv64-a hash)生成Compressd block當中會儲存metric值，資料壓縮演算法後面會進行詳述

Index Block結構

0 9

讀取資料

首先會根據查詢請求的時間範圍，在資料檔案中進行二進位制搜尋，找到符合範圍的檔案。之後在記憶體中的對映表根據查詢指標項HASH獲取ID，並透過索引找到資料塊的起始地址。之後根據資料塊及其下一資料塊的timestamp我們可以推算出需要取出多少個數據塊，最後將資料塊中的資料解壓，得到結果

10

更新資料

如果多個更新在同一個時間範圍內，預寫日誌會快取起來一起更新。

11

12

資料壓縮

資料壓縮的目的是為了 減少儲存空間以及降低寫磁碟的開銷每個壓縮資料塊當中會包含一個系列的點（壓縮時間戳、壓縮值), 因為時間戳是一個單調遞增的序列，因此壓縮時填入的時間的偏移量

13

總結

influxdb的資料儲存結構實現了資料基於系列以及時間戳2個維度的有序存取。並透過壓縮資料來降低I/O開銷。在取一個系列在一定時間範圍內的資料這個場景下，能夠提高處理速度。由於資料按時間進行歸併，對Retention操作而言，可以以資料檔案為單位進行操作，效率會比較高。

14

硬體需求

低配

CPU: 2-4核RAM: 2-4 GBIOPS: 500

標配

CPU: 4-6核RAM: 8-32 GBIOPS: 500-1000

高

CPU: 8核+RAM: 32+ GBIOPS: 1000+

記憶體大小與唯一系列（指標項）數量相關。