小 T 導(dǎo)讀：

為了有效處理每日億級(jí)的數(shù)據(jù)量，早在 2021 年，韻達(dá)就選擇用 TDengine 替代了 MySQL，并在三臺(tái)服務(wù)器上成功部署和上線了 TDengine 2.0 集群。如今，隨著 TDengine 3.0 版本的逐漸成熟，韻達(dá)決定將現(xiàn)有的 2.0 版本升級(jí)到 3.0 版本，并基于本文為大家分享其在升級(jí)過(guò)程中所進(jìn)行的優(yōu)化措施以及升級(jí)后的性能表現(xiàn)。

作為一家頭部物流公司，韻達(dá)每日的訂單掃描量破億級(jí)別，該類數(shù)據(jù)為典型的時(shí)序數(shù)據(jù)，這也是我們公司數(shù)據(jù)量最大的一塊業(yè)務(wù)。系統(tǒng)需要匯總統(tǒng)計(jì)全國(guó)網(wǎng)點(diǎn)的掃描數(shù)據(jù)（韻達(dá)的所有訂單數(shù)據(jù)），并實(shí)時(shí)反饋給用戶。此外，這些數(shù)據(jù)也會(huì)給到網(wǎng)點(diǎn)、分撥中心的內(nèi)部員工使用，用于個(gè)人工作量、站點(diǎn)掃描量等統(tǒng)計(jì)工作。在“雙十一、二”期間，面對(duì)快遞業(yè)務(wù)量的暴漲，TDengine 幫助我們很好地完成了既定規(guī)劃，保障了“雙十一、二”任務(wù)的順利完成。

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

從 2.0 到 3.0

在早些年業(yè)務(wù)尚未擴(kuò)張時(shí)，我們采用的是 MySQL 分區(qū)+索引方式進(jìn)行掃描槍數(shù)據(jù)的處理，但隨著企業(yè)的發(fā)展、業(yè)務(wù)量的增加，面對(duì)每日億級(jí)的數(shù)據(jù)量，MySQL 顯然已經(jīng)無(wú)法滿足當(dāng)下的數(shù)據(jù)處理需求。

在這種背景下，我們決定進(jìn)行時(shí)序數(shù)據(jù)庫(kù)（Time Series Database）選型。經(jīng)過(guò)嚴(yán)格的選項(xiàng)測(cè)試，我們最終選擇了 TDengine 作為核心數(shù)據(jù)庫(kù)處理該部分?jǐn)?shù)據(jù)。在 2021 年，我們?cè)谌_(tái) 16C 64G 的服務(wù)器上部署上線了 TDengine 2.0 版本集群。（http://www.fjzmyy.cn/tdengine-user-cases/7815.html）

該集群每天要承載日常 6 億行數(shù)據(jù)的寫入和一定量的查詢，“雙十一、二”等特殊業(yè)務(wù)期間，寫入/查詢量還要上漲 50% 左右，數(shù)據(jù)需要保留 2 個(gè)月。

我們的架構(gòu)是 Spring Boot + MyBatis + MySQL + TDengine，TDengine 負(fù)責(zé)處理時(shí)序數(shù)據(jù)，MySQL 則負(fù)責(zé)非時(shí)序數(shù)據(jù)的存儲(chǔ)及應(yīng)用，如下：

使用 2.0 的這兩年數(shù)據(jù)庫(kù)是很穩(wěn)定的，但考慮到后期業(yè)務(wù)需求會(huì)用到 3.0 的新特性，所以我們自打 TDengine 3.0 發(fā)布之后，就一直在著手準(zhǔn)備數(shù)據(jù)庫(kù)的遷移工作。

數(shù)據(jù)遷移經(jīng)驗(yàn)分享

數(shù)據(jù)庫(kù)遷移是一項(xiàng)很重大的工作，在此期間，我們仔細(xì)梳理了 2.0 版本使用期間的一些使用情況，嘗試做出針對(duì)性的優(yōu)化。

在 2.0 時(shí)期，我們是根據(jù)“一個(gè)掃描槍一張表”的模型建表，把設(shè)備的地點(diǎn)和站點(diǎn)類型設(shè)置為標(biāo)簽。來(lái)到 3.0 時(shí)期后，我們和官方團(tuán)隊(duì)反復(fù)調(diào)試，選擇了“一個(gè)站點(diǎn)一張表”的建模方式。這樣一來(lái)，表數(shù)量從百萬(wàn)級(jí)直接縮減到了萬(wàn)級(jí)。

做這個(gè)改動(dòng)的核心原因有兩個(gè)：

1. 我們有很多臨時(shí)的虛擬掃描槍，由于只是臨時(shí)使用，所以沒(méi)有幾條數(shù)據(jù)，但卻單獨(dú)占據(jù)了一個(gè)表。
2. 雖然掃描槍寫入頻率較低，但是整個(gè)站點(diǎn)有很多掃描槍，這樣的建模方式使得低頻寫入轉(zhuǎn)化為了高頻寫入，降低了存儲(chǔ)中碎片數(shù)據(jù)的比例。

2.x 超級(jí)表結(jié)構(gòu)：

優(yōu)化過(guò)后，3.x 超級(jí)表的結(jié)構(gòu)：

除此之外，3.0 由于底層有很多的重構(gòu)，因此和 2.0 相比出現(xiàn)了很多的參數(shù)改動(dòng)，可以參考：https://docs.taosdata.com/reference/config/，https://docs.taosdata.com/taos-sql/database/。優(yōu)化思路可以參考這篇文章中的內(nèi)容：http://www.fjzmyy.cn/tdengine-engineering/21550.html。

尤其是 3.0 關(guān)于數(shù)據(jù)入庫(kù)頻率、數(shù)據(jù)亂序、更新、建表等處理邏輯的變化，均需要投入一定量的學(xué)習(xí)測(cè)試時(shí)間。尤其是在數(shù)據(jù)量極大的情況下，每一次測(cè)試環(huán)境的搭建都需要較大的時(shí)間人力成本。我們?cè)?TDengine 官方團(tuán)隊(duì)的協(xié)助下，斷斷續(xù)續(xù)大概用了 2 個(gè)月的時(shí)間才完成這個(gè)階段。

優(yōu)化效果顯著

最終優(yōu)化過(guò)后，我們的查詢速度得到了進(jìn)一步提升。尤其是下面這類查詢優(yōu)化效果十分明顯，該查詢的邏輯是：從 6 億行的當(dāng)天數(shù)據(jù)中，通過(guò)標(biāo)簽、普通列做出多次篩選，最終返回分頁(yè)后的十條結(jié)果。其中，最為耗時(shí)的便是從標(biāo)簽過(guò)濾之后的 1.5 億條數(shù)據(jù)的普通列篩選。

在 2.6 版本中，這個(gè)過(guò)程需要大約 10 秒的時(shí)間，升級(jí)到 3.x 之后，只需要 2-3 秒左右便會(huì)返回結(jié)果：

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;

至此，我們從 TDengine 2.0 遷移到 3.0 版本的工作就圓滿完成了。

寫在最后

對(duì)于我們這種集快遞、物流、電子商務(wù)配送和倉(cāng)儲(chǔ)服務(wù)為一體的快遞企業(yè)，掃描槍設(shè)備產(chǎn)生的數(shù)據(jù)是相當(dāng)龐大的，而 TDengine 可以輕松高效地處理和存儲(chǔ)這些時(shí)序數(shù)據(jù)，它所具備的快速寫入和查詢的能力，使得我們的系統(tǒng)可以輕松應(yīng)對(duì)高負(fù)載和大規(guī)模數(shù)據(jù)的需求。

落實(shí)到業(yè)務(wù)使用方面，通過(guò)實(shí)時(shí)了解包裹狀態(tài)、配送進(jìn)度等信息，我們能夠更加方便地做出實(shí)時(shí)決策，物流運(yùn)營(yíng)的效率和效果也獲得了大幅提高。

文章最后，祝 TDengine 越來(lái)越好，早日成為時(shí)序數(shù)據(jù)庫(kù)領(lǐng)域的 NO.1。