小t簡介：為了有效處理日運千億級的資料量，早在2024年，韻達就選擇用TDengine替代MySQL，並在三颱伺服器上成功部署並上線了TDENGINE 20 個集群。 如今，隨著TDENGINE 3的推出隨著 0 版本的逐漸成熟，韻達決定替換現有的 2版本 0 公升級到 30 版本，基於本文，我們將分享公升級過程中所做的優化措施以及公升級後的效能。作為一家領先的物流公司，韻達的日訂單掃瞄量超過1億元，這是乙個典型的時間序列資料，也是我們公司資料中最大的部分。 系統需要採集全國網點的掃瞄資料（韻達的所有訂單資料），並實時反饋給使用者。 此外，這些資料還將被網點和配送中心的內部員工用於統計工作，例如個人工作量和現場掃瞄。 在“雙。
十。 “一二”期間，面對快遞業務量的激增，TDENGINE幫我們做好了既定計畫，保證了“雙倍”。
十。 1. 2.任務的成功完成。
本文旨在分享我們公司使用TDengine的歷程和經驗。
早些年，當業務還沒有拓展的時候，我們用MySQL分割槽+索引的方式對掃瞄器的資料進行處理，但隨著企業的發展和業務量的增加，面對每天上億的資料，MySQL顯然已經無法滿足現在的資料處理需求。
在這種背景下，我們決定選擇乙個時序資料庫。 經過對選項的嚴格測試，我們最終選擇了TDENGINE作為核心資料庫來處理這部分資料。 2021 年，我們在三颱 16C 64G 伺服器上部署了 TDEngine 2版本 0 群集。
集群每天要承載 6 億次資料寫入和一定數量的查詢。
十。 在“1、2”等特殊業務期間，寫查詢量應在50%左右，資料需保留2個月。
我們的架構是Spring Boot+MyBat+MySQL+TDengine，TDENGINE負責處理時序資料，MySQL負責非時序資料的儲存和應用，具體如下：
使用 20 的資料庫在兩年內非常穩定，但 3. 將用於考慮後期業務需求0 個新功能，所以我們打了 TDengine 3自 0 發布以來，我們一直在為資料庫的遷移做準備。
資料庫遷移是一項艱鉅的任務，我們已經梳理了 2版本 0 使用期間的一些使用情況，嘗試進行有針對性的優化。
在 2在第 0 個週期，我們基於“一掃瞄器，一張桌子”模型構建了乙個表格，並將裝置的位置和站點型別設定為標籤。 來到 30期過後，我們和官方團隊反覆除錯，選擇了“一站一表”的建模方式。 因此，表的數量從數百萬個減少到 10,000 個。
此更改有兩個核心原因：
我們有很多臨時的虛擬掃瞄器，它們沒有幾條資料，因為它們只是臨時使用的，但它們占用了乙個單獨的表。
雖然掃瞄器寫入頻率較低，但整個站點的掃瞄器很多，這種建模方法將低頻寫入轉換為高頻寫入，降低了儲存中碎片資料的比例。
2.x 超級表結構：
優化後，3x 超級手錶的結構：
除此之外，還有 3 個0 由於底部有很多重構，所以和 2 一樣0 對比很多引數改動，可以參考： 有關優化思路，請參考本文內容：
特別是 30 處理邏輯的變化需要一定的學習和測試時間，例如資料儲存頻率、資料亂序、更新和表建立等。 特別是在資料量大的情況下，每個測試環境都需要大量的時間和人力成本。 在TDENGINE官方團隊的協助下，斷斷續續地完成了這個階段，大約花了2個月的時間。
經過最終的優化，我們的查詢速度得到了進一步的提公升。 特別是下面查詢的優化效果明顯，查詢的邏輯是，從如今的6億行資料中，通過標籤和普通列進行多次篩選，最後經過分頁後返回十個結果。 其中，最耗時的是1對 5 億條資料進行正常列篩選。
在 2在版本 6 中，此過程大約需要 10 秒才能公升級到版本 3x，返回結果只需 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 >= # and ts <= # and site_type=# and equipment_code = # limit 0,10;
至此，我們從TDENGINE 2開始0 到 3版本 0 已完成。
對於像我們這樣集快遞、物流、電商配送、倉儲服務於一體的快遞公司來說，掃瞄裝置產生的資料量相當大，而TDENGINE能夠輕鬆高效地處理和儲存這些時序資料，其快速寫入和查詢的能力，使我們的系統輕鬆應對高負載、大規模資料的需求。
在業務使用方面，我們可以通過實時了解包裹的狀態、派送進度等資訊，更輕鬆地做出實時決策，物流運營的效率和有效性也得到了極大的提高。
在文章的最後，祝願TDEngine越來越好，早日成為時序資料庫領域的No.1。