小 T 導讀：

為了有效處理(li)每日億級的(de)數據量，早在 2021 年，韻(yun)(yun)達就選擇(ze)用 TDengine 替代了 MySQL，并在三(san)臺(tai)服務器上成功部署和(he)上線了 TDengine 2.0 集群。如今，隨(sui)著 TDengine 3.0 版本的(de)逐漸(jian)成熟，韻(yun)(yun)達決定(ding)將現有的(de) 2.0 版本升級到 3.0 版本，并基于(yu)本文為大家分享其在升級過程中所(suo)進行的(de)優化措施以(yi)及升級后的(de)性能(neng)表現。

作為(wei)一家(jia)頭部(bu)物流公(gong)司，韻(yun)達(da)(da)每日的(de)訂單(dan)掃描量破(po)億級別，該類數(shu)據(ju)為(wei)典型的(de)時(shi)序數(shu)據(ju)，這(zhe)也(ye)是我們公(gong)司數(shu)據(ju)量最大的(de)一塊業務(wu)。系統需要(yao)匯總統計全國(guo)網點的(de)掃描數(shu)據(ju)（韻(yun)達(da)(da)的(de)所有訂單(dan)數(shu)據(ju)），并實時(shi)反(fan)饋給用戶。此(ci)外(wai)，這(zhe)些數(shu)據(ju)也(ye)會給到(dao)網點、分撥中心(xin)的(de)內部(bu)員工(gong)使用，用于個人(ren)工(gong)作量、站點掃描量等(deng)統計工(gong)作。在(zai)“雙十一、二”期間，面對快遞業務(wu)量的(de)暴漲(zhang)，TDengine 幫(bang)助我們很好(hao)地(di)完成了(le)既定規劃，保障(zhang)了(le)“雙十一、二”任務(wu)的(de)順利完成。

本文用于分享我(wo)司在 TDengine 上使用的歷程和心得(de)。

從 2.0 到 3.0

在早些(xie)年業(ye)務(wu)尚未擴張時，我們(men)采用(yong)的是 MySQL 分(fen)區(qu)+索引方式進行(xing)掃描(miao)槍數據(ju)的處理，但隨著(zhu)企(qi)業(ye)的發展、業(ye)務(wu)量的增加(jia)，面對每日億(yi)級的數據(ju)量，MySQL 顯然已經無法滿足(zu)當下的數據(ju)處理需(xu)求。

在這種背景下，我們決定進行時序數據庫（Time Series Database）選型。經過嚴格的選項測試，我們最終選擇了 TDengine 作為核心數據庫處理該部分數據。在 2021 年，我們在三臺 16C 64G 的服務器上部署上線了 TDengine 2.0 版本集群。（//yakult-sh.com.cn/tdengine-user-cases/7815.html）

該集群每天要(yao)(yao)承載日常(chang) 6 億行數(shu)據(ju)的(de)寫(xie)入和一(yi)定量(liang)(liang)的(de)查(cha)詢(xun)，“雙十一(yi)、二”等特殊(shu)業務期間，寫(xie)入/查(cha)詢(xun)量(liang)(liang)還(huan)要(yao)(yao)上(shang)漲(zhang) 50% 左右，數(shu)據(ju)需要(yao)(yao)保留(liu) 2 個月。

我(wo)們的架構(gou)是 Spring Boot + MyBatis + MySQL + TDengine，TDengine 負(fu)責(ze)處理時序(xu)數(shu)據，MySQL 則負(fu)責(ze)非時序(xu)數(shu)據的存儲及應用，如下(xia)：

使用 2.0 的這兩(liang)年數據庫是很穩定的，但考慮到后(hou)期(qi)業務需求(qiu)會用到 3.0 的新特性，所以我們自打 TDengine 3.0 發布之后(hou)，就(jiu)一直在著(zhu)手準備(bei)數據庫的遷移(yi)工(gong)作。

數據遷移經驗分享

數據庫遷移是一項(xiang)很重大的工作，在此期(qi)間(jian)，我們仔細梳(shu)理了 2.0 版本(ben)使(shi)用(yong)期(qi)間(jian)的一些使(shi)用(yong)情況，嘗(chang)試(shi)做出針對性的優化。

在 2.0 時期，我們是根據“一個掃描槍一張表”的模型建表，把設備的地點和站點類型設置為標簽。來到 3.0 時期后，我們和官方團隊反復調試，選擇了“一個站點一張表”的建模方式。這樣一來，表數量從百萬級直接縮減到了萬級。

做這個改動(dong)的核心(xin)原因有兩個：

1. 我們有很多臨時的虛擬掃描槍，由于只是臨時使用，所以沒有幾條數據，但卻單獨占據了一個表。
2. 雖然掃描槍寫入頻率較低，但是整個站點有很多掃描槍，這樣的建模方式使得低頻寫入轉化為了高頻寫入，降低了存儲中碎片數據的比例。

2.x 超級表結構：

優化過(guo)后(hou)，3.x 超(chao)級表的結構(gou)：

除此之外，3.0 由于底層有很多的重構，因此和 2.0 相比出現了很多的參數改動，可以參考：，。優化思路可以參考這篇文章中的內容：//yakult-sh.com.cn/tdengine-engineering/21550.html。

尤其是 3.0 關于數據(ju)入(ru)庫頻(pin)率、數據(ju)亂序、更新、建表等處理邏輯的(de)(de)(de)(de)(de)變化，均需要投入(ru)一(yi)定(ding)量(liang)的(de)(de)(de)(de)(de)學習(xi)測(ce)試(shi)時(shi)間。尤其是在數據(ju)量(liang)極大的(de)(de)(de)(de)(de)情況下(xia)，每一(yi)次測(ce)試(shi)環(huan)境的(de)(de)(de)(de)(de)搭(da)建都需要較大的(de)(de)(de)(de)(de)時(shi)間人力成(cheng)本。我們在 TDengine 官方(fang)團隊的(de)(de)(de)(de)(de)協助下(xia)，斷(duan)斷(duan)續(xu)續(xu)大概(gai)用了(le) 2 個月的(de)(de)(de)(de)(de)時(shi)間才完成(cheng)這個階段。

優化效果顯著

最(zui)終優化(hua)過后，我們(men)的(de)(de)(de)查(cha)詢(xun)速度得到了進一步提升。尤其是下面這類查(cha)詢(xun)優化(hua)效果(guo)十分(fen)明顯，該查(cha)詢(xun)的(de)(de)(de)邏(luo)輯是：從 6 億行的(de)(de)(de)當天數(shu)據(ju)(ju)中(zhong)，通(tong)過標簽(qian)、普通(tong)列(lie)做出多次篩(shai)選(xuan)，最(zui)終返回分(fen)頁(ye)后的(de)(de)(de)十條結果(guo)。其中(zhong)，最(zui)為耗時的(de)(de)(de)便是從標簽(qian)過濾之(zhi)后的(de)(de)(de) 1.5 億條數(shu)據(ju)(ju)的(de)(de)(de)普通(tong)列(lie)篩(shai)選(xuan)。

在 2.6 版本中，這個過程需要大約 10 秒的時間，升級到 3.x 之后，只需要 2-3 秒左右便會返回結果：

select waybill_barcode,location,scanning_person,equipment_code,scan_category,remark,weight_info weight,scan_time,volume,lower_location,lrfs from base.scan_data WHERE ts >= #{beginTime} and ts <= #{endTime} and site_type=#{siteType} and equipment_code = #{equipmentCode} limit 0,10;

至此(ci)，我們從 TDengine 2.0 遷(qian)移到 3.0 版本(ben)的工作(zuo)就圓滿(man)完成了(le)。

寫在最后

對(dui)于我們這種集快(kuai)(kuai)遞(di)、物流(liu)、電子商務配送和(he)倉儲服務為一(yi)體(ti)的(de)(de)快(kuai)(kuai)遞(di)企業，掃描(miao)槍(qiang)設備產生的(de)(de)數(shu)據是相當龐(pang)大(da)(da)的(de)(de)，而 TDengine 可(ke)(ke)以輕松高效地處理和(he)存(cun)儲這些時序數(shu)據，它(ta)所(suo)具備的(de)(de)快(kuai)(kuai)速寫入和(he)查詢的(de)(de)能力，使得我們的(de)(de)系統可(ke)(ke)以輕松應對(dui)高負載和(he)大(da)(da)規模數(shu)據的(de)(de)需求(qiu)。

落實到業務使用方面，通過實時(shi)了(le)解包裹狀態、配(pei)送進度等信息(xi)，我們能夠(gou)更加(jia)方便地做出實時(shi)決策，物流運(yun)營的效率和效果也獲得了(le)大幅(fu)提高。

文章最后，祝 TDengine 越來越好，早日成為時序數(shu)據庫(ku)領域的 NO.1。