一、測試背景

1.1 測試場景介紹

我們使用了 IoT 場景作為基礎數(shù)據(jù)集。TSBS 框架模擬虛擬貨運公司車隊的一組卡車的時序數(shù)據(jù)，針對每個卡車的診斷數(shù)據(jù)（diagnostics）記錄包含 3 個測量值和 1 個（納秒分辨率）時間戳，8 個標簽值；卡車的指標信息（readings）記錄包含 7 個測量值和 1 個（納秒分辨率）時間戳，8 個標簽值。數(shù)據(jù)模式（schema）見下圖 1。生成的數(shù)據(jù)每 10 秒一條記錄，IoT 場景引入了環(huán)境因素，所以每個卡車存在無序和缺失的時間序列數(shù)據(jù)。

在整個基準性能評估中，涉及以下五個場景，每個場景的具體數(shù)據(jù)規(guī)模和特點見下表，由于存在數(shù)據(jù)缺失，所以單個卡車數(shù)據(jù)記錄取記錄均值：

表 1. 場景數(shù)據(jù)集說明

	場景一 100 devices × 10 metrics	場景二 4,000 devices × 10 metrics	場景三 100,000 devices × 10 metrics	場景四 1,000,000 devices × 10 metrics	場景五 10,000,000 devices × 10 metrics
數(shù)據(jù)間隔	10 秒	10 秒	10 秒	10 秒	10 秒
持續(xù)時間	31 天	4 天	3 小時	3 分鐘	3 分鐘
卡車數(shù)目	100	4000	100,000	1,000,000	10,000,000
單個卡車記錄數(shù)	241,145	31,118	972	16	16
數(shù)據(jù)集記錄數(shù)	48,229,186	248,944,316	194,487,997	32,414,619	324,145,090

可以看到，五個場景的區(qū)別主要在于數(shù)據(jù)集所包含的單個卡車記錄數(shù)量，卡車總數(shù)的差異。數(shù)據(jù)時間間隔均維持在 10 秒。整體上看，五個場景的數(shù)據(jù)規(guī)模都不大，數(shù)據(jù)規(guī)模最大的是場景五，數(shù)據(jù)規(guī)模最小的場景四只有 32,414,619 條記錄。在場景四和場景五中，由于卡車數(shù)量相對較多，所以數(shù)據(jù)集僅覆蓋了 3 分鐘的時間跨度。

1.2 數(shù)據(jù)建模

在 TSBS 框架中， TimescaleDB 和 InfluxDB 會自動創(chuàng)建相應的數(shù)據(jù)模型并生成對應格式的數(shù)據(jù)。本文不再贅述其具體的數(shù)據(jù)建模方式，只介紹 TDengine 的數(shù)據(jù)建模的策略。

TDengine 一個重要的創(chuàng)新是其獨特的數(shù)據(jù)模型——為每個設備創(chuàng)建獨立的數(shù)據(jù)表（子表），并通過超級表（Super Table）在邏輯上和語義上對同一采集類型的設備進行統(tǒng)一管理。針對 IoT 場景的數(shù)據(jù)內容，我們?yōu)槊總€卡車創(chuàng)建了兩張表（后文中設備和卡車同義），用來存儲診斷信息和指標信息的時序數(shù)據(jù)。在 1.1 章節(jié)數(shù)據(jù)記錄中，我們看到 truck  name 可以作為每個卡車的標識 Id，因為有兩張超級表，因此我們在 TDengine 中使用  truck  name 拼接 d（r）作為子表的名稱。我們使用如下的語句創(chuàng)建名為 diagnostics 和 readings 的超級表，分別包含 3 、7 個測量值和 8 個標簽。

CREATE STABLE `readings` (`ts` TIMESTAMP, `latitude` DOUBLE, `longitude` DOUBLE, `elevation` DOUBLE, `velocity` DOUBLE, `heading` DOUBLE, `grade` DOUBLE, `fuel_consumption` DOUBLE) TAGS (`name` VARCHAR(30), `fleet` VARCHAR(30), `driver` VARCHAR(30), `model` VARCHAR(30), `device_version` VARCHAR(30), `load_capacity` DOUBLE, `fuel_capacity` DOUBLE, `nominal_fuel_consumption` DOUBLE)
 
CREATE STABLE `diagnostics` (`ts` TIMESTAMP, `fuel_state` DOUBLE, `current_load` DOUBLE, `status` BIGINT) TAGS (`name` VARCHAR(30), `fleet` VARCHAR(30), `driver` VARCHAR(30), `model` VARCHAR(30), `device_version` VARCHAR(30), `load_capacity` DOUBLE, `fuel_capacity` DOUBLE, `nominal_fuel_consumption` DOUBLE)

然后 ，我們使用如下語句創(chuàng)建名為 r_truck_1和 d_truck_1 的子表：

CREATE TABLE `r_truck_1` USING `readings` (`name`, `fleet`, `driver`, `model`, `device_version`, `load_capacity`, `fuel_capacity`, `nominal_fuel_consumption`) TAGS ("truck_1", "South", "Albert", "F-150", "v1.5", 2.000000e+03, 2.000000e+02, 1.500000e+01)
 
CREATE TABLE `d_truck_1` USING `diagnostics` (`name`, `fleet`, `driver`, `model`, `device_version`, `load_capacity`, `fuel_capacity`, `nominal_fuel_consumption`) TAGS ("truck_1", "South", "Albert", "F-150", "v1.5", 2.000000e+03, 2.000000e+02, 1.500000e+01)

上述語句創(chuàng)建了一個子表。由此可知，對于 100 個設備（CPU）的場景一，我們將會建立 100 個子表。對于 4000 個設備的場景二，系統(tǒng)中將會建立 4000 個子表用以存儲各自對應的數(shù)據(jù) 。在 TSBS 的框架生成的數(shù)據(jù)中，我們發(fā)現(xiàn)存在標簽信息 truck 為  null 的數(shù)據(jù)內容，對于這部分數(shù)據(jù)，我們建立了 d_truck_null(r_truck_null)的表，用以存儲所有未能標識 truck 的數(shù)據(jù)。

1.3 軟件版本和配置

本報告比較 TDengine, InfluxDB 與 TimeScaleDB 三種類型的時序數(shù)據(jù)庫，下面對使用的版本和配置做出說明。

1.3.1 TDengine

我們直接采用 TDengine 3.0 版，從 GitHub 克隆 TDengine 代碼編譯版本作為性能對比的版本。

gitinfo: 1bea5a53c27e18d19688f4d38596413272484900

在服務器上編譯安裝運行。

cmake .. -DDISABLE_ASSERT=true -DSIMD_SUPPORT=true -DCMAKE_BUILD_TYPE=Release  -DBUILD_TOOLS=false

在 TDengine 的配置文件中設置了六個涉及查詢的配置參數(shù)。

numOfVnodeFetchThreads   4

queryRspPolicy           1

compressMsgSize          128000

SIMD-builtins            1

tagFilterCache           1

numOfTaskQueueThreads    24

第一個參數(shù) numOfVnodeFetchThreads 設置 Vnode 的Fetch 線程數(shù)量為 4個， 第二個參數(shù) queryRspPolicy 打開  query response 快速返回機制， 第三個參數(shù) compressMsgSize 讓TDengine 在傳輸層上大于 128000 bytes的消息自動進行壓縮，第四個參數(shù)是如果 CPU支持，啟用內置的 FMA/AVX/AVX2 硬件加速。第五個參數(shù)開啟tag 列的過濾緩存。第六個參數(shù)是設置任務隊列的線程數(shù)量為 24。

對于 IoT 場景，表數(shù)目是卡車規(guī)模數(shù)的二倍，所以 TDengine 建庫默認創(chuàng)建 12 個 vnodes，即創(chuàng)建的表會按照表名隨機分配到 12 個 虛擬節(jié)點（virtual node, VNode) 中。打開 LRU 緩存，設置為 last_row 緩存模式。對于場景一和場景二，stt_trigger 設置為 1，此時 TDengine 會準備一個 Sorted Time-series Table (STT) 文件，用于容納單表寫入量小于 minimum rows 的時候，數(shù)據(jù)直接保存在 STT 文件中，當 STT 文件中無法容納新數(shù)據(jù)的時候，會將 STT 中的數(shù)據(jù)整理，再寫入到數(shù)據(jù)文件中。對于場景三配置 stt_trigger 為 8，場景四和五，stt_trigger 設置為 16 ，即允許最多生成 16 個 STT 文件。針對低頻表多的場景，需要適度增加 STT 的值，以此來獲得更好的寫入性能。

1.3.2 TimescaleDB 

為確保結果具有可比性，我們選用 TimescaleDB 版本 version 2.10.1。為獲得較好的性能，TimescaleDB 需要針對不同的場景設置不同的 Chunk 參數(shù)，不同場景下參數(shù)的設置如下表所示。

表 2. 不同場景下 TimescaleDB 的 chunk 配置

	場景一	場景二	場景三	場景四	場景五
設備數(shù)目	100	4000	100,000	1,000,000	10,000,000
Chunk 數(shù)目	12	12	12	12	12
Chunk 持續(xù)時間	2.58 天	8 小時	15 分	15 秒	15 秒
Chunk 內記錄數(shù)	2,009,550	10,372,680	8,103,667	1,350,610	13,506,045

上述參數(shù)的設置，充分參考了對比報告[7]中推薦的配置參數(shù)設置，以確保能夠最大化寫入性能指標。

1.3.3 InfluxDB

我們選擇 InfluxDB version 1.8.10。這里沒有使用 InfluxDB 最新的 2.x 版本是因為 TSBS 沒有對其進行適配，所以選用了能夠運行 TSBS 框架的 InfluxDB 最新版本。

我們采用對比報告[7]中推薦的方式配置 InfluxDB，將緩沖區(qū)配置為 80G，以便 1000w 設備寫入時能夠順利進行，同時開啟 Time Series Index（TSI）。

配置系統(tǒng)在系統(tǒng)插入數(shù)據(jù)完成 30s 后開始數(shù)據(jù)壓縮。

cache-max-memory-size = "80g"
max-values-per-tag = 0
index-version = "tsi1"
compact-full-write-cold-duration = "30s"

二、測試步驟

2.1 硬件準備

為與對比報告[7]的環(huán)境高度接近，我們使用亞馬遜 AWS 的 EC2 提供的 r4.8xlarge 類型實例作為基礎運行平臺，包括 1 臺服務器、1 臺客戶端共兩個節(jié)點構成的環(huán)境?？蛻舳伺c服務器硬件配置完全相同，客戶端與服務器使用 10 Gbps 網絡連接。配置簡表如下：

表 3. 物理節(jié)點配置

	CPU	Memory	Disk
服務器	Intel(R) Xeon(R) CPU E5-2686 v4 @ 2.30GHz 32vCPU	244GiB	800G SSD，3000 IOPS. 吞吐量上限是 125 MiB/Sec
客戶端	Intel(R) Xeon(R) CPU E5-2686 v4 @ 2.30GHz 32vCPU	244GiB	800G SSD，3000 IOPS. 吞吐量上限是 125 MiB/Sec

2.2 服務器環(huán)境準備

為運行測試腳本，服務器 OS 需要是 ubuntu20.04 以上的系統(tǒng)。AWS EC2 的服務器系統(tǒng)信息如下：

1. OS： Linux tv5931 5.15.0-1028-aws #32~20.04.1-Ubuntu SMP Mon Jan 9 18:02:08 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
2. Gcc：gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04)
3. 基礎環(huán)境，版本信息為：Go1.16.9 , python3.8 , pip20.0.2 (無需手動安裝，測試腳本將自動安裝） 
4. 編譯依賴：gcc , cmake, build-essential, git, libssl-dev (無需手動安裝，測試腳本將自動安裝）

但請做兩個配置：

1. client 和 server 配置 ssh 訪問免密，以便腳本可不暴露密碼，可參考文檔：免密配置。
2. 保證 client 和 server 之間所有端口開放。

2.3 獲取測試腳本

為便于重復測試，隱藏繁瑣的下載、安裝、配置、啟動、匯總結果等細節(jié)，整個 TSBS 的測試過程被封裝成一個測試腳本。重復本測試報告，需要先下載該測試腳本，腳本暫支持 ubuntu20.04 的系統(tǒng)。以下操作要求具有 root 權限。

在客戶端機器，進入測試目錄拉取代碼，默認進入 /usr/local/src/ 目錄，

cd /usr/local/src/ && apt install git && git clone https://github.com/taosdata/tsbs.git && cd tsbs/scripts/tsdbComp

修改配置文件 test.ini 中服務端和客戶端的 IP 地址（這里配置 AWS 的私網地址即可）和 hostname，如果服務器未配置免密，還需要配置服務器端的 root 密碼，本次測試 IoT 場景，故修改 caseType 為 iot。

clientIP="192.168.0.203"   #client ip
clientHost="trd03"         #client hostname
serverIP="192.168.0.204"   #server ip
serverHost="trd04"         #server hostname
serverPass="taosdata123"   #server root password
caseType="iot"             #testcase

2.4 一鍵執(zhí)行對比測試

執(zhí)行以下命令：

nohup bash tsdbComparison.sh > test.log &

測試腳本將自動安裝 TDengine, InfluxDB, TimeScaleDB 等軟件，并自動運行各種對比測試項。在目前的硬件配置下，整個測試跑完需要大約三天的時間。測試結束后，將自動生成 CSV 格式的對比測試報告，并存放在客戶端的 /data2 目錄，對應 load 和 query 前綴的文件夾下。

三、寫入性能對比

3.1 不同場景下寫入性能對比

可以看到在全部五個場景中，TDengine 的寫入性能全面超越 TimescaleDB 和 InfluxDB。在場景二中 TDengine 寫入性能是 TimescaleDB 的最大達到 3.3倍，在差距最小場景五中，是 TimescaleDB 寫入性能的 1.04 倍。相對于 InfluxDB，TDengine在場景五中寫入性能是 InfluxDB 的 16 倍，在差距最小的場景三中也有 1.8 倍。

我們還注意到，隨著設備數(shù)規(guī)模的增加，所有系統(tǒng)寫入基本上呈現(xiàn)下降趨勢。TimescaleDB 在小規(guī)模數(shù)據(jù)情況下寫入性能不及 InfluxDB，但是隨著設備數(shù)量的增加，其寫入性能超過了 InfluxDB，這點上與對比報告[7]中的結論一致。

表 4. TDengine 相對于 InfluxDB 與TimescaleDB 寫入性能

	TDengine/InfluxDB	TDengine/TimescaleDB
100 devices × 10 metrics	196.42%	332.21%
4,000 devices × 10 metrics	327.26%	320.90%
100,000 devices × 10 metrics	182.91%	245.73%
1,000,000 devices × 10 metrics	272.08%	125.85%
10,000,000 devices × 10 metrics	1620.21%	104.40%

3.2 寫入過程資源消耗對比

數(shù)據(jù)寫入速度并不能夠全面的反映三個系統(tǒng)在不同場景下數(shù)據(jù)寫入的整體表現(xiàn)。為此我們以 1,000,000 devices × 10  metrics （場景 四）為例，檢查數(shù)據(jù)寫入過程中的服務器和客戶端（包括客戶端與服務器）的整體負載狀況，并以此來對比三個系統(tǒng)在寫入過程中服務器/客戶端節(jié)點的資源占用情況，這里的資源占用主要包括服務器端的 CPU 開銷/磁盤 IO 開銷和客戶端 CPU 開銷。

3.2.1 服務端 CPU 開銷

圖四展示了在場景四寫入過程之中服務器端 CPU 負載狀況?？梢钥吹?，三個系統(tǒng)在返回給客戶端寫入完成消息以后，都還繼續(xù)使用服務器的資源 進行相應的處理工作，這點上，TimescaleDB 尤為明顯，TimescaleDB 在 7X 秒的時候即反饋客戶端寫入完成，但是其服務器端仍然調用 CPU 資源進行了數(shù)據(jù)壓縮和整理工作，當然整個工作帶來的 CPU 負載相對而言并不高，只有其峰值 CPU 開銷的一半左右，但是其持續(xù)時間相當長，接近其凈寫入時間的 4 倍。InfluxDB 則使用相當多的 CPU 資源，瞬時峰值使用了全部的 CPU 資源，其寫入負載較高，并且其持續(xù)時間比 TimescaleDB 更長，當然遠長于 TDengine。三個系統(tǒng)對比，TDengine 對服務器的 CPU 需求最小，峰值也僅使用了 17% 左右的服務器 CPU 資源。由此可見，TDengine 獨特的數(shù)據(jù)模型對于時序數(shù)據(jù)寫入不僅在性能上，在整體的資源開銷上也具有非常大的優(yōu)勢。

3.2.2 磁盤 I/O 對比

圖 4 展示了 1,000,000 devices × 10  metrics （場景四）數(shù)據(jù)寫入過程中服務器端磁盤寫入狀態(tài)。可以看到，結合著服務器端 CPU 開銷表現(xiàn)，其 IO 動作與 CPU 呈現(xiàn)同步的活躍狀態(tài)。

寫入相同規(guī)模的數(shù)據(jù)集，TDengine 在寫入過程中對于磁盤寫入能力的占用遠小于 TimescaleDB 和 InfluxDB，寫入過程只占用了部分磁盤寫入能力（125MiB/Sec. 3000IOPS）。從圖上能看到，數(shù)據(jù)寫入過程中磁盤的 IO 瓶頸是確實存在的。InfluxDB 長時間消耗完全部的磁盤寫入能力，TimescaleDB 寫入過程對于寫入的消耗相對 InfluxDB來說要更具優(yōu)勢，但是仍然遠超過了 TDengine 對磁盤寫入能力的需求。

3.2.3 客戶端 CPU 開銷

從圖 5 可以看到，客戶端上 TDengine 對 CPU 的需求大于 TimescaleDB 和 InfluxDB， 而 InfluxDB 在整個寫入過程中，客戶端負載整體上來說，三個系統(tǒng)中計算資源占用最低，對客戶端壓力最小，其寫入的壓力基本上完全集中在服務端。這種模式很容易導致服務端成為瓶頸，TimescaleDB 相對于 InfluxDB 而言，對于客戶端壓力更大，CPU 峰值達到 20% 左右。TDengine 在客戶端的開銷最大，峰值瞬間達到了 70%，然后快速回落。TDengine 在客戶端的開銷相比于 TimescaleDB 多了 1 倍。綜合服務器與客戶端的資源開銷來看，TDengine 寫入持續(xù)時間更短，在系統(tǒng)整體 CPU 開銷上TDengine 仍然具有優(yōu)勢。

3.3 寫入性能對比總結

在全部的場景中，TDengine 的寫入性能超過 TimescaleDB 和 InfluxDB。在整個寫入過程中，TDengine 除了在提供了更高的寫入能力的前提下，在服務器的 CPU 和 IO 上，也均遠優(yōu)于 TimescaleDB 和 InfluxDB。對于服務器的磁盤 IO 開銷遠小于 TimescaleDB 和 InfluxDB。即使加上客戶端的開銷統(tǒng)計，TDengine 在寫入開銷上遠優(yōu)于 TimescaleDB 和 InfluxDB。

3.4 磁盤空間占用

三個系統(tǒng)數(shù)據(jù)完全落盤以后，比較了三個系統(tǒng)在不同場景下的磁盤空間占用比較。

從圖 6 可以看到，TimescaleDB  在所有的場景下數(shù)據(jù)規(guī)模均顯著地大于 InfluxDB 和 TDengine，并且這種差距隨著數(shù)據(jù)規(guī)模增加快速變大。TimescaleDB 在場景四和場景五中占用磁盤空間超過了 TDengine 的 11 倍。在前面三個場景中，InfluxDB 落盤后數(shù)據(jù)文件規(guī)模與 TDengine 比較接近。但是在場景四/五兩個場景中，InfluxDB 落盤后文件占用的磁盤空間是 TDengine 的 2 倍以上。

這里還有個小插曲，表 5 反應了 TimescaleDB 的壓縮比率，TimescaleDB 在小數(shù)劇規(guī)模的情況下，壓縮比正常。但是在大數(shù)據(jù)規(guī)模場景四和場景五中，壓縮以后的磁盤空間占用比例反而增大了 3.4 倍左右，疑似 bug。

表 5. TimescaleDB 寫入后壓縮磁盤空間占用比例

壓縮后磁盤空間占用（KB）	壓縮前磁盤空間占用（KB）	壓縮比率
998312	6907312	14%
4246528	36490408	12%
6035528	26290904	23%
16612380	4841552	343%
165769964	48305396	343%

3.5 性能基準評估擴展部分

為了更全面地評估 TDengine 在默認參數(shù)下寫入性能，我們在下面的性能評估中調整可能會影響寫入性能的兩個參數(shù)，進行評估測試。

3.5.1 虛擬節(jié)點（vnodes）數(shù)量

我們調整數(shù)據(jù)庫中虛擬節(jié)點數(shù)量（默認是 12）為 12，18， 24，并衡量不同 vnode 數(shù)量情況下 TDengine 寫入性能。

表 6. 不同虛擬節(jié)點數(shù)據(jù)量情況寫入性能變化

	scale=1,000,000 場景四		scale=10,000,000 場景五
vnodes=12	1,867,506.54	100%	1,404,185.26	100%
vnodes=18	2,052,924.52	109.9%	1,556,203.18	103.6%
vnodes=24	2,100,190.87	112.4%	1,612,303.67	114.8%

我們看到，在較多的設備的場景（場景四、五）中，增加 vnodes 的數(shù)量 ，TDengine 寫入性能提升明顯?？梢娫诓煌?guī)模的場景中，可以通過調整虛擬節(jié)點的數(shù)量來獲得更好的寫入性能。

3.5.2 設備記錄數(shù)量

TDengine 為一個設備一張表的數(shù)據(jù)模型，需要在數(shù)據(jù)寫入時創(chuàng)建表，建表操作對每個設備只執(zhí)行一次，但這使得 TDengine 在數(shù)據(jù)寫入的準備階段時間耗時較多。當單個表中數(shù)據(jù)量增加以后 ，數(shù)據(jù)準備（建表）的開銷被分攤到更多的數(shù)據(jù)寫入的整體開銷中，以場景四（1,000,000 devices × 10  metrics）為例，單個設備的數(shù)據(jù)量僅有 18 條。當我們調整參數(shù)，將單個設備記錄數(shù)據(jù)增加到 36、72、144 條時，整體寫入時間更長，因此表現(xiàn)出來就是建表開銷被分攤到更多的數(shù)據(jù)寫入過程中，建表的開銷相對于數(shù)據(jù)寫入的耗時占比越來越小，相應的整體寫入速度也越來越快。因此可以看到，TDengine 表現(xiàn)出了更加明顯的寫入優(yōu)勢。（這里每張表的記錄數(shù)忽略了 IoT 場景中丟失的記錄。所以單個設備記錄數(shù)據(jù)這個值并非百分百準確）

我們調整 vnodes 數(shù)量配置，同時測試兩個不同 vnodes 數(shù)量情況下的寫入性能指標。如圖 7 所示，隨著表中記錄數(shù)的增加，vgroups=12 和 vgroups=24，TDengine 寫入性能均呈現(xiàn)出持續(xù)增加的趨勢。當設備記錄數(shù)達到 576 行（此時數(shù)據(jù)集規(guī)模約等于 32,414,619 x 32  = 10.37 億行數(shù)據(jù)記錄）的時候，vgroups=12 時，寫入性能達到 2,827,696.64 metrics/sec，性能均大幅領先 TimescaleDB 與 InfluxDB，是 TimescaleDB 的6.1 倍， InfluxDB 的 4.6 倍。

TimescaleDB 寫入性能在單表記錄數(shù)量大于 72 行以后出現(xiàn)了快速衰減。InfluxDB 在單設備記錄增加過程中，寫入性能有衰減，但衰減趨勢非常緩慢。

3.5.3 總結

通過調整不同的數(shù)據(jù)庫參數(shù)(vgroups)，以及設置不同的數(shù)據(jù)規(guī)模（增加每個設備包含記錄數(shù)）方式，我們在更多的方面評估了 TDengine 在 TSBS 基準數(shù)據(jù)集上的寫入性能。通過這一系列深入的對比可以看到，針對更大規(guī)模（設備數(shù)量和每個設備記錄數(shù)量）數(shù)據(jù)集，TDengine 可以通過簡單調整虛擬節(jié)點數(shù)量的方式，獲得更高的寫入性能，并且 TDengine 在針對大數(shù)據(jù)集寫入場景下展現(xiàn)出更好的性能優(yōu)勢，同時具有遠低于 TimescaleDB 和 InfluxDB 對服務端資源（服務器 CPU 和 磁盤 IO、內存等）的開銷。

四、查詢性能對比

在查詢性能評估部分，我們使用場景一（只包含4天數(shù)據(jù)，這個修改與[7]中要求一致）和場景二作為基準數(shù)據(jù)集，具體基礎數(shù)據(jù)集的特點，請參加本文前面1.2章節(jié)。在查詢性能評估之前，對于 TimescaleDB, 我們采用[7]中推薦配置，設置為 8 個 Chunk ，以確保其充分發(fā)揮查詢性能。對于 lInfluxDB，我們開啟 InfluxDB  的 TSI (time series index)。在整個查詢對比中，TDengine 數(shù)據(jù)庫的虛擬節(jié)點數(shù)量（vnodes）保持為默認的 6 個（scale=100 時配置 1 個），其他的數(shù)據(jù)庫參數(shù)配置為默認值。

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

由于大部分類型單次查詢響應時間過長，為了更加準確地測量每個查詢場景的較為穩(wěn)定的響應時間，我們依據(jù)卡車數(shù)量規(guī)模，將單個查詢運行次數(shù)分別提升到 2,000 次（場景一）和 500 次（場景二），然后使用  TSBS 自動統(tǒng)計并輸出結果，最后結果是多次查詢的算數(shù)平均值，使用并發(fā)客戶端 Workers 數(shù)量為 4。首先我們提供 場景二 （4,000 設備）的查詢性能對比結果。

表7. 4,000 devices × 10 metrics（場景二）查詢性能對比表（單位：ms）

查詢類型	TDengine	InfluxDB	InfluxDB/TDengine	TimescaleDB	TimescaleDB/TDengine
last-loc	11.52	562.86	4885.94%	11.77	102.17%
low-fuel	30.72	635	2067.06%	416.75	1356.61%
high-load	10.74	861.13	8017.97%	11.62	108.19%
stationary-trucks	23.9	3156.65	13207.74%	195.46	817.82%
long-driving-sessions	59.44	374.98	630.85%	2938.54	4943.71%
long-daily-sessions	218.97	1439.19	657.25%	19080.95	8713.96%
avg-vs-projected-fuel-consumption	3111.18	40842.05	1312.75%	37127.24	1193.35%
avg-daily-driving-duration	4402.15	43588.02	990.15%	73781.97	1676.04%
avg-daily-driving-session	4034.09	84494.79	2094.52%	80765.04	2002.06%
avg-load	1295.97	552493.78	42631.68%	30452.26	2349.77%
daily-activity	2314.64	15248.66	658.79%	79242.14	3423.52%
breakdown-frequency	5416.3	288804.93	5332.14%	70205.29	1296.19%

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

對于分組選擇的查詢中，TDengine 采用一張表一個設備（卡車）的設計方式，并采用緩存模式的 last_row 函數(shù)來查詢最新的數(shù)據(jù)，使得TDengine 的查詢響應時間上均優(yōu)于 InfluxDB 和 TimescaleDB。

在復雜分組聚合的查詢中，我們看到 TDengine 查詢性能相比于 TimescaleDB 和 InfluxDB 有非常大的優(yōu)勢；而在時間窗口聚合的查詢過程中，TimescaleDB 針對規(guī)模較大的數(shù)據(jù)集其查詢性能不佳，long-driving-sessions 和 long-daily-sessions 均表現(xiàn)很差。TDengine 在 stationary-trucks 查詢性能是 InfluxDB 的 132倍，是 TimescaleDB 的 8 倍。在 long-daily-sessions 中是TimescaleDB 的 87 倍，是 InfluxDB 的 6.5 倍。

在復雜的混合查詢中， TDengine 展現(xiàn)出巨大的性能優(yōu)勢，其查詢響應時間來度量，其中 avg-load 和 breakdown-frequency 的查詢性能是 InfluxDB 的 426 倍和 53 倍 ；對比 TimescaleDB，在 daily-activity 查詢中，TDengine 是其 34 倍，在 avg-load 查詢中，TDengine 是其 23 倍。

4.2 資源開銷對比

由于部分查詢持續(xù)時間特別短，并不能完整地看到查詢過程中服務器的 IO/CPU/網絡情況。我們針對場景二，以 daily-activity 查詢?yōu)槔?，?zhí)行 50 次查詢，記錄整個過程中三個軟件系統(tǒng)在查詢執(zhí)行的整個過程中服務器 CPU、內存、網絡的開銷進行對比。

服務器 CPU 開銷

如圖 9 可以看到，三個系統(tǒng)在整個查詢過程中 CPU 的使用均較為平穩(wěn)。TDengine 在查詢過程中整體 CPU 占用約 70%，  TimescaleDB 在查詢過程中瞬時 CPU  最低，約 22%。InfluxDB 的穩(wěn)定的 CPU  占用的最大，約 98 %（有較多的瞬時100%）。整體 CPU 開銷上來看，雖然 TimescaleDB 瞬時 CPU 開銷最低，但是其完成查詢持續(xù)時間最長，所以整體 CPU 資源消耗最多。InfluxDB 基本頂格100%使用全部 cpu，持續(xù)時間是TDengine的三倍，開銷次之。 TDengine 完成全部查詢的時間僅是  TimescaleDB 的  1/30，整體 CPU 開銷最低。

服務器內存狀況

如圖 10 所示，在整個查詢過程中，TDengine 內存維持了一個相對平穩(wěn)的狀態(tài)，平均使用約為 12G。TimescaleDB 和InfluxDB 內存占用在整個查詢過程中保持平穩(wěn)，平均約為 10G；其中 TimescaleDB 對 buffer 和 cache 使用比較多。

服務器網絡帶寬

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

4.3 100 devices × 10 metrics 查詢性能對比

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

表 9. InfluxDB 與 Timescale 相對于 TDengine 查詢響應時間比率 (單位：ms)

查詢類型	TDengine	InfluxDB	InfluxDB/TDengine	TimescaleDB	TimescaleDB/TDengine
last-loc	1.03	14.94	1450.49%	1.35	131.07%
low-fuel	4.61	17.45	378.52%	6.74	146.20%
high-load	1.03	18.33	1779.61%	1.31	127.18%
stationary-trucks	3.59	69.1	1924.79%	4.02	111.98%
long-driving-sessions	5.4	13	240.74%	61.87	1145.74%
long-daily-sessions	13.88	42.91	309.15%	228.38	1645.39%
avg-vs-projected-fuel-consumption	267.03	1033.72	387.12%	830.79	311.12%
avg-daily-driving-duration	278.62	942.47	338.26%	1049.07	376.52%
avg-daily-driving-session	166.49	1707.27	1025.45%	1066.69	640.69%
avg-load	102.31	15956.73	15596.45%	487.39	476.39%
daily-activity	146.5	510.3	348.33%	1245.05	849.86%
breakdown-frequency	413.82	6953.83	1680.40%	955.2	230.82%

如表 9 所示，在更小規(guī)模的數(shù)據(jù)集（場景一）上的查詢對比可以看到，整體上 TDengine 同樣展現(xiàn)出極好的性能，在全部的查詢語句中全面優(yōu)于 TimescaleDB  和 InfluxDB，部分查詢性能超過 TimescaleDB 16 倍，超過 InfluxDB 155 倍。

五、總結

本次基于 TSBS 性能基準框架的對比測評，拓展了 IoT 場景。得益于 TDengine 契合時序數(shù)據(jù)特點的架構設計，TDengine 相對于 TimescaleDB 和 InfluxDB，不論是數(shù)據(jù)寫入的性能，寫入過程中對于資源的消耗，查詢的響應延遲還是查詢過程中資源的開銷，均全面優(yōu)于 TimescaleDB 和 InfluxDB。加之上次的 CPU 場景[10]，在流行的工業(yè)物聯(lián)網領域，TDengine 依然能作為企業(yè)的銀彈 ，來發(fā)揮時序數(shù)據(jù)庫的最大潛能。

六、參考文獻

[1] Timescale. https://www.timescale.com/

[2] High-cardinality TSDB benchmarks: VictoriaMetrics vs TimescaleDB vs InfluxDB. https://valyala.medium.com/high-cardinality-tsdb-benchmarks-victoriametrics-vs-timescaledb-vs-influxdb-13e6ee64dd6b

[3] ClickHouse Crushing Time Series. https://altinity.com/blog/clickhouse-for-time-series

[4] ClickHouse Continues to Crush Time Series. https://altinity.com/blog/clickhouse-continues-to-crush-time-series

[5] Benchmarking Time Series workloads on Apache Kudu using TSBS.https://blog.cloudera.com/benchmarking-time-series-workloads-on-apache-kudu-using-tsbs/

[6] RedisTimeSeries Version 1.2 Benchmarks. https://redis.com/blog/redistimeseries-version-1-2-benchmarks/

[7] TimescaleDB vs. InfluxDB: Purpose Built Differently for Time-Series Data. https://www.timescale.com/blog/timescaledb-vs-influxdb-for-time-series-data-timescale-influx-sql-nosql-36489299877/

[8] QuestDB vs. TimescaleDB. https://towardsdatascience.com/questdb-vs-timescaledb-38160a361c0e

[9] Time Series Benchmark Suite. https://github.com/timescale/tsbs

[10] Performance Comparison: InfluxDB and TimescaleDB vs. TDengine. https://tdengine.com/performance-comparison-influxdb-and-timescaledb-vs-tdengine/