小 T 導(dǎo)讀：此前，韻達(dá)使用 MySQL 分區(qū)+索引處理訂單數(shù)據(jù)的方式遭受到了挑戰(zhàn)，面對(duì)每日億級(jí)的數(shù)據(jù)量，MySQL 顯然已經(jīng)無(wú)法滿(mǎn)足當(dāng)下的數(shù)據(jù)處理需求。為更好地發(fā)展業(yè)務(wù)，在此基礎(chǔ)上韻達(dá)新增了 TDengine 的數(shù)據(jù)源，用專(zhuān)業(yè)的數(shù)據(jù)庫(kù)來(lái)進(jìn)行時(shí)序數(shù)據(jù)的處理。

作為一家頭部物流公司，韻達(dá)每日的訂單掃描量能達(dá)到上億級(jí)，這也是目前公司數(shù)據(jù)量最大的一塊業(yè)務(wù)。要保證業(yè)務(wù)的正常運(yùn)作，系統(tǒng)就需要匯總統(tǒng)計(jì)全國(guó)網(wǎng)點(diǎn)的掃描數(shù)據(jù)（韻達(dá)的所有訂單數(shù)據(jù)），并實(shí)時(shí)反饋給用戶(hù)。此外，這些數(shù)據(jù)也會(huì)給到網(wǎng)點(diǎn)、分撥中心的內(nèi)部員工使用，用于個(gè)人工作量、站點(diǎn)掃描量等統(tǒng)計(jì)工作。

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

在這種背景下，我們決定進(jìn)行數(shù)據(jù)庫(kù)選型。考慮到目前業(yè)務(wù)主要是統(tǒng)計(jì)各個(gè)網(wǎng)點(diǎn)設(shè)備實(shí)時(shí)上傳的數(shù)據(jù)，無(wú)需再進(jìn)行修改等操作，是典型的時(shí)序數(shù)據(jù)。經(jīng)過(guò)一番調(diào)研，我們發(fā)現(xiàn)時(shí)序數(shù)據(jù)庫(kù) TDengine 就很符合當(dāng)下的業(yè)務(wù)要求，其數(shù)據(jù)模型與我們的場(chǎng)景十分契合，基于百億千億級(jí)大數(shù)據(jù)量的查詢(xún)性能也很強(qiáng)悍。在對(duì) TDengine Database 進(jìn)行實(shí)際測(cè)試與使用后，實(shí)際的效果也讓我們很滿(mǎn)意。

一、落地實(shí)踐與效果展示

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

由于我們的架構(gòu)未做遷移，只是新增了 TDengine 的數(shù)據(jù)源，因此沒(méi)有增加很多工作量就完成了數(shù)據(jù)架構(gòu)的升級(jí)。

我們目前使用 TDengine 2.2.2.0 版本，在三臺(tái) 16C 64G 的服務(wù)器上部署了集群，數(shù)據(jù)寫(xiě)入速度大概為每秒 5000 行。根據(jù)“一個(gè)掃描槍一張表”的模型建表，把設(shè)備的地點(diǎn)和站點(diǎn)類(lèi)型設(shè)置為標(biāo)簽。

為了防止設(shè)備更換地點(diǎn)導(dǎo)致標(biāo)簽值發(fā)生變化，我們選擇在建表的時(shí)候把地點(diǎn)也放進(jìn)表名中，這樣一來(lái)，當(dāng)?shù)攸c(diǎn)發(fā)生變化后，也能通過(guò)新建一張表達(dá)到同樣的使用效果。比如：scan_6100000000265_790117，代表的就是設(shè)備編號(hào)為 6100000000265 所在地址為 790117 的掃描槍?zhuān)?dāng)這把掃描槍更換位置的時(shí)候，我們可以新建一張 scan_6100000000265_800000 的子表，和舊表區(qū)分開(kāi)，并且同時(shí)保留兩份數(shù)據(jù)。

當(dāng)前，這個(gè)超級(jí)表下面已經(jīng)有了近百萬(wàn)子表，經(jīng)過(guò) 1 個(gè)多月的正式使用，保存了大約 200 億行的數(shù)據(jù)量。

值得一提的是，基于 TDengine 常用的查詢(xún)基本可以在 1 秒之內(nèi)完成，一些特定查詢(xún)甚至可以達(dá)到毫秒級(jí)：

select location,sum(weight_info) as weightSum,count (waybill_barcode) as ticketNum from base.scan_data where ts>='2022-04-07 00:00:00' and ts<='2022-04-07 23:59:59' group by location;

展示效果如下：

select waybill_barcode,location,scanning_person,scan_category,remark,weight_info weight,scan_time,volume from base.scan_data where ts>='2022-04-07 00:00:00' and ts<='2022-04-07 23:59:59' and site_type=3 limit 0,10;

展示效果如下：

在存儲(chǔ)上可以看到，我們的超級(jí)表是 20 個(gè)字段，大部分是 int 類(lèi)型，有 5 個(gè)左右是 varchar 類(lèi)型，最大的字段是一個(gè)用來(lái)存儲(chǔ)中文的 500 長(zhǎng)度的 nchar ，大約占用 300GB 不到的磁盤(pán)（單副本）。而此前使用 MySQL 時(shí)，光硬盤(pán)使用就需要幾個(gè) TB（主從），這還沒(méi)有算上內(nèi)存和 CPU 等資源，由此可見(jiàn) TDengine 帶來(lái)的降本增效是多么顯著。

二、寫(xiě)在最后

當(dāng)然，TDengine 的測(cè)試使用過(guò)程中也并非一帆風(fēng)順，我們也遇到了一些問(wèn)題，放在這里供大家參考：

• 由于對(duì)數(shù)據(jù)并發(fā)量預(yù)估不足，我們使用的默認(rèn)毫秒時(shí)間精度經(jīng)常會(huì)出現(xiàn)時(shí)間戳重復(fù)的現(xiàn)象，導(dǎo)致數(shù)據(jù)沒(méi)能成功入庫(kù)，后續(xù)依靠增加精度解決。
• 超級(jí)表如果新增標(biāo)簽，已有數(shù)據(jù)的標(biāo)簽為 null，需要手動(dòng)為每個(gè)子表更改標(biāo)簽，不夠友好。
• 由于 TDengine 建表是單線程所以是有瓶頸的，大概每秒是萬(wàn)張以下，所以在初步搭建環(huán)境的時(shí)候不建議使用自動(dòng)建表，如果表數(shù)據(jù)量不多就無(wú)所謂了。

在與 TDengine 的社區(qū)工作人員反饋之后，以上問(wèn)題最終都通過(guò)參數(shù)的配置優(yōu)化或者合理的使用方式得到了解決，之后我們會(huì)考慮把TDengine擴(kuò)展到更多業(yè)務(wù)中去。相信隨著 3.0 的優(yōu)化，TDengine 可以更好地融入到韻達(dá)的使用場(chǎng)景中，未來(lái)我們會(huì)有更加緊密的合作。