一、背景介紹

1.1 性能基準(zhǔn)對比框架

Time Series Benchmark Suite (TSBS) 是 Timescale ^[1]開源，集多種應(yīng)用場景下時序數(shù)據(jù)生成、數(shù)據(jù)寫入、查詢處理、自動化結(jié)果匯總統(tǒng)計等功能于一體的時序數(shù)據(jù)（Time Series Data）性能基準(zhǔn)測評平臺。TSBS 提供 IoT、DevOps 兩個典型應(yīng)用場景，具有簡單、易用、擴展性優(yōu)異等特點。由于 TSBS 是一個開源的平臺，因此得到了 InfluxDB、TimescaleDB、QuestDB、ClickHouse 等眾多數(shù)據(jù)庫系統(tǒng)的廣泛支持，并被多家數(shù)據(jù)庫廠商使用，作為基準(zhǔn)性能測評平臺。

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

為了客觀、準(zhǔn)確、可驗證地評估 TDengine Ver3.0 的性能表現(xiàn)，我們也選用了 TSBS 框架作為性能基準(zhǔn)對比平臺，作為橫向?qū)Ρ鹊漠a(chǎn)品，我們選擇了 TimescaleDB 和  InfluxDB 進行對比。請參見 GitHub – timescale/tsbs ^[9]獲得關(guān)于該框架的詳細(xì)介紹和相關(guān)信息。

1.2 測試場景介紹

我們使用了 DevOps 場景中的 cpu-only 作為基礎(chǔ)數(shù)據(jù)集。TSBS 框架中 cpu-only 場景模擬對服務(wù)器 CPU 監(jiān)控生成的時序數(shù)據(jù)，針對每個設(shè)備（ CPU）記錄其 10 個測量值，1個（納秒分辨率）時間戳，10 個標(biāo)簽值。具體的內(nèi)容和示例數(shù)據(jù)見下表 1，生成的數(shù)據(jù)每 10 秒一條記錄。數(shù)據(jù)模式（schema）見下圖 1。其中每條記錄包含了 10 個標(biāo)簽（tags）和 1 個時間戳 及 10 個測量值（metric）。

在整個基準(zhǔn)性能評估中，涉及以下五個場景，每個場景的具體數(shù)據(jù)規(guī)模和特點見下表 1：

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

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

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

TDengine 一個重要的創(chuàng)新是其獨特的數(shù)據(jù)模型——為每個設(shè)備創(chuàng)建獨立的數(shù)據(jù)表（子表），并通過超級表（Super Table）在邏輯上和語義上對同一采集類型的設(shè)備進行統(tǒng)一管理。針對 DevOps 場景的數(shù)據(jù)內(nèi)容，我們?yōu)槊總€設(shè)備 （這里是 CPU）創(chuàng)建了一個表，用以存儲該表的時序數(shù)據(jù)。在 1.2 章節(jié)數(shù)據(jù)記錄中，我們看到 hostname 可以作為每個設(shè)備的標(biāo)識 Id , 因此我們在 TDengine 中使用 hostname 作為子表的名稱。我們使用如下的語句創(chuàng)建名為 CPU 的超級表，包含 10 個測量值和 10 個標(biāo)簽。

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))

然后 ，我們使用如下語句創(chuàng)建名為 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')

上述語句創(chuàng)建了一個子表。由此可知，對于 100 個設(shè)備（CPU）的場景 一，我們將會建立 100 個子表。對于 4000  個設(shè)備的場景二，系統(tǒng)中將會建立 4000 個子表用以存儲各自對應(yīng)的數(shù)據(jù) 。

1.4 軟件版本和配置

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

1.4.1 TDengine

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

gitinfo: c90e2aa791ceb62542f6ecffe7bd715165f181e8

在服務(wù)器上編譯安裝運行。

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

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

numOfVnodeFetchThreads           4

queryRspPolicy                   1

compressMsgSize             128000

SIMD-builtins                    1

第一個參數(shù) numOfVnodeFetchThreads 設(shè)置 Vnode 的Fetch 線程數(shù)量為 4 個， 第二個參數(shù) queryRspPolicy 打開  query response 快速返回機制， 第三個參數(shù) compressMsgSize 讓TDengine 在傳輸層上大于 128,000 bytes的消息自動進行壓縮，第四個參數(shù)是如果 CPU 支持，啟用內(nèi)置的 FMA/AVX/AVX2 硬件加速。

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

1.4.2 TimescaleDB 

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

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

1.4.3 InfluxDB

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

我們采用對比報告[7]中推薦的方式配置 InfluxDB，將緩沖區(qū)配置為 80G，以便 1000w 設(shè)備寫入時能夠順利進行，同時開啟 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 硬件準(zhǔn)備

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

2.2 服務(wù)器環(huán)境準(zhǔn)備

為運行測試腳本，服務(wù)器OS需要是ubuntu20以上的系統(tǒng)。AWS EC2的服務(wù)器系統(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. 基礎(chǔ)環(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 獲取測試腳本

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

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

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

2. 修改配置文件 test.ini 中服務(wù)端和客戶端的 IP 地址（這里配置 AWS 的私網(wǎng)地址即可）和 hostname，如果服務(wù)器未配置免密，還需要配置服務(wù)器端的 root 密碼。

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 一鍵執(zhí)行對比測試

執(zhí)行以下命令：

nohup bash tsdbComparison.sh > test.log &

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

三、寫入性能對比

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

可以看到在全部五個場景中，TDengine 的寫入性能全面超越 TimescaleDB 和 InfluxDB。在場景二中 TDengine 寫入性能是 TimescaleDB 的最大達到 6.74 倍，在差距最小場景五中，是 TimescaleDB 寫入性能的 1.52 倍。相對于 InfluxDB，TDengine 在場景五中寫入性能是 InfluxDB 的 10.63 倍，在差距最小的場景一中也有 3.01 倍，具體的倍率關(guān)系請參見表 4。

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

3.2 寫入過程資源消耗對比

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

3.2.1 服務(wù)端 CPU 開銷

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

3.2.2 磁盤 I/O 對比

圖 4 展示了 1,000,000 devices × 10  metrics （場景四）數(shù)據(jù)寫入過程中服務(wù)器端磁盤寫入狀態(tài)?？梢钥吹剑Y(jié)合著服務(wù)器端 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 在整個寫入過程中，客戶端負(fù)載整體上來說，三個系統(tǒng)中計算資源占用最低，對客戶端壓力最小，其寫入的壓力基本上完全集中在服務(wù)端。這種模式很容易導(dǎo)致服務(wù)端成為瓶頸，TimescaleDB 相對于 InfluxDB 而言，對于客戶端壓力更大，CPU 峰值達到 17% 左右。TDengine 在客戶端的開銷最大，峰值瞬間達到了 56%，然后快速回落。TDengine 在客戶端的開銷相比于 TimescaleDB 多了1倍。綜合服務(wù)器與客戶端的資源開銷來看，TDengine 寫入持續(xù)時間更短，在系統(tǒng)整體 CPU 開銷上 TDengine 仍然具有相當(dāng)大的優(yōu)勢。

3.3 寫入性能對比總結(jié)

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

3.4 磁盤空間占用

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

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

3.5 性能基準(zhǔn)評估擴展部分

為了更全面地評估 TDengine 在默認(rèn)參數(shù)下寫入性能，我們在下面的性能評估中調(diào)整可能會影響寫入性能的多個參數(shù)，進行全面的評估。

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

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

我們看到，在設(shè)備數(shù)最小的場景一 ，隨著虛擬節(jié)點數(shù)的增加，寫入變化趨勢不明顯。在較多的設(shè)備的場景（場景五）中，增加 vnodes 的數(shù)量 ，寫入性能獲得了顯著的提升?？梢娫诓煌?guī)模的場景中，可以通過調(diào)整虛擬節(jié)點的數(shù)量來獲得更好的寫入性能。在大規(guī)模的場景中，增加 vnodes 的數(shù)量可以獲得顯著的性能提升。

3.5.2 fsync 對寫入性能的影響

數(shù)據(jù)庫的 fsync 參數(shù)控制寫入到預(yù)寫日志（write ahead log, WAL）文件中的數(shù)據(jù)調(diào)用 fsync 的頻率， 以確保數(shù)據(jù)可靠落盤。調(diào)用 fsync 會消耗較多的 IO 資源，并會對寫入過程帶來一定的影響。從下表看到，fsync 的配置對 TDengine 寫入性能影響很小。

在前面的四個場景中我們看到在 fsync 配置為實時同步刷入磁盤（fsync 為 0）的時候，寫入性能并沒有出現(xiàn)顯著的降低，是由于寫入過程采用了大批量的寫入模式，降低了每次刷入磁盤的次數(shù)需求，所以對性能影響并不明顯，如果降低每批次寫入的數(shù)據(jù)量，應(yīng)該能看到寫入性能降低，因此 ，增加每批次寫入數(shù)據(jù)量，可以有效緩解 fsync 配置寫入的影響。

3.5.3 設(shè)備記錄數(shù)量

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

我們調(diào)整 vnodes 數(shù)量配置，同時測試兩個不同 vnodes 數(shù)量情況下的寫入性能指標(biāo)。如圖 7 所示，隨著表中記錄數(shù)的增加，單表記錄增加到72 的時候，TDengine 設(shè)置為 6 vnodes 的寫入性能出現(xiàn)了下降，但是在 24 vnodes 的情況下，寫入性能呈現(xiàn)出持續(xù)增加的趨勢，并且全部場景下寫入性能均優(yōu)于 6 vnodes 的寫入性能。當(dāng)設(shè)備記錄數(shù)達到 576 行（此時數(shù)據(jù)集規(guī)模1,000,000 × 576 = 5.76 億行數(shù)據(jù)記錄）的時候，寫入性能達到 6,605,515 metrics/sec. 。不論是默認(rèn)的 6 vnodes，還是 24 vnodes，在單設(shè)備記錄達到 576 行的時候，默認(rèn) 6 vnodes 配置下 TDengine 寫入性能是 TimescaleDB 和 InfluxDB 的 7 倍多，當(dāng)設(shè)置為 24 vnodes 的時候，性能更是達到其 均大幅領(lǐng)先 TimescaleDB 與 InfluxDB，最高達到了 TimescaleDB 和 InfluxDB 的 13 倍多。

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

3.5.4 總結(jié)

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

四、查詢性能對比

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

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

由于部分類型（分類標(biāo)準(zhǔn)參見[7] ）單次查詢響應(yīng)時間非常短，為了更加準(zhǔn)確地測量每個查詢場景的較為穩(wěn)定的響應(yīng)時間，我們將單個查詢運行次數(shù)提升到 5,000 次，然后使用  TSBS 自動統(tǒng)計并輸出結(jié)果，最后結(jié)果是 5,000 次查詢的算數(shù)平均值，使用并發(fā)客戶端 Workers 數(shù)量為 8。首先我們提供場景二 （4,000 設(shè)備）的查詢性能對比結(jié)果。

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

由于 Simple Rollups 的整體查詢響應(yīng)時間非常短，制約查詢響應(yīng)時間主體因素并不是查詢涉及的數(shù)據(jù)規(guī)模，即這種類型查詢的瓶頸并不是數(shù)據(jù)規(guī)模。但是 TDengine 仍然在所有類型的查詢響應(yīng)時間上優(yōu)于 InfluxDB 和 TimescaleDB，具體的數(shù)值比較請參見表 7 中的詳細(xì)數(shù)據(jù)表格。

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

在 Double-rollups 類型查詢中， TDengine 展現(xiàn)出巨大的性能優(yōu)勢，其查詢響應(yīng)時間來度量，double-groupby-5 和 double-groupby-all 的查詢性能是 TimescaleDB 的 24 倍，在 double-groupby-5 查詢上是 InfluxDB 的 26 倍 和 double-groupby-all 是其 34 倍。

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

對于 Complex-queries 類型的查詢，TDengine 兩個查詢均大幅領(lǐng)先 TimescaleDB 和 InfluxDB。在lastpoint 查詢中，查詢性能是 TimescaleDB 的 5 倍， InfluxDB 的 21倍。在 groupby-orderby-limit 場景中查詢性能是TimescaleDB的 8 倍，是 InfluxDB 的 15 倍。在時間窗口聚合的查詢過程中，TimescaleDB 針對規(guī)模較大的數(shù)據(jù)集其查詢性能不佳（double rollups類型查詢），對于 groupby-orderby-limit 的查詢，其性能上表現(xiàn)同樣不是太好。

4.2 資源開銷對比

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

如圖 9 可以看到，三個系統(tǒng)在整個查詢過程中 CPU 的使用均較為平穩(wěn)。TDengine 在查詢過程中整體 CPU 占用約 80%, 在三個系統(tǒng)中使用的 CPU 資源最高，TimescaleDB 在查詢過程中瞬時 CPU 占用次之，約 38%。InfluxDB 的穩(wěn)定的 CPU 占用的最小，約 27 %（但是有較多的瞬時沖高）。整體 CPU 開銷上來看，雖然 InfluxDB 瞬時 CPU 開銷大部分是最低的，但是其完成查詢持續(xù)時間最長，所以整體 CPU 資源消耗最多。由于 TDengine 完成全部查詢的時間僅 TimescaleDB 或 InfluxDB 的  1/20，雖然 CPU 穩(wěn)定值是 TimescaleDB 與 InfluxDB 的 2 倍多，整體的 CPU 計算時間消耗只有其 1/10 。

服務(wù)器內(nèi)存狀況

如圖 10 所示，在整個查詢過程中，TDengine 內(nèi)存維持了一個相對平穩(wěn)的狀態(tài)。TimescaleDB 在整個查詢過程中內(nèi)存呈現(xiàn)增加的狀態(tài)，查詢完成后即恢復(fù)到初始狀態(tài)，InfluxDB 內(nèi)存占用呈現(xiàn)相對穩(wěn)定的狀態(tài)。

服務(wù)器網(wǎng)絡(luò)帶寬

圖 11 展示了查詢過程中服務(wù)器端上行和下行的網(wǎng)絡(luò)帶寬情況，負(fù)載狀況基本上和 CPU 狀況相似。TDengine 網(wǎng)絡(luò)帶寬開銷最高，因為在最短的時間內(nèi)就完成了全部查詢，需要將查詢結(jié)果返回給客戶端。InfluxDB 網(wǎng)絡(luò)帶寬開銷最低，TimescaleDB 介于兩者之間。

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

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

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

五、總結(jié)

基于 TSBS 性能基準(zhǔn)測評框架的結(jié)果可以看到，得益于 TDengine 契合時序數(shù)據(jù)特點的架構(gòu)設(shè)計，TDengine 在數(shù)據(jù)寫入和查詢性能上相對于 TimescaleDB 和 InfluxDB，不論是數(shù)據(jù)寫入的性能，寫入過程中對于資源的消耗，查詢的響應(yīng)延遲還是查詢過程中資源的開銷，均全面優(yōu)于 TimescaleDB 和 InfluxDB。本次對比測評只將 TDengine 橫向?qū)Ρ攘藘蓚€較為流行的時序數(shù)據(jù)庫軟件，后續(xù)我們進行更加深入全面的對比測評，涉及更多的數(shù)據(jù)庫產(chǎn)品，更廣泛的數(shù)據(jù)集，并會陸續(xù)發(fā)布相關(guān)的結(jié)果。

《基于 TSBS 標(biāo)準(zhǔn)數(shù)據(jù)集時序數(shù)據(jù)庫 TimescaleDB、InfluxDB 與 TDengine 在 IoT 場景性能對比測試報告》已發(fā)布，點擊這里獲取。

六、參考文獻

[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