小 T 導讀：在(zai)柳工(gong)的(de)(de)工(gong)業車(che)聯網應用(yong)(yong) LiuGong iLink 中，由于應用(yong)(yong)層不合(he)理的(de)(de)復雜查詢和歷史數(shu)據(ju)的(de)(de)高(gao)頻寫入，導致 MySQL 處(chu)理速度(du)緩(huan)慢，甚(shen)至容易(yi)宕機，嚴重影響了用(yong)(yong)戶體驗。在(zai)此背(bei)景下，柳工(gong)決定改用(yong)(yong) TDengine Database 來處(chu)理時序數(shu)據(ju)，本文(wen)分享(xiang)了他們的(de)(de)改進效果與實踐(jian)經(jing)驗。

企業簡介

廣西(xi)柳工(gong)機(ji)械股份有(you)(you)限(xian)公司是中(zhong)國(guo)(guo)制(zhi)造業(ye)(ye) 500 強企業(ye)(ye)——柳工(gong)集團(tuan)的核心企業(ye)(ye)。作為(wei)國(guo)(guo)內(nei)工(gong)程機(ji)械行業(ye)(ye)和廣西(xi)第一家上市公司，柳工(gong)被譽為(wei)“中(zhong)國(guo)(guo)工(gong)程機(ji)械行業(ye)(ye)的排頭兵”，在全球擁(yong)有(you)(you) 20 多個制(zhi)造基地(di)(di)(di)、17000 多名員工(gong)、5 個研發基地(di)(di)(di)，產品遍布 170 多個國(guo)(guo)家和地(di)(di)(di)區。

項目介紹

LiuGong iLink 是柳工(gong)面向國際市場業(ye)務的一個工(gong)業(ye)車聯網應用，包含 Web 端和 App 端。它可以(yi)(yi)讓用戶看到所有車輛設(she)備的實(shi)時(shi)動態(tai)，例如(ru)(ru)在(zai)哪里工(gong)作、何(he)時(shi)工(gong)作以(yi)(yi)及如(ru)(ru)何(he)工(gong)作，也(ye)可以(yi)(yi)實(shi)現設(she)備的遠程監控，以(yi)(yi)便更有效地(di)實(shi)施服務和維護計劃。

此前，我們使用 MySQL 數據庫承載了包括應用層和接入解析層的大多數業務，但由于應用層不合理的復雜查詢和歷史數據的高頻寫入，給 MySQL 造成了非常大的壓力，導致其處理速度緩慢，甚至容易宕機，嚴重影響了用戶體驗。究其原因，還是因為關系型數據庫并不適用于存儲海量的時序數據，在海量數據聚合計算、抽稀等業務中效率很低。

為解決上述問題，我們選擇以專用的時序數據庫（Time Series Database）存儲處理時序(xu)(xu)數據，這樣可(ke)以(yi)大(da)(da)大(da)(da)增加整個系統(tong)的吞吐能(neng)力。經過調(diao)研(yan)，我(wo)(wo)們選擇(ze)了時序(xu)(xu)數據庫 TDengine，原(yuan)因在于，我(wo)(wo)們的業務(wu)場(chang)景與 TDengine 的“一(yi)個設備(bei)采集點(dian)一(yi)張(zhang)表”的理念(nian)十分(fen)吻合，而且 TDengine 可(ke)以(yi)支持對(dui)大(da)(da)數據進行聚(ju)合和(he)降采樣查詢(xun)這些特性，也恰好(hao)可(ke)以(yi)解(jie)決(jue)上述(shu)技(ji)術痛點(dian)。

從真實環境出發，TDengine 的寫入、查詢、存儲效果如何？

分(fen)析(xi)架構可知，數(shu)據采集(ji)來(lai)源主要是 TBOX 等設(she)備(bei)，通過解析(xi)層解析(xi)為 JSON 后發往 Kafka，再通過入庫程序消費寫入到 TDengine Database 中。

我們落地使用的是 TDengine2.4.0.16 版本，單副本模式，只用了一臺 4 核 8GB+1TB 的服務器就撐起了服務，當前磁盤占用約 110G。

當前，庫中總表數量達到了 55701 張，秉承著“一個采集點一張表”的原則，我們選擇不同維度，共建立了 21 張超級表，如：車輛類型，設備類型，數據類型。當前總數據量大概為 4-5 億行左右，寫入規模大概是每臺車每 5 分鐘上報一次，TDengine 可以輕松抗住這個級別的寫入。

在(zai)查(cha)詢方面(mian)，我(wo)(wo)們通過封(feng)裝 API 的方式，可以便捷地提供查(cha)詢服務，這(zhe)也(ye)是針對(dui)我(wo)(wo)們業務痛(tong)點改進(jin)最為明(ming)顯(xian)的地方。在(zai)決(jue)定(ding)對(dui) MySQL 進(jin)行替(ti)換時，我(wo)(wo)們做(zuo)了(le)充(chong)分的查(cha)詢對(dui)比測試。

如上圖所示表格(ge)中的(de)(de) API 分別代(dai)表了查(cha)詢 mcu 歷(li)(li)史數(shu)據(ju)、查(cha)詢 TBOX 歷(li)(li)史數(shu)據(ju)、查(cha)詢設備軌(gui)跡(ji)、查(cha)詢設備故障(zhang)歷(li)(li)史數(shu)據(ju)四個功能。可以看到，面對大批量的(de)(de)數(shu)據(ju)，TDengine 的(de)(de)查(cha)詢能力(li)是遠遠超過(guo) MySQL 的(de)(de)。

再分享一個真實場景：在替換TDengine之前，我們每天都有一些業務報表需要展示，每一小時需統計一次下一個時區內所有設備的數據，這個流程在 MySQL 中經常需要耗時1小時以上，無法正常執行后續業務。而換到TDengine后，整個出表流程只需要10 秒左右。

實際應用時遇到的問題與經驗分享

從上圖中(zhong)可以看到，我們(men)每類設(she)備的(de)采集點位（列數）是比較多的(de)，動(dong)輒破百，這也給我們(men)帶來(lai)了一個潛在的(de)問(wen)(wen)題——間(jian)接地影響了壓縮(suo)率，這是后(hou)來(lai)在和 TDengine 官方人員排查別的(de)問(wen)(wen)題時發(fa)現的(de)。

后來我們了解到了產生此問題的原因：由于 TDengine 中的每個 Vnode 都有一塊自己(ji)的(de)緩(huan)沖區，大小(xiao)由 cache * blocks 的(de)值決定（單位 MB）。每當(dang)寫(xie)滿三分(fen)之一時(shi)(shi)就會觸發數據落盤，并(bing)在落盤時(shi)(shi)完成壓縮。列(lie)寬帶來的(de)影響是單行(xing)長度(du)過大，每次寫(xie)滿三分(fen)之一的(de)時(shi)(shi)候，并(bing)不(bu)需要(yao)多少行(xing)數據，由于(yu)樣本太少，所以(yi)數據并(bing)不(bu)能很好的(de)壓縮。

通過 selct _block_dist() from 超(chao)級表的方(fang)式查看(kan)數據(ju)塊的分布(bu)，可以(yi)看(kan)到小塊 SmallBlocks 相(xiang)當之多，在(zai) 99% 以(yi)上。

我們的(de)(de)解決方案就是通過放大 blocks 參數(shu)（默(mo)認為 6），來(lai)緩解后續新數(shu)據(ju)的(de)(de)壓縮(suo)。至(zhi)于歷史數(shu)據(ju)，我們計劃(hua)使用 TDengine Database 提供(gong)的(de)(de)重整數(shu)據(ju)碎片(pian)的(de)(de)壓縮(suo)功(gong)能來(lai)完成(cheng)。

具(ju)體到操作上(shang)是比較簡單的(de)，備份(fen)數(shu)據文(wen)件后(hou)，使用 compact vgroups in (3,4,5,6) 即(ji)可(ke)（數(shu)字為 Vgroup ID）。但(dan)由于重(zhong)整的(de)過程中會對寫入有一定的(de)影(ying)響，所以我(wo)們(men)需要選擇(ze)在(zai)業(ye)務休整期來(lai)完成這(zhe)個(ge)操作。這(zhe)個(ge)時間點可(ke)能(neng)會在(zai) TDengine 3.0 發布(bu)后(hou)，屆(jie)時我(wo)們(men)可(ke)以對現有場景再度(du)完成一次質變級(ji)別(bie)的(de)升級(ji)。

寫在最后

目前，我們還在規(gui)劃車輛維保相關的項目，通過車輛實(shi)時設(she)備產生報警，提高車輛使用(yong)時長和(he)(he)安全(quan)率(lv)。聚(ju)焦“智慧”“電動”“智能”等關鍵詞，柳工向世界伙伴(ban)們展示了各(ge)個行業(ye)的解決方案，未來我們也(ye)會和(he)(he) TDengine 產生更多深層次(ci)的互動。