一、背景介紹

1.1 性能基準對比框架

是  ^[1]開源，集多種應用(yong)(yong)場景(jing)下時序數據(ju)(ju)生(sheng)成、數據(ju)(ju)寫(xie)入、查詢處理、自動化(hua)結果匯總(zong)統(tong)計等(deng)(deng)功能于一體的時序數據(ju)(ju)（Time Series Data）性能基準測(ce)評(ping)平臺。TSBS 提供 IoT、DevOps 兩個典(dian)型應用(yong)(yong)場景(jing)，具有簡單、易(yi)用(yong)(yong)、擴展性優異等(deng)(deng)特點(dian)。由于 TSBS 是一個開源的平臺，因此(ci)得到了 InfluxDB、TimescaleDB、QuestDB、ClickHouse 等(deng)(deng)眾多數據(ju)(ju)庫(ku)系統(tong)的廣泛支(zhi)持，并被多家數據(ju)(ju)庫(ku)廠商使用(yong)(yong)，作為基準性能測(ce)評(ping)平臺。

早在 2018 年，VictoriaMetrics 的創始人 Aliaksandr Valialkin 就基于 TSBS 框架發布 VictoriaMetrics 與 Timescale 和 InfluxDB 的性能對比報告^[2]。2018 年 11 月，文章《ClickHouse Crushing Time Series》^[3]《ClickHouse Continues to Crush Time Series》^[4]對比 TimescaleDB, InfluxDB, ClickHouse 在時序數據場景下進行了性能。2020年 3 月 Cloudera 的網站博客中發布了基于 TSBS 框架，在DevOps場景的性能測評對比報告，對比了Apache Kudu, InfluxDB,  VictoriaMetrics, ClickHouse 等數據庫產品在該時序場景下的性能表現^[5]。同一個月，Redis發布了基于 TSBS 的性能報告《RedisTimeSeries Version 1.2 Benchmarks》^[6]，同年8 月，Timescale 在其官方博客中給出了基于此框架平臺的性能基準對比報告《TimescaleDB vs. InfluxDB: Purpose Built Differently for Time-Series Data》^[7]，在該報告中 Timescale 提供了其核心產品 TimescaleDB 和 InfluxDB 基于 TSBS 框架的性能測評報告。2021年 8 月，QuestDB 發布了QuestDB與 TimescaleDB 的性能對比報告——《QuestDB vs. TimescaleDB》^[8]。從(cong)上述(shu)眾多的(de)對比報告，不論是(shi)時間跨度還是(shi)發布的(de)廠(chang)商(shang)來看，TSBS 作為基準測試平臺具有相(xiang)當高的(de)認可度。

為了客觀、準確、可驗證地評估 TDengine Ver3.0 的性能表現，我們也選用了 TSBS 框架作為性能基準對比平臺，作為橫向對比的產品，我們選擇了 TimescaleDB 和  InfluxDB 進行對比。請參見  ^[9]獲得關于該框架的詳(xiang)細(xi)介紹和相關信息。

1.2 測試場景介紹

我們使用了 DevOps 場景(jing)中的(de)(de) cpu-only 作為基礎數(shu)據(ju)集(ji)。TSBS 框(kuang)架中 cpu-only 場景(jing)模擬對(dui)服務(wu)器 CPU 監控生成的(de)(de)時(shi)序數(shu)據(ju)，針(zhen)對(dui)每個(ge)設備（ CPU）記錄其 10 個(ge)測量值，1個(ge)（納秒(miao)分辨率）時(shi)間(jian)戳，10 個(ge)標簽(qian)值。具體的(de)(de)內容(rong)和示例數(shu)據(ju)見下表(biao) 1，生成的(de)(de)數(shu)據(ju)每 10 秒(miao)一條記錄。數(shu)據(ju)模式(shi)（schema）見下圖 1。其中每條記錄包含了 10 個(ge)標簽(qian)（tags）和 1 個(ge)時(shi)間(jian)戳 及 10 個(ge)測量值（metric）。

在(zai)整個(ge)基準性(xing)能評估(gu)中，涉及以下(xia)五(wu)個(ge)場景(jing)(jing)，每(mei)個(ge)場景(jing)(jing)的具(ju)體(ti)數據規模和特(te)點見(jian)下(xia)表(biao) 1：

可以看到，五個(ge)場(chang)景(jing)(jing)的(de)區別主要在于數(shu)(shu)據(ju)集(ji)所包含的(de)設(she)備記(ji)錄數(shu)(shu)量，設(she)備數(shu)(shu)的(de)差異。數(shu)(shu)據(ju)時間間隔均(jun)維(wei)持在 10 sec。整體上(shang)看，五個(ge)場(chang)景(jing)(jing)的(de)數(shu)(shu)據(ju)規(gui)(gui)模(mo)都(dou)不(bu)大，數(shu)(shu)據(ju)規(gui)(gui)模(mo)最(zui)大的(de)是場(chang)景(jing)(jing)五，數(shu)(shu)據(ju)規(gui)(gui)模(mo)最(zui)小(xiao)的(de)場(chang)景(jing)(jing)四只有 18,000,000 條記(ji)錄。在場(chang)景(jing)(jing)四和(he)場(chang)景(jing)(jing)五中，由(you)于設(she)備數(shu)(shu)量相對較多，所以數(shu)(shu)據(ju)集(ji)僅(jin)覆蓋了 3 分鐘的(de)時間跨度(du)。

1.3 數據建模

在 TSBS 框架中(zhong)， TimescaleDB 和(he) InfluxDB 會自動創建相應的數據模(mo)型(xing)并生成(cheng)對(dui)應格式(shi)的數據。本文(wen)不再(zai)贅述其具體(ti)的數據建模(mo)方(fang)式(shi)，只介紹 TDengine 的數據建模(mo)的策略。

TDengine 一個(ge)重要的(de)(de)(de)(de)創(chuang)新是(shi)其(qi)獨特的(de)(de)(de)(de)數(shu)據(ju)模型——為(wei)(wei)每個(ge)設(she)(she)備(bei)(bei)創(chuang)建獨立的(de)(de)(de)(de)數(shu)據(ju)表（子表），并通(tong)過(guo)超級(ji)表（Super Table）在邏輯上(shang)和語(yu)義上(shang)對(dui)同(tong)一采集類(lei)型的(de)(de)(de)(de)設(she)(she)備(bei)(bei)進行統一管(guan)理(li)。針對(dui) DevOps 場(chang)景的(de)(de)(de)(de)數(shu)據(ju)內容，我(wo)們(men)(men)為(wei)(wei)每個(ge)設(she)(she)備(bei)(bei) （這里是(shi) CPU）創(chuang)建了一個(ge)表，用以(yi)存(cun)儲(chu)該表的(de)(de)(de)(de)時序數(shu)據(ju)。在 1.2 章(zhang)節數(shu)據(ju)記錄中，我(wo)們(men)(men)看(kan)到 hostname 可(ke)以(yi)作為(wei)(wei)每個(ge)設(she)(she)備(bei)(bei)的(de)(de)(de)(de)標識(shi) Id , 因(yin)此我(wo)們(men)(men)在 TDengine 中使用 hostname 作為(wei)(wei)子表的(de)(de)(de)(de)名稱。我(wo)們(men)(men)使用如(ru)下的(de)(de)(de)(de)語(yu)句創(chuang)建名為(wei)(wei) CPU 的(de)(de)(de)(de)超級(ji)表，包(bao)含(han) 10 個(ge)測量(liang)值和 10 個(ge)標簽。

create stable cpu (ts timestamp,usage_user bigint,usage_system bigint,usage_idle bigint,usage_nice bigint,usage_iowait bigint,usage_irq bigint,usage_softirq bigint,usage_steal bigint,usage_guest bigint,usage_guest_nice bigint)
tags (hostname varchar(30), region varchar(30),datacenter varchar(30),rack varchar(30),os varchar(30),arch varchar(30),team varchar(30),service varchar(30),service_version varchar(30),service_environment varchar(30))

然(ran)后 ，我們使用如下(xia)語句(ju)創建名(ming)為(wei) host_0 的子表：

create table host_0 using cpu (hostname,region,datacenter,rack,os,arch,team,service,service_version,service_environment)
tags ('host_0','eu-central-1','eu-central-1a','6','Ubuntu15.10','x86','SF','19','1','test')

上述語句創建(jian)了一個(ge)子(zi)表(biao)。由(you)此可知，對于 100 個(ge)設備（CPU）的場(chang)景 一，我們將會(hui)建(jian)立(li) 100 個(ge)子(zi)表(biao)。對于 4000  個(ge)設備的場(chang)景二，系統中(zhong)將會(hui)建(jian)立(li) 4000 個(ge)子(zi)表(biao)用以存儲(chu)各(ge)自對應的數據 。

1.4 軟件版本和配置

本報告僅比較(jiao) TDengine、InfluxDB 與 TimeScaleDB，下面對(dui)使用的版本和配置做出說明。

1.4.1 TDengine

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

gitinfo: c90e2aa791ceb62542f6ecffe7bd715165f181e8

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

cmake .. -DDISABLE_ASSERT=true -DSIMD_SUPPORT=true -DCMAKE_BUILD_TYPE=Release  -DBUILD_TOOLS=false
make -j  && make install

在TDengine的(de)配置文件中設置了四(si)個(ge)涉及(ji)查詢的(de)配置參(can)數。

numOfVnodeFetchThreads           4

queryRspPolicy                   1

compressMsgSize             128000

SIMD-builtins                    1

第(di)一(yi)個參(can)(can)數 numOfVnodeFetchThreads 設置 Vnode 的(de)Fetch 線程數量為 4 個， 第(di)二個參(can)(can)數 queryRspPolicy 打開(kai)  query response 快速(su)返回(hui)機(ji)制(zhi)， 第(di)三個參(can)(can)數 compressMsgSize 讓TDengine 在傳輸層上大于 128,000 bytes的(de)消息自動進(jin)行壓(ya)縮，第(di)四個參(can)(can)數是如果 CPU 支持(chi)，啟(qi)用內置的(de) FMA/AVX/AVX2 硬(ying)件加速(su)。

如(ru)上所(suo)述，TDengine 建(jian)(jian)庫(ku)默認創建(jian)(jian) 6 個(ge) vnodes，即創建(jian)(jian)的表會按照表名(ming)隨(sui)機分配(pei)到 6 個(ge) 虛擬節點（virtual node, VNode) 中(zhong)(zhong)(zhong)。打(da)開 LRU 緩(huan)存，設(she)置(zhi)(zhi)(zhi)為 last_row 緩(huan)存模式。對(dui)于(yu)(yu)(yu)場(chang)(chang)景(jing)一和場(chang)(chang)景(jing)二(er)，stt_trigger 設(she)置(zhi)(zhi)(zhi)為 1，此時(shi) TDengine 會準備(bei)一個(ge) Sorted Time-series Table (STT) 文(wen)件(jian)(jian)，用于(yu)(yu)(yu)容納單表寫(xie)入量小于(yu)(yu)(yu) minimum rows 的時(shi)候，數據(ju)直(zhi)接保存在 STT 文(wen)件(jian)(jian)中(zhong)(zhong)(zhong)，當 STT 文(wen)件(jian)(jian)中(zhong)(zhong)(zhong)無(wu)法容納新數據(ju)的時(shi)候，會將 STT 中(zhong)(zhong)(zhong)的數據(ju)整理，再寫(xie)入到數據(ju)文(wen)件(jian)(jian)中(zhong)(zhong)(zhong)。對(dui)于(yu)(yu)(yu)其他(ta)的場(chang)(chang)景(jing)（場(chang)(chang)景(jing)三、四(si)、五），stt_trigger 設(she)置(zhi)(zhi)(zhi)為 8，即允許(xu)最多生成 8 個(ge) STT 文(wen)件(jian)(jian)。針對(dui)表較多的場(chang)(chang)景(jing)，需要適(shi)度增加(jia) STT 的值，以此來獲得(de)更好的寫(xie)入性能。

1.4.2 TimescaleDB 

為(wei)確保結果具有可(ke)比性(xing)，我們選用 TimescaleDB 版本(ben) 。為(wei)獲得較(jiao)好的(de)性(xing)能，TimescaleDB 需要針對不(bu)同的(de)場景(jing)設置不(bu)同的(de) Chunk 參數(shu)，不(bu)同場景(jing)下參數(shu)的(de)設置如下表所(suo)示。

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

1.4.3 InfluxDB

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

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

配置系統(tong)在(zai)系統(tong)插入數(shu)據完(wan)成 30s 后開始數(shu)據壓縮。

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

二、測試步驟

2.1 硬件準備

為與對比報告[7]的(de)環(huan)(huan)境高度接近(jin)，我(wo)們使用亞馬遜 AWS 的(de) EC2 提供的(de) r4.8xlarge 類(lei)型實(shi)例(li)作為基(ji)礎(chu)運行平臺，包括(kuo) 1 臺服務器(qi)、1 臺客戶端(duan)共兩個節點(dian)構成的(de)環(huan)(huan)境。客戶端(duan)與服務器(qi)硬件配(pei)置完全相同，客戶端(duan)與服務器(qi)使用 10 Gbps 網絡連(lian)接。配(pei)置簡表如(ru)下(xia)：

2.2 服務器環境準備

為運(yun)行測試(shi)腳本(ben)，服(fu)務(wu)器(qi)OS需要是ubuntu20以上的(de)系統(tong)。AWS EC2的(de)服(fu)務(wu)器(qi)系統(tong)信(xin)息如下：

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 獲取測試腳本

為便于重復(fu)測(ce)試(shi)(shi)，隱(yin)藏繁瑣的下載、安(an)裝、配置、啟動、匯(hui)總結果等細(xi)節，整個(ge)(ge) TSBS 的測(ce)試(shi)(shi)過程被封(feng)裝成一(yi)個(ge)(ge)測(ce)試(shi)(shi)腳本(ben)。重復(fu)本(ben)測(ce)試(shi)(shi)報告，需要先下載該測(ce)試(shi)(shi)腳本(ben)，腳本(ben)暫支持 ubuntu20 以上的系統。以下操作要求具有 root 權限(xian)。

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

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

2. 修改(gai)配置文件 test.ini 中服務端和(he)客戶(hu)端的 IP 地(di)址(zhi)（這里(li)配置 AWS 的私網地(di)址(zhi)即可）和(he) hostname，如果服務器(qi)未配置免密(mi)，還需要配置服務器(qi)端的 root 密(mi)碼。

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

2.4 一鍵執行對比測試

執行以下命令：

nohup bash tsdbComparison.sh > test.log &

測(ce)試(shi)(shi)(shi)腳(jiao)本(ben)將自動(dong)(dong)安裝 TDengine, InfluxDB, TimeScaleDB 等(deng)軟件，并自動(dong)(dong)運行各種對比測(ce)試(shi)(shi)(shi)項。在(zai)目前(qian)的硬件配置下，整(zheng)個測(ce)試(shi)(shi)(shi)跑完需要(yao)大約(yue)一天半的時間(jian)。測(ce)試(shi)(shi)(shi)結束后(hou)，將自動(dong)(dong)生成 CSV 格式的對比測(ce)試(shi)(shi)(shi)報告，并存放在(zai)客(ke)戶端的 /data2 目錄。

三、寫入性能對比

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

可(ke)以看到在(zai)(zai)全部五個(ge)場(chang)景(jing)中(zhong)，TDengine 的(de)(de)寫(xie)入性能(neng)全面超越 TimescaleDB 和 InfluxDB。在(zai)(zai)場(chang)景(jing)二中(zhong) TDengine 寫(xie)入性能(neng)是 TimescaleDB 的(de)(de)最(zui)大達(da)到 6.74 倍(bei)，在(zai)(zai)差距最(zui)小場(chang)景(jing)五中(zhong)，是 TimescaleDB 寫(xie)入性能(neng)的(de)(de) 1.52 倍(bei)。相對于(yu) InfluxDB，TDengine 在(zai)(zai)場(chang)景(jing)五中(zhong)寫(xie)入性能(neng)是 InfluxDB 的(de)(de) 10.63 倍(bei)，在(zai)(zai)差距最(zui)小的(de)(de)場(chang)景(jing)一中(zhong)也(ye)有 3.01 倍(bei)，具體的(de)(de)倍(bei)率關系請參見(jian)表(biao) 4。

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

3.2 寫入過程資源消耗對比

數據(ju)寫(xie)入(ru)速度并不能夠全面的(de)(de)反映三個系(xi)統在不同場(chang)景下數據(ju)寫(xie)入(ru)的(de)(de)整體(ti)表現。為此我們以 1,000,000 devices × 10  metrics （場(chang)景 四）為例，檢查(cha)數據(ju)寫(xie)入(ru)過程中的(de)(de)服(fu)務(wu)器(qi)和客戶端(duan)(duan)（包括客戶端(duan)(duan)與服(fu)務(wu)器(qi)）的(de)(de)整體(ti)負載狀(zhuang)況(kuang)，并以此來對比三個系(xi)統在寫(xie)入(ru)過程中服(fu)務(wu)器(qi)/客戶端(duan)(duan)節點的(de)(de)資源占用情況(kuang)，這里的(de)(de)資源占用主要包括服(fu)務(wu)器(qi)端(duan)(duan)的(de)(de) CPU 開(kai)銷/磁盤 IO 開(kai)銷和客戶端(duan)(duan) CPU 開(kai)銷。

3.2.1 服務端 CPU 開銷

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

3.2.2 磁盤 I/O 對比

圖(tu) 4 展示了 1,000,000 devices × 10 ; metrics （場景四(si)）數據(ju)寫入過(guo)程中服(fu)務器端磁(ci)盤(pan)寫入狀(zhuang)態。可以(yi)看到，結(jie)合著服(fu)務器端 CPU 開銷(xiao)表現(xian)，其 IO 動作與 CPU 呈(cheng)現(xian)同步(bu)的活躍狀(zhuang)態。

寫(xie)入相同(tong)規模的(de)數(shu)(shu)據集(ji)，TDengine 在(zai)寫(xie)入過程(cheng)中對(dui)于(yu)(yu)磁盤(pan)(pan)(pan)寫(xie)入能(neng)力的(de)占(zhan)用(yong)遠小于(yu)(yu) TimescaleDB 和 InfluxDB，寫(xie)入過程(cheng)只占(zhan)用(yong)了部(bu)分磁盤(pan)(pan)(pan)寫(xie)入能(neng)力（125MiB/Sec.  3000IOPS）。從圖(tu)上能(neng)看到，數(shu)(shu)據寫(xie)入過程(cheng)中磁盤(pan)(pan)(pan)的(de) IO 瓶頸是確(que)實(shi)存(cun)在(zai)的(de)。InfluxDB 長時間消耗完全部(bu)的(de)磁盤(pan)(pan)(pan)寫(xie)入能(neng)力，TimescaleDB 寫(xie)入過程(cheng)對(dui)于(yu)(yu)寫(xie)入的(de)消耗相對(dui) InfluxDB 來說要更(geng)具優勢(shi)，但(dan)是仍然(ran)遠超過了 TDengine 對(dui)磁盤(pan)(pan)(pan)寫(xie)入能(neng)力的(de)需求。

3.2.3 客戶端 CPU 開銷

從圖(tu) 5 可以看(kan)到，客(ke)(ke)戶(hu)(hu)端(duan)(duan)上 TDengine 對 CPU 的(de)(de)需求大于(yu) TimescaleDB 和 InfluxDB， 而 InfluxDB 在(zai)(zai)整(zheng)個寫入過(guo)程中，客(ke)(ke)戶(hu)(hu)端(duan)(duan)負(fu)載整(zheng)體(ti)上來(lai)說，三個系(xi)統中計(ji)算資源占用最(zui)低，對客(ke)(ke)戶(hu)(hu)端(duan)(duan)壓(ya)力(li)最(zui)小(xiao)，其(qi)寫入的(de)(de)壓(ya)力(li)基本上完全集(ji)中在(zai)(zai)服(fu)務(wu)(wu)端(duan)(duan)。這種模(mo)式(shi)很容易導致(zhi)服(fu)務(wu)(wu)端(duan)(duan)成為(wei)瓶頸，TimescaleDB 相對于(yu) InfluxDB 而言，對于(yu)客(ke)(ke)戶(hu)(hu)端(duan)(duan)壓(ya)力(li)更大，CPU 峰(feng)值達到 17% 左右。TDengine 在(zai)(zai)客(ke)(ke)戶(hu)(hu)端(duan)(duan)的(de)(de)開(kai)(kai)銷(xiao)最(zui)大，峰(feng)值瞬間(jian)(jian)達到了 56%，然后快速回落(luo)。TDengine 在(zai)(zai)客(ke)(ke)戶(hu)(hu)端(duan)(duan)的(de)(de)開(kai)(kai)銷(xiao)相比于(yu) TimescaleDB 多了1倍。綜合服(fu)務(wu)(wu)器(qi)與客(ke)(ke)戶(hu)(hu)端(duan)(duan)的(de)(de)資源開(kai)(kai)銷(xiao)來(lai)看(kan)，TDengine 寫入持(chi)續時間(jian)(jian)更短，在(zai)(zai)系(xi)統整(zheng)體(ti) CPU 開(kai)(kai)銷(xiao)上 TDengine 仍然具(ju)有相當大的(de)(de)優勢。

3.3 寫入性能對比總結

在(zai)(zai)全部(bu)的(de)場景中(zhong)(zhong)，寫(xie)入性(xing)能超過(guo)TimescaleDB 和 InfluxDB。在(zai)(zai)整個寫(xie)入過(guo)程中(zhong)(zhong)，TDengine 在(zai)(zai)提供了更高的(de)寫(xie)入能力(li)的(de)前提下(xia)，不論是服務器(qi)的(de)CPU 還是 IO，TDengine 均遠優于 TimescaleDB 和 InfluxDB。對(dui)于服務器(qi)的(de)磁盤IO開銷遠小于 TimescaleDB 和  InfluxDB。即使(shi)加(jia)上客戶端的(de)開銷統計(ji)，TDengine 在(zai)(zai)寫(xie)入開銷上遠優于 TimescaleDB 和 InfluxDB。

3.4 磁盤空間占用

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

可以看(kan)到，TimescaleDB 在(zai)(zai)所有的場景(jing)(jing)(jing)下數(shu)據規模均顯著(zhu)地大于 InfluxDB 和(he)(he) TDengine，并且這種(zhong)差(cha)距(ju)隨(sui)著(zhu)數(shu)據規模增加快(kuai)速變大。TimescaleDB 在(zai)(zai)場景(jing)(jing)(jing)四和(he)(he)場景(jing)(jing)(jing)五(wu)中(zhong)(zhong)占(zhan)(zhan)用(yong)磁盤(pan)空(kong)間是 TDengine 的 25 倍。在(zai)(zai)前(qian)面三個場景(jing)(jing)(jing)中(zhong)(zhong)，InfluxDB 落盤(pan)后(hou)數(shu)據文件規模與 TDengine 非常接近（在(zai)(zai)場景(jing)(jing)(jing)二(er)中(zhong)(zhong)，TDengine 的數(shu)據落盤(pan)規模比 InfluxDB 大了(le) 1%）。但是在(zai)(zai)場景(jing)(jing)(jing)四/五(wu)兩個場景(jing)(jing)(jing)中(zhong)(zhong)，InfluxDB 落盤(pan)后(hou)文件占(zhan)(zhan)用(yong)的磁盤(pan)空(kong)間是 TDengine 的 4 倍以上。

3.5 性能基準評估擴展部分

為了更全面(mian)地(di)評估 TDengine 在默認參(can)(can)數(shu)(shu)下(xia)寫入性能(neng)，我(wo)們在下(xia)面(mian)的(de)性能(neng)評估中調整可能(neng)會(hui)影響(xiang)寫入性能(neng)的(de)多個(ge)參(can)(can)數(shu)(shu)，進(jin)行全面(mian)的(de)評估。

3.5.1 虛擬節點（vnodes）數量

我們(men)調整數(shu)據庫中虛擬節點(dian)數(shu)量(liang)（默認是(shi) 6）為6， 8， 12， 24，并(bing)衡(heng)量(liang)不(bu)同 vnode 數(shu)量(liang)情(qing)況(kuang)下 TDengine 寫(xie)入性能(neng)。

我(wo)們(men)看到，在(zai)設(she)(she)備數(shu)最小的(de)(de)(de)場景(jing)(jing)一(yi) ，隨著虛擬節(jie)點(dian)數(shu)的(de)(de)(de)增(zeng)加(jia)，寫入(ru)變化趨(qu)勢不明顯(xian)(xian)。在(zai)較(jiao)多的(de)(de)(de)設(she)(she)備的(de)(de)(de)場景(jing)(jing)（場景(jing)(jing)五）中(zhong)(zhong)，增(zeng)加(jia) vnodes 的(de)(de)(de)數(shu)量(liang)(liang) ，寫入(ru)性能(neng)獲(huo)(huo)得(de)了顯(xian)(xian)著的(de)(de)(de)提升。可見在(zai)不同(tong)規模(mo)的(de)(de)(de)場景(jing)(jing)中(zhong)(zhong)，可以通(tong)過調整(zheng)虛擬節(jie)點(dian)的(de)(de)(de)數(shu)量(liang)(liang)來獲(huo)(huo)得(de)更好的(de)(de)(de)寫入(ru)性能(neng)。在(zai)大規模(mo)的(de)(de)(de)場景(jing)(jing)中(zhong)(zhong)，增(zeng)加(jia) vnodes 的(de)(de)(de)數(shu)量(liang)(liang)可以獲(huo)(huo)得(de)顯(xian)(xian)著的(de)(de)(de)性能(neng)提升。

3.5.2 fsync 對寫入性能的影響

數(shu)據(ju)庫的(de) fsync 參數(shu)控制寫(xie)入(ru)(ru)到(dao)預寫(xie)日(ri)志（write ahead log, WAL）文件中的(de)數(shu)據(ju)調用 fsync 的(de)頻率， 以確保(bao)數(shu)據(ju)可(ke)靠落盤。調用 fsync 會消耗較多(duo)的(de) IO 資源，并會對寫(xie)入(ru)(ru)過程帶來一(yi)定的(de)影響。從下(xia)表看到(dao)，fsync 的(de)配置對 TDengine 寫(xie)入(ru)(ru)性能影響很(hen)小。

在前面(mian)的四個(ge)場景中我(wo)們看到(dao)在 fsync 配置為(wei)實時(shi)同步刷入(ru)(ru)磁盤（fsync 為(wei) 0）的時(shi)候，寫(xie)(xie)入(ru)(ru)性(xing)能并沒(mei)有出現顯(xian)著的降(jiang)低(di)，是由于寫(xie)(xie)入(ru)(ru)過程采用了(le)大批(pi)量(liang)的寫(xie)(xie)入(ru)(ru)模式，降(jiang)低(di)了(le)每(mei)次刷入(ru)(ru)磁盤的次數(shu)需(xu)求，所以對性(xing)能影響(xiang)并不明顯(xian)，如果降(jiang)低(di)每(mei)批(pi)次寫(xie)(xie)入(ru)(ru)的數(shu)據量(liang)，應該能看到(dao)寫(xie)(xie)入(ru)(ru)性(xing)能降(jiang)低(di)，因(yin)此(ci) ，增(zeng)加每(mei)批(pi)次寫(xie)(xie)入(ru)(ru)數(shu)據量(liang)，可以有效(xiao)緩解 fsync 配置寫(xie)(xie)入(ru)(ru)的影響(xiang)。

3.5.3 設備記錄數量

TDengine 為一(yi)(yi)個(ge)設備一(yi)(yi)張表(biao)(biao)的(de)(de)(de)(de)數(shu)(shu)據(ju)(ju)模型(xing)，需要在數(shu)(shu)據(ju)(ju)寫(xie)(xie)入(ru)時(shi)(shi)創建(jian)表(biao)(biao)，建(jian)表(biao)(biao)操(cao)作對每個(ge)設備只執(zhi)行(xing)一(yi)(yi)次，但這使(shi)得 TDengine 在數(shu)(shu)據(ju)(ju)寫(xie)(xie)入(ru)的(de)(de)(de)(de)準備階(jie)段(duan)時(shi)(shi)間(jian)(jian)耗時(shi)(shi)較(jiao)多(duo)(duo)。當(dang)單(dan)個(ge)表(biao)(biao)中數(shu)(shu)據(ju)(ju)量增(zeng)加(jia)以后 ，數(shu)(shu)據(ju)(ju)準備（建(jian)表(biao)(biao)）的(de)(de)(de)(de)開(kai)銷(xiao)被分攤(tan)到更(geng)(geng)多(duo)(duo)的(de)(de)(de)(de)數(shu)(shu)據(ju)(ju)寫(xie)(xie)入(ru)的(de)(de)(de)(de)整(zheng)(zheng)體(ti)開(kai)銷(xiao)中，所(suo)以應該(gai)有(you)更(geng)(geng)好的(de)(de)(de)(de)數(shu)(shu)據(ju)(ju)寫(xie)(xie)入(ru)性能。以場(chang)景四（1,000,000 devices × 10  metrics）為例(li)，單(dan)個(ge)設備的(de)(de)(de)(de)數(shu)(shu)據(ju)(ju)量僅有(you) 18 條。當(dang)我們調(diao)整(zheng)(zheng)參數(shu)(shu)，將單(dan)個(ge)設備記錄數(shu)(shu)據(ju)(ju)增(zeng)加(jia)到 36 、72 、144 條時(shi)(shi)，整(zheng)(zheng)體(ti)寫(xie)(xie)入(ru)時(shi)(shi)間(jian)(jian)更(geng)(geng)長(chang)，因(yin)此表(biao)(biao)現出來就是(shi)建(jian)表(biao)(biao)開(kai)銷(xiao)被分攤(tan)到更(geng)(geng)多(duo)(duo)的(de)(de)(de)(de)數(shu)(shu)據(ju)(ju)寫(xie)(xie)入(ru)過程中，建(jian)表(biao)(biao)的(de)(de)(de)(de)開(kai)銷(xiao)相對于數(shu)(shu)據(ju)(ju)寫(xie)(xie)入(ru)的(de)(de)(de)(de)耗時(shi)(shi)占比越來越小，相應的(de)(de)(de)(de)整(zheng)(zheng)體(ti)寫(xie)(xie)入(ru)速(su)度也越來越快(kuai)。因(yin)此可以看到，TDengine 表(biao)(biao)現出了更(geng)(geng)加(jia)明顯的(de)(de)(de)(de)寫(xie)(xie)入(ru)優勢。

我們調整 vnodes 數(shu)(shu)量配置(zhi)，同時測試兩(liang)個(ge)不同 vnodes 數(shu)(shu)量情況下(xia)的(de)(de)(de)寫入(ru)(ru)(ru)性能(neng)(neng)指標。如圖 7 所示，隨著表中記錄數(shu)(shu)的(de)(de)(de)增加(jia)(jia)，單(dan)表記錄增加(jia)(jia)到(dao)(dao)72 的(de)(de)(de)時候(hou)，TDengine 設置(zhi)為(wei) 6 vnodes 的(de)(de)(de)寫入(ru)(ru)(ru)性能(neng)(neng)出現了(le)(le)下(xia)降，但是(shi)在 24 vnodes 的(de)(de)(de)情況下(xia)，寫入(ru)(ru)(ru)性能(neng)(neng)呈現出持(chi)續增加(jia)(jia)的(de)(de)(de)趨勢，并且(qie)全部場景下(xia)寫入(ru)(ru)(ru)性能(neng)(neng)均(jun)優于(yu) 6 vnodes 的(de)(de)(de)寫入(ru)(ru)(ru)性能(neng)(neng)。當設備(bei)記錄數(shu)(shu)達到(dao)(dao) 576 行(xing)（此時數(shu)(shu)據集規(gui)模1,000,000 × 576 = 5.76 億行(xing)數(shu)(shu)據記錄）的(de)(de)(de)時候(hou)，寫入(ru)(ru)(ru)性能(neng)(neng)達到(dao)(dao) 6,605,515 metrics/sec. 。不論是(shi)默認(ren)的(de)(de)(de) 6 vnodes，還是(shi) 24 vnodes，在單(dan)設備(bei)記錄達到(dao)(dao) 576 行(xing)的(de)(de)(de)時候(hou)，默認(ren) 6 vnodes 配置(zhi)下(xia) TDengine 寫入(ru)(ru)(ru)性能(neng)(neng)是(shi) TimescaleDB 和 InfluxDB 的(de)(de)(de) 7 倍多，當設置(zhi)為(wei) 24 vnodes 的(de)(de)(de)時候(hou)，性能(neng)(neng)更是(shi)達到(dao)(dao)其(qi) 均(jun)大幅領(ling)先 TimescaleDB 與 InfluxDB，最高達到(dao)(dao)了(le)(le) TimescaleDB 和 InfluxDB 的(de)(de)(de) 13 倍多。

TimescaleDB 寫(xie)入性(xing)能在單表記錄數(shu)(shu)量大于 72 行的時候就出(chu)現了下降趨(qu)勢，在單表記錄數(shu)(shu) 144 行以后出(chu)現了快速衰(shuai)減(jian)。InfluxDB 在單設備記錄增加過程中，寫(xie)入性(xing)能有(you)衰(shuai)減(jian)，但衰(shuai)減(jian)趨(qu)勢非常緩慢。

3.5.4 總結

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

四、查詢性能對比

在查詢性能評估部分，我們使用場景一（只包含 4 天數據，這個修改與[7]中要求一致）和場景二作為基準數據集，具體基礎數據集的特點，請參加本文前面 1.2 章節。在查詢性能評估之前，對于 TimescaleDB, 我們采用[7]中(zhong)推薦配置(zhi)，設置(zhi)為(wei) 8 個 Chunk ，以確保(bao)其(qi)充分發揮(hui)查(cha)詢(xun)性能。對于 InfluxDB，我(wo)們開啟(qi) InfluxDB  的 TSI (time series index)。在(zai)整(zheng)個查(cha)詢(xun)對比中(zhong)，TDengine 數(shu)(shu)據(ju)庫(ku)的虛擬節點(dian)數(shu)(shu)量（vnodes）保(bao)持為(wei)默認的 6 個，其(qi)他的數(shu)(shu)據(ju)庫(ku)參數(shu)(shu)配置(zhi)為(wei)默認值。

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

由于部分類型（分類標準參見[7] ）單次查(cha)(cha)詢(xun)響應(ying)時間(jian)非常短，為了(le)更加準確地測量(liang)(liang)每個(ge)查(cha)(cha)詢(xun)場景的(de)(de)較為穩定的(de)(de)響應(ying)時間(jian)，我(wo)(wo)們(men)將單個(ge)查(cha)(cha)詢(xun)運行次數(shu)(shu)提升到 5,000 次，然后使用  TSBS 自(zi)動統(tong)計并(bing)輸(shu)出(chu)結果(guo)，最后結果(guo)是(shi) 5,000 次查(cha)(cha)詢(xun)的(de)(de)算數(shu)(shu)平均值，使用并(bing)發客戶端 Workers 數(shu)(shu)量(liang)(liang)為 8。首先我(wo)(wo)們(men)提供場景二 （4,000 設(she)備）的(de)(de)查(cha)(cha)詢(xun)性(xing)能(neng)對比結果(guo)。

下面我(wo)們對(dui)每(mei)個查詢結(jie)果(guo)做一定的分析說(shuo)明(ming)：

由于 Simple Rollups 的(de)整體查(cha)(cha)詢響應(ying)(ying)時(shi)間(jian)非(fei)常短，制約查(cha)(cha)詢響應(ying)(ying)時(shi)間(jian)主體因素并不(bu)是(shi)查(cha)(cha)詢涉(she)及的(de)數據規(gui)模，即這種類(lei)型查(cha)(cha)詢的(de)瓶頸(jing)并不(bu)是(shi)數據規(gui)模。但(dan)是(shi) TDengine 仍(reng)然在所有類(lei)型的(de)查(cha)(cha)詢響應(ying)(ying)時(shi)間(jian)上優于 InfluxDB 和 TimescaleDB，具(ju)體的(de)數值比較(jiao)請參見表(biao) 7 中(zhong)的(de)詳細數據表(biao)格(ge)。

在  Aggregates 類型的(de)查詢中，我們(men)看到 TDengine 查詢性能相比(bi)于 TimescaleDB 和 InfluxDB 有比(bi)較大的(de)優(you)勢，TDengine 在 cpu-max-all-8 查詢性能是(shi) InfluxDB 的(de) 7 倍(bei)，是(shi) TimescaleDB 的(de) 6 倍(bei)。

在 Double-rollups 類型(xing)查(cha)詢中， TDengine 展現(xian)出巨(ju)大(da)的性能優勢，其(qi)查(cha)詢響應時間來度量，double-groupby-5 和(he) double-groupby-all 的查(cha)詢性能是(shi) TimescaleDB 的 24 倍(bei)，在 double-groupby-5 查(cha)詢上是(shi) InfluxDB 的 26 倍(bei) 和(he) double-groupby-all 是(shi)其(qi) 34 倍(bei)。

如圖 8(d) 所示 threshold 類型(xing)(xing)的(de)(de)查(cha)詢(xun)，TDengine 的(de)(de)查(cha)詢(xun)響(xiang)應時間均顯著低于(yu) TimescaleDB 和 InfluxDB。在 high-cpu-all 類型(xing)(xing)的(de)(de)查(cha)詢(xun)上，TDengine 的(de)(de)性能是 InfluxDB 的(de)(de) 15 倍，是 TimescaleDB 的(de)(de) 1.23 倍。

對(dui)于(yu) Complex-queries 類型(xing)的(de)(de)(de)(de)(de)查(cha)(cha)詢(xun)(xun)(xun)，TDengine 兩個查(cha)(cha)詢(xun)(xun)(xun)均大幅領先(xian) TimescaleDB 和(he) InfluxDB。在lastpoint 查(cha)(cha)詢(xun)(xun)(xun)中，查(cha)(cha)詢(xun)(xun)(xun)性能是(shi) TimescaleDB 的(de)(de)(de)(de)(de) 5 倍(bei)(bei)(bei)， InfluxDB 的(de)(de)(de)(de)(de) 21倍(bei)(bei)(bei)。在 groupby-orderby-limit 場(chang)景中查(cha)(cha)詢(xun)(xun)(xun)性能是(shi)TimescaleDB的(de)(de)(de)(de)(de) 8 倍(bei)(bei)(bei)，是(shi) InfluxDB 的(de)(de)(de)(de)(de) 15 倍(bei)(bei)(bei)。在時間窗口聚合的(de)(de)(de)(de)(de)查(cha)(cha)詢(xun)(xun)(xun)過程中，TimescaleDB 針對(dui)規模較大的(de)(de)(de)(de)(de)數據集(ji)其查(cha)(cha)詢(xun)(xun)(xun)性能不佳(jia)（double rollups類型(xing)查(cha)(cha)詢(xun)(xun)(xun)），對(dui)于(yu) groupby-orderby-limit 的(de)(de)(de)(de)(de)查(cha)(cha)詢(xun)(xun)(xun)，其性能上(shang)表(biao)現同(tong)樣不是(shi)太好(hao)。

4.2 資源開銷對比

由于部分查(cha)(cha)詢(xun)(xun)(xun)持續時(shi)間特別短，并(bing)不(bu)能完(wan)整(zheng)地看到查(cha)(cha)詢(xun)(xun)(xun)過程中(zhong)服務器(qi)的(de)(de) IO/CPU/網絡(luo)情(qing)況。我們針對(dui)場景二以(yi) Double rollups 類別中(zhong)的(de)(de) double-groupby-5 查(cha)(cha)詢(xun)(xun)(xun)為例(li)，執行(xing) 1,000 次查(cha)(cha)詢(xun)(xun)(xun)，記錄整(zheng)個過程中(zhong)三(san)個軟(ruan)件(jian)系(xi)統在查(cha)(cha)詢(xun)(xun)(xun)執行(xing)的(de)(de)整(zheng)個過程中(zhong)服務器(qi) CPU、內存、網絡(luo)的(de)(de)開(kai)銷進行(xing)對(dui)比。

如(ru)圖 9 可以(yi)看(kan)(kan)到，三個(ge)系(xi)統在整個(ge)查(cha)詢過程(cheng)中 CPU 的(de)(de)(de)使用(yong)均較為平穩。TDengine 在查(cha)詢過程(cheng)中整體(ti) CPU 占(zhan)用(yong)約 80%, 在三個(ge)系(xi)統中使用(yong)的(de)(de)(de) CPU 資源(yuan)最高，TimescaleDB 在查(cha)詢過程(cheng)中瞬(shun)時(shi)(shi) CPU 占(zhan)用(yong)次之，約 38%。InfluxDB 的(de)(de)(de)穩定的(de)(de)(de) CPU 占(zhan)用(yong)的(de)(de)(de)最小(xiao)，約 27 %（但(dan)是有較多(duo)(duo)的(de)(de)(de)瞬(shun)時(shi)(shi)沖高）。整體(ti) CPU 開銷(xiao)上來(lai)看(kan)(kan)，雖(sui)(sui)然(ran)(ran) InfluxDB 瞬(shun)時(shi)(shi) CPU 開銷(xiao)大部(bu)分是最低的(de)(de)(de)，但(dan)是其(qi)完(wan)成查(cha)詢持續時(shi)(shi)間(jian)最長，所以(yi)整體(ti) CPU 資源(yuan)消耗最多(duo)(duo)。由(you)于 TDengine 完(wan)成全部(bu)查(cha)詢的(de)(de)(de)時(shi)(shi)間(jian)僅(jin) TimescaleDB 或 InfluxDB 的(de)(de)(de)  1/20，雖(sui)(sui)然(ran)(ran) CPU 穩定值是 TimescaleDB 與 InfluxDB 的(de)(de)(de) 2 倍多(duo)(duo)，整體(ti)的(de)(de)(de) CPU 計算(suan)時(shi)(shi)間(jian)消耗只有其(qi) 1/10 。

服務器內存狀況

如圖(tu) 10 所(suo)示，在(zai)(zai)整(zheng)個(ge)(ge)查詢過程中(zhong)，TDengine 內(nei)存維持了(le)一個(ge)(ge)相對平(ping)穩的(de)狀(zhuang)(zhuang)態。TimescaleDB 在(zai)(zai)整(zheng)個(ge)(ge)查詢過程中(zhong)內(nei)存呈(cheng)現增(zeng)加的(de)狀(zhuang)(zhuang)態，查詢完成后即恢復到初始狀(zhuang)(zhuang)態，InfluxDB 內(nei)存占用呈(cheng)現相對穩定的(de)狀(zhuang)(zhuang)態。

服務器網絡帶寬

圖(tu) 11 展示了(le)查(cha)詢(xun)過程中(zhong)服務(wu)器端上(shang)行和下行的(de)網絡帶寬(kuan)(kuan)情況(kuang)(kuang)，負載狀(zhuang)況(kuang)(kuang)基本(ben)上(shang)和 CPU 狀(zhuang)況(kuang)(kuang)相似。TDengine 網絡帶寬(kuan)(kuan)開(kai)銷最高，因為在最短的(de)時(shi)間內就(jiu)完成(cheng)了(le)全部查(cha)詢(xun)，需要(yao)將(jiang)查(cha)詢(xun)結果返回(hui)給(gei)客戶(hu)端。InfluxDB 網絡帶寬(kuan)(kuan)開(kai)銷最低，TimescaleDB 介于兩者之間。

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

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

如(ru)表 8 所(suo)示，在(zai)更小規(gui)模的數據集（100設備）上的查詢(xun)對比可以看到，整體上 TDengine 同樣(yang)展現出極好的性能(neng)，在(zai)全(quan)部的查詢(xun)語(yu)句中全(quan)面優于 TimescaleDB  和 InfluxDB，部分查詢(xun)性能(neng)超過(guo)(guo) TimescaleDB 28 倍(bei)，超過(guo)(guo) InfluxDB 37 倍(bei)。

五、總結

基于 TSBS 性能基準測評(ping)框架(jia)的(de)結果可以看到，得益于 TDengine 契合(he)時(shi)序數據特點(dian)的(de)架(jia)構設計(ji)，TDengine 在數據寫入(ru)(ru)(ru)和(he)查詢(xun)性能上相(xiang)對(dui)(dui)于 TimescaleDB 和(he) InfluxDB，不論(lun)是(shi)(shi)數據寫入(ru)(ru)(ru)的(de)性能，寫入(ru)(ru)(ru)過程(cheng)中(zhong)對(dui)(dui)于資源的(de)消耗，查詢(xun)的(de)響應延遲還是(shi)(shi)查詢(xun)過程(cheng)中(zhong)資源的(de)開銷，均(jun)全面優于 TimescaleDB 和(he) InfluxDB。本(ben)次對(dui)(dui)比測評(ping)只將(jiang) TDengine 橫向對(dui)(dui)比了(le)兩個較為流(liu)行(xing)的(de)時(shi)序數據庫軟(ruan)件(jian)，后續我們進行(xing)更加深入(ru)(ru)(ru)全面的(de)對(dui)(dui)比測評(ping)，涉及更多的(de)數據庫產品，更廣泛的(de)數據集(ji)，并會陸續發(fa)布(bu)相(xiang)關的(de)結果。

《基于 TSBS 標準數據集時序數據庫 TimescaleDB、InfluxDB 與 TDengine 在 IoT 場景性能對比測試報告》已發布，點擊這里獲取。

六、參考文獻

[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.