基于第三方基準性能測試平臺 TSBS（Time Series Benchmark Suite） 標準數據集，TDengine 團隊在 TSBS 的 IoT 場景中，預設了五種規模的卡車車隊基礎數據集，在相同的 AWS 云環境下對時序數據庫（Time Series Database） TDengine 3.0 和 TimescaleDB 2.10.1 進行了對比分(fen)析。本文將會從寫(xie)入、存儲、查詢及(ji)資源開銷等幾(ji)大(da)維度為(wei)大(da)家(jia)匯(hui)總分(fen)析測(ce)試結(jie)果(guo)。

為了讓(rang) TimescaleDB 獲得(de)較好的性能，確(que)保(bao)結果具有可(ke)比(bi)性，TimescaleDB 需要針對不同(tong)(tong)的場(chang)景(jing)設置(zhi)不同(tong)(tong)的 Chunk 參數，不同(tong)(tong)場(chang)景(jing)下參數的設置(zhi)如下表所示：

	場景一	場景二	場景三	場景四	場景五
設備數目	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

上述(shu)參(can)(can)數(shu)的(de)設置(zhi)，充分參(can)(can)考了(le)下方 TimescaleDB vs. InfluxDB 對(dui)比(bi)報告中推薦的(de)配置(zhi)參(can)(can)數(shu)設置(zhi)，以確保寫入性能指標的(de)最(zui)優(you)化。

TimescaleDB vs. InfluxDB 測(ce)試報告(gao)：

關于系統的配置詳情、如何一鍵復現測試結果及詳細的測試數據介紹等內容，大家可參考《一鍵獲取測試腳本，輕松驗證 TDengine 3.0 IoT 場景下 TSBS 測試報告》一文，本文便(bian)不再贅述。

寫入性能

總體而言，在預設的五種規模的卡車車隊場景中，TDengine 寫入性能均優于 TimescaleDB。相比 TimescaleDB，TDengine 寫入速度最領先的場景是其 3.3 倍（場景一），最少也是 1.04 倍（場景四），而且對于場景四，如果將每個采集點的記錄條數由 18 條增加到 576 條，且 vgroups=24 時，TDengine 寫入速度就達到了 TimescaleDB 的 7 倍。此外，TDengine 在(zai)寫(xie)入過程(cheng)中(zhong)消耗的(de) CPU 資源和(he)磁(ci)盤 IO 開銷也是最(zui)低的(de)。

不同場景下寫入性能對比

從上圖中我們可以看到，在全部五個場景中，TDengine 的寫入性能全面超越 TimescaleDB。在場景二中 TDengine 寫入性能最大達到 TimescaleDB 的 3.3 倍，在差(cha)距最小的場景五中(zhong)，也(ye)達到了(le) TimescaleDB 的 1.04 倍(bei)。

寫入過程資源消耗對比

僅憑數(shu)(shu)據(ju)(ju)寫(xie)(xie)入(ru)速(su)度，并不能全面(mian)地反映出三個系統(tong)在(zai)不同場景下數(shu)(shu)據(ju)(ju)寫(xie)(xie)入(ru)的(de)整(zheng)(zheng)體(ti)表現。為此(ci)我(wo)們以 1,000,000 devices × 10 metrics（場景四）為數(shu)(shu)據(ju)(ju)模板，檢查數(shu)(shu)據(ju)(ju)寫(xie)(xie)入(ru)過(guo)程中的(de)服(fu)務(wu)(wu)(wu)器(qi)和(he)客戶端（包括客戶端與(yu)服(fu)務(wu)(wu)(wu)器(qi)）的(de)整(zheng)(zheng)體(ti)負載狀況，并以此(ci)來對比兩大系統(tong)在(zai)寫(xie)(xie)入(ru)過(guo)程中服(fu)務(wu)(wu)(wu)器(qi)/客戶端節點的(de)資(zi)(zi)源(yuan)占用情況。這里(li)的(de)資(zi)(zi)源(yuan)占用主(zhu)要包括服(fu)務(wu)(wu)(wu)器(qi)端的(de) CPU 開(kai)(kai)銷(xiao)/磁盤 IO 開(kai)(kai)銷(xiao)和(he)客戶端 CPU 開(kai)(kai)銷(xiao)。

服務端 CPU 開銷

下圖展示了在(zai)場景四寫(xie)入(ru)(ru)(ru)過程中服(fu)務器端(duan) CPU 負載狀況。可以看到，兩大系(xi)統在(zai)返回給(gei)客戶端(duan)寫(xie)入(ru)(ru)(ru)完成(cheng)(cheng)消息(xi)以后，都(dou)還繼續(xu)使用服(fu)務器的(de)資源進行相(xiang)應(ying)的(de)處理(li)工(gong)作(zuo)。TimescaleDB 在(zai) 7x 秒時(shi)即反饋(kui)客戶端(duan)寫(xie)入(ru)(ru)(ru)完成(cheng)(cheng)，但(dan)是(shi)其(qi)服(fu)務器端(duan)仍然(ran)調用 CPU 資源進行了數(shu)據壓縮和整理(li)工(gong)作(zuo)，當然(ran)整個工(gong)作(zuo)帶(dai)來的(de) CPU 負載相(xiang)對而(er)言并不高(gao)，只有其(qi)峰值(zhi) CPU 開銷的(de)一半左右，但(dan)是(shi)其(qi)持續(xu)時(shi)間相(xiang)當長，接近凈寫(xie)入(ru)(ru)(ru)時(shi)間的(de) 4 倍。

兩個系統對比，TDengine 對服務器的 CPU 需求最小，峰值也僅使用了 17% 左右的服務器 CPU 資源。由此可見，TDengine 獨特的數(shu)據(ju)模(mo)型不(bu)僅體(ti)現在時序數(shu)據(ju)寫入性能上，同樣也展現在整體(ti)的資(zi)源開銷上。

磁盤 I/O 對比

下(xia)圖(tu)展示了 1,000,000 devices × 10 metrics （場景四）數(shu)據寫(xie)入過程中服(fu)務器端磁(ci)盤寫(xie)入狀態。可以看到，結合著服(fu)務器端 CPU 開銷表現，IO 動作與 CPU 呈現同步(bu)的活躍狀態。

在寫入相同規模數據集情況下，TDengine 在寫入過程中對于磁盤寫入能力的占用遠小于 TimescaleDB，只占用了部分磁盤寫入能力（125MiB/Sec. 3000IOPS）。從上圖能看到，數據寫入過程中磁盤的 IO 瓶頸是確實存在的，TimescaleDB 在寫入過程中對磁盤寫入能力的需求遠超 TDengine。

客戶端 CPU 開銷

從上圖可以看到，客戶端上 TDengine 對 CPU 的需求大于 TimescaleDB。TimescaleDB 對于客戶端壓力更大，CPU 峰值達到 20% 左右；TDengine 在客戶端的開銷最大，峰值瞬間達到了 70%，然后快速回落，其在客戶端的開銷相比于 TimescaleDB 多了 1 倍。但綜合服務器與客戶端的資源開銷來看，TDengine 寫入持續時間更短，在系統整體 CPU 開銷上 TDengine 仍然具有優勢。

查詢性能

在場景一（只包含 4 天數據）與場景二的 15 個不同類型的查詢中，TDengine 的查詢平均響應時間全面優于 TimescaleDB，而且在復雜查詢上優勢更為明顯，同時具有最小的計算資源開銷。相比 TimeScaleDB，場景一中 TDengine 的查詢性能是其 1.1 到 16.4 倍，場景二中 TDengine 的查(cha)詢性(xing)能是其(qi) 1.02 倍到 87 倍。

在(zai)查詢(xun)性能評(ping)估(gu)部分，我們(men)使用場景一(yi)和(he)場景二作為(wei)(wei)基準數(shu)(shu)(shu)據(ju)集。在(zai)查詢(xun)性能評(ping)估(gu)之前，對(dui)(dui)于 TimescaleDB，我們(men)采用上文(wen)出現(xian)的(de)(de) [TimescaleDB vs. InfluxDB] 對(dui)(dui)比(bi)報告(gao)中推薦配(pei)(pei)置(zhi)，設置(zhi)為(wei)(wei) 8 個 Chunk ，以確保其(qi)充分發(fa)揮查詢(xun)性能。在(zai)整個查詢(xun)對(dui)(dui)比(bi)中，TDengine 數(shu)(shu)(shu)據(ju)庫(ku)的(de)(de)虛(xu)擬(ni)節(jie)點數(shu)(shu)(shu)量（vnodes）保持為(wei)(wei)默(mo)認的(de)(de) 6 個（scale=100 時配(pei)(pei)置(zhi) 1 個），其(qi)他(ta)的(de)(de)數(shu)(shu)(shu)據(ju)庫(ku)參數(shu)(shu)(shu)配(pei)(pei)置(zhi)為(wei)(wei)默(mo)認值。

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

由于大部(bu)分(fen)類型單次(ci)(ci)查(cha)詢(xun)(xun)響(xiang)應(ying)時(shi)間(jian)過長，為(wei)了更加準確地測量(liang)每個查(cha)詢(xun)(xun)場(chang)景下(xia)較(jiao)為(wei)穩(wen)定的(de)(de)響(xiang)應(ying)時(shi)間(jian)，我們(men)依(yi)據卡車數量(liang)規模(mo)，將單個查(cha)詢(xun)(xun)運行次(ci)(ci)數分(fen)別(bie)提升到 2,000 次(ci)(ci)（場(chang)景一）和(he) 500 次(ci)(ci)（場(chang)景二(er)），然后(hou)(hou)使(shi)用 TSBS 自動統計(ji)并(bing)輸出結果(guo)，最(zui)后(hou)(hou)結果(guo)是(shi)多次(ci)(ci)查(cha)詢(xun)(xun)的(de)(de)算(suan)數平(ping)均值，使(shi)用并(bing)發(fa)客戶端(duan) Workers 數量(liang)為(wei) 4。下(xia)表是(shi)場(chang)景二(er) （4,000 設(she)備）的(de)(de)查(cha)詢(xun)(xun)性能對(dui)比結果(guo)。

查詢類型	TDengine	TimescaleDB	TimescaleDB/TDengine
last-loc	11.52	11.77	102.17%
low-fuel	30.72	416.75	1356.61%
high-load	10.74	11.62	108.19%
stationary-trucks	23.9	195.46	817.82%
long-driving-sessions	59.44	2938.54	4943.71%
long-daily-sessions	218.97	19080.95	8713.96%
avg-vs-projected-fuel-consumption	3111.18	37127.24	1193.35%
avg-daily-driving-duration	4402.15	73781.97	1676.04%
avg-daily-driving-session	4034.09	80765.04	2002.06%
avg-load	1295.97	30452.26	2349.77%
daily-activity	2314.64	79242.14	3423.52%
breakdown-frequency	5416.3	70205.29	1296.19%

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

注：查詢(xun)(xun)(xun)一=daily-activity；查詢(xun)(xun)(xun)二(er)=avg-daily-driving-session；查詢(xun)(xun)(xun)三=avg-daily-driving-duration；查詢(xun)(xun)(xun)四=avg-vs-projected-fuel-consumption

在分組選擇的查詢中，TDengine 采(cai)(cai)用一張表一個設(she)備（卡車）的(de)設(she)計方式，并采(cai)(cai)用緩(huan)存(cun)模式的(de) last_row 函數(shu)來查詢最(zui)新的(de)數(shu)據。從結(jie)果上看(kan)，TDengine 的(de)查詢響應時(shi)間優(you)于 TimescaleDB。

在復雜分組聚合的查詢中，我們看到 TDengine 查詢性能相比于 TimescaleDB 有非常大的優勢；而在時間窗口聚合的查詢過程中，針對規模較大的數據集，TimescaleDB 查詢性能不佳——long-driving-sessions 和 long-daily-sessions 均表現很差。TDengine 在 stationary-trucks 查詢性能是 TimescaleDB 的 8 倍；在 long-daily-sessions 中是 TimescaleDB 的 87 倍。

在復雜的混合查詢中， TDengine 展現出巨大的性能優勢，按查詢響應時間來度量，在 daily-activity 查詢中，TDengine 是TimescaleDB 的 34 倍，在 avg-load 查詢中，TDengine 是其 23 倍。

資源開銷對比

由于部分查(cha)詢(xun)持續(xu)時間(jian)特別(bie)短(duan)，因此(ci)(ci)并(bing)不能完(wan)整地看到(dao)查(cha)詢(xun)過(guo)程中服(fu)務器的 IO/CPU/網(wang)絡情(qing)況。為此(ci)(ci)，我們針對場景二(er)，以 daily-activity 查(cha)詢(xun)為例，執(zhi)行(xing) 50 次查(cha)詢(xun)，記錄兩(liang)大(da)軟(ruan)件系(xi)統在查(cha)詢(xun)執(zhi)行(xing)的整個過(guo)程中服(fu)務器 CPU、內存、網(wang)絡的開銷并(bing)進行(xing)對比。

服務器 CPU 開銷

從上圖可以看到，兩大系統在整個查詢過程中 CPU 的使用均較為平穩。TDengine 在查詢過程中整體 CPU 占用約 為 70%，TimescaleDB 在查詢過程中瞬時 CPU 最低，約為 22%。從整體 CPU 開銷上來看，雖然 TimescaleDB 瞬時 CPU 開銷最低，但是其完成查詢持續時間最長，所以整體 CPU 資源消耗最多。TDengine 完(wan)成全部查詢的時間僅是 TimescaleDB 的 1/30，整體 CPU 開銷最低(di)。

服務器內存狀況

如上圖所示，在整個查詢過程中，TDengine 內存維(wei)持(chi)了(le)一個相對(dui)平(ping)穩的(de)狀態，平(ping)均(jun)使(shi)用約為 12GB；TimescaleDB 內存占用在(zai)整個查(cha)詢(xun)過程中均(jun)保持(chi)平(ping)穩，平(ping)均(jun)約為 10GB，此外其對(dui) buffer 和 cache 使(shi)用比(bi)較多。

服務器網絡帶寬

上圖展示了查詢過程中兩大系統服務器端上行和下行的網絡帶寬情況，負載狀況基本上和 CPU 狀況相似——TDengine 網絡帶寬開(kai)銷最(zui)高，因為在最(zui)短(duan)的(de)時(shi)間內就完成(cheng)了全部查(cha)(cha)詢，需要將查(cha)(cha)詢結果返回(hui)給客戶端。

100 devices × 10 metrics 查詢性能對比

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

查詢類型	TDengine	TimescaleDB	TimescaleDB/TDengine
last-loc	1.03	1.35	131.07%
low-fuel	4.61	6.74	146.20%
high-load	1.03	1.31	127.18%
stationary-trucks	3.59	4.02	111.98%
long-driving-sessions	5.4	61.87	1145.74%
long-daily-sessions	13.88	228.38	1645.39%
avg-vs-projected-fuel-consumption	267.03	830.79	311.12%
avg-daily-driving-duration	278.62	1049.07	376.52%
avg-daily-driving-session	166.49	1066.69	640.69%
avg-load	102.31	487.39	476.39%
daily-activity	146.5	1245.05	849.86%
breakdown-frequency	413.82	955.2	230.82%

如上表所示，從更小規模的數據集（場景一）上的查詢對比可以看到，整體上 TDengine 同樣展現出極好的性能，在全部的查詢語句中全面優于 TimescaleDB，部分查詢性能超過 TimescaleDB 16 倍。

磁盤空間占用

在兩大系統數據完全落盤后，我們針對 TimescaleDB 和 TDengine 在不同場(chang)景下的磁盤空間占(zhan)用進行了比(bi)較。

從上圖可以看到，TimescaleDB 在所有的場景下數據規模均顯著地大于 TDengine，并且這種差距隨著數據規模增加快速變大。其中，TimescaleDB 在場景四和場景五中占用磁盤空間超過了 TDengine 的 11 倍。

測試過程中還(huan)有個小插曲(qu)，下表反(fan)應(ying)了 TimescaleDB 的(de)(de)壓(ya)(ya)縮(suo)比(bi)率，可以看到，TimescaleDB 在小數據(ju)規(gui)模的(de)(de)情況(kuang)下，壓(ya)(ya)縮(suo)比(bi)正常，但(dan)是在數據(ju)規(gui)模較大的(de)(de)場景(jing)(jing)四和(he)場景(jing)(jing)五中，壓(ya)(ya)縮(suo)以后(hou)的(de)(de)磁盤空(kong)間占用比(bi)例(li)反(fan)而(er)增大了 3.4 倍左右，疑似 bug。

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

寫在最后

值得一提的是，本次性能測試所用的基準性能測試平臺 TSBS 是由 Timescale 一手打造的，測試結果的公平公正性可見一斑。從上述 IoT 場景下的 TSBS 測試報告中我們可以得出結論，不管是在寫入性能、查詢性能還是存儲性能，TDengine 比 TimescaleDB 都略勝一籌，且不論是服務器的 CPU 還是 IO 抑或是客戶端的開銷統計，TDengine 均遠優于 TimescaleDB。

具體到實踐上，在八五信息的新能源電力物聯網平臺項目，曾經使用的數據庫便是 TimescaleDB，后面因為種種原因，他們選擇應用 TDengine 升級數據架構，關于本次案例的具體信息可以查看《代替 TimescaleDB，TDengine 接管數據量日增 40 億條的光伏日電系統》。

為了方便大家驗證測試結果，本測試報告支持運行測試腳本一鍵復現，歡迎各位檢驗。同時，我們(men)也(ye)歡(huan)迎(ying)大家添加(jia) 小(xiao)T vx：tdengine，加(jia)入 TDengine 用(yong)戶交流群，和更多志同道合(he)的開發者(zhe)一起探討數據處理難題。