為了(le)(le)驗證 TDengine 3.0 在 IoT 場景(jing)下(xia)的性(xing)能(neng)(neng)，我們針對第三方基準性(xing)能(neng)(neng)測(ce)(ce)試平臺(tai) TSBS（Time Series Benchmark Suite） 中的 IoT 場景(jing)，預設了(le)(le)五種規模的卡(ka)車(che)(che)車(che)(che)隊基礎(chu)數據(ju)集(ji)，在相同的 AWS 云環(huan)境下(xia)對 TDengine 3.0 和 InfluxDB 1.8（該版(ban)本是 InfluxDB 能(neng)(neng)夠運行 TSBS 框(kuang)架的最新版(ban)本）進(jin)行了(le)(le)對比分析(xi)。在本篇文(wen)章中，我們將從寫入、存儲、查詢、及(ji)資源(yuan)開銷(xiao)等幾大維(wei)度對兩(liang)大數據(ju)庫的測(ce)(ce)試結(jie)果進(jin)行匯總分析(xi)，給到大家參考。

為了將 InfluxDB 的性能發(fa)揮到極致，我們采用下方 [TimescaleDB vs. InfluxDB] 對比報告(gao)中推薦的方式配置(zhi) InfluxDB，將緩沖(chong)區配置(zhi)為 80GB，以便 1000W 設備(bei)寫入(ru)時能夠順利進行，同時開啟 Time Series Index（TSI）。配置(zhi)系統(tong)在系統(tong)插入(ru)數據完成 30s 后開始(shi)數據壓縮。

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

關于系統的配置詳情、如何一鍵復現測試結果及詳細的測試數據介紹等內容，大家可參考《一鍵獲取測試腳本，輕松驗證 TDengine 3.0 IoT 場景下 TSBS 測試報告》一文，本(ben)文便不再(zai)贅述。

寫入性能

總體而言，在(zai)預設的(de)五種規模的(de)卡車車隊場(chang)景中，TDengine 寫入性能(neng)均優于 InfluxDB。相(xiang)比 InfluxDB，TDengine 寫入速度最(zui)領先的(de)場(chang)景達到其 16.2 倍（場(chang)景五），最(zui)小為 1.82 倍（場(chang)景三(san))。此外，TDengine 在(zai)寫入過程中消耗了最(zui)少 CPU 資源和磁盤 IO 開(kai)銷。下面看(kan)一下具體分(fen)析(xi)：

不同場景下寫入性能對比

不同場(chang)景下寫(xie)入(ru)性能的對比(bi)（metrics/sec. 數值越(yue)大越(yue)好）

可以看到在全部五個場景中，TDengine 的寫入性能全面超越 InfluxDB。相對(dui)于 InfluxDB，TDengine在場(chang)景(jing)五(wu)中(zhong)寫入性能是 InfluxDB 的 16 倍(bei)，在差(cha)距最小的場(chang)景(jing)三中(zhong)也有 1.8 倍(bei)。

寫入過程資源消耗對比

數(shu)據(ju)寫(xie)(xie)入(ru)(ru)速度(du)并不能(neng)夠全面的(de)反映三個(ge)系統(tong)在不同場景(jing)下數(shu)據(ju)寫(xie)(xie)入(ru)(ru)的(de)整體(ti)表現。為此(ci)我們以 1,000,000 devices × 10 metrics（場景(jing)四）為例(li)，檢(jian)查數(shu)據(ju)寫(xie)(xie)入(ru)(ru)過(guo)(guo)程中的(de)服(fu)務器(qi)和(he)客(ke)戶端(duan)（包括客(ke)戶端(duan)與服(fu)務器(qi)）的(de)整體(ti)負載狀況，并以此(ci)來(lai)對(dui)比 TDengine 和(he) InfluxDB 在寫(xie)(xie)入(ru)(ru)過(guo)(guo)程中服(fu)務器(qi)/客(ke)戶端(duan)節點的(de)資源占(zhan)用情(qing)況，這里的(de)資源占(zhan)用主(zhu)要包括服(fu)務器(qi)端(duan)的(de) CPU 開(kai)銷/磁盤 IO 開(kai)銷和(he)客(ke)戶端(duan) CPU 開(kai)銷。

服務端 CPU 開銷

下圖展(zhan)示了在場景四寫(xie)(xie)入過(guo)程之中服(fu)(fu)務器(qi)端(duan) CPU 負載狀況。可以看(kan)到，TDengine 和 InfluxDB 在返回給(gei)客戶(hu)端(duan)寫(xie)(xie)入完成消(xiao)息以后，都還繼續使(shi)(shi)用服(fu)(fu)務器(qi)的(de)(de)資(zi)源(yuan)進行相(xiang)應的(de)(de)處理(li)工作。其(qi)中，InfluxDB 使(shi)(shi)用了相(xiang)當多的(de)(de) CPU 資(zi)源(yuan)，瞬時峰值(zhi)甚(shen)至使(shi)(shi)用了全部的(de)(de) CPU 資(zi)源(yuan)，其(qi)寫(xie)(xie)入負載較高，并且其(qi)持續時間遠長于 TDengine。兩(liang)個系(xi)統對(dui)比，TDengine 對(dui)服(fu)(fu)務器(qi)的(de)(de) CPU 需求最小，峰值(zhi)也(ye)僅(jin)使(shi)(shi)用了 17% 左右的(de)(de)服(fu)(fu)務器(qi) CPU 資(zi)源(yuan)。由此可見，TDengine 獨(du)特(te)的(de)(de)數(shu)據模(mo)型對(dui)于時序數(shu)據寫(xie)(xie)入不僅(jin)體(ti)現(xian)在性能上，同樣也(ye)體(ti)現(xian)在了整體(ti)的(de)(de)資(zi)源(yuan)開銷(xiao)上。

寫(xie)入過(guo)程中服務器CPU開(kai)銷(xiao)

磁盤 I/O 對比

下圖展示了(le) 1,000,000 devices × 10 metrics（場景四）數據寫入過程中服(fu)務器(qi)端磁盤寫入狀(zhuang)態。可以看到，結合(he)著服(fu)務器(qi)端 CPU 開銷表現，其 IO 動作與 CPU 呈現同步的活(huo)躍狀(zhuang)態。

寫入過程(cheng)中(zhong)服(fu)務器 IO 開銷(xiao)

在(zai)寫(xie)(xie)(xie)入(ru)(ru)相同規模的(de)數據情(qing)況下，TDengine 在(zai)寫(xie)(xie)(xie)入(ru)(ru)過(guo)程(cheng)中對(dui)(dui)于磁(ci)盤(pan)(pan)寫(xie)(xie)(xie)入(ru)(ru)能(neng)(neng)(neng)力(li)的(de)占(zhan)用遠小于 InfluxDB，寫(xie)(xie)(xie)入(ru)(ru)過(guo)程(cheng)只占(zhan)用了部(bu)(bu)分磁(ci)盤(pan)(pan)寫(xie)(xie)(xie)入(ru)(ru)能(neng)(neng)(neng)力(li)（125MiB/Sec. 3000IOPS）。從上圖能(neng)(neng)(neng)看(kan)到，對(dui)(dui)于兩(liang)大數據庫(ku)，數據寫(xie)(xie)(xie)入(ru)(ru)過(guo)程(cheng)中磁(ci)盤(pan)(pan)的(de) IO 瓶(ping)頸是(shi)確(que)實存(cun)在(zai)的(de)。但 InfluxDB 長時間消耗(hao)完全部(bu)(bu)的(de)磁(ci)盤(pan)(pan)寫(xie)(xie)(xie)入(ru)(ru)能(neng)(neng)(neng)力(li)，遠遠超過(guo)了 TDengine 對(dui)(dui)磁(ci)盤(pan)(pan)寫(xie)(xie)(xie)入(ru)(ru)能(neng)(neng)(neng)力(li)的(de)需求。

客戶端 CPU 開銷

寫入(ru)過程中客戶端 CPU 開銷

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

查詢性能

在(zai)查(cha)詢性能評估部分，我們(men)使用場景(jing)一(yi)(yi)（只(zhi)包(bao)含(han) 4 天數(shu)據(ju)(ju)，本(ben)修(xiu)改與 [TimescaleDB vs. InfluxDB] 中(zhong)要求一(yi)(yi)致）和場景(jing)二(er)作為基準(zhun)數(shu)據(ju)(ju)集。在(zai)整個查(cha)詢對比中(zhong)，TDengine 數(shu)據(ju)(ju)庫的虛擬節點(dian)數(shu)量(liang)（vnodes）保持為默(mo)認的 6 個（scale=100 時配(pei)置 1 個），其他的數(shu)據(ju)(ju)庫參數(shu)配(pei)置為默(mo)認值。

總體來說，查詢方(fang)面(mian)，在場(chang)景一（只包含 4 天的(de)數據）與場(chang)景二的(de) 15 個不同(tong)(tong)類型的(de)查詢中(zhong)，TDengine 的(de)查詢平均(jun)響應時(shi)間全(quan)面(mian)優于 InfluxDB，而且在復雜查詢上優勢(shi)更為明顯，同(tong)(tong)時(shi)具有最小的(de)計算資源開銷(xiao)。相比 InfluxDB，場(chang)景一中(zhong) TDengine 查詢性(xing)能是(shi)其(qi) 2.4 到 155.9 倍，場(chang)景二中(zhong) TDengine 查詢性(xing)能是(shi)其(qi) 6.3 到 426.3 倍。

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

由(you)于大部(bu)分類型單(dan)次(ci)查詢響應時間過長，為(wei)了更加準確地測量(liang)每個查詢場景的(de)較(jiao)為(wei)穩定的(de)響應時間，我們(men)依據卡車數量(liang)規模，將單(dan)個查詢運行次(ci)數分別提升(sheng)到 2,000 次(ci)（場景一(yi)）和 500 次(ci)（場景二(er)），然后使用 TSBS 自動統計并輸出(chu)結果，最后結果是多次(ci)查詢的(de)算(suan)數平均值，使用并發客戶(hu)端 Workers 數量(liang)為(wei) 4。首先我們(men)提供場景二(er) （4,000 設備）的(de)查詢性能對比結果。

下(xia)面(mian)我們(men)對每個查詢(xun)結果做一定的(de)分析(xi)說(shuo)明：

4000 devices 查詢響應時間 (數值越(yue)小越(yue)好(hao))

在(zai)分組選擇的(de)查(cha)詢中(zhong)，TDengine 采用(yong)一張(zhang)表一個設(she)(she)備（卡(ka)車(che)）的(de)設(she)(she)計方式，并采用(yong)緩(huan)存(cun)模式的(de) last_row 函數來查(cha)詢最新的(de)數據，在(zai)查(cha)詢響應時間上(shang)全面優于 InfluxDB。

4000 devices Aggregates 查(cha)詢響應(ying)時間 (數值越(yue)小越(yue)好(hao))

在復雜分組聚合的(de)查詢中，我(wo)們看到 TDengine 查詢性能相比(bi)于 InfluxDB 有非(fei)常大的(de)優勢。其中，TDengine 在 stationary-trucks 查詢性能是 InfluxDB 的(de) 132倍，在 long-daily-sessions 中是 InfluxDB 的(de) 6.5 倍。

4000 devices Double rollups 查詢響應時間 (數(shu)值越(yue)小(xiao)越(yue)好(hao))

4000 devices 查詢響(xiang)應時間 (數值越小越好)

在復雜的混合查詢中(zhong)， TDengine 同樣展現出(chu)巨大的性能優勢，從查詢響應時間來看，其中(zhong) avg-load 和 breakdown-frequency 的查詢性能是(shi) InfluxDB 的 426 倍(bei)和 53 倍(bei)。

資源開銷對比

由(you)于(yu)部(bu)分查詢持續(xu)時間特別短，并不能完(wan)整地看到查詢過程(cheng)中(zhong)服務(wu)器的 IO/CPU/網絡(luo)情(qing)況，為此我們針對(dui)場景(jing)二，以 daily-activity 查詢為例，執行(xing) 50 次查詢，記(ji)錄整個(ge)過程(cheng)中(zhong)三個(ge)軟件系(xi)統在查詢執行(xing)中(zhong)服務(wu)器 CPU、內存、網絡(luo)的開銷并進行(xing)對(dui)比。

• 服務器 CPU 開銷

查詢過程(cheng)中服務(wu)器 CPU 開銷(xiao)

從上圖可以看到，兩個系(xi)統在整(zheng)(zheng)個查詢(xun)過(guo)程中(zhong) CPU 的(de)(de)使(shi)(shi)用(yong)(yong)均較為(wei)平穩，TDengine 在查詢(xun)過(guo)程中(zhong)整(zheng)(zheng)體 CPU 占用(yong)(yong)約(yue) 70%，InfluxDB 穩定(ding)的(de)(de) CPU 占用(yong)(yong)最(zui)大(da)，約(yue) 98 %（有較多(duo)的(de)(de)瞬時(shi) 100%）。從整(zheng)(zheng)體 CPU 開(kai)銷上來看，InfluxDB 基本頂格 100% 使(shi)(shi)用(yong)(yong)全部 CPU，持續時(shi)間(jian)是 TDengine 的(de)(de)三倍(bei)，開(kai)銷次之；TDengine 完成全部查詢(xun)的(de)(de)時(shi)間(jian)較短，整(zheng)(zheng)體 CPU 開(kai)銷最(zui)低。

• 服務器內存狀況

查(cha)詢過(guo)程中服(fu)務(wu)器(qi)內存(cun)情況(kuang)

如上(shang)圖所示，在整(zheng)個查(cha)詢過程中(zhong)，TDengine 內(nei)存(cun)維持在一個相對(dui)平(ping)穩(wen)的狀態，平(ping)均(jun)使用(yong)約為 12GB；InfluxDB 內(nei)存(cun)占用(yong)在整(zheng)個查(cha)詢過程中(zhong)保持平(ping)穩(wen)，平(ping)均(jun)約為 10GB。

• 服務器網絡帶寬

查(cha)詢(xun)過程中網絡占用情況

上圖(tu)展示了兩大系統在查詢(xun)過程中服務(wu)器端上行(xing)和下(xia)行(xing)的網(wang)絡(luo)帶寬情況，負載狀況基本上和 CPU 狀況相似。其中 TDengine 網(wang)絡(luo)帶寬開銷最高，因為(wei)在最短的時間內就(jiu)完成了全部查詢(xun)，需要將查詢(xun)結果(guo)返回給客戶(hu)端。

100 devices × 10 metrics 查詢性能對比

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

如(ru)上表(biao)所示，從更小規模的(de)數(shu)據集（場景一）上的(de)查詢對比(bi)可(ke)以看到，整體上 TDengine 同(tong)樣展現出了極好的(de)性(xing)能，在全部的(de)查詢語句中全面(mian)優于 InfluxDB，部分查詢性(xing)能甚至(zhi)超過 InfluxDB 155 倍。

磁盤空間占用

在兩(liang)大系統數據完全落盤(pan)以后，我(wo)們對 TDengine 和 InfluxDB 在不(bu)同場景下(xia)的磁盤(pan)空(kong)間占用也進行了比(bi)較(jiao)。

磁盤空(kong)間(jian)占用（數值(zhi)越小越優）

從(cong)上圖可以(yi)(yi)看到，在前面三個(ge)場(chang)景中(zhong)，InfluxDB 落盤(pan)后數據文件規模與(yu) TDengine 比較接近(jin)；但(dan)是(shi)在場(chang)景四/五兩個(ge)場(chang)景中(zhong)，InfluxDB 落盤(pan)后文件占用(yong)的磁盤(pan)空間是(shi) TDengine 的 2 倍(bei)以(yi)(yi)上。

寫在最后

基于本次(ci)測試報告，我們可以(yi)得(de)出結(jie)論，在全部的 IoT 數據(ju)場景(jing)中(zhong)，TDengine 寫(xie)入性能(neng)(neng)、查(cha)詢性能(neng)(neng)均全面超過 InfluxDB。在整個(ge)寫(xie)入過程中(zhong)，TDengine 在提供(gong)更高寫(xie)入和查(cha)詢能(neng)(neng)力的前提下，不論是(shi)服務器(qi)的 CPU 還(huan)是(shi) IO，均優于 InfluxDB。即使加上(shang)客戶端(duan)的開銷統計，TDengine 在寫(xie)入開銷上(shang)也在 InfluxDB 之下。

從實踐角度出發，這個報告結果也很好地說明了為什么有很多企業和開發者在時序數據庫（Time Series Database） InfluxDB 和 TDengine 的選型調研中選擇了 TDengine，在《從 InfluxDB 到 TDengine，我們為什么會做出這個選擇》這篇文章中(zhong)，便闡述了作者(zhe)在(zai)進行項目選型調研過程時的具體思考。

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