為了驗證 TDengine 3.0 的性能，我們使用第三方基準性能測試平臺 TSBS（Time Series Benchmark Suite） 中針對 DevOps 的 cpu-only 五個場景作為基礎數據集，在相同的 AWS 云環境下對 TDengine 3.0 和 InfluxDB 1.8（該版本是 InfluxDB 能夠運行 TSBS 框架的最新版本） 進(jin)行了對比(bi)分析。在本(ben)篇文章中，我們將從(cong)寫(xie)入、存儲、查詢(xun)、及資源(yuan)開銷等幾大維(wei)度對測試結(jie)果(guo)進(jin)行匯總分析，給到(dao)大家參考。

我們采用下(xia)方(fang) TimescaleDB vs. InfluxDB 對比報(bao)告中(zhong)推(tui)薦的方(fang)式配(pei)置 InfluxDB，將緩沖區(qu)配(pei)置為 80G，以便 1000W 設備寫入(ru)時能(neng)夠(gou)順利進行，同(tong)時開啟(qi) Time Series Index（TSI）。配(pei)置系統(tong)在(zai)系統(tong)插入(ru)數據完成(cheng) 30s 后(hou)開始數據壓縮。

TimescaleDB vs. InfluxDB: Purpose Built Differently for Time-Series Data：

關于系統的配置詳情、如何一鍵復現測試結果及詳細的測試數據介紹等內容，大家可參考《一鍵獲取測試腳本，輕松驗證“TSBS 時序數據庫性能基準測試報告”》、《TSBS 是什么？為什么時序數據庫 TDengine 會選擇它作為性能對比測試平臺？》兩篇文(wen)章，本文(wen)便不(bu)再贅(zhui)述。

寫入性能最高達到 InfluxDB 的 10.6 倍

總體而言，在 TSBS 報告全部的 cpu-only 五個場景中，時序數據庫（Time Series Database,TSDB）TDengine 寫(xie)入(ru)性能均(jun)優于 InfluxDB。相比 InfluxDB，TDengine 寫(xie)入(ru)速度(du)最領先(xian)的(de)場(chang)(chang)景是(shi)其 10.6 倍(bei)（場(chang)(chang)景五），最少(shao)也是(shi) 3.0 倍(bei)（場(chang)(chang)景一)。此外，TDengine 在(zai)寫(xie)入(ru)過程中消耗了最少(shao) CPU 資(zi)源和磁(ci)盤 IO 開銷。下(xia)面看一下(xia)具體分析：

不同場景下寫入性能對比

從上圖可以看到，在全部五個場景中，TDengine 的寫入性能全面超越 InfluxDB。TDengine 在場景(jing)五中寫入性能是 InfluxDB 的 10.63 倍，在差距最(zui)小的場景(jing)一(yi)中也(ye)有 3.01 倍。

寫入過程資源消耗對比

數據寫入速度并不能(neng)夠全(quan)面的(de)反映 TDengine 和(he) InfluxDB 在不同場景下數據寫入的(de)整體表(biao)現。為(wei)此(ci)我們以(yi) 1,000,000 devices × 10 metrics （場景四(si)）為(wei)例(li)，檢查數據寫入過程中(zhong)的(de)服(fu)務(wu)器(qi)(qi)和(he)客(ke)(ke)戶端(duan)(duan)（包括(kuo)客(ke)(ke)戶端(duan)(duan)與服(fu)務(wu)器(qi)(qi)）的(de)整體負載狀況，并以(yi)此(ci)來對比 TDengine 和(he) InfluxDB 在寫入過程中(zhong)服(fu)務(wu)器(qi)(qi)/客(ke)(ke)戶端(duan)(duan)節(jie)點的(de)資(zi)源(yuan)占(zhan)用(yong)情況，這(zhe)里的(de)資(zi)源(yuan)占(zhan)用(yong)主要包括(kuo)服(fu)務(wu)器(qi)(qi)端(duan)(duan)的(de) CPU 開銷(xiao)/磁盤 IO 開銷(xiao)和(he)客(ke)(ke)戶端(duan)(duan) CPU 開銷(xiao)。

服務端 CPU 開銷

下圖展示了兩大數據庫在場景四寫入過程中服務器端 CPU 負載狀況。可以看到，TDengine 和 InfluxDB 在返回給客戶端寫入完成消息以后，都還繼續使用服務器的資源進行相應的處理工作，InfluxDB 使用了相當多的 CPU 資源，瞬時峰值甚至使用了全部的 CPU 資源，其寫入負載較高，并且其持續時間遠長于 TDengine。兩個系統對比，TDengine 對服務器的 CPU 需求最小，峰值也僅使用了 17% 左右的服務器 CPU 資源。由此(ci)可見，TDengine 獨(du)特的數(shu)據(ju)模型對于(yu)時序數(shu)據(ju)寫入(ru)不僅在性能上，在整體的資源開(kai)銷上也具有非常大的優勢。

磁盤 I/O 對比

下(xia)圖(tu)展示了 1,000,000 devices × 10 metrics （場景四）數據(ju)寫(xie)入過程(cheng)中兩大數據(ju)庫在服(fu)務器端磁盤(pan)的(de)寫(xie)入狀態。可以看到(dao)，結合著服(fu)務器端 CPU 開銷表現，其 IO 動作與 CPU 呈現同步的(de)活躍狀態。

在寫入相同規模的數據集情況下，TDengine 在寫入過程中對于磁盤寫入能力的占用遠小于 InfluxDB，寫入過程只占用了部分磁盤寫入能力（125MiB/Sec. 3000IOPS）。從上圖能看到，對于兩大數據庫，數據寫入過程中磁盤的 IO 瓶頸都是確實存在的。但 InfluxDB 長時間消耗完全部的磁盤寫入能力，遠遠超過了 TDengine 對磁盤寫入能力的需求。

客戶端 CPU 開銷

從上圖可以看到，客戶端上 TDengine 對 CPU 的需求是大于 InfluxDB 的。整體來說，在整個寫入過程中，InfluxDB 客戶端負載計算資源占用較低，對客戶端壓力小，這是因為其寫入的壓力基本上完全集中在服務端，但這種模式很容易導致服務端成為瓶頸。而 TDengine 在客戶端的開銷最大，峰值瞬間達到了 56%，然后快速回落。綜合服務器與客戶端的資源開銷來看，TDengine 寫入持續時間更短，在系統整體 CPU 開銷上 TDengine 仍然具有相當大的優勢。

查詢性能最高達到 InfluxDB 的 37 倍

在(zai)查(cha)詢(xun)(xun)性能(neng)的評估(gu)上，我(wo)們(men)使(shi)用場景一和場景二作為基準數據(ju)集。為了讓 InfluxDB 發揮出更好(hao)的查(cha)詢(xun)(xun)性能(neng)，我(wo)們(men)開啟 InfluxDB 的 TSI (time series index)。在(zai)整個查(cha)詢(xun)(xun)對比中(zhong)，TDengine 數據(ju)庫的虛擬節點數量（vnodes）保(bao)持為默(mo)認(ren)的 6 個，其他的數據(ju)庫參(can)數配(pei)置為默(mo)認(ren)值。

總(zong)體來說，查詢(xun)方面，在場(chang)景(jing)一(yi)(yi)（只包含 4 天的(de)(de)數據）與場(chang)景(jing)二的(de)(de) 15 個(ge)不同類型的(de)(de)查詢(xun)中(zhong)(zhong)，TDengine 的(de)(de)查詢(xun)平均響應時間是全面優于 InfluxDB 的(de)(de)，而且在復雜查詢(xun)上優勢(shi)更為明顯，同時具有最小的(de)(de)計算資源開銷。相比(bi) InfluxDB，場(chang)景(jing)一(yi)(yi)中(zhong)(zhong) TDengine 查詢(xun)性(xing)能(neng)是其 1.9 ～ 37.0 倍，場(chang)景(jing)二中(zhong)(zhong) TDengine 查詢(xun)性(xing)能(neng)是其 1.8 ～ 34.2 倍。

4,000 devices × 10 metrics查詢性能對比

由于(yu)部分類型（分類標準參見 TimescaleDB vs. InfluxDB 對比(bi)(bi)報告）單(dan)次查(cha)詢(xun)響(xiang)應時間非常短，為(wei)了更加準確(que)地測(ce)量每個查(cha)詢(xun)場景(jing)(jing)的較為(wei)穩(wen)定的響(xiang)應時間，我(wo)們將單(dan)個查(cha)詢(xun)運行次數提升到 5,000 次，然(ran)后使用(yong) TSBS 自動統計(ji)并(bing)(bing)輸出結(jie)(jie)(jie)果(guo)，最后結(jie)(jie)(jie)果(guo)是(shi) 5,000 次查(cha)詢(xun)的算(suan)數平(ping)均值(zhi)，使用(yong)并(bing)(bing)發(fa)客戶端 Workers 數量為(wei) 8。首先(xian)我(wo)們提供場景(jing)(jing)二（4,000 設備）的查(cha)詢(xun)性能對比(bi)(bi)結(jie)(jie)(jie)果(guo)：

下面我們對每個查詢結果做一定的分析說明：

由于 Simple Rollups 的整體查(cha)(cha)詢(xun)響(xiang)應(ying)時(shi)間非(fei)常短，制約查(cha)(cha)詢(xun)響(xiang)應(ying)時(shi)間主體因(yin)素并不(bu)是(shi)查(cha)(cha)詢(xun)涉(she)及的數據(ju)(ju)規模(mo)，即這(zhe)種類(lei)型(xing)查(cha)(cha)詢(xun)的瓶頸并不(bu)是(shi)數據(ju)(ju)規模(mo)。但是(shi) TDengine 仍(reng)然在所有類(lei)型(xing)的查(cha)(cha)詢(xun)響(xiang)應(ying)時(shi)間上優于 InfluxDB，具體的數值比較請參見(jian)上表中的詳細數據(ju)(ju)表格。

在 Aggregates 類型的查詢中，我們看到 TDengine 查詢性能相比于 InfluxDB 有較大優勢，TDengine cpu-max-all-8 類型的查詢性能是 InfluxDB 的 7 倍。

在 Double-rollups 類型查詢中， TDengine 同樣展現出巨大的性能優勢，以查詢響應時間來度量，在 double-groupby-5 查詢上 TDengine 是 InfluxDB 的 26 倍，double-groupby-all 上是其 34 倍。

上面兩圖是 threshold 類型的查詢對比，TDengine 的查詢響應時間均顯著低于 InfluxDB。在 high-cpu-all 類型的查詢上，TDengine 的性能是 InfluxDB 的 15 倍。

對于 Complex-queries 類型的查詢，TDengine 兩個查詢均大幅領先 InfluxDB。在 lastpoint 查詢中，查詢性能是 InfluxDB 的 21倍；在 groupby-orderby-limit 場景中查詢性能是 InfluxDB 的 15 倍。

資源開銷對比

由(you)于(yu)部分查(cha)(cha)詢持續時間(jian)特(te)別短(duan)，因此(ci)我們(men)并不能完整地看到查(cha)(cha)詢過程中服務器(qi)的(de) IO/CPU/網(wang)絡(luo)情(qing)況。為此(ci)我們(men)針(zhen)對場景二以 Double rollups 類(lei)別中的(de) double-groupby-5 查(cha)(cha)詢為例，執(zhi)(zhi)行(xing) 1,000 次(ci)查(cha)(cha)詢，記錄(lu) TDengine 和(he) InfluxDB 在(zai)查(cha)(cha)詢執(zhi)(zhi)行(xing)的(de)整個過程中服務器(qi) CPU、內存、網(wang)絡(luo)的(de)開(kai)銷(xiao)并進行(xing)對比。

從上圖可以看到，TDengine 和 InfluxDB 在整個查詢過程中 CPU 的使用均較為平穩。TDengine 在查詢過程中整體 CPU 占用約 80%，使用的 CPU 資源較高，InfluxDB 穩定的 CPU 占用較小，約 27 %（但是有較多的瞬時沖高）。從整體 CPU 開銷上來看，雖然 InfluxDB 瞬時 CPU 開銷大部分是較低的，但是其完成查詢持續時間最長，所以整體 CPU 資源消耗最多。由于 TDengine 完成全部查詢的時間僅是 InfluxDB 的 1/20，雖然 CPU 穩定值是 InfluxDB 的 2 倍多，但整體的 CPU 計算時間消耗只有其 1/10 。

服務器內存狀況

如(ru)上圖所示，在整個查詢過程(cheng)中，TDengine 與 InfluxDB 的(de)內存均維持在一個相對平穩的(de)狀(zhuang)態。

服務器網絡帶寬

上圖展示了查詢過程中服務器端上行和下行的網絡帶寬情況，負載狀況基本上和 CPU 狀況相似。TDengine 網絡帶寬開銷最高，因為在最短的時間內就完成了全部查詢，需要將查詢結果返回給客戶端。InfluxDB 網絡帶寬開銷最低，持續時間也較(jiao)長(chang)。

3,100 devices × 10 metrics 查詢性能對比

對(dui)于場(chang)景(jing)一(100 devices x 10 metrics)，TSBS 的 15 個查詢對(dui)比結果如下：

如上表所示，在更小規模的數據集（100設備）上的查詢對比可以看到，整體上 TDengine 同樣展現出極好的性能，在全部的查詢語句中全面優于 InfluxDB，部分查詢性能超過 InfluxDB 37 倍。

InfluxDB 占用的磁盤空間最高達到 TDengine 的 4.5 倍

在前面三個(ge)場(chang)景中，InfluxDB 落盤后數據(ju)文(wen)件(jian)規(gui)模與 TDengine 非常(chang)接(jie)近(jin)，但是在大數據(ju)規(gui)模的場(chang)景四和場(chang)景五中，InfluxDB 落盤后文(wen)件(jian)占用(yong)的磁(ci)盤空間顯著超過了 TDengine。下(xia)(xia)圖比較了 TDengine 和 InfluxDB 在不同場(chang)景下(xia)(xia)的磁(ci)盤空間占用(yong)情況(kuang)：

從上圖可以看到，在前面三個場景中，InfluxDB 落盤后數據文件規模與 TDengine 非常接近（在場景二中，TDengine 的數據落盤規模比 InfluxDB 大了 1%）。但是在場景四和場景五中，InfluxDB 落盤后文件占用的磁盤空間分別是 TDengine 的 4.2 倍和 4.5 倍。

寫在最后

基(ji)于本(ben)次測(ce)試報告，我(wo)們(men)可以(yi)得出(chu)結論，在(zai)(zai)全部(bu)的(de)數據場(chang)景(jing)中，TDengine 寫入性(xing)能(neng)、查(cha)(cha)詢性(xing)能(neng)均全面超過 InfluxDB。在(zai)(zai)整個寫入過程中，TDengine 在(zai)(zai)提供更高寫入和查(cha)(cha)詢能(neng)力的(de)前提下(xia)，不(bu)論是(shi)服務器的(de) CPU 還是(shi) IO，TDengine 均優于 InfluxDB。即使(shi)加(jia)上(shang)客(ke)戶端的(de)開銷(xiao)統計(ji)，TDengine 在(zai)(zai)寫入開銷(xiao)上(shang)也(ye)在(zai)(zai) InfluxDB 之下(xia)。

從實踐角度出發，這個報告結果也很好地說明了為什么有很多企業客戶在 InfluxDB 和 TDengine 的選型調研中選擇了 TDengine，雙匯便是其中之一，在《雙匯大數據方案選型：從棘手的InfluxDB+Redis到毫秒級查詢的TDengine》這篇(pian)文章中，便闡(chan)述了其選型(xing)調研(yan)過程的具體思(si)考。

為了方便大家驗證測試結果，本測試報告支持運行測試腳本一鍵復現，歡迎大家在評論區互動交流。同(tong)(tong)時，你也可以添(tian)加 小T vx：tdengine1，加入 TDengine 用戶交流群，和(he)更多志同(tong)(tong)道(dao)合的(de)開(kai)發者一起探討數據處理難題。