基于第三方基準性能測試平臺 TSBS（Time Series Benchmark Suite） 標準數據集，TDengine 團隊分別就 TSBS 指定的 DevOps 中 cpu-only 五個場景，對時序數據庫（Time Series Database，TSDB）TimescaleDB 和 TDengine 進行了對比測試。本文(wen)將會從寫入、存儲、查詢(xun)及資源開(kai)銷等(deng)幾大維度為大家匯(hui)總分析測試結果。

為確(que)保結果(guo)具有可(ke)比(bi)性，本(ben)次(ci)測試選用(yong) TimescaleDB 2.6.0 版本(ben)。為獲得較好(hao)的性能，TimescaleDB 需要針(zhen)對不(bu)同(tong)(tong)的場(chang)景(jing)設置不(bu)同(tong)(tong)的 Chunk 參數(shu)，不(bu)同(tong)(tong)場(chang)景(jing)下(xia)(xia)參數(shu)的設置如(ru)下(xia)(xia)表所示：

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

TimescaleDB vs. InfluxDB: Purpose Built Differently for Time-Series Data：

關于系統的配置詳情、如何一鍵復現測試結果及詳細的測試數據介紹等內容，大家可參考《一鍵獲取測試腳本，輕松驗證“TSBS 時序數據庫性能基準測試報告”》、《TSBS 是什么？為什么時序數據庫 TDengine 會選擇它作為性能對比測試平臺？》兩(liang)篇文(wen)章(zhang)，本文(wen)便(bian)不再贅述。

寫入性能最高達到了 TimescaleDB 的 6.7 倍

在 TSBS 全(quan)部(bu)的(de)(de)(de) cpu-only 五個場(chang)景中，TDengine 寫(xie)入性能均優于 TimescaleDB。相(xiang)比 TimescaleDB，TDengine 寫(xie)入速(su)度最領先的(de)(de)(de)場(chang)景是(shi)其 6.7 倍（場(chang)景二），最少也(ye)是(shi) 1.5 倍（場(chang)景五），而且(qie)對于場(chang)景四，如(ru)果將(jiang)每個采集點的(de)(de)(de)記錄(lu)條(tiao)(tiao)(tiao)數由 18 條(tiao)(tiao)(tiao)增加到 576 條(tiao)(tiao)(tiao)，TDengine 寫(xie)入速(su)度就達(da)到了 TimescaleDB 的(de)(de)(de) 13.2 倍。此外，TDengine 在寫(xie)入過(guo)程中消耗的(de)(de)(de) CPU 資源和磁盤 IO 開銷(xiao)也(ye)是(shi)最低的(de)(de)(de)。

不同場景下寫入性能對比

從上圖可以看到，在全部五個場景中，TDengine 的寫入性能全面超越 TimescaleDB。在場景二中 TDengine 寫入性能最大達到了 TimescaleDB 的 6.74 倍，在差距最小的場景五中，也達到了 TimescaleDB 的 1.52 倍。

寫入過程資源消耗對比

但僅憑數(shu)據(ju)寫(xie)(xie)入速度，并(bing)不(bu)能(neng)全面地反(fan)映出 TDengine 和(he)(he) TimescaleDB 在不(bu)同場景(jing)下數(shu)據(ju)寫(xie)(xie)入的(de)整體(ti)表現(xian)。為此(ci)我們以 1,000,000 devices × 10 metrics （場景(jing)四）為例，檢查數(shu)據(ju)寫(xie)(xie)入過程中的(de)服(fu)務(wu)(wu)器(qi)和(he)(he)客戶端(duan)(duan)的(de)整體(ti)負(fu)載狀況，并(bing)以此(ci)來對(dui)比 TDengine 和(he)(he) TimescaleDB 在寫(xie)(xie)入過程中服(fu)務(wu)(wu)器(qi)/客戶端(duan)(duan)節點的(de)資源(yuan)占(zhan)用情(qing)況，這里的(de)資源(yuan)占(zhan)用主要(yao)包括服(fu)務(wu)(wu)器(qi)端(duan)(duan)的(de) CPU 開銷/磁(ci)盤 IO 開銷和(he)(he)客戶端(duan)(duan) CPU 開銷。

服務端 CPU 開銷

上圖展示了在場景四寫入過程之中服務器端 CPU 負載狀況。可以看到，TDengine 和 TimescaleDB 在返回給客戶端寫入完成消息以后，都還繼續使用服務器的資源進行相應的處理工作，這點上，TimescaleDB 尤為明顯，TimescaleDB 在 7x 秒的時候即反饋客戶端寫入完成，但是其服務器端仍然在調用 CPU 資源進行數據壓縮和整理工作，當然整個工作帶來的 CPU 負載相對而言并不高，只有其峰值 CPU 開銷的一半左右，但是其持續時間相當長，接近凈寫入時間的 4 倍，遠長于 TDengine。TDengine 對服務器的 CPU 需求較小，峰值也僅使用了 17% 左右的服務器 CPU 資源。由此可見(jian)，TDengine 獨特的(de)數據模型不僅(jin)體現在(zai)時序數據的(de)寫入性能(neng)上，也體現在(zai)整體的(de)資源開銷(xiao)上。

磁盤 I/O 對比

上圖展示了 1,000,000 devices × 10 metrics （場景四(si)）兩大(da)系(xi)統(tong)在數據寫入過程中(zhong)服務器(qi)端磁(ci)盤寫入狀(zhuang)態。結合服務器(qi)端 CPU 開(kai)銷表現，可以看到(dao)，兩大(da)數據庫的 IO 動(dong)作與 CPU 均(jun)呈(cheng)現出同步活躍狀(zhuang)態。

在寫入相同規模數據集的情況下，TDengine 在寫入過程中對于磁盤寫入能力的占用遠小于 TimescaleDB，整體寫入過程只占用了部分磁盤寫入能力（125MiB/Sec. 3000IOPS）。從圖(tu)上(shang)能看(kan)到，對(dui)于(yu)兩大數據(ju)庫來說，數據(ju)寫入(ru)過程中(zhong)磁盤(pan)(pan)的(de)(de) IO 瓶頸是確實存在的(de)(de)，但 TimescaleDB 寫入(ru)過程對(dui)于(yu)寫入(ru)的(de)(de)消耗遠超過了(le) TDengine 對(dui)磁盤(pan)(pan)寫入(ru)能力的(de)(de)需求。

客戶端 CPU 開銷

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

查詢性能最高達到了 TimescaleDB 的 28.6 倍

在場(chang)景(jing)一(yi)（只包(bao)含(han) 4 天數據）與場(chang)景(jing)二(er)的 15 個不(bu)同類型的查詢(xun)中(zhong)，TDengine 的查詢(xun)平均(jun)響應時間全(quan)面優(you)于 TimescaleDB，而且(qie)在復雜查詢(xun)上(shang)優(you)勢(shi)更為明顯，同時具有最小(xiao)的計算資源開銷。相比 TimeScaleDB，場(chang)景(jing)一(yi)中(zhong) TDengine 的查詢(xun)性能是其 1.1 ～ 28.6 倍(bei)，場(chang)景(jing)二(er)中(zhong) TDengine 的查詢(xun)性能是其 1.2 ～ 24.6 倍(bei)。

在查詢(xun)性能評估(gu)部分，我們使用場景(jing)一(yi)和場景(jing)二作為基準數(shu)據集。在查詢(xun)性能評估(gu)之前，對于 TimescaleDB，我們采用上文出(chu)現的(de)(de) TimescaleDB vs. InfluxDB 對比報告(gao)中(zhong)推薦(jian)配置(zhi)，設置(zhi)為 8 個 Chunk ，以確保(bao)其充分發揮查詢(xun)性能。在整(zheng)個查詢(xun)對比中(zhong)，TDengine 數(shu)據庫(ku)的(de)(de)虛擬節(jie)點數(shu)量（vnodes）保(bao)持為默(mo)認的(de)(de) 6 個，其他(ta)的(de)(de)數(shu)據庫(ku)參(can)數(shu)配置(zhi)為默(mo)認值(zhi)。

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

由于部分類型(xing)（分類標準參見(jian) TimescaleDB vs. InfluxDB 對比報告）單(dan)次查詢響(xiang)應(ying)時間非常短(duan)，為了更加準確(que)地測量(liang)(liang)每個查詢場景的(de)較為穩定的(de)響(xiang)應(ying)時間，我們將單(dan)個查詢運(yun)行次數提升到 5,000 次，然后使用(yong) TSBS 自動(dong)統(tong)計并輸出(chu)結果，最后結果是 5,000 次查詢的(de)算數平(ping)均值(zhi)，使用(yong)并發(fa)客戶端 Workers 數量(liang)(liang)為 8。下表(biao)是場景二(er) （4,000 設備）下兩(liang)大數據庫的(de)查詢性能對比結果。

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

由于(yu) Simple Rollups 的整體(ti)查(cha)詢(xun)響應(ying)時(shi)間(jian)(jian)非常短，因此制約查(cha)詢(xun)響應(ying)時(shi)間(jian)(jian)的主體(ti)因素(su)并不是(shi)查(cha)詢(xun)所涉及的數據規(gui)模(mo)，即(ji)這一類型查(cha)詢(xun)的瓶頸并非數據規(gui)模(mo)。但從結(jie)果上(shang)看(kan)，TDengine 仍然(ran)在所有類型的查(cha)詢(xun)響應(ying)時(shi)間(jian)(jian)上(shang)優于(yu) TimescaleDB，具體(ti)的數值對比請(qing)參見上(shang)表。

通過上圖可以看到，在 Aggregates 類型的查詢中，TDengine 的查詢性能相比 TimescaleDB 有比較大的優勢，其cpu-max-all-8 查詢性能是 TimescaleDB 的 6 倍。

在(zai) Double-rollups 類型查(cha)詢(xun)中， TDengine 同樣展現出巨大的(de)性(xing)(xing)能優勢(shi)，以(yi)查(cha)詢(xun)響應(ying)時間(jian)來度(du)量，其在(zai) double-groupby-5 和 double-groupby-all 類型下的(de)查(cha)詢(xun)性(xing)(xing)能均達到了 TimescaleDB 的(de) 24 倍。

上面兩圖展示的是 threshold 類型的查詢對比，可以看到，TDengine 的查詢響應時間均顯著低于 TimescaleDB。在 high-cpu-all 類型的查詢上，TDengine 的性能是 TimescaleDB 的 1.23 倍。

對于 Complex-queries 類型的查詢，TDengine 兩個查詢同樣均大幅領先 TimescaleDB。在 lastpoint 查詢中TDengine 的查詢性能是 TimescaleDB 的 5 倍，在 groupby-orderby-limit 場景中 TDengine 的查詢性能是 TimescaleDB 的 8 倍。在時間窗口聚合的(de)查(cha)詢過程中，針對規模(mo)較(jiao)大的(de)數據(ju)集 TimescaleDB 查(cha)詢性能不佳（double rollups 類型(xing)查(cha)詢），對于 groupby-orderby-limit 類型(xing)的(de)查(cha)詢，TimescaleDB 的(de)性能表現(xian)同(tong)樣不是太好。

資源開銷對比

由于部分查(cha)詢(xun)(xun)持續時間特(te)別短(duan)，因此我(wo)們并(bing)不能(neng)完整地看到查(cha)詢(xun)(xun)過程中服務器的(de) IO/CPU/網(wang)絡(luo)情況(kuang)。為此我(wo)們針對場景二以 Double rollups 類(lei)別中的(de) double-groupby-5 查(cha)詢(xun)(xun)為例(li)，執行(xing)(xing) 1,000 次(ci)查(cha)詢(xun)(xun)，記錄(lu)整個(ge)過程中 TDengine、TimescaleDB 兩個(ge)軟(ruan)件系(xi)統在查(cha)詢(xun)(xun)執行(xing)(xing)的(de)整個(ge)過程中服務器 CPU、內存、網(wang)絡(luo)的(de)開(kai)銷并(bing)進行(xing)(xing)對比。

如上圖所示，兩個系統在整個查詢過程中 CPU 的使用均較為平穩。TDengine 在查詢過程中整體 CPU 占用約 80%，使用的 CPU 資源最高，TimescaleDB 在查詢過程中瞬時 CPU 占用約 38%。由于 TDengine 完成全部查詢的時間僅 TimescaleDB 1/20，因此雖然其 CPU 穩定值是 TimescaleDB 的 2 倍多，但整體的 CPU 計算時間消耗只有其 1/10 。

• 服務器內存狀況

如上圖所(suo)示，在(zai)(zai)整個查(cha)詢過程中(zhong)，TDengine 內(nei)存(cun)維持在(zai)(zai)一個相對平(ping)穩的狀(zhuang)態。而 TimescaleDB 在(zai)(zai)整個查(cha)詢過程中(zhong)內(nei)存(cun)呈(cheng)現(xian)增加的狀(zhuang)態，查(cha)詢完成后即恢復到初(chu)始狀(zhuang)態。

• 服務器網絡帶寬

上圖展示了查詢過程中兩個系統的服務器端上行和下行的網絡帶寬情況，可以看到，負載狀況基本上和 CPU 狀況相似。TDengine 網絡帶寬開銷較高，因為在最短的時間內就完成了全部查詢，需要將查詢結果返回給客戶端。TimescaleDB 開銷較低，但持續時間長。

100 devices × 10 metrics 查詢性能對比

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

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

TimescaleDB 占用的磁盤空間最高達到 TDengine 的 26.9 倍

下(xia)圖是TDengine 和 TimescaleDB 數據完全(quan)落盤以后，比(bi)較了兩(liang)個系統在不同(tong)場景下(xia)的磁(ci)盤空(kong)間占用：

在磁盤空間的占用上，從上圖可以看到，TimescaleDB 在全部五個場景下的數據規模均顯著大于 TDengine，并且這種差距隨著數據規模增加快速變大。TimescaleDB 在場景四和場景五中占用磁盤空間是 TDengine 的 25.6 倍和 26.9 倍。

寫在最后

從上述 TSBS 測試報告中我們可以得出結論，不管是在寫入性能、查詢性能還是存儲性能，TDengine 時序數據庫 比(bi) TimescaleDB 時序數(shu)據庫 都略勝一籌(chou)，且不論(lun)是(shi)服務器的 CPU 還(huan)是(shi) IO 抑或是(shi)客(ke)戶(hu)端的開銷(xiao)統計(ji)，TDengine 均遠優于 TimescaleDB。尤其本次性(xing)(xing)能測試還(huan)是(shi)基于 Timescale 打(da)造的基準性(xing)(xing)能測試平臺(tai) TSBS 進行的，測試結果的公(gong)平公(gong)正(zheng)性(xing)(xing)可(ke)見(jian)一斑。

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

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