在上一篇文章《寫入性能：TDengine 最高達到 InfluxDB 的 10.3 倍，TimeScaleDB 的 6.74 倍》中，我們基于 TSBS 時序數據庫（Time Series Database）性(xing)能(neng)(neng)基準測試報告對(dui)三(san)大(da)數(shu)據庫寫入(ru)性(xing)能(neng)(neng)進行了(le)相關(guan)解讀，較為直觀地(di)展現出了(le) TDengine 的眾多(duo)寫入(ru)優勢。本篇文章將以查詢性(xing)能(neng)(neng)作為主題，給正在為數(shu)據分析痛點而(er)頭疼的朋友們帶來一(yi)些幫助。
在查詢性能評估部分，我們使用場景一（只包含 4 天數據）和場景二作為基準數據集，關于基礎數據集的具體特點，請點擊進入《TSBS 是什么？為什么 TDengine 會選擇它作為性能對比測試平臺？》一文中查看。在(zai)查詢性(xing)能(neng)評估(gu)之前，為確保兩(liang)大數(shu)據(ju)庫(ku)充(chong)分發揮查詢性(xing)能(neng)，對于(yu) TimescaleDB，我(wo)們采用了(le)《TimescaleDB vs. InfluxDB》（見下(xia)方鏈接）中的(de)推薦配置，設置為 8 個 Chunk；對于(yu) InfluxDB，我(wo)們開啟(qi) InfluxDB 的(de) TSI (time series index)。在(zai)整(zheng)個查詢對比中，TDengine 數(shu)據(ju)庫(ku)的(de)虛擬節點(dian)數(shu)量（vnodes）保持為默認的(de) 6 個，其他的(de)數(shu)據(ju)庫(ku)參數(shu)配置為默認值。
TimescaleDB vs. InfluxDB: Purpose Built Differently for Time-Series Data：
4,000 devices × 10 metrics 查詢性能對比：最高達到 InfluxDB 的 34.2 倍
由于(yu)部分類型（分類標(biao)準參見上方《TimescaleDB vs. InfluxDB》 一文）單次(ci)查(cha)詢(xun)響應時間非常短，為(wei)(wei)了更加準確地測量(liang)每(mei)個查(cha)詢(xun)場景(jing)下較為(wei)(wei)穩定(ding)的(de)響應時間，我們將單個查(cha)詢(xun)運(yun)行次(ci)數(shu)提升(sheng)到 5000 次(ci)，然后使(shi)用 TSBS 自動統計(ji)并(bing)輸出(chu)結果，最后結果是 5000 次(ci)查(cha)詢(xun)的(de)算(suan)數(shu)平均值，使(shi)用并(bing)發客戶端(duan) Workers 數(shu)量(liang)為(wei)(wei) 8。下表是場景(jing)二 （4000設(she)備）的(de)查(cha)詢(xun)性(xing)能對比結果。
下面我們(men)對每個查詢結果做一定的(de)分析(xi)說明(ming)：
由(you)于(yu) Simple Rollups 的(de)(de)(de)整體查(cha)(cha)詢(xun)(xun)響應時間非常短，因(yin)此(ci)制約(yue)查(cha)(cha)詢(xun)(xun)響應時間的(de)(de)(de)主體因(yin)素并(bing)不是查(cha)(cha)詢(xun)(xun)所涉(she)及的(de)(de)(de)數(shu)(shu)據(ju)規模(mo)，即這一類(lei)型(xing)查(cha)(cha)詢(xun)(xun)的(de)(de)(de)瓶頸并(bing)非數(shu)(shu)據(ju)規模(mo)。但從結果上(shang)(shang)看，TDengine 仍(reng)然在(zai)所有類(lei)型(xing)的(de)(de)(de)查(cha)(cha)詢(xun)(xun)響應時間上(shang)(shang)優(you)于(yu) InfluxDB 和 TimescaleDB，具(ju)體的(de)(de)(de)數(shu)(shu)值對比(bi)請參見上(shang)(shang)表。
在 Aggregates 類型的查詢中，TDengine 的查詢性能相比于 TimescaleDB 和 InfluxDB 優勢更為明顯，其在 cpu-max-all-8 中的查詢性能是 InfluxDB 的 7 倍，是 TimescaleDB 的 6 倍。
從上表可見，在 Double-rollups 類型查詢中， TDengine 展現出了巨大的性能優勢。以查詢響應時間來度量，其在 double-groupby-5 和 double-groupby-all 的查詢性能均是 TimescaleDB 的 24 倍；在 double-groupby-5 查詢上是 InfluxDB 的 26 倍，double-groupby-all 上是其 34 倍。
如上面兩圖所示，threshold 類型的查詢中，high-cpu-1 中 TDengine 的查詢響應時間均顯著低于 TimescaleDB 和 InfluxDB。在 high-cpu-all 的查詢中，TDengine 的性能是 InfluxDB 的 15 倍，是 TimescaleDB 的 1.23 倍。
對于 Complex-queries 類型的查詢，TDengine 兩個查詢均大幅領先 TimescaleDB 和 InfluxDB——在 lastpoint 查詢中，其性能是 TimescaleDB 的 5 倍， InfluxDB 的 21 倍；在 groupby-orderby-limit 場景中其查詢性能是TimescaleDB的 8 倍，是 InfluxDB 的 15 倍。在時間(jian)窗口聚合的(de)查詢過程(cheng)中，TimescaleDB 針對規(gui)模較大的(de)數據集(ji)查詢性能不佳（double rollups 類型查詢），對于 groupby-orderby-limit 的(de)查詢，其(qi)性能上表現同樣不是(shi)太好。
資源開銷對比：整體 CPU 計算時間消耗是 InfluxDB 的 1/10
由于(yu)部分(fen)查(cha)(cha)詢(xun)持續時(shi)間特別短，因此(ci)并不能憑借以(yi)上信息完(wan)整(zheng)地看到查(cha)(cha)詢(xun)過程(cheng)中服(fu)(fu)務器(qi)的(de)(de) IO/CPU/網絡(luo)情況。為此(ci)，我們以(yi)場景二的(de)(de)數(shu)據為模擬數(shu)據，以(yi) Double rollups 類別中的(de)(de) double-groupby-5 查(cha)(cha)詢(xun)為例(li)，執(zhi)行(xing)(xing) 1000 次查(cha)(cha)詢(xun)，記錄整(zheng)個(ge)過程(cheng)中三個(ge)軟件系統在(zai)查(cha)(cha)詢(xun)執(zhi)行(xing)(xing)的(de)(de)整(zheng)個(ge)過程(cheng)中服(fu)(fu)務器(qi) CPU、內(nei)存(cun)、網絡(luo)的(de)(de)開銷(xiao)并進行(xing)(xing)對比(bi)。
服務器 CPU 開銷
從上圖可以看到，三個系統在整個查詢過程中 CPU 的使用均較為平穩。TDengine 在查詢過程中整體 CPU 占用約 80%, 在三個系統中使用的 CPU 資源最高；TimescaleDB 在查詢過程中瞬時 CPU 占用次之，約 38%；InfluxDB 的 CPU 占用的最小，約 27 %（但是有較多的瞬時沖高）。從整體 CPU 開銷上來看，雖然 InfluxDB 瞬時 CPU 開銷最低，但是其完成查詢持續時間也最長，所以整體 CPU 資源消耗最多。由于 TDengine 完成全部查詢的時間僅為 TimescaleDB 或 InfluxDB 的 1/20，因此雖然其 CPU 穩定值是 TimescaleDB 與 InfluxDB 的 2 倍多，但整體的 CPU 計算時間消耗卻只有其 1/10 。
服務器內存狀況
如(ru)上圖所(suo)示，在整個(ge)(ge)查詢(xun)過程(cheng)中，TDengine 內存(cun)維持了一個(ge)(ge)相對(dui)(dui)平穩的(de)狀(zhuang)態(tai)。TimescaleDB 在整個(ge)(ge)查詢(xun)過程(cheng)中內存(cun)呈現增(zeng)加的(de)狀(zhuang)態(tai)，查詢(xun)完成后即恢復到(dao)初(chu)始狀(zhuang)態(tai)，InfluxDB 內存(cun)占(zhan)用呈現相對(dui)(dui)穩定(ding)的(de)狀(zhuang)態(tai)。
服務器網絡帶寬
上圖展示了查詢過(guo)程(cheng)中服務器端上行(xing)和下行(xing)的網(wang)絡(luo)帶寬(kuan)情(qing)況，負(fu)載狀況基本(ben)上和 CPU 狀況相似。TDengine 網(wang)絡(luo)帶寬(kuan)開銷最(zui)高，因為(wei)在最(zui)短(duan)的時(shi)間內(nei)就(jiu)完(wan)成了全部查詢，需要(yao)將(jiang)查詢結果返回給客戶(hu)端。InfluxDB 網(wang)絡(luo)帶寬(kuan)開銷最(zui)低，TimescaleDB 介于兩者之(zhi)間。
100 devices × 10 metrics 查詢性能對比：最高達到 TimescaleDB 的 28.6 倍
對于場景一(100 devices x 10 metrics)來說(shuo)，TSBS 的(de) 15 個查詢對比結果(guo)如下：
如上表所示，在更小規模的數據集（100 設備）上的查詢對比可以看到，整體來說 TDengine 同樣展現出極好的性能，在全部查詢語句中均優于 TimescaleDB 和 InfluxDB，部分查詢性能超過 TimescaleDB 28 倍，超過 InfluxDB 37 倍。
寫在最后
基(ji)于(yu)上文(wen)可以做出總結，整體來(lai)講，在(zai)場(chang)景(jing)一（只包含 4 天的(de)數據(ju)）與(yu)場(chang)景(jing)二(er)的(de) 15 個不同(tong)類(lei)型的(de)查(cha)(cha)(cha)(cha)詢(xun)(xun)中(zhong)，TDengine 的(de)查(cha)(cha)(cha)(cha)詢(xun)(xun)平均響(xiang)應時間全面優于(yu) InfluxDB 和 TimescaleDB，在(zai)復雜(za)查(cha)(cha)(cha)(cha)詢(xun)(xun)上優勢(shi)更為明顯(xian)，同(tong)時具有最小的(de)計算(suan)資源開(kai)銷。相(xiang)(xiang)對(dui)(dui)于(yu) InfluxDB，場(chang)景(jing)一中(zhong) TDengine 查(cha)(cha)(cha)(cha)詢(xun)(xun)性(xing)能(neng)(neng)是(shi)(shi)(shi)其(qi)(qi) 1.9 ～ 37 倍，場(chang)景(jing)二(er)中(zhong) TDengine 查(cha)(cha)(cha)(cha)詢(xun)(xun)性(xing)能(neng)(neng)是(shi)(shi)(shi)其(qi)(qi) 1.8 ～ 34.2 倍；相(xiang)(xiang)對(dui)(dui)于(yu) TimeScaleDB，場(chang)景(jing)一中(zhong)TDengine 查(cha)(cha)(cha)(cha)詢(xun)(xun)性(xing)能(neng)(neng)是(shi)(shi)(shi)其(qi)(qi) 1.1 ～ 28.6 倍，場(chang)景(jing)二(er)中(zhong) TDengine 查(cha)(cha)(cha)(cha)詢(xun)(xun)性(xing)能(neng)(neng)是(shi)(shi)(shi)其(qi)(qi) 1.2 ～ 24.6 倍。
事實上，TDengine 高效的查詢性能此前在很多企業客戶的實踐中就已經展示出來了，以廣東省環境科學研究院生態環境數據治理服務項目為例，對于 76 億行的超級表，TDengine 運行分組 TOP 查詢僅用了 0.2 秒；基于 TDengine 返回 2,968 行，僅用了 0.06 秒；返回 5,280 行數據，僅用了 0.1 秒。如果你也面臨著數據處理難題或想要進行數據架構升級，歡迎添加小T vx：tdengine1，加(jia)入 TDengine 用戶(hu)交流群，和更(geng)多志同道合(he)的(de)開發者一起攻克(ke)難關。
