我們之前已經發布了報告，今天我們再來對比一下兩款時序資料庫產品的查詢效能。

1. 前言

本報告包含了基礎測試部分內容，並根據具體的場景，增加了部分擴充套件測試場景，以便更加全面、準確地呈現兩款資料庫產品在不同應用場景下的查詢效能表現。

1.1 硬體環境

為便於大家復現該測試，我們在 Microsoft Azure 雲服務上搭建了測試環境。測試中用到了兩臺伺服器，分別部署客戶端和伺服器，客戶端與伺服器通過雲服務的內網連線。

兩臺伺服器的具體配置如下。

作業系統均為 Ubuntu 20.10 Linux。使用的 Go 版本為 1.16。

1.2 軟體安裝

TDengine 2.1.7.2 社群版，可以在下載。也可以通過 clone 上的程式碼自行編譯生成。該版本的 git 的資訊如下：

community version: 2.1.7.2 compatible_version: 2.0.0.0

gitinfo: c6be1bb809536182f7d4f27c0d8267b3b25c9354

InfluxDB 1.8.4（由於該效能測試框架最高只能適配到 1.8 版本，所以這裡選取了 InfluxDB 1.8 版本進行對比），可以在下載。

1.3 執行指令碼生成查詢用資料

1.3.1 安裝準備

部署完 TDengine、InfluxDB 與 Go 語言環境，確保兩臺伺服器的資料庫也連線正常使用正常（建庫刪庫寫入查詢功能均需測試，建庫之後立即刪除，如有問題立刻排查）

此外，在測試中應該注意以下幾點（ TDengine 的預設配置檔案為 /etc/taos/taos.cfg ）：

1）fsync 的設定要保持同步，InfluxDB 預設是無延時的 fsync，需要修改 TDengine 的這兩個引數：walLevel=2 ，fsync=0 才能達到相同的配置環境。後續的一切測試均是在這個設定條件下完成。

2）TDengine 的客戶端要把 maxSQLLength 開到最大 1048576。

3）客戶端伺服器要安裝 TDengine 的客戶端。（注意：bulk_load_tdengine 編譯需要依賴 TDengine 客戶端）

1.3.2 從 GitHub 取下程式碼,在客戶端伺服器執行：

git clone

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 : 資料間隔，預設10ss : 樣本數量，預設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. 測試執行

執行該測試要求關閉 TDengine 系統日誌，然後自動執行指令碼即可。

在不同的場景之間切換時，會重啟資料庫後臺服務（Influxd/taosd），並清除 Linux 系統的全部快取。

3. 對比測試結果

本小節說明執行測試指令碼獲得的對比測試結果，並對結果進行了初步的分析。

對於測試結果，所有的響應是測試指令碼自動記錄的時間，即該時間並不是單次查詢執行的響應時間，而是完成 1,000 次重複查詢最後獲得的時間。需要說明的是，由於整個測試持續時間較長，測試獲得的資料並非同一個時刻。不同的時間，測試程式執行過程中會受到雲伺服器所能發揮的最大效能影響，獲得的結果資料能看到有輕微的抖動，但是整體趨勢是一致的。

100 臺裝置模擬生成的 1 天的資料集，在 TDengine 中生成了 900 個子表，每個裝置間隔 10 s 生成一條資料，總記錄數是 7,776,000。

1,000 臺裝置在 TDengine 中生成了 9,000 個子表，每個裝置間隔 10 s 生成一條記錄，總記錄數是 77,760,000。

測試主要包括四個測試場景，分別是：

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

通過測試結果可以看出：整體來看，TDengine 在多種場景下（單執行緒、多執行緒）的效能均優於 InfluxDB。在極少的幾個情況下，TDengine 與 InfluxDB 的差異非常小。在更多的場景下，TDengine 擁有數倍的效能優勢，部分場景的效能優勢能達到 40 倍。

3.1 100 臺裝置資料集查詢結果對比

本部分呈現的是，在 100 臺裝置上模擬 1 天的資料生成的結果集上，執行測試程式所獲得的效能對比測試結果。

圖 1. 100 臺裝置資料集上的查詢結果對比

由圖 1 可以看到，在所有的場景中，只有第三個測試場景單執行緒的時候 TDengine 查詢響應時間超過 InfluxDB，其他的場景均優於 InfluxDB，並且部分場景（場景二）下其查詢效能有著 40 倍的巨大優勢。具體的測試響應資料見附錄表 1。

圖 2. 不同場景下調整查詢執行緒獲得最終響應時間

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

3.2 擴充套件測試

在上述的兩個標準測試之外，我們基於現有的資料集合設計了一系列擴充套件測試，以期更全面準確地評估兩個資料庫產品在不同場景下的效能表現。在以下測試中，我們只使用 cgo 的執行測試結果。

3.2.1 標籤篩選量對查詢效能的影響

調整過濾 host 的數量，設定並行執行的 work 為 16，使用 1,000 個裝置的資料集合執行全部查詢，所獲得的結果如下表所示。查詢響應時間單位為秒，數值越小越好。

圖 3. 不同場景下改變篩選時間線查詢響應時間

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

3.2.2 查詢時間視窗對查詢效能的影響

為了評估不同長度的時間視窗對查詢效能的影響，我們選取了第四個查詢場景，設定並行執行的 work 數量 16，時間區間是隨機選取的 1 h / 2 h / 4 h / 8 h / 12 h 等連續時間段，單個聚合時間視窗維持在 1 min 不變。獲得的查詢響應時間如圖 4 所示。

圖 4. 改變查詢時間區間範圍對查詢響應的影響

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

3.2.3 複雜查詢效能表現

考慮到標準測試中只使用了較為簡單的查詢函式，我們使用多個查詢函式組合的複雜查詢，評估查詢效能。我們選取了第四個執行場景，隨機選取 1 h 的時間段，聚合時間視窗為 1 min，過濾篩選 8 個時間線進行查詢處理。

三個場景分別是：

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

圖 5. 不同查詢場景下的響應時間對比

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

3.2.4 資料讀取測試

在這個場景測試中，我們測試了 TDengine 和 InfluxDB 的資料讀取表現。針對全部資料集，不限定查詢時間範圍，調整標籤的過濾條件，投影查詢來獲取全部的資料內容。其結果如圖 6 所示。

圖 6. 不同資料規模的投影查詢響應時間

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