上周一，TDengine 正式發布了 IoT 場景下基于 TSBS 的時序數據庫（Time Series Database，TSDB）性能基準測試報告。該報告模擬虛擬貨運公司車隊中一組卡車的時序數據，預設了五(wu)種(zhong)卡車規模場(chang)景，在(zai)相同的 AWS 云環境下運行了 TDengine 3.0、TimescaleDB 2.10.1 和 InfluxDB 1.8.10，從(cong)四大(da)維度進行對(dui)比測試(shi)并輸出(chu)結果。

為了便于大家更好地閱讀和理解，基于本報告內容，我們將從寫入、查詢及測試過程如何復現等幾大維度輸出系列文章。本篇文章將為大家解讀三大時序數據庫在寫入性能上的差異點。在上一篇文章《IoT 場景 TSBS 測試報告結果一鍵檢驗，測試腳本是______》中，我們對測(ce)試(shi)場(chang)景和基(ji)本(ben)配置(zhi)已經(jing)進行了詳細介紹，本(ben)篇文章(zhang)便不(bu)再贅述(shu)，還沒有了解過的(de)小伙伴可以點擊(ji)上文鏈(lian)接查(cha)看(kan)。

不同場景下寫入性能對比

從上圖中我們可以看到，在全部五個場景中，TDengine 的寫入性能全面超越 TimescaleDB 和 InfluxDB。在場景二中 TDengine 寫入性能最大達到 TimescaleDB 的 3.3 倍，在差距最小的場景五中，也達到了 TimescaleDB 的 1.04 倍。相比 InfluxDB，TDengine 在場景五中寫入性能是 InfluxDB 的 16 倍，在差距最小的(de)場景(jing)三中也有 1.8 倍。

此外，我們(men)還注意到，隨著設備(bei)數(shu)(shu)規(gui)模的增加(jia)，所有系(xi)統寫入(ru)基本上(shang)呈現下降趨勢。TimescaleDB 在(zai)小規(gui)模數(shu)(shu)據情況下寫入(ru)性(xing)能不及(ji) InfluxDB，但是隨著設備(bei)數(shu)(shu)量的增加(jia)，其寫入(ru)性(xing)能超過了 InfluxDB，這點上(shang)與[TimescaleDB vs. InfluxDB]對比報(bao)告中(zhong)的結論一致。

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

在三個系統(tong)(tong)數據(ju)完全落盤后，我們針對三個系統(tong)(tong)在不同場景(jing)下的磁(ci)盤空(kong)間占用進行(xing)了比較。

從上圖可以看到，TimescaleDB 在所有的場景下數據規模均顯著地大于 InfluxDB 和 TDengine，并且這種差距隨著數據規模增加快速變大。其中(zhong)，TimescaleDB 在場(chang)(chang)景(jing)四(si)和(he)場(chang)(chang)景(jing)五中(zhong)占用磁盤(pan)(pan)空間超過了 TDengine 的(de) 11 倍。在前面(mian)三個場(chang)(chang)景(jing)中(zhong)，InfluxDB 落盤(pan)(pan)后數據文件規模與 TDengine 比較(jiao)接近；但是(shi)在場(chang)(chang)景(jing)四(si)/五兩個場(chang)(chang)景(jing)中(zhong)，InfluxDB 落盤(pan)(pan)后文件占用的(de)磁盤(pan)(pan)空間是(shi) TDengine 的(de) 2 倍以上(shang)。

測(ce)試過(guo)程(cheng)中還(huan)有(you)個小(xiao)(xiao)插曲(qu)，下表(biao)反(fan)應(ying)了(le) TimescaleDB 的(de)壓(ya)縮比(bi)率，可以看到，TimescaleDB 在小(xiao)(xiao)數(shu)據(ju)規(gui)模的(de)情況下，壓(ya)縮比(bi)正常，但(dan)是在數(shu)據(ju)規(gui)模較大(da)的(de)場(chang)景四和場(chang)景五中，壓(ya)縮以后(hou)的(de)磁盤空間占用(yong)比(bi)例反(fan)而增大(da)了(le) 3.4 倍(bei)左(zuo)右，疑似 bug。

寫入過程資源消耗對比

僅憑(ping)數(shu)(shu)據(ju)寫(xie)(xie)入(ru)速度，并(bing)不能(neng)全(quan)面地反映出三個(ge)系(xi)統在(zai)不同場景下(xia)數(shu)(shu)據(ju)寫(xie)(xie)入(ru)的(de)(de)整(zheng)體表現。為(wei)此我們以(yi) 1,000,000 devices × 10 metrics（場景四）為(wei)數(shu)(shu)據(ju)模板，檢查(cha)數(shu)(shu)據(ju)寫(xie)(xie)入(ru)過程中(zhong)的(de)(de)服(fu)務器(qi)和客(ke)(ke)戶端（包括客(ke)(ke)戶端與服(fu)務器(qi)）的(de)(de)整(zheng)體負載(zai)狀況，并(bing)以(yi)此來對比三個(ge)系(xi)統在(zai)寫(xie)(xie)入(ru)過程中(zhong)服(fu)務器(qi)/客(ke)(ke)戶端節(jie)點的(de)(de)資源(yuan)占用(yong)情況。這里的(de)(de)資源(yuan)占用(yong)主要包括服(fu)務器(qi)端的(de)(de) CPU 開(kai)銷/磁盤(pan) IO 開(kai)銷和客(ke)(ke)戶端 CPU 開(kai)銷。

服務端 CPU 開銷

下圖(tu)展示了在場景四寫入(ru)過程中服(fu)(fu)務(wu)器端 CPU 負載狀況(kuang)。可以看到，三個(ge)系(xi)統在返回(hui)給(gei)客戶端寫入(ru)完(wan)成消(xiao)息以后(hou)，都還繼(ji)續使用(yong)服(fu)(fu)務(wu)器的(de)(de)資源進(jin)行相應的(de)(de)處(chu)理工作，這(zhe)點上，TimescaleDB 尤為明(ming)顯。TimescaleDB 在 7x 秒(miao)時(shi)(shi)即反饋客戶端寫入(ru)完(wan)成，但是其(qi)(qi)服(fu)(fu)務(wu)器端仍然(ran)調用(yong) CPU 資源進(jin)行了數據(ju)壓縮和整(zheng)理工作，當(dang)然(ran)整(zheng)個(ge)工作帶來(lai)的(de)(de) CPU 負載相對而言并不高，只有其(qi)(qi)峰值 CPU 開銷的(de)(de)一半(ban)左(zuo)右(you)，但是其(qi)(qi)持續時(shi)(shi)間(jian)(jian)相當(dang)長，接近(jin)凈寫入(ru)時(shi)(shi)間(jian)(jian)的(de)(de) 4 倍。

InfluxDB 則使用了相當多的 CPU 資源，瞬時峰值甚至使用了全部的 CPU 資源，其寫入負載較高，并且持續時間比 TimescaleDB 更長，當然更遠長于 TDengine。三個系統對比，TDengine 對服務器的 CPU 需求最小，峰值也僅使用了 17% 左右的服務器 CPU 資源。由此(ci)可見，TDengine 獨特(te)的(de)數據模型不僅(jin)體(ti)現(xian)在(zai)時序數據寫入性能上(shang)，同(tong)樣(yang)也展現(xian)在(zai)整體(ti)的(de)資(zi)源(yuan)開銷上(shang)。

磁盤 I/O 對比

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

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

客戶端 CPU 開銷

從上圖可以看到，客戶端上 TDengine 對 CPU 的需求大于 TimescaleDB 和 InfluxDB。InfluxDB 在整個寫入過程中，從客戶端整體負載來看是三個系統中計算資源占用最低的，對客戶端壓力最小，其寫入的壓力基本上完全集中在服務端，但這種模式很容易導致服務端成為瓶頸。相比 InfluxDB，TimescaleDB 對于客戶端壓力更大，CPU 峰值達到 20% 左右。TDengine 在客戶端的開銷最大，峰值瞬間達到了 70%，然后快速回落，其在客戶端的開銷相比于 TimescaleDB 多了 1 倍。但綜合服務器與客戶端的資源開銷來看，TDengine 寫入持續時間更短，在系統整體 CPU 開銷上 TDengine 仍然具有優勢。

性能基準評估擴展部分

為了更全面(mian)地評估 TDengine 在(zai)默認參數下(xia)的(de)寫入(ru)(ru)性能(neng)，我們在(zai)下(xia)面(mian)的(de)性能(neng)評估中對可能(neng)會影響寫入(ru)(ru)性能(neng)的(de)多個參數進行了調整，以便開展更全面(mian)的(de)評估工作。

虛擬節點（vnodes）數量

我(wo)們調整(zheng)數據(ju)庫中虛(xu)擬節(jie)點數量(liang)（默認是(shi) 12）為(wei) 12、18、24，并衡量(liang)不同(tong) vnode 數量(liang)情況下 TDengine 寫(xie)入性能。

可以看到，在較多設備的場景（場景四、五）中，增加 vnodes 的數量 ，TDengine 寫入性能提升明顯。可見在不同規模的場景中，我們可以通過調整 TDengine 虛擬節點的數量來獲得更好的寫入性能。

設備記錄數量

TDengine 創新設(she)計(ji)了(le)“一個(ge)設(she)備(bei)一張表(biao)(biao)”的(de)數(shu)據(ju)模型，需要在數(shu)據(ju)寫入時創建(jian)表(biao)(biao)，建(jian)表(biao)(biao)操作對每個(ge)設(she)備(bei)只執行一次，但(dan)這也使得 TDengine 在數(shu)據(ju)寫入的(de)準(zhun)備(bei)階段耗(hao)時較多(duo)。當單個(ge)表(biao)(biao)中(zhong)數(shu)據(ju)量(liang)增加以(yi)后(hou)，數(shu)據(ju)準(zhun)備(bei)（建(jian)表(biao)(biao)）的(de)開(kai)銷被分攤(tan)到更多(duo)的(de)數(shu)據(ju)寫入整體開(kai)銷中(zhong)。

以場(chang)景四（1,000,000 devices × 10 metrics）為例(li)，單個(ge)設(she)(she)備(bei)的數(shu)(shu)據(ju)(ju)(ju)量僅有 18 條，當我們調整參數(shu)(shu)，將單個(ge)設(she)(she)備(bei)記錄數(shu)(shu)據(ju)(ju)(ju)增加(jia)到(dao) 36、72、144 條時，整體寫(xie)入(ru)(ru)時間(jian)更長，因(yin)此(ci)表(biao)(biao)現出來(lai)就是在建(jian)表(biao)(biao)開銷被分攤到(dao)更多的數(shu)(shu)據(ju)(ju)(ju)寫(xie)入(ru)(ru)過程中(zhong)，建(jian)表(biao)(biao)的開銷相對于數(shu)(shu)據(ju)(ju)(ju)寫(xie)入(ru)(ru)的耗時占比越(yue)來(lai)越(yue)小，相應的整體寫(xie)入(ru)(ru)速度(du)也會(hui)越(yue)來(lai)越(yue)快(kuai)。因(yin)此(ci)可以看到(dao)，TDengine 表(biao)(biao)現出了更加(jia)明顯(xian)的寫(xie)入(ru)(ru)優勢。（這里(li)每(mei)張表(biao)(biao)的記錄數(shu)(shu)忽略了 IoT 場(chang)景中(zhong)丟失(shi)的記錄，所以單個(ge)設(she)(she)備(bei)記錄數(shu)(shu)據(ju)(ju)(ju)這個(ge)值并非百(bai)(bai)分百(bai)(bai)準確）

我們調整 vnodes 數量配置，同時測試兩個不同 vnodes 數量情況下的寫入性能指標。如上圖所示，隨著表中記錄數的增加，vgroups=12 和 vgroups=24，TDengine 寫入性能均呈現出持續增加的趨勢。當設備記錄數達到 576 行（此時數據集規模約等于 32,414,619 x 32 = 10.37 億行數據記錄），vgroups=12 時，寫入性能達到 2,827,696.64 metrics/sec，性能均大幅領先 TimescaleDB 與 InfluxDB，是(shi) TimescaleDB 的 6.1 倍， InfluxDB 的 4.6 倍。

TimescaleDB 寫入性(xing)能(neng)在單表記錄數量大于(yu) 72 行以后出(chu)現了(le)快速衰減(jian)。InfluxDB 在單設備記錄增加過程中，寫入性(xing)能(neng)有(you)衰減(jian)，但(dan)衰減(jian)趨勢非常緩慢。

寫在最后

由此可見，在全部的場景中，TDengine 的寫(xie)入性能(neng)超過 TimescaleDB 和(he) InfluxDB。在整個寫(xie)入過程(cheng)中，TDengine 除(chu)了提(ti)供更(geng)高的寫(xie)入能(neng)力(li)，在服務器的 CPU 和(he) IO 上(shang)，也均遠(yuan)優于 TimescaleDB 和(he) InfluxDB——不管是(shi)服務器的磁盤 IO 開銷(xiao)抑或(huo)客戶端(duan)的開銷(xiao)，TDengine 均遠(yuan)小于 TimescaleDB 和(he) InfluxDB。

在(zai)(zai)后(hou)面的(de)拓展(zhan)部分(fen)，通過調(diao)整不(bu)同的(de)數(shu)(shu)(shu)據(ju)(ju)庫參(can)數(shu)(shu)(shu)(vgroups)，以及設置(zhi)不(bu)同的(de)數(shu)(shu)(shu)據(ju)(ju)規模(mo)（增加每(mei)個設備包含記錄(lu)數(shu)(shu)(shu)）方(fang)(fang)式，我(wo)們在(zai)(zai)更多的(de)方(fang)(fang)面評估了 TDengine 在(zai)(zai) TSBS 基準(zhun)數(shu)(shu)(shu)據(ju)(ju)集(ji)上的(de)寫(xie)入性能。通過這(zhe)一系列深(shen)入的(de)對(dui)比(bi)可(ke)以看到(dao)，針對(dui)更大規模(mo)（設備數(shu)(shu)(shu)量(liang)和每(mei)個設備記錄(lu)數(shu)(shu)(shu)量(liang)）數(shu)(shu)(shu)據(ju)(ju)集(ji)，TDengine 可(ke)以通過簡單調(diao)整虛擬(ni)節(jie)點(dian)數(shu)(shu)(shu)量(liang)的(de)方(fang)(fang)式，獲得(de)更高(gao)的(de)寫(xie)入性能，并且(qie) TDengine 在(zai)(zai)針對(dui)大數(shu)(shu)(shu)據(ju)(ju)集(ji)寫(xie)入場景下展(zhan)現出(chu)更好的(de)性能優勢(shi)，同時具有遠低于 TimescaleDB 和 InfluxDB 對(dui)服務端資源(yuan)（服務器 CPU 和磁盤 IO、內(nei)存等）的(de)開銷。

在《中移物聯車聯網項目，在 TDengine 3.0 的應用》一文中，TDengine 3.0 高效的寫入性能也在企業實踐中得到了驗證——從 2.0 到 3.0，面對 1.2-1.3w 行/s 的業務寫入峰值，以及 20w 行/s 的數據遷移巨大寫入量，TDengine 都可以輕松應對，磁盤占用量約占 MySQL 的 1/7。如果你也面臨著數據處理難題或想要進行數據架構升級，歡迎添加小T vx：tdengine1，加入 TDengine 用戶交(jiao)流群(qun)，和更多志同道合的開發者(zhe)一起攻克難關。