基于influxDB的工業時序數據庫引擎設計

徐化巖 初彥龍

1(冶金自動化研究設計院混合流程工業自動化系統及裝備技術國家重點實驗室 北京 100071)2(遼寧警察學院治安管理系 遼寧 大連 116036)

0 引 言

時序數據即時間序列數據，指按照時間先后順序變化、帶時間標簽的數據。時序數據主要由電力、化工、冶金等各類型實時監測、檢查與分析設備所采集、產生的數據，這些數據的典型特點是：(1) 采樣頻率快，每秒甚至幾十毫秒采樣一次；(2) 測點多信息量大，一個千萬噸級鋼鐵聯合企業共有約50萬個在線監測點，如果每秒采集后不壓縮存儲，一天需要800 GB存儲空間；(3) 數據按照時間順序產生，一經產生不再變化；(4) 一次讀取的數據量大，繪制一條24小時秒級曲線需要讀取86 400條數據；(5) 沒有關系數據的并發寫入/更改情況，沒有讀寫共享沖突問題；(6) 單點數據價值小，對數據一致性要求沒有業務數據嚴格。

目前，工業領域普遍的做法是使用商業實時數據庫軟件，如OSIsoft PI、Wonderware Insql、GE IHistorian等，作為時序數據庫的存儲和讀取工具。隨著大數據技術的發展，近年來也有一些基于HBase、MongoDB[1]等大數據平臺的研究。

2013年，Errplane公司將influxDB[2]開源，經過不斷改進現已在開源時序數據庫中排名第一[3]。influxDB參考O’Neil P等[4]提出應用于BigTable[5]的日志結構合并樹(Log Structured Merge Tree，LSM)，提出了時間結構合并樹(Time Structured Merge Tree，TSM)，針對時序數據的讀寫分別進行了優化設計。在寫入時，將數據追加寫入到日志文件(Write Ahead Log，WAL)中，并在內存中進行緩存，當內存緩存達到一定大小時創建新的日志文件，并啟動壓縮線程，將數據按照讀取優化的方式壓縮成TSM數據文件。根據官方提供的數據[2]，influxDB與其他幾個時序數據庫的性能比較如表1所示。

表1 開源時序數據庫性能對比表

influxDB起源于對服務器運行情況進行監控這一特定領域，設計了較為復雜的元數據模型以便能夠保存除測點、時間、取值之外的附加屬性信息。數據存儲時的鍵為含有測點名、屬性類型、取值類型的字符串，不僅占用空間多，而且索引時需要根據字符串長度計算數據位置，增加了檢索計算量，這一復雜設計對于工業時序數據而言是多余的。本文參考influxDB的引擎代碼，改進了TSM文件結構，實現了工業時序數據庫引擎，并進行了性能測試。

1 時序數據庫引擎結構

引擎自頂而下包括數據庫實例、存儲策略、存儲分片幾個層次，如圖1所示。每個數據庫實例包含一個或更多存儲策略，用于定義存儲時長，存儲策略包含多個存儲分片，每個存儲分片負責一段時間的數據，超過時長的過期數據會以存儲分片為單位進行整體刪除，以提高刪除效率。每個存儲分片里包含一個內存緩存區、一個或更多日志文件、多個數據文件，以及用于處理寫入、壓縮、讀取的線程。

圖1 時序數據庫引擎結構示意圖

在寫入時，系統根據數據點所屬數據庫實例名找到數據庫實例，由數據庫實例找到數據點所屬數據存儲策略，然后由存儲策略根據數據的時間范圍找到命中的存儲片區，如果片區不存在則創建片區，并將數據分發給片區執行寫入。存儲片區負責將數據同時寫入到內存緩存與日志文件中，日志文件定時壓縮為數據文件，數據文件再逐步壓縮為更大的數據文件，直到數據文件大小達到上限不再壓縮。寫入流程如圖2所示。

圖2 數據寫入及文件壓縮流程圖

在讀取時，系統首先找到所有命中的存儲片區，由片區判斷是從其內存緩存中讀取還是從其數據文件中讀取。如果是從數據文件中讀取，利用文件中的索引快速定位數據位置，讀取后由系統將所有命中片區返回的結果按照時間先后順序合并，返回最終查詢結果。讀取流程如圖3所示。

圖3 數據讀取流程圖

2 TSM文件結構設計

TSM采用內存緩存和WAL日志文件來保證高效寫入，內存緩存目的是代替日志文件提供對臨近數據的高效讀取，日志文件的目的是在數據庫重啟后能夠重建內存緩存，日志文件不用于讀取數據。由于磁盤的順序寫入速度快而隨機寫入速度慢(尋道和旋轉延遲)，而時序數據的特點是大量數據實時采集、實時寫入，為了提高寫入效率將一批數據(一般為5 000到10 000點)按照數據類型、點位編號、點數、時間、值、時間、值、…、數據類型等順序編碼為字節流，如圖4所示，再利用snappy算法[6]壓縮后寫入WAL日志文件。同時，將寫入日志文件的數據以點位編號、時間、值的結構存入內存緩存區，內存緩存區與日志文件保持同步。日志文件大小固定，當達到規定大小時自動生成一個新的日志文件。

圖4 WAL日志文件結構圖

TSM數據文件中包含5字節文件頭、多個數據塊、一個索引塊和8字節文件尾，如圖5所示。文件頭存放數據庫引擎的幻數和版本號；數據塊區由若干組4字節校驗和與N字節數據塊組成；校驗和是數據塊的32位循環冗余校驗碼；數據塊為數據點的一組按時間排序后的數據經過壓縮后得到的字節數組；索引塊由點位編號、數據類型、數據塊數量、數據塊索引1、數據塊索引2等構成，每個數據塊索引包含數據塊起始時間、數據塊結束時間、數據塊在文件中的起始位置、數據塊字節數構成；文件尾8字節用于保存索引塊在TSM數據文件中的起始字節位置。

圖5 TSM數據文件結構圖

3 數據的無損壓縮方法

時序數據包含點名、時間和數值信息，寫入一組時序數據時，如圖6所示，壓縮器遍歷每個點，判斷數值的數據類型是整數、浮點數、布爾值還是字符串，分別調用相應的壓縮方法進行壓縮，時間類型調用時間壓縮方法壓縮，將兩者壓縮得到的字節數組合并后寫入到數據文件中。整數、浮點數、布爾、字符串、時間五種數據類型的壓縮算法如下所述。

圖6 數據壓縮流程圖

整數的壓縮方法為：第一個整數不壓縮，從第二個整數開始計算與前一個數的差值，并對差值通過ZigZag編碼[7]將差值為負數的變為正數，然后分三種情況進行壓縮：(1) 如果連續兩個以上差值相等，則只存儲差值及差值出現的次數；(2) 如果差值超過十六進制數值0x0800000000000000，不壓縮；(3) 否則，將差值采用simple8b算法[8]進行壓縮。

浮點數的壓縮方法[9]為：第一個浮點數不壓縮，從第二個浮點數開始與前一個數進行異或計算，得到一個64位無符號整數作為差值，當兩個浮點數數值接近時得到的差值很小。當差值為0時僅存1位0；不為零時存1位1，然后用5位存儲64位中位于左端的0的數量，用6位存儲居右端的0的數量，再將非零位截取出來存儲。

布爾值的壓縮方法為：直接將布爾值用1位存儲到字節末尾(每個字節有8位)，當存滿1個字節后分配一個新字節。

字符串的壓縮方法為：將字符串順序添加到字節流后用snappy算法[6]壓縮。

時間類型的壓縮方法為：第一個時間不壓縮，從第二個時間開始與前一個時間進行差值計算。第一個差值不壓縮，然后從第二個差值開始計算與前一個差值的差值。如果差值的差值為0(當數據的存儲間隔相同時)，僅存儲0和0出現的次數；否則采用simple8b算法[8]存儲該差值的差值。

4 讀寫性能測試

influxDB開源代碼[10]采用GO語言實現，本文將引擎部分用.net framework 4.5重新實現，通過隨機數發生器每秒生成50 000點整型隨機數，進行了性能測試。測試硬件設備為一臺ThinkPad T550筆記本電腦，CPU：i5 5200U 2.2 G雙核，內存：8 GB，硬盤：256 GB固態硬盤。

寫入測試是每秒隨機發生5萬點整型數據，重復3 600次寫入，寫入平均耗時310毫秒。讀取性能測試進行了兩組，一組測試從1條/點到200條/點，分200次讀取5萬點的數據，讀取的數據條目數從5萬條到1 000萬條，如圖7所示，讀取耗時從2.8秒到9.2秒，隨著條數增加耗時呈線性增長趨勢；另一組測試分50次固定讀取100萬條數據，點數從1 000開始以1 000點步長一直增長到5萬點，得到的曲線如圖8所示，隨著點數增加，用時從0.6秒到3.3秒呈線性增長趨勢。

根據測試結果，引擎能夠實現單實例每秒5萬點的數據寫入，讀取相同記錄數的情況下，點數越少速度越快，這主要是在TSM文件中，一段時間內相同點的數據是按時間順序連續存儲的，而不同點的數據是間隔存儲的，因此點數越多文件位置的計算越多。考慮到工業時序數據庫應用以單點歷史曲線讀取為主，TSM文件結構有利于提高讀性能。

引擎的時間消耗中，用于集合運算和比較約占1/3，五種數據類型的壓縮和解壓縮約占2/3。由于.net framework相較.net core集合運算性能差距較大，加上浮點數、整數壓縮算法性能還有提升空間，引擎通過.net core重新編譯并采用性能更高的壓縮算法后，讀寫性能會有較大提升。

圖7 5萬點數據讀取速度曲線

圖8 100萬條數據讀取速度曲線

5 結 語

本文按照工業時序數據的特點，參考influxDB思想設計了工業時序數據庫的引擎。引擎自頂而下包括數據庫實例、存儲策略、存儲分片幾個層次，每個存儲分片里包含一個內存緩存區、一個或更多日志文件、多個數據文件，以及用于處理寫入、壓縮、讀取的線程。本文簡化了TSM文件結構，數據點位關鍵字由influxDB的字符型改為整型，降低了存儲占用和索引計算量。最后，進行了引擎的開發和性能測試。

未來，還需要做三個方面的改進：一是利用.net core重新編譯提高性能；二是壓縮解壓縮部分替換為性能更高的算法庫；三是增加分布式冗余機制，以便實現更大規模的數據吞吐量，并提高數據容錯能力。