一、背景介紹

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

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

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

為了客觀、準(zhǔn)確、可驗(yàn)證地評(píng)估 TDengine Ver3.0 的性能表現(xiàn)，我們也選用了 TSBS 框架作為性能基準(zhǔn)對比平臺(tái)，作為橫向?qū)Ρ鹊漠a(chǎn)品，我們選擇了 TimescaleDB 和  InfluxDB 進(jìn)行對比。請參見 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í)序數(shù)據(jù)，針對每個(gè)設(shè)備（ CPU）記錄其 10 個(gè)測量值，1個(gè)（納秒分辨率）時(shí)間戳，10 個(gè)標(biāo)簽值。具體的內(nèi)容和示例數(shù)據(jù)見下表 1，生成的數(shù)據(jù)每 10 秒一條記錄。數(shù)據(jù)模式（schema）見下圖 1。其中每條記錄包含了 10 個(gè)標(biāo)簽（tags）和 1 個(gè)時(shí)間戳 及 10 個(gè)測量值（metric）。

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

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

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

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

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

1.4 軟件版本和配置

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

1.4.1 TDengine

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

gitinfo: c90e2aa791ceb62542f6ecffe7bd715165f181e8

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

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

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

numOfVnodeFetchThreads           4

queryRspPolicy                   1

compressMsgSize             128000

SIMD-builtins                    1

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

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

1.4.2 TimescaleDB 

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

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

1.4.3 InfluxDB

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

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

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

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

為運(yù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 (無需手動(dòng)安裝，測試腳本將自動(dòng)安裝） 
4. 編譯依賴：gcc , cmake, build-essential, git, libssl-dev (無需手動(dòng)安裝，測試腳本將自動(dòng)安裝）

但請做兩個(gè)配置：

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

2.3 獲取測試腳本

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

1. 在客戶端機(jī)器，進(jìn)入測試目錄拉取代碼，默認(rèn)進(jì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 &

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

三、寫入性能對比

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

可以看到在全部五個(gè)場景中，TDengine 的寫入性能全面超越 TimescaleDB 和 InfluxDB。在場景二中 TDengine 寫入性能是 TimescaleDB 的最大達(dá)到 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，這點(diǎn)上與對比報(bào)告[7]中的結(jié)論一致。

3.2 寫入過程資源消耗對比

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

3.2.1 服務(wù)端 CPU 開銷

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

3.2.2 磁盤 I/O 對比

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

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

3.2.3 客戶端 CPU 開銷

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

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

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

3.4 磁盤空間占用

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

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

3.5 性能基準(zhǔn)評(píng)估擴(kuò)展部分

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

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

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

我們看到，在設(shè)備數(shù)最小的場景一 ，隨著虛擬節(jié)點(diǎn)數(shù)的增加，寫入變化趨勢不明顯。在較多的設(shè)備的場景（場景五）中，增加 vnodes 的數(shù)量 ，寫入性能獲得了顯著的提升?？梢娫诓煌?guī)模的場景中，可以通過調(diào)整虛擬節(jié)點(diǎn)的數(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 會(huì)消耗較多的 IO 資源，并會(huì)對寫入過程帶來一定的影響。從下表看到，fsync 的配置對 TDengine 寫入性能影響很小。

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

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

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

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

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

3.5.4 總結(jié)

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

四、查詢性能對比

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

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

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

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

由于 Simple Rollups 的整體查詢響應(yīng)時(shí)間非常短，制約查詢響應(yīng)時(shí)間主體因素并不是查詢涉及的數(shù)據(jù)規(guī)模，即這種類型查詢的瓶頸并不是數(shù)據(jù)規(guī)模。但是 TDengine 仍然在所有類型的查詢響應(yīng)時(shí)間上優(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)時(shí)間來度量，double-groupby-5 和 double-groupby-all 的查詢性能是 TimescaleDB 的 24 倍，在 double-groupby-5 查詢上是 InfluxDB 的 26 倍 和 double-groupby-all 是其 34 倍。

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

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

4.2 資源開銷對比

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

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

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

如圖 10 所示，在整個(gè)查詢過程中，TDengine 內(nèi)存維持了一個(gè)相對平穩(wěn)的狀態(tài)。TimescaleDB 在整個(gè)查詢過程中內(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ò)帶寬開銷最高，因?yàn)樵谧疃痰臅r(shí)間內(nèi)就完成了全部查詢，需要將查詢結(jié)果返回給客戶端。InfluxDB 網(wǎng)絡(luò)帶寬開銷最低，TimescaleDB 介于兩者之間。

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

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

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

五、總結(jié)

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

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

六、參考文獻(xiàn)

[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