基于試飛數據的時序數據庫性能測試

韓超

上海航空工業（集團）有限公司 上海 200120

引言

隨著民機研發進程的加快，試飛愈加頻繁，試飛數據飛速增長，傳統的關系型數據庫已不能滿足試飛時序數據存儲全時全量、高效寫入、緊湊存儲的需求，hadoop大數據系統也不能提供實時高效查詢的功能。而時序數據庫是專門存儲時序數據的，并對其查詢做了專門的優化，可以滿足試飛時序數據的需求，本文將對其進行介紹，并根據試飛業務需求對其測試在試飛時序數據上的性能。

1 介紹

1.1 時序數據

時序數據，即時間序列數據，把用一系列按順序排列的時間戳標識的數據稱為時間序列數據。近年來，各行各業產生的數據越來越多，時序數據的應用更為廣泛，比如風機、物聯網、智能制造、環境監測領域等各方面，往過去看可以做成多維度報表，揭示其趨勢性、規律性、異常性；往未來看可以做大數據分析，機器學習，實現預測和預警，所以越來越多的公司開始關注時序數據。所有有時序數據產生，并且需要展現其歷史規律、周期規律、異常性等，進一步對未來做出預測分析的，都是時序數據庫適合的場景。

時序數據具有以下特點，①數據產生快，每秒高頻采集工況數據頻率高；②數據總量大，如果機器長期處于24小時不間斷采集數據的運行狀態，這就對海量時序數據存儲提出了要求；③數據種類多，數據的來源與格式多種多樣，有布爾值、浮點數，有的傳感器一個時間戳對應多個值[1]。

時序數據與關系型數據存在較大差異，①時序數據以時間戳作為唯一標識，按其大小排序區分，而關系型數據庫以其他字段為標識；②時序數據不關心實體屬性關系；③時序數據的數據量持續呈線性增長，機器運行期間，時時刻刻產生新數據。而關系性數據增長通常不隨時間持續增長，在一段時間內相對穩定；④時序數據很少有更新操作，歷史值將不會發生改變。而關系型數據對于存量數據經常需要更新[2]。

1.2 時序數據庫

由于時序數據的飛速增長，及其與關系型數據的區別，一種新的數據庫——時序數據庫應運而生，并且應用越來越廣泛。時序數據庫一般具有以下特點：

1.2.1 高壓縮率。海量的時序數據需要大量的存儲空間，并且可能會存儲很長時間，這就要求時序數據庫根據數據特征進行壓縮。

1.2.2 高吞吐量。由于時序數據會持續產生，并且寫入的并發量大，這就要求時序數據庫系統實現高吞吐的高速寫入功能。

1.2.3 高效的時間窗口查詢能力。時序數據的業務分兩類，一是實時數據查詢；二是查詢某個時間段的歷史數據；

1.2.4 高效聚合能力。時序業務通常會關注數據的count、avg、first_value等聚合值，來反應某時間段內的數據特征，這就需要時序數據庫提供高效的聚合函數。

1.2.5 批量刪除能力。時序業務對于部分歷史數據有批量刪除的需求。

1.2.6 通常不具備事物的能力。近年來時序數據庫的產品相繼出現，早在2016年7月，百度云在其天工物聯網平臺上發布了國內首個多租戶的分布式時序數據庫產品TSDB，成為支持其發展制造、交通、能源、智慧城市等產業領域的核心產品，同時也成為百度戰略發展產業物聯網的標志性事件。2017年2月Facebook開源了beringe時序數據庫，4月PostgreSQL開源了TimeScalaDB開源數據庫；相繼又出現了許多優秀的時序數據庫，包括DolphinDB，InfluxDB，HiTSDB，Druid，OpenTSDB，IoTDB等。

2 基于試飛數據的性能測試

根據試飛業務需求，試飛數據在壓縮率、數據寫入方面要求較高，實時查詢次之，故先橫向對比，根據壓縮率、數據寫入性能選出適用于試飛數據的時序數據庫，再縱向測試實時查詢性能，并對其多次寫入、查詢性能穩定性進行測試。

本測試選取了InfluxDB、TimescalaDB、Druid、TDengine、IoTDB幾種主流的時序數據庫，在相同的環境下，測試相同的試飛時序數據（只測試單機版，未考慮分布式）。采用的評測環境為：

CPU型號： Intel(R) Xeon(R) CPU E5-4850 v4@ 2.10GHz(16核32線程*4）。

內存：256G(DDR4,2400MHz)。

硬盤：1T (非SSD)。

操作系統：Windows Server2012R2 Standard。

2.1 數據壓縮能力

對IoTDB、InfluxDB、TimescalaDB、Druid、TDengine幾種時序數據庫依次寫入試飛數據，對比試飛數據文件與數據庫文件的空間占用情況，得出圖1壓縮率對比圖，壓縮率IoTDB＞Druid＞TDengine＞influxDB＞Timescala， DB、IoTDB的空間占用率明顯優于其他幾種數據庫。TimescaleDB 中數據庫占用的存儲空間甚至大于原始數據文件的大小，由于Timescale 只對比較大的字段進行自動壓縮（TOAST），對數據表沒有自動壓縮的功能，即如果字段較小、每行較短而行數較多，則數據表不會進行自動壓縮，若使用 ZFS 等壓縮文件系統，則會顯著影響查詢性能。

將10架次的試飛數據依次寫入IOTDB中，后9架次試飛數據作為增量數據寫入，數據文件tsfile空間占比如圖2，可見IOTDB壓縮率保持在4.5%左右，性能比較穩定，并沒有隨著數據庫數據的增加而大幅波動，可以大大節省空間。

圖1 壓縮率對比

圖2 壓縮率

2.2 數據寫入能力

將試飛數據文件寫入到數據庫，數據具有多頻率、多時間段、多參數的特征，測試包含了亂序寫入的情況。第一架次寫入時數據庫為無存量數據寫入，后九架次試飛數據作為增量數據寫入，得到文件寫入速率如圖3所示，IoTDB＞ TDengine ＞InfluxDB ＞ TimescalaDB ＞ Druid,顯然單機狀態下IoTDB寫入性能明顯優于其他數據庫。

10個架次試飛數據依次寫入IOTDB時，寫入速率折線圖如圖3所示，顯然隨著試飛數據的寫入，寫入速率并沒有明顯降低，穩定在31.25M/s，寫入性能比較穩定。

圖3 寫入速率對比圖

圖4 寫入速率

2.3 數據查詢能力

對于試飛數據來說，壓縮率與寫入速率是最重要的兩個指標，通過測試可以看出單機情況下IOTDB壓縮、寫入性能明顯優于其他幾種數據庫，并且性能穩定，下面針對IOTDB的查詢性能及查詢穩定性進行測試。對于數據查詢，主要關注的五種常見的查詢場景下，吞吐量和請求響應時間這兩個指標。

2.3.1 一般查詢。一般查詢指的是對數據庫內已有數據的一些字段進行查看。在查詢的變量數不同的情況下，考察各個時序數據庫的吞吐量和請求響應延時的變化。

2.3.2 時間段查詢。時間段查詢是時序數據庫獨有的場景，針對某一段時間內的某些字段進行查看。這一部分要評測的是時序數據庫對于同一個時間段的請求的響應延時情況，這主要取決于數據庫對時間戳的存放方式。

根據1、2查詢場景，設計了所有時間范圍內單參數查詢和確定時間單參數查詢，結果如圖5所示，隨著數據庫試飛數據的增加，可見兩種情況都在各自均值范圍波動，波動很小為毫秒級；時間范圍查詢比確定時間的查詢耗時稍多，可見隨著時間范圍的增加，會增加毫秒級耗時，時間上差別并不大。

圖5 單參數查詢

2.3.3 多參數查詢。試飛數據在應用過程中，經常需要進行分包，供業務部門分析使用，針對此場景，設計了隨著試飛數據的寫入，時間范圍內參數個數為1、50、100、150、200、250、300、350、400的查詢，測評數據庫的請求響應延時的變化情況。

由圖6可見，隨著時序數據庫數據量的增加，從其中依次查詢1、50、100、150...400個參數，查詢相同參數的時間在相同數量級上，并沒有明顯的耗時增加，始終在毫秒級耗時波動，比較穩定；從另一個維度看，初始查詢狀態，IOTDB索引的緩存機制還沒有建立，故查詢耗時較大，此后查詢時間急劇下降并穩定，如圖7所示。

圖6 多參數查詢1

圖7 多參數查詢2

2.3.4 聚合查詢。聚合查詢指的是對數據庫內已有數據進行例如求和、取平均值、取不同值等復雜的查詢操作。我們會對各個數據庫，進行不同的查詢變量數、不同的查詢數據量以及不同的聚合查詢語句的聚合查詢性能評測，考察各個時序數據庫的吞吐量和請求響應延時情況。

2.3.5 降頻查詢。試飛數據有的數據頻率較高，業務部門分析時有時需要低頻率數據，分包時就需要降頻率。在這一部分，我們評測的是IoTDB在查詢過程中將原本的高頻字段進行低頻查詢后，數據庫吞吐量和請求響應延時的變化情況。

根據4、5查詢場景，設計了1、2個參數的計數聚合查詢和時間范圍內的一個參數最大值、最小值、最大時間、最小時間、平均值、和、降頻查詢、count計數查詢，結果如圖8、圖9所示。

由圖8可得，計數聚合查詢主要與IOTDB數據庫的數據量有關，隨著數據量的增加，耗時逐漸稍微增加，由于索引及緩存機制，可減少查詢時間；由圖9可得，最大值、最小值、最大時間、最小時間、平均值、和、count查詢都在500ms內響應，降頻統計在1500ms內響應，波動都很小，受數據庫數據量的影響較小，性能穩定。

圖8 計數聚合查詢

圖9 聚合查詢

3 基于時序數據庫的查詢應用

基于時序數據庫IOTDB，應用清華數為系統集成框架（DataWay Framework DWF）連接數據庫，開發了試飛數據的參數查詢平臺，可以查詢選定時間范圍內的多個參數，并設置與預警線、均值等，如圖10所示。

圖10 試飛參數查詢

4 結束語

本文根據試飛業務數據需求的側重點，測試了試飛數據在幾種時序數據庫上的寫入性能、壓縮性能，并對選出的IOTDB測試了幾種查詢場景的性能，綜合分析得出，IOTDB是比較適合應用在試飛業務中，最后使用DWF建立了試飛參數查詢平臺。 對于試飛業務數據來說，時序數據庫的效率遠遠優于傳統數據庫，在今后會得到更加廣泛的應用。