一、測試背景

1.1 測試場景介紹

我們使用了(le)(le) IoT 場(chang)景作(zuo)為基礎數據集。TSBS 框(kuang)架模擬虛(xu)擬貨運公(gong)司車(che)(che)(che)隊的(de)(de)一(yi)組卡車(che)(che)(che)的(de)(de)時(shi)(shi)序數據，針對(dui)每(mei)個(ge)卡車(che)(che)(che)的(de)(de)診斷(duan)數據（diagnostics）記(ji)錄包含 3 個(ge)測量(liang)(liang)值和 1 個(ge)（納秒分辨率(lv)）時(shi)(shi)間(jian)戳，8 個(ge)標(biao)簽(qian)值；卡車(che)(che)(che)的(de)(de)指標(biao)信息（readings）記(ji)錄包含 7 個(ge)測量(liang)(liang)值和 1 個(ge)（納秒分辨率(lv)）時(shi)(shi)間(jian)戳，8 個(ge)標(biao)簽(qian)值。數據模式（schema）見下圖 1。生成的(de)(de)數據每(mei) 10 秒一(yi)條(tiao)記(ji)錄，IoT 場(chang)景引入了(le)(le)環境(jing)因素，所(suo)以每(mei)個(ge)卡車(che)(che)(che)存在無序和缺(que)失的(de)(de)時(shi)(shi)間(jian)序列數據。

在整個(ge)基準(zhun)性能評估中，涉及(ji)以(yi)(yi)下五個(ge)場(chang)景，每個(ge)場(chang)景的具體數據規模和特點見下表，由于存在數據缺(que)失(shi)，所以(yi)(yi)單個(ge)卡車數據記錄(lu)取記錄(lu)均值：

表 1. 場景數據集說明

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

可以(yi)看到(dao)，五(wu)個(ge)場(chang)(chang)(chang)景的(de)區別主要在(zai)于(yu)數(shu)(shu)(shu)據(ju)(ju)集所包含的(de)單個(ge)卡(ka)(ka)車(che)記(ji)錄數(shu)(shu)(shu)量，卡(ka)(ka)車(che)總數(shu)(shu)(shu)的(de)差異(yi)。數(shu)(shu)(shu)據(ju)(ju)時間間隔均維(wei)持在(zai) 10 秒。整(zheng)體上看，五(wu)個(ge)場(chang)(chang)(chang)景的(de)數(shu)(shu)(shu)據(ju)(ju)規模都不大，數(shu)(shu)(shu)據(ju)(ju)規模最大的(de)是場(chang)(chang)(chang)景五(wu)，數(shu)(shu)(shu)據(ju)(ju)規模最小的(de)場(chang)(chang)(chang)景四(si)只有 32,414,619 條記(ji)錄。在(zai)場(chang)(chang)(chang)景四(si)和(he)場(chang)(chang)(chang)景五(wu)中(zhong)，由(you)于(yu)卡(ka)(ka)車(che)數(shu)(shu)(shu)量相對較多，所以(yi)數(shu)(shu)(shu)據(ju)(ju)集僅覆(fu)蓋了(le) 3 分鐘的(de)時間跨度(du)。

1.2 數據建模

在 TSBS 框架(jia)中， TimescaleDB 和(he) InfluxDB 會(hui)自(zi)動創建(jian)(jian)相(xiang)應的數(shu)(shu)(shu)據(ju)模型并生成對(dui)應格(ge)式的數(shu)(shu)(shu)據(ju)。本文不再贅述其具體的數(shu)(shu)(shu)據(ju)建(jian)(jian)模方式，只介紹 TDengine 的數(shu)(shu)(shu)據(ju)建(jian)(jian)模的策略。

TDengine 一(yi)(yi)個(ge)(ge)(ge)重要的(de)創(chuang)新是其獨特(te)的(de)數(shu)據(ju)模型——為(wei)每個(ge)(ge)(ge)設備創(chuang)建(jian)獨立的(de)數(shu)據(ju)表(biao)(biao)（子(zi)(zi)表(biao)(biao)），并通過超(chao)(chao)級(ji)表(biao)(biao)（Super Table）在(zai)邏輯上和(he)語(yu)義(yi)上對同(tong)一(yi)(yi)采集類(lei)型的(de)設備進行(xing)統(tong)一(yi)(yi)管(guan)理。針對 IoT 場景(jing)的(de)數(shu)據(ju)內(nei)容，我(wo)們(men)(men)為(wei)每個(ge)(ge)(ge)卡(ka)車(che)創(chuang)建(jian)了兩張(zhang)表(biao)(biao)（后文(wen)中設備和(he)卡(ka)車(che)同(tong)義(yi)），用來存儲診斷信息(xi)(xi)和(he)指標(biao)信息(xi)(xi)的(de)時序數(shu)據(ju)。在(zai) 1.1 章節數(shu)據(ju)記錄(lu)中，我(wo)們(men)(men)看到 truck  name 可以作為(wei)每個(ge)(ge)(ge)卡(ka)車(che)的(de)標(biao)識 Id，因為(wei)有兩張(zhang)超(chao)(chao)級(ji)表(biao)(biao)，因此(ci)我(wo)們(men)(men)在(zai) TDengine 中使用  truck  name 拼(pin)接 d（r）作為(wei)子(zi)(zi)表(biao)(biao)的(de)名(ming)稱(cheng)。我(wo)們(men)(men)使用如下的(de)語(yu)句創(chuang)建(jian)名(ming)為(wei) diagnostics 和(he) readings 的(de)超(chao)(chao)級(ji)表(biao)(biao)，分別(bie)包含 3 、7 個(ge)(ge)(ge)測量值和(he) 8 個(ge)(ge)(ge)標(biao)簽。

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)

然后 ，我們(men)使用如(ru)下語(yu)句創建(jian)名(ming)為(wei) 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)

上述語句(ju)創建(jian)了一(yi)個子表(biao)。由(you)此可知，對(dui)于 100 個設(she)備（CPU）的(de)場景(jing)一(yi)，我們(men)(men)將(jiang)會(hui)建(jian)立(li) 100 個子表(biao)。對(dui)于 4000 個設(she)備的(de)場景(jing)二，系統中將(jiang)會(hui)建(jian)立(li) 4000 個子表(biao)用(yong)以存儲各自對(dui)應的(de)數(shu)據 。在(zai) TSBS 的(de)框架生成的(de)數(shu)據中，我們(men)(men)發現存在(zai)標簽信息 truck 為  null 的(de)數(shu)據內容，對(dui)于這部(bu)分數(shu)據，我們(men)(men)建(jian)立(li)了 d_truck_null(r_truck_null)的(de)表(biao)，用(yong)以存儲所(suo)有未能標識 truck 的(de)數(shu)據。

1.3 軟件版本和配置

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

1.3.1 TDengine

我們直接采用(yong) 版，從 GitHub 克隆(long) TDengine 代碼(ma)編譯版本作為(wei)性(xing)能對(dui)比的(de)版本。

gitinfo: 1bea5a53c27e18d19688f4d38596413272484900

在服務器(qi)上編(bian)譯安裝運行。

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

在 TDengine 的配(pei)(pei)置(zhi)文(wen)件中設置(zhi)了六(liu)個(ge)涉及查詢的配(pei)(pei)置(zhi)參(can)數。

numOfVnodeFetchThreads   4

queryRspPolicy           1

compressMsgSize          128000

SIMD-builtins            1

tagFilterCache           1

numOfTaskQueueThreads    24

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

對(dui)于(yu) IoT 場(chang)(chang)景(jing)，表(biao)數(shu)(shu)目是卡車規模數(shu)(shu)的(de)(de)二倍，所以(yi) TDengine 建庫默(mo)認創建 12 個 vnodes，即創建的(de)(de)表(biao)會(hui)按(an)照表(biao)名隨機分配(pei)到 12 個 虛擬節點（virtual node, VNode) 中。打開 LRU 緩(huan)存，設置為 last_row 緩(huan)存模式。對(dui)于(yu)場(chang)(chang)景(jing)一(yi)和場(chang)(chang)景(jing)二，stt_trigger 設置為 1，此時(shi) TDengine 會(hui)準備一(yi)個 Sorted Time-series Table (STT) 文件，用于(yu)容納(na)(na)單表(biao)寫入量小于(yu) minimum rows 的(de)(de)時(shi)候，數(shu)(shu)據(ju)直接(jie)保存在(zai) STT 文件中，當 STT 文件中無法容納(na)(na)新數(shu)(shu)據(ju)的(de)(de)時(shi)候，會(hui)將 STT 中的(de)(de)數(shu)(shu)據(ju)整理，再(zai)寫入到數(shu)(shu)據(ju)文件中。對(dui)于(yu)場(chang)(chang)景(jing)三(san)配(pei)置 stt_trigger 為 8，場(chang)(chang)景(jing)四和五，stt_trigger 設置為 16 ，即允(yun)許(xu)最多生(sheng)成 16 個 STT 文件。針對(dui)低(di)頻表(biao)多的(de)(de)場(chang)(chang)景(jing)，需(xu)要適(shi)度增(zeng)加 STT 的(de)(de)值(zhi)，以(yi)此來(lai)獲得更好的(de)(de)寫入性能。

1.3.2 TimescaleDB 

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

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

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

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

1.3.3 InfluxDB

我們選擇(ze) InfluxDB 。這里沒有使用 InfluxDB 最新(xin)的 2.x 版本是因為 TSBS 沒有對(dui)其進行(xing)適配，所以(yi)選用了(le)能夠(gou)運行(xing) TSBS 框架的 InfluxDB 最新(xin)版本。

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

配置系統在系統插入數據完成 30s 后開(kai)始數據壓縮(suo)。

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

二、測試步驟

2.1 硬件準備

為與對比報告[7]的環境(jing)高(gao)度接(jie)近(jin)，我們使(shi)用亞(ya)馬(ma)遜(xun) AWS 的 EC2 提供(gong)的 r4.8xlarge 類型(xing)實例作為(wei)基礎(chu)運行平臺，包括 1 臺服務器(qi)、1 臺客(ke)戶端(duan)共(gong)兩(liang)個節點構成的環境(jing)。客(ke)戶端(duan)與服務器(qi)硬(ying)件配置完全相同，客(ke)戶端(duan)與服務器(qi)使(shi)用 10 Gbps 網絡連接(jie)。配置簡表如下：

表 3. 物理節點配置

	CPU	Memory	Disk
服務器(qi)	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. 吞吐(tu)量(liang)上限是 125 MiB/Sec

2.2 服務器環境準備

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

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. 基礎環境，版本信息為：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 獲取測試腳本

為便于(yu)重(zhong)復測(ce)試(shi)(shi)(shi)，隱藏繁瑣的(de)下(xia)載、安裝(zhuang)、配置(zhi)、啟動、匯總結果(guo)等細節，整個(ge) TSBS 的(de)測(ce)試(shi)(shi)(shi)過程(cheng)被封(feng)裝(zhuang)成一(yi)個(ge)測(ce)試(shi)(shi)(shi)腳(jiao)本(ben)。重(zhong)復本(ben)測(ce)試(shi)(shi)(shi)報(bao)告，需要(yao)先(xian)下(xia)載該(gai)測(ce)試(shi)(shi)(shi)腳(jiao)本(ben)，腳(jiao)本(ben)暫支(zhi)持 ubuntu20.04 的(de)系統。以下(xia)操作要(yao)求具有 root 權限(xian)。

在(zai)客戶端(duan)機器，進入(ru)測試目錄拉取代碼(ma)，默認(ren)進入(ru) /usr/local/src/ 目錄，

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

修(xiu)(xiu)改配(pei)置(zhi)文件 test.ini 中(zhong)服務(wu)端和(he)客戶端的(de) IP 地(di)址(zhi)（這里配(pei)置(zhi) AWS 的(de)私網地(di)址(zhi)即可）和(he) hostname，如果服務(wu)器未(wei)配(pei)置(zhi)免密，還需(xu)要配(pei)置(zhi)服務(wu)器端的(de) root 密碼，本次(ci)測試 IoT 場景，故修(xiu)(xiu)改 caseType 為(wei) 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 一鍵執行對比測試

執行以下命令：

nohup bash tsdbComparison.sh > test.log &

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

三、寫入性能對比

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

可以看(kan)到在(zai)(zai)(zai)(zai)全(quan)部五(wu)個場(chang)(chang)景(jing)(jing)(jing)(jing)中(zhong)(zhong)，TDengine 的寫(xie)(xie)入性(xing)(xing)能全(quan)面超越(yue) TimescaleDB 和 InfluxDB。在(zai)(zai)(zai)(zai)場(chang)(chang)景(jing)(jing)(jing)(jing)二(er)中(zhong)(zhong) TDengine 寫(xie)(xie)入性(xing)(xing)能是 TimescaleDB 的最大達(da)到 3.3倍(bei)(bei)，在(zai)(zai)(zai)(zai)差距(ju)最小場(chang)(chang)景(jing)(jing)(jing)(jing)五(wu)中(zhong)(zhong)，是 TimescaleDB 寫(xie)(xie)入性(xing)(xing)能的 1.04 倍(bei)(bei)。相對(dui)于 InfluxDB，TDengine在(zai)(zai)(zai)(zai)場(chang)(chang)景(jing)(jing)(jing)(jing)五(wu)中(zhong)(zhong)寫(xie)(xie)入性(xing)(xing)能是 InfluxDB 的 16 倍(bei)(bei)，在(zai)(zai)(zai)(zai)差距(ju)最小的場(chang)(chang)景(jing)(jing)(jing)(jing)三中(zhong)(zhong)也有 1.8 倍(bei)(bei)。

我們還注意到，隨著設備數規模的增加，所有系統寫入基本上呈現下降趨勢。TimescaleDB 在小規模數據情況下寫入性能不及 InfluxDB，但是隨著設備數量的增加，其寫入性能超過了 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 寫入過程資源消耗對比

數(shu)據寫(xie)入(ru)速(su)度并不(bu)能夠全面(mian)的(de)反映三個系統在不(bu)同場景下(xia)數(shu)據寫(xie)入(ru)的(de)整(zheng)體(ti)表現。為(wei)此我們以 1,000,000 devices × 10  metrics （場景 四）為(wei)例，檢查數(shu)據寫(xie)入(ru)過(guo)程(cheng)中(zhong)的(de)服(fu)(fu)務器和客戶(hu)端（包(bao)括(kuo)客戶(hu)端與服(fu)(fu)務器）的(de)整(zheng)體(ti)負載狀(zhuang)況(kuang)，并以此來對比(bi)三個系統在寫(xie)入(ru)過(guo)程(cheng)中(zhong)服(fu)(fu)務器/客戶(hu)端節點的(de)資(zi)源占用情況(kuang)，這(zhe)里(li)的(de)資(zi)源占用主(zhu)要(yao)包(bao)括(kuo)服(fu)(fu)務器端的(de) CPU 開銷/磁盤 IO 開銷和客戶(hu)端 CPU 開銷。

3.2.1 服務端 CPU 開銷

圖四(si)展(zhan)示(shi)了(le)在(zai)場(chang)景四(si)寫(xie)(xie)入(ru)(ru)(ru)(ru)過程之中服務(wu)器(qi)端(duan) CPU 負載狀況。可(ke)以看到，三(san)個系統(tong)在(zai)返回(hui)給客(ke)戶端(duan)寫(xie)(xie)入(ru)(ru)(ru)(ru)完成(cheng)消息以后，都(dou)還(huan)繼(ji)續(xu)(xu)(xu)使用(yong)(yong)服務(wu)器(qi)的(de)(de)資(zi)(zi)源(yuan) 進(jin)(jin)行(xing)相應的(de)(de)處理(li)(li)工作，這點上(shang)，TimescaleDB 尤(you)為明顯，TimescaleDB 在(zai) 7X 秒的(de)(de)時(shi)候即反饋客(ke)戶端(duan)寫(xie)(xie)入(ru)(ru)(ru)(ru)完成(cheng)，但是其(qi)服務(wu)器(qi)端(duan)仍然調(diao)用(yong)(yong) CPU 資(zi)(zi)源(yuan)進(jin)(jin)行(xing)了(le)數(shu)據壓(ya)縮和整(zheng)理(li)(li)工作，當(dang)(dang)然整(zheng)個工作帶來的(de)(de) CPU 負載相對(dui)而言并(bing)不(bu)(bu)高，只有其(qi)峰(feng)值 CPU 開銷的(de)(de)一半左右，但是其(qi)持(chi)續(xu)(xu)(xu)時(shi)間(jian)相當(dang)(dang)長，接近其(qi)凈寫(xie)(xie)入(ru)(ru)(ru)(ru)時(shi)間(jian)的(de)(de) 4 倍。InfluxDB 則使用(yong)(yong)相當(dang)(dang)多的(de)(de) CPU 資(zi)(zi)源(yuan)，瞬(shun)時(shi)峰(feng)值使用(yong)(yong)了(le)全(quan)部的(de)(de) CPU 資(zi)(zi)源(yuan)，其(qi)寫(xie)(xie)入(ru)(ru)(ru)(ru)負載較(jiao)高，并(bing)且其(qi)持(chi)續(xu)(xu)(xu)時(shi)間(jian)比 TimescaleDB 更長，當(dang)(dang)然遠長于(yu) TDengine。三(san)個系統(tong)對(dui)比，TDengine 對(dui)服務(wu)器(qi)的(de)(de) CPU 需(xu)求最小，峰(feng)值也僅使用(yong)(yong)了(le) 17% 左右的(de)(de)服務(wu)器(qi) CPU 資(zi)(zi)源(yuan)。由此(ci)可(ke)見(jian)，TDengine 獨特的(de)(de)數(shu)據模(mo)型對(dui)于(yu)時(shi)序數(shu)據寫(xie)(xie)入(ru)(ru)(ru)(ru)不(bu)(bu)僅在(zai)性能上(shang)，在(zai)整(zheng)體的(de)(de)資(zi)(zi)源(yuan)開銷上(shang)也具(ju)有非常大的(de)(de)優勢。

3.2.2 磁盤 I/O 對比

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

寫入(ru)(ru)相同規模(mo)的(de)數據(ju)(ju)集，TDengine 在(zai)寫入(ru)(ru)過(guo)(guo)程中(zhong)(zhong)對(dui)于(yu)磁(ci)盤(pan)寫入(ru)(ru)能力的(de)占用遠(yuan)小于(yu) TimescaleDB 和 InfluxDB，寫入(ru)(ru)過(guo)(guo)程只占用了部分磁(ci)盤(pan)寫入(ru)(ru)能力（125MiB/Sec. 3000IOPS）。從圖上能看(kan)到(dao)，數據(ju)(ju)寫入(ru)(ru)過(guo)(guo)程中(zhong)(zhong)磁(ci)盤(pan)的(de) IO 瓶頸是確實存在(zai)的(de)。InfluxDB 長(chang)時間(jian)消耗(hao)完全部的(de)磁(ci)盤(pan)寫入(ru)(ru)能力，TimescaleDB 寫入(ru)(ru)過(guo)(guo)程對(dui)于(yu)寫入(ru)(ru)的(de)消耗(hao)相對(dui) InfluxDB來說(shuo)要更具優勢(shi)，但是仍然(ran)遠(yuan)超過(guo)(guo)了 TDengine 對(dui)磁(ci)盤(pan)寫入(ru)(ru)能力的(de)需求。

3.2.3 客戶端 CPU 開銷

從圖 5 可以看到，客(ke)(ke)(ke)戶(hu)(hu)端上 TDengine 對 CPU 的(de)需(xu)求大于 TimescaleDB 和(he) InfluxDB， 而 InfluxDB 在整(zheng)(zheng)個寫入過程中(zhong)，客(ke)(ke)(ke)戶(hu)(hu)端負(fu)載整(zheng)(zheng)體上來(lai)(lai)說(shuo)，三個系(xi)統(tong)中(zhong)計(ji)算資(zi)源(yuan)占用最(zui)低，對客(ke)(ke)(ke)戶(hu)(hu)端壓(ya)(ya)力最(zui)小，其寫入的(de)壓(ya)(ya)力基本上完全(quan)集中(zhong)在服務端。這種(zhong)模式(shi)很容易導致服務端成為瓶頸(jing)，TimescaleDB 相對于 InfluxDB 而言(yan)，對于客(ke)(ke)(ke)戶(hu)(hu)端壓(ya)(ya)力更(geng)大，CPU 峰(feng)值達到 20% 左(zuo)右。TDengine 在客(ke)(ke)(ke)戶(hu)(hu)端的(de)開(kai)(kai)銷(xiao)(xiao)最(zui)大，峰(feng)值瞬間達到了(le) 70%，然(ran)后快速回落。TDengine 在客(ke)(ke)(ke)戶(hu)(hu)端的(de)開(kai)(kai)銷(xiao)(xiao)相比于 TimescaleDB 多了(le) 1 倍。綜合(he)服務器與客(ke)(ke)(ke)戶(hu)(hu)端的(de)資(zi)源(yuan)開(kai)(kai)銷(xiao)(xiao)來(lai)(lai)看，TDengine 寫入持續時(shi)間更(geng)短，在系(xi)統(tong)整(zheng)(zheng)體 CPU 開(kai)(kai)銷(xiao)(xiao)上TDengine 仍然(ran)具有優勢。

3.3 寫入性能對比總結

在全部的(de)場景中(zhong)，TDengine 的(de)寫(xie)(xie)入(ru)性(xing)能(neng)超(chao)過(guo) TimescaleDB 和 InfluxDB。在整個寫(xie)(xie)入(ru)過(guo)程中(zhong)，TDengine 除了在提(ti)供了更高的(de)寫(xie)(xie)入(ru)能(neng)力的(de)前提(ti)下，在服務器(qi)的(de) CPU 和 IO 上(shang)，也均遠(yuan)優于 TimescaleDB 和 InfluxDB。對于服務器(qi)的(de)磁盤 IO 開銷遠(yuan)小于 TimescaleDB 和 InfluxDB。即(ji)使加上(shang)客(ke)戶端的(de)開銷統計，TDengine 在寫(xie)(xie)入(ru)開銷上(shang)遠(yuan)優于 TimescaleDB 和 InfluxDB。

3.4 磁盤空間占用

三(san)個系(xi)統數據(ju)完全(quan)落盤以后，比(bi)較(jiao)了三(san)個系(xi)統在不同場景下的磁盤空間占用比(bi)較(jiao)。

從圖 6 可以看(kan)到，TimescaleDB  在(zai)所(suo)有的(de)場(chang)景(jing)(jing)下數據規模(mo)均顯(xian)著(zhu)地(di)大(da)于 InfluxDB 和 TDengine，并(bing)且這種差(cha)距隨(sui)著(zhu)數據規模(mo)增加(jia)快(kuai)速變大(da)。TimescaleDB 在(zai)場(chang)景(jing)(jing)四和場(chang)景(jing)(jing)五(wu)中(zhong)占用磁盤空(kong)間超過了 TDengine 的(de) 11 倍。在(zai)前面(mian)三個場(chang)景(jing)(jing)中(zhong)，InfluxDB 落(luo)盤后數據文(wen)件規模(mo)與 TDengine 比較接近。但是在(zai)場(chang)景(jing)(jing)四/五(wu)兩個場(chang)景(jing)(jing)中(zhong)，InfluxDB 落(luo)盤后文(wen)件占用的(de)磁盤空(kong)間是 TDengine 的(de) 2 倍以上。

這里還有(you)個(ge)小插曲，表 5 反(fan)應了 TimescaleDB 的壓縮(suo)比(bi)(bi)率(lv)，TimescaleDB 在(zai)小數(shu)(shu)劇規模的情(qing)況(kuang)下，壓縮(suo)比(bi)(bi)正常。但是(shi)在(zai)大數(shu)(shu)據規模場(chang)景四和場(chang)景五(wu)中，壓縮(suo)以(yi)后的磁盤空間占用比(bi)(bi)例反(fan)而增(zeng)大了 3.4 倍左右，疑似 bug。

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

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

3.5 性能基準評估擴展部分

為了更(geng)全(quan)面(mian)地評(ping)估(gu) TDengine 在默認參(can)數下(xia)寫(xie)入性能(neng)(neng)，我們(men)在下(xia)面(mian)的性能(neng)(neng)評(ping)估(gu)中調整(zheng)可(ke)能(neng)(neng)會影響(xiang)寫(xie)入性能(neng)(neng)的兩(liang)個參(can)數，進行評(ping)估(gu)測(ce)試。

3.5.1 虛擬節點（vnodes）數量

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

表 6. 不同虛擬節點數據量情況寫入性能變化

	scale=1,000,000 場景四		scale=10,000,000 場景(jing)五
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%

我們看到(dao)，在較多的(de)(de)設(she)備的(de)(de)場景（場景四、五）中，增加 vnodes 的(de)(de)數量 ，TDengine 寫入性能提(ti)升明顯。可(ke)見(jian)在不同規模的(de)(de)場景中，可(ke)以通過(guo)調(diao)整虛(xu)擬節點的(de)(de)數量來獲得(de)更好的(de)(de)寫入性能。

3.5.2 設備記錄數量

TDengine 為(wei)(wei)一(yi)個(ge)(ge)(ge)設(she)備(bei)(bei)一(yi)張(zhang)表(biao)(biao)的(de)(de)(de)(de)(de)數(shu)據模型，需(xu)要在數(shu)據寫(xie)入(ru)(ru)時(shi)(shi)創建(jian)表(biao)(biao)，建(jian)表(biao)(biao)操作對(dui)每(mei)個(ge)(ge)(ge)設(she)備(bei)(bei)只執行一(yi)次，但這使得 TDengine 在數(shu)據寫(xie)入(ru)(ru)的(de)(de)(de)(de)(de)準備(bei)(bei)階段時(shi)(shi)間(jian)耗(hao)時(shi)(shi)較多。當單(dan)個(ge)(ge)(ge)表(biao)(biao)中(zhong)數(shu)據量(liang)(liang)增(zeng)加以后 ，數(shu)據準備(bei)(bei)（建(jian)表(biao)(biao)）的(de)(de)(de)(de)(de)開(kai)銷(xiao)被(bei)分攤到更(geng)(geng)(geng)多的(de)(de)(de)(de)(de)數(shu)據寫(xie)入(ru)(ru)的(de)(de)(de)(de)(de)整(zheng)體(ti)開(kai)銷(xiao)中(zhong)，以場(chang)景四（1,000,000 devices × 10  metrics）為(wei)(wei)例，單(dan)個(ge)(ge)(ge)設(she)備(bei)(bei)的(de)(de)(de)(de)(de)數(shu)據量(liang)(liang)僅(jin)有(you) 18 條(tiao)(tiao)。當我(wo)們調(diao)整(zheng)參數(shu)，將(jiang)單(dan)個(ge)(ge)(ge)設(she)備(bei)(bei)記(ji)錄(lu)數(shu)據增(zeng)加到 36、72、144 條(tiao)(tiao)時(shi)(shi)，整(zheng)體(ti)寫(xie)入(ru)(ru)時(shi)(shi)間(jian)更(geng)(geng)(geng)長，因(yin)此(ci)表(biao)(biao)現(xian)出(chu)來就是建(jian)表(biao)(biao)開(kai)銷(xiao)被(bei)分攤到更(geng)(geng)(geng)多的(de)(de)(de)(de)(de)數(shu)據寫(xie)入(ru)(ru)過(guo)程(cheng)中(zhong)，建(jian)表(biao)(biao)的(de)(de)(de)(de)(de)開(kai)銷(xiao)相(xiang)對(dui)于數(shu)據寫(xie)入(ru)(ru)的(de)(de)(de)(de)(de)耗(hao)時(shi)(shi)占(zhan)比越來越小，相(xiang)應的(de)(de)(de)(de)(de)整(zheng)體(ti)寫(xie)入(ru)(ru)速度(du)也越來越快。因(yin)此(ci)可以看到，TDengine 表(biao)(biao)現(xian)出(chu)了更(geng)(geng)(geng)加明顯的(de)(de)(de)(de)(de)寫(xie)入(ru)(ru)優勢(shi)。（這里(li)每(mei)張(zhang)表(biao)(biao)的(de)(de)(de)(de)(de)記(ji)錄(lu)數(shu)忽略(lve)了 IoT 場(chang)景中(zhong)丟失的(de)(de)(de)(de)(de)記(ji)錄(lu)。所以單(dan)個(ge)(ge)(ge)設(she)備(bei)(bei)記(ji)錄(lu)數(shu)據這個(ge)(ge)(ge)值(zhi)并非百(bai)分百(bai)準確(que)）

我們調整 vnodes 數量配置(zhi)，同(tong)時測試兩個不同(tong) vnodes 數量情況(kuang)下的(de)寫入性能(neng)指標。如圖 7 所示，隨(sui)著表中記(ji)(ji)錄數的(de)增加，vgroups=12 和 vgroups=24，TDengine 寫入性能(neng)均(jun)呈(cheng)現出持(chi)續增加的(de)趨勢。當(dang)設(she)備(bei)記(ji)(ji)錄數達(da)到(dao) 576 行（此時數據(ju)集規模約等于 32,414,619 x 32  = 10.37 億行數據(ju)記(ji)(ji)錄）的(de)時候，vgroups=12 時，寫入性能(neng)達(da)到(dao) 2,827,696.64 metrics/sec，性能(neng)均(jun)大幅(fu)領先 TimescaleDB 與 InfluxDB，是(shi) TimescaleDB 的(de)6.1 倍(bei)， InfluxDB 的(de) 4.6 倍(bei)。

TimescaleDB 寫(xie)入(ru)性(xing)能在(zai)單(dan)表記(ji)錄數(shu)量(liang)大于 72 行以后出現了快(kuai)速(su)衰(shuai)(shuai)減。InfluxDB 在(zai)單(dan)設備(bei)記(ji)錄增加(jia)過(guo)程(cheng)中，寫(xie)入(ru)性(xing)能有衰(shuai)(shuai)減，但衰(shuai)(shuai)減趨(qu)勢非常緩慢。

3.5.3 總結

通(tong)過調整不同的(de)(de)(de)數(shu)(shu)(shu)據(ju)(ju)庫參數(shu)(shu)(shu)(vgroups)，以(yi)及設置不同的(de)(de)(de)數(shu)(shu)(shu)據(ju)(ju)規模（增加每個(ge)設備(bei)包含記錄數(shu)(shu)(shu)）方(fang)式(shi)，我們在更(geng)多的(de)(de)(de)方(fang)面評(ping)估了 TDengine 在 TSBS 基準(zhun)數(shu)(shu)(shu)據(ju)(ju)集上的(de)(de)(de)寫入性能。通(tong)過這(zhe)一系列(lie)深入的(de)(de)(de)對(dui)(dui)比可以(yi)看到(dao)，針(zhen)對(dui)(dui)更(geng)大規模（設備(bei)數(shu)(shu)(shu)量和(he)每個(ge)設備(bei)記錄數(shu)(shu)(shu)量）數(shu)(shu)(shu)據(ju)(ju)集，TDengine 可以(yi)通(tong)過簡單調整虛擬節(jie)點(dian)數(shu)(shu)(shu)量的(de)(de)(de)方(fang)式(shi)，獲(huo)得(de)更(geng)高(gao)的(de)(de)(de)寫入性能，并且(qie) TDengine 在針(zhen)對(dui)(dui)大數(shu)(shu)(shu)據(ju)(ju)集寫入場景下展現(xian)出更(geng)好的(de)(de)(de)性能優勢，同時具有遠低于 TimescaleDB 和(he) InfluxDB 對(dui)(dui)服務端資源（服務器 CPU 和(he) 磁盤 IO、內(nei)存等）的(de)(de)(de)開銷(xiao)。

四、查詢性能對比

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

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

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

表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%

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

對于分組選擇的查(cha)詢中(zhong)，TDengine 采用一(yi)張表(biao)一(yi)個設(she)備（卡車(che)）的設(she)計方式，并(bing)采用緩存模(mo)式的 last_row 函數來(lai)查(cha)詢最新的數據，使得TDengine 的查(cha)詢響應時間上均優于 InfluxDB 和 TimescaleDB。

在復(fu)雜分(fen)組聚合(he)的(de)(de)(de)(de)查詢(xun)中，我們(men)看到 TDengine 查詢(xun)性(xing)(xing)能(neng)相比于 TimescaleDB 和 InfluxDB 有非(fei)常大的(de)(de)(de)(de)優勢；而在時間窗口聚合(he)的(de)(de)(de)(de)查詢(xun)過程中，TimescaleDB 針對規模較大的(de)(de)(de)(de)數據集其查詢(xun)性(xing)(xing)能(neng)不佳(jia)，long-driving-sessions 和 long-daily-sessions 均表現很(hen)差。TDengine 在 stationary-trucks 查詢(xun)性(xing)(xing)能(neng)是(shi)(shi) InfluxDB 的(de)(de)(de)(de) 132倍(bei)，是(shi)(shi) TimescaleDB 的(de)(de)(de)(de) 8 倍(bei)。在 long-daily-sessions 中是(shi)(shi)TimescaleDB 的(de)(de)(de)(de) 87 倍(bei)，是(shi)(shi) InfluxDB 的(de)(de)(de)(de) 6.5 倍(bei)。

在(zai)復雜的混合查(cha)詢(xun)(xun)中(zhong)， TDengine 展現出巨大的性能(neng)優勢，其查(cha)詢(xun)(xun)響應時間來度量，其中(zhong) avg-load 和 breakdown-frequency 的查(cha)詢(xun)(xun)性能(neng)是(shi) InfluxDB 的 426 倍(bei)和 53 倍(bei) ；對比(bi) TimescaleDB，在(zai) daily-activity 查(cha)詢(xun)(xun)中(zhong)，TDengine 是(shi)其 34 倍(bei)，在(zai) avg-load 查(cha)詢(xun)(xun)中(zhong)，TDengine 是(shi)其 23 倍(bei)。

4.2 資源開銷對比

由(you)于部分查(cha)詢(xun)(xun)持續時(shi)間特別(bie)短，并不能完整(zheng)地看到查(cha)詢(xun)(xun)過程中(zhong)服務(wu)器的(de) IO/CPU/網絡情況。我(wo)們針對場景二，以 daily-activity 查(cha)詢(xun)(xun)為例(li)，執行(xing) 50 次(ci)查(cha)詢(xun)(xun)，記(ji)錄整(zheng)個過程中(zhong)三個軟(ruan)件系統在查(cha)詢(xun)(xun)執行(xing)的(de)整(zheng)個過程中(zhong)服務(wu)器 CPU、內存(cun)、網絡的(de)開銷進行(xing)對比(bi)。

服務器 CPU 開銷

如圖 9 可以看到，三個系統在整(zheng)(zheng)個查(cha)詢過程(cheng)(cheng)中 CPU 的(de)使用均較(jiao)為平穩。TDengine 在查(cha)詢過程(cheng)(cheng)中整(zheng)(zheng)體(ti) CPU 占(zhan)用約 70%，  TimescaleDB 在查(cha)詢過程(cheng)(cheng)中瞬(shun)時 CPU  最(zui)低(di)，約 22%。InfluxDB 的(de)穩定的(de) CPU  占(zhan)用的(de)最(zui)大，約 98 %（有較(jiao)多的(de)瞬(shun)時100%）。整(zheng)(zheng)體(ti) CPU 開(kai)銷上來看，雖然 TimescaleDB 瞬(shun)時 CPU 開(kai)銷最(zui)低(di)，但是(shi)其完成查(cha)詢持續(xu)時間(jian)最(zui)長，所以整(zheng)(zheng)體(ti) CPU 資源消耗最(zui)多。InfluxDB 基本頂格100%使用全部(bu)(bu) cpu，持續(xu)時間(jian)是(shi)TDengine的(de)三倍，開(kai)銷次之。 TDengine 完成全部(bu)(bu)查(cha)詢的(de)時間(jian)僅是(shi)  TimescaleDB 的(de)  1/30，整(zheng)(zheng)體(ti) CPU 開(kai)銷最(zui)低(di)。

服務器內存狀況

如圖(tu) 10 所示，在整(zheng)個(ge)查詢過(guo)程(cheng)中，TDengine 內(nei)存(cun)維(wei)持了一個(ge)相對(dui)平穩(wen)的(de)狀態，平均使用約為 12G。TimescaleDB 和(he)(he)InfluxDB 內(nei)存(cun)占用在整(zheng)個(ge)查詢過(guo)程(cheng)中保持平穩(wen)，平均約為 10G；其中 TimescaleDB 對(dui) buffer 和(he)(he) cache 使用比較多(duo)。

服務器網絡帶寬

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

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

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

表 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 所示，在更小規模的(de)數據集(ji)（場(chang)景一）上的(de)查(cha)詢(xun)(xun)對比可以(yi)看到，整體上 TDengine 同樣展現(xian)出(chu)極好的(de)性能，在全部(bu)的(de)查(cha)詢(xun)(xun)語句中全面優于 TimescaleDB  和 InfluxDB，部(bu)分(fen)查(cha)詢(xun)(xun)性能超(chao)過(guo) TimescaleDB 16 倍(bei)，超(chao)過(guo) InfluxDB 155 倍(bei)。

五、總結

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

六、參考文獻

[1] Timescale. 

[2] High-cardinality TSDB benchmarks: VictoriaMetrics vs TimescaleDB vs InfluxDB. 

[3] ClickHouse Crushing Time Series. 

[4] ClickHouse Continues to Crush Time Series. 

[5] Benchmarking Time Series workloads on Apache Kudu using TSBS.

[6] RedisTimeSeries Version 1.2 Benchmarks. 

[7] TimescaleDB vs. InfluxDB: Purpose Built Differently for Time-Series Data. 

[8] QuestDB vs. TimescaleDB. 

[9] Time Series Benchmark Suite. 

[10] Performance Comparison: InfluxDB and TimescaleDB vs. TDengine.