> 小 T 導讀：此前，韻達使用 MySQL 分割槽+索引處理訂單資料的方式遭受到了挑戰，面對每日億級的資料量，MySQL 顯然已經無法滿足當下的資料處理需求。為更好地發展業務，在此基礎上韻達新增了 TDengine 的資料來源，用專業的資料庫來進行時序資料的處理。

作為一家頭部物流公司，韻達每日的訂單掃描量能達到上億級，這也是目前公司資料量最大的一塊業務。要保證業務的正常運作，系統就需要彙總統計全國網點的掃描資料（韻達的所有訂單資料），並實時反饋給使用者。此外，這些資料也會給到網點、分撥中心的內部員工使用，用於個人工作量、站點掃描量等統計工作。

在業務尚未擴張之前，我們採用的是 MySQL 分割槽+索引方式進行此類資料的處理，但隨著企業的發展、業務量的增加，面對每日億級的資料量，MySQL 顯然已經無法滿足當下的資料處理需求。

在這種背景下，我們決定進行資料庫選型。考慮到目前業務主要是統計各個網點裝置實時上傳的資料，無需再進行修改等操作，是典型的時序資料。經過一番調研，我們發現時序資料庫 TDengine 就很符合當下的業務要求，其資料模型與我們的場景十分契合，基於百億千億級大資料量的查詢效能也很強悍。在對 TDengine 進行實際測試與使用後，實際的效果也讓我們很滿意。

**一、落地實踐與效果展示**

當前我們的架構是 Spring Boot + MyBatis + MySQL + TDengine，TDengine 負責處理時序資料，MySQL 則負責非時序資料的儲存及應用，整體架構如下：
![](http://img.blog.itpub.net/blog/2022/04/26/69c78e390fb5a235.png?x-oss-process=style/bb)

由於我們的架構未做遷移，只是新增了 TDengine 的資料來源，因此沒有增加很多工作量就完成了資料架構的升級。
![](http://img.blog.itpub.net/blog/2022/04/26/093fe473481ccdaa.png?x-oss-process=style/bb)

![](http://img.blog.itpub.net/blog/2022/04/26/7f2a828d7a6993e1.png?x-oss-process=style/bb)

**我們目前使用 TDengine2.2.2.0 版本，在三臺 16C 64G 的伺服器上部署了叢集，資料寫入速度大概為每秒 2000 行。根據“一個掃描槍一張表”的模型建表，把裝置的地點和站點型別設定為標籤。**

為了防止裝置更換地點導致標籤值發生變化，我們選擇在建表的時候把地點也放進表名中，這樣一來，當地點發生變化後，也能透過新建一張表達到同樣的使用效果。比如：scan_6100000000265_790117，代表的就是裝置編號為 6100000000265 所在地址為 790117 的掃描槍，當這把掃描槍更換位置的時候，我們可以新建一張 scan_6100000000265_800000 的子表，和舊錶區分開，並且同時保留兩份資料。

當前，這個超級表下面已經有了近百萬子表，經過 1 個多月的正式使用，儲存了大約 200 億行的資料量。
![](http://img.blog.itpub.net/blog/2022/04/26/ea8c0055f46ccb11.png?x-oss-process=style/bb)

![](http://img.blog.itpub.net/blog/2022/04/26/fc0f699c5e12d485.png?x-oss-process=style/bb)

值得一提的是，基於 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;

![](http://img.blog.itpub.net/blog/2022/04/26/2a2c4956e80e6170.png?x-oss-process=style/bb)

展示效果如下：
![](http://img.blog.itpub.net/blog/2022/04/26/c6b06454d237058e.png?x-oss-process=style/bb)

> 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;

![](http://img.blog.itpub.net/blog/2022/04/26/6798c33300d3efe5.png?x-oss-process=style/bb)

展示效果如下：
![](http://img.blog.itpub.net/blog/2022/04/26/ea9508ebfedbc27a.png?x-oss-process=style/bb)

在儲存上可以看到，我們的超級表是 20 個欄位，大部分是 int 型別，有 5 個左右是 varchar 型別，最大的欄位是一個用來儲存中文的 500 長度的 nchar ，大約佔用300GB 不到的磁碟。而此前使用 MySQL 時，光硬碟使用就需要幾個TB，這還沒有算上記憶體和 CPU 等資源，由此可見 TDengine 帶來的降本增效是多麼顯著。

**寫在最後**

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

- 由於對資料併發量預估不足，我們使用的預設毫秒時間精度經常會出現時間戳重複的現象，導致資料沒能成功入庫，後續依靠增加精度解決。
- 超級表如果新增標籤，已有資料的標籤為 null，需要手動為每個子表更改標籤，不夠友好。
- 由於 TDengine 建表是單執行緒所以是有瓶頸的，大概每秒是萬張以下，所以在初步搭建環境的時候不建議使用自動建表，如果表資料量不多就無所謂了。

在與 TDengine 的社群工作人員反饋之後，以上問題最終都透過引數的配置最佳化或者合理的使用方式得到了解決，之後我們會考慮把TDengine擴充套件到更多業務中去。相信隨著 3.0 的最佳化，TDengine 可以更好地融入到韻達的使用場景中，未來我們會有更加緊密的合作。

------------

想了解更多 TDengine 的具體細節，歡迎大家在[GitHub](https://github.com/taosdata/TDengine "GitHub")上檢視相關原始碼。
[![](http://img.blog.itpub.net/blog/2022/03/31/0fd6ee826ee55f96.jpeg?x-oss-process=style/bb)](https://www.taosdata.com/?utm_source=itpub&utm_medium=tdengine&utm_campaign=usecase&utm_term=20220426)

“一個掃描槍一張表”，韻達選擇 TDengine 應對每日億級資料量

相關文章