我們之前已經發布了?TDengine 和 InfluxDB 的寫入性能測試報告，今天我們再來對比一下兩款時序數據庫（Time-Series Database）產品(pin)的查(cha)詢性能。

1. 前言

本(ben)報告包含(han)了基礎測(ce)試部分(fen)內容，并根(gen)據(ju)具體的(de)場(chang)景，增加了部分(fen)擴展測(ce)試場(chang)景，以便更(geng)加全面(mian)、準確地呈(cheng)現(xian)兩(liang)款數據(ju)庫產品(pin)在不同應用場(chang)景下的(de)查詢性能(neng)表現(xian)。

1.1 硬件環境

為(wei)便于(yu)大家復現該測(ce)試(shi)(shi)，我們在(zai) Microsoft Azure 云(yun)服(fu)務(wu)(wu)上搭建了測(ce)試(shi)(shi)環境。測(ce)試(shi)(shi)中用到了兩臺(tai)服(fu)務(wu)(wu)器(qi)，分別部署(shu)客(ke)戶端和(he)服(fu)務(wu)(wu)器(qi)，客(ke)戶端與服(fu)務(wu)(wu)器(qi)通過云(yun)服(fu)務(wu)(wu)的(de)內網連接。

兩臺(tai)服務器的具體配置如(ru)下。

客戶端	8C，Intel(R) Xeon(R) Platinum 8272CL CPU @ 2.60GHz	16 GB	64 GB SSD， 無寫入情況下，4k 隨機讀取 IOPS 5000
服務端	16C， AMD EPYC 7452 32-Core Processor	128 GB	1 TB SSD，   無寫入情況下，4k 隨機讀取 IOPS 25000

操作系統均(jun)為 Ubuntu 20.10 Linux。使用的 Go 版本為 1.16。

1.2 軟件安裝

TDengine 2.1.7.2 社區版，可以在濤思官網下載。也可(ke)以通(tong)過 clone 上(shang)的代碼自(zi)行編(bian)譯(yi)生成。該版(ban)本的 git 的信(xin)息(xi)如下：

community version: 2.1.7.2 compatible_version: 2.0.0.0

gitinfo: c6be1bb809536182f7d4f27c0d8267b3b25c9354

InfluxDB 1.8.4（由于該性能測試框架(jia)最高只能適配到 1.8 版本(ben)(ben)，所以這里選取了 InfluxDB 1.8 版本(ben)(ben)進行對比），可以在 下載。

1.3 運行腳本生成查詢用數據

1.3.1 安裝準備

部署(shu)完 TDengine、InfluxDB 與 Go 語言環境，確保兩臺服(fu)務器的數據庫也連(lian)接正常使(shi)用正常（建(jian)庫刪(shan)庫寫入查詢功能(neng)均需測試(shi)，建(jian)庫之后立即刪(shan)除，如(ru)有問題(ti)立刻排查）

此外，在(zai)測試中應該注(zhu)意以下幾點（ TDengine 的(de)默(mo)認配置文件(jian)為 /etc/taos/taos.cfg ）：

1）fsync 的設置要保持同步，InfluxDB 默認是無延時的 fsync，需要修(xiu)改 TDengine 的這兩個參數：walLevel=2 ，fsync=0 才能達到相同的配置環境。后(hou)續的一切測(ce)試(shi)均是在這個設置條件(jian)下完成。

2）TDengine 的客戶(hu)端(duan)要把(ba) maxSQLLength 開到最大 1048576。

3）客(ke)(ke)戶端(duan)服務器要安(an)裝 TDengine 的客(ke)(ke)戶端(duan)。（注意：bulk_load_tdengine 編譯(yi)需要依賴 TDengine 客(ke)(ke)戶端(duan)）

1.3.2 從 GitHub 取下代碼,在客戶端服務器執行：

git clone //github.com/taosdata/timeseriesdatabase-comparisons

1.3.3 準備編譯環境，生成寫入程序，timeseriesdatabase-comparisons 的根目錄為工作目錄：

cd timeseriesdatabase-comparisons/build/tsdbcompare/
./compilation.sh

1.3.4 切換到build/tsdbcompare目錄下，產生測試數據集合并寫入數據庫。

在build/tsdbcompare下執行./writ_to_server.sh -a "test217"
 
# 本次測試的服務端 hostname 是"test217"，./writ_to_server.sh -h 可以查看對應參數: 

生成數據參數（總記錄數=（t-e)*24*3600/ i * s）
i : 數據間隔，默認10s
s : 樣本數量，默認100
t : 數據起始時間，默認'2018-01-01T00:00:00Z'
e : 數據終止時間，默認'2018-01-02T00:00:00Z'
g : 是否生成數據，默認1（1：生成數據，0：不生成數據）
T : TDengine的默認數據目錄路徑，默認為"/var/lib/taos"
I : InfluxDB默認數據目錄路徑，默認為"/var/lib/influxdb" 

寫入參數
b ： batchsize(默認5000）
w :  workers(默認16）
n :  TDengine寫入方式(false:cgo,true:rest,默認false)
a :  TDengine 和 InfluxDB 的 hostname 或者ip地址，默認為127.0.0.1 

如果希望自定義更多參數值，可以查看 write_to_server.sh 腳本代碼

1.3.5 生成查詢文件，并進行查詢測試，在build/tsdbcompare下運行腳本：

./read_all.sh -a "test217" 
腳本參數和 write_to_server.sh 一致。

2. 測試運行

運行(xing)該(gai)測試要求關閉 TDengine 系統日志(zhi)，然后自動執(zhi)行(xing)腳本即可。

在不同的(de)場景之間切換時(shi)，會重啟數據庫后臺服務（Influxd/taosd），并清除 Linux 系統的(de)全部緩存。

3. 對比測試結果

本小節說明運行測試腳本獲得(de)的對(dui)比測試結果，并(bing)對(dui)結果進行了初步(bu)的分析。

對于(yu)測(ce)試(shi)結(jie)果，所有的(de)響(xiang)應是(shi)測(ce)試(shi)腳本自動(dong)記錄的(de)時(shi)(shi)間(jian)，即(ji)該時(shi)(shi)間(jian)并不(bu)是(shi)單次(ci)查(cha)詢執行(xing)的(de)響(xiang)應時(shi)(shi)間(jian)，而是(shi)完成 1,000 次(ci)重復查(cha)詢最(zui)后獲(huo)得的(de)時(shi)(shi)間(jian)。需要(yao)說明(ming)的(de)是(shi)，由(you)于(yu)整個(ge)測(ce)試(shi)持續(xu)時(shi)(shi)間(jian)較長，測(ce)試(shi)獲(huo)得的(de)數據并非(fei)同(tong)一(yi)個(ge)時(shi)(shi)刻。不(bu)同(tong)的(de)時(shi)(shi)間(jian)，測(ce)試(shi)程序運行(xing)過程中會受到云(yun)服(fu)務器所能(neng)發揮的(de)最(zui)大性能(neng)影響(xiang)，獲(huo)得的(de)結(jie)果數據能(neng)看到有輕微(wei)的(de)抖動(dong)，但是(shi)整體趨(qu)勢是(shi)一(yi)致的(de)。

100 臺設備模擬生成的 1 天的數據集，在 TDengine 中生成了(le) 900 個子表，每個設備間隔 10 s 生成一(yi)條(tiao)數據，總記錄數是(shi) 7,776,000。

1,000 臺設(she)備在 TDengine 中生成了 9,000 個子表，每個設(she)備間隔 10 s 生成一條記(ji)錄，總記(ji)錄數(shu)是 77,760,000。

測試(shi)主要包(bao)括四個測試(shi)場景，分別是：

• 場景一：通過標簽過濾隨機篩選出 8 個時間線后，取其中的最大值。
• 場景二：隨機選取 1 h 時間區間，通過標簽隨機篩選出 8 個時間線，取其中的最大值。
• 場景三：隨機選取 12 h 的時間區間，通過標簽隨機篩選出 8 個時間線，使用 10 min 作為一個時間窗口，獲取每個時間窗口的最大值。
• 場景四：隨機選取 1 h 時間區間，通過標簽過濾隨機篩選出 8 個時間線，使用 1 min 為一個時間窗口，獲取每個時間窗口的最大值。

通(tong)過測(ce)試結果可以看出：整(zheng)體來看，TDengine 在(zai)多(duo)(duo)種場(chang)景下（單線程(cheng)(cheng)、多(duo)(duo)線程(cheng)(cheng)）的(de)(de)(de)性(xing)能(neng)均優(you)于 InfluxDB。在(zai)極少的(de)(de)(de)幾個(ge)情(qing)況(kuang)下，TDengine 與 InfluxDB 的(de)(de)(de)差異非(fei)常(chang)小。在(zai)更多(duo)(duo)的(de)(de)(de)場(chang)景下，TDengine 擁有數倍的(de)(de)(de)性(xing)能(neng)優(you)勢(shi)，部分場(chang)景的(de)(de)(de)性(xing)能(neng)優(you)勢(shi)能(neng)達到 40 倍。

3.1 100 臺設備數據集查詢結果對比

本(ben)部分呈現的(de)是，在 100 臺設(she)備上(shang)(shang)模擬(ni) 1 天的(de)數據生成的(de)結(jie)果集上(shang)(shang)，運行測試(shi)程序所獲得的(de)性能對比(bi)測試(shi)結(jie)果。

由圖  1  可以看到，在所有的場景中，只有第三個測試場景單線程的時候 TDengine 查詢響應時間超過 InfluxDB，其他的場景均優于 InfluxDB，并且部分場景（場景二）下其查詢性能有著 40 倍的巨大優勢。具體的測試響應數據見附錄表 1。

在 1,000 個設備上測試結果顯示出 TDengine 仍然展現出較大的性能優勢，即使部分相對于 InfluxDB 較慢的場景（多線程場景下的場景四），其差距也非常小。而領先的部分，則仍然有巨大的性能優勢，最高的性能差達到近 20 倍，具體的查詢響應數據見附錄表 2。

3.2 擴展測試

在上述的兩個標(biao)準測試(shi)之外，我們基于現有的數據集(ji)合設(she)計了一系列擴展測試(shi)，以期更全面準確地評估兩個數據庫產(chan)品在不(bu)同場景下(xia)(xia)的性能表現。在以下(xia)(xia)測試(shi)中，我們只使用(yong) cgo 的運行測試(shi)結果。

3.2.1 標簽篩選量對查詢性能的影響

調整過(guo)濾 host 的(de)(de)(de)數(shu)量，設(she)定并行執行的(de)(de)(de) work 為 16，使用 1,000 個設(she)備的(de)(de)(de)數(shu)據集合執行全部查(cha)(cha)詢(xun)，所獲(huo)得的(de)(de)(de)結果如下表所示。查(cha)(cha)詢(xun)響(xiang)應時間單位為秒，數(shu)值越小越好。

可以看到，隨著篩選的時間線的增加，InfluxDB 的查詢響應時間在四個測試場景均呈現快速增加的趨勢，而 TDengine 對于數據篩選規模的變大則呈現出相對穩定的查詢響應時間，并且隨著時間線篩選規模的擴大呈現出更大的優勢。 由此可以推斷，隨著查詢規模的繼續擴大，InfluxDB 的查詢響應時間還會繼續快速增加。各種場景下的查詢響應具體時間見表 3。

3.2.2 查詢時間窗口對查詢性能的影響

為了評估(gu)不同長(chang)度(du)的時(shi)間(jian)窗口對(dui)查(cha)(cha)詢(xun)性(xing)能的影響，我們(men)選取了第四個(ge)查(cha)(cha)詢(xun)場(chang)景(jing)，設(she)定并行執行的 work 數(shu)量 16， 時(shi)間(jian)區間(jian)是隨(sui)機選取的 1 h / 2 h / 4 h / 8 h / 12 h 等連續(xu)時(shi)間(jian)段，單個(ge)聚合時(shi)間(jian)窗口維持在 1 min 不變。獲(huo)得的查(cha)(cha)詢(xun)響應時(shi)間(jian)如圖 4 所(suo)示(shi)。

由上圖可見，TDengine 相對于 InfluxDB 有更好的查詢性能，并且，隨著查詢時間區間的增加，TDengine 的領先優勢持續擴大，當查詢時間區間是 1 小時的時候，TDengine 只比 InfluxDB 快約 8%。但是當查詢區間增加到 12 小時的時候，TDengine 的查詢優勢已經擴大到近 2 倍。具體查詢響應時間見表 4。

3.2.3 復雜查詢性能表現

考慮(lv)到標準(zhun)測(ce)試中(zhong)只使用了較為簡單的查(cha)(cha)詢(xun)函數，我們(men)使用多(duo)個(ge)查(cha)(cha)詢(xun)函數組合的復雜查(cha)(cha)詢(xun)，評估查(cha)(cha)詢(xun)性能。我們(men)選(xuan)取了第(di)四(si)個(ge)運行(xing)場景，隨(sui)機選(xuan)取 1 h 的時(shi)間(jian)段，聚合時(shi)間(jian)窗(chuang)口為 1 min，過濾篩選(xuan) 8 個(ge)時(shi)間(jian)線進行(xing)查(cha)(cha)詢(xun)處理。

三個場景分別是：

1. max(value), count(value),first(value),last(value)
2. top(value, 10)
3. max(value),count(value),first(value),last(value),integral(value1)*spread(ts)/1000  在該場景中，TDengine 中沒有 integral 函數，因此采用 TWA(value) * Spread(value) / 1000 的計算方式進行了等效替代。此外，integral 函數查詢的是另一個列 value1，而不是 value。

由上圖的結果可以看到，在三種復雜函數組合的查詢條件下，TDengine 查詢性能均優于 InfluxDB。特別是在第一種組合場景中，TDengine 的性能是 InfluxDB 的 2.5 倍。具體的查詢響應時間見表 5。

3.2.4 數據讀取測試

在這個場景測試中，我們測試了 TDengine 和(he) InfluxDB 的(de)數(shu)據(ju)讀取表現。針對(dui)全部數(shu)據(ju)集(ji)，不限定查詢時間范圍，調整標簽的(de)過(guo)濾條件，投影查詢來獲取全部的(de)數(shu)據(ju)內容。其(qi)結果如圖 6 所(suo)示。

可以看到，在提取不同比例的情況下，TDengine 的總的時間開銷穩定在 InfluxDB 的 11% 左右，即該項測試的性能，TDengine 是 InfluxDB 的 8.78 倍，并且該優勢隨著時間線數量的增加而得到擴大，在 128 個時間線的時候，達到了 9.37 倍。即在更大數據規模的情況下，TDengine 展現出了更好的性能優勢。在時間線為 256 的時候，InfluxDB 最終未能完成測試運行，服務端(duan)出(chu)現了連接(jie)拒絕的問題，而(er)TDengine也僅(jin)用(yong)時 365.61 s 就跑完(wan)該項(xiang)測試。

4. 總結

在基于(yu)該對比測試(shi)框架下運行的測試(shi)中，展示出(chu)了(le) TDengine Database 相對于(yu) InfluxDB 較(jiao)大的性(xing)能(neng)優勢，特別(bie)是(shi)更(geng)加(jia)多樣化的條(tiao)件和(he)變量控制情況下的擴展測試(shi)中，我們看到 TDengine 一致性(xing)地表現出(chu)相對于(yu) InfluxDB 的較(jiao)大性(xing)能(neng)優勢。

附錄

對比測試運行(xing)的具體數據匯(hui)總如下：

表1. 100臺設備數據集上的查詢結果對比

表2. 1000臺設備數據集上的查詢結果對比

表3. 調整篩選標簽數量

表4. 不同長度的時間范圍查詢響應（秒）

表5. 復雜查詢性能表現

表6. 不同規模數據讀取性能表現（秒）