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

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

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

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

一、落地實踐與效果展示

當前我們的架構是 Spring Boot + MyBatis + MySQL + TDengine，TDengine 負責處理時序數(shù)據(jù)，MySQL 則負責非時序數(shù)據(jù)的存儲及應用，整體架構如下：

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

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

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

當前，這個超級表下面已經有了近百萬子表，經過 1 個多月的正式使用，保存了大約 200 億行的數(shù)據(jù)量。

值得一提的是，基于 TDengine 常用的查詢基本可以在 1 秒之內完成，一些特定查詢甚至可以達到毫秒級：

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;

展示效果如下：

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

二、寫在最后

當然，TDengine 的測試使用過程中也并非一帆風順，我們也遇到了一些問題，放在這里供大家參考：

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

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