“雙十一、二” 業務高峰如何扛住?韻達快遞選擇 TDengine

TDengine發表於2023-12-25

小 T 導讀:

為了有效處理每日億級的資料量,早在 2021 年,韻達就選擇用 TDengine 替代了 MySQL,並在三臺伺服器上成功部署和上線了 TDengine 2.0 叢集。如今,隨著 TDengine 3.0 版本的逐漸成熟,韻達決定將現有的 2.0 版本升級到 3.0 版本,並基於本文為大家分享其在升級過程中所進行的最佳化措施以及升級後的效能表現。

作為一家頭部物流公司,韻達每日的訂單掃描量破億級別,該類資料為典型的時序資料,這也是我們公司資料量最大的一塊業務。系統需要彙總統計全國網點的掃描資料(韻達的所有訂單資料),並實時反饋給使用者。此外,這些資料也會給到網點、分撥中心的內部員工使用,用於個人工作量、站點掃描量等統計工作。在“雙十一、二”期間,面對快遞業務量的暴漲,TDengine 幫助我們很好地完成了既定規劃,保障了“雙十一、二”任務的順利完成。

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

從 2.0 到 3.0

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

在這種背景下,我們決定進行時序資料庫(Time Series Database)選型。 經過嚴格的選項測試,我們最終選擇了 TDengine 作為核心資料庫處理該部分資料。在 2021 年,我們在三臺 16C 64G 的伺服器上部署上線了 TDengine 2.0 版本叢集。

該叢集每天要承載日常 6 億行資料的寫入和一定量的查詢,“雙十一、二”等特殊業務期間,寫入/查詢量還要上漲 50% 左右,資料需要保留 2 個月。

我們的架構是 Spring Boot + MyBatis + MySQL + TDengine,TDengine 負責處理時序資料,MySQL 則負責非時序資料的儲存及應用,如下:

使用 2.0 的這兩年資料庫是很穩定的,但考慮到後期業務需求會用到 3.0 的新特性,所以我們自打 TDengine 3.0 釋出之後,就一直在著手準備資料庫的遷移工作。

資料遷移經驗分享

資料庫遷移是一項很重大的工作,在此期間,我們仔細梳理了 2.0 版本使用期間的一些使用情況,嘗試做出針對性的最佳化。

在 2.0 時期,我們是根據“一個掃描槍一張表”的模型建表,把裝置的地點和站點型別設定為標籤。 來到 3.0 時期後,我們和官方團隊反覆除錯,選擇了“一個站點一張表”的建模方式。這樣一來,表數量從百萬級直接縮減到了萬級。

做這個改動的核心原因有兩個:

  1. 我們有很多臨時的虛擬掃描槍,由於只是臨時使用,所以沒有幾條資料,但卻單獨佔據了一個表。
  2. 雖然掃描槍寫入頻率較低,但是整個站點有很多掃描槍,這樣的建模方式使得低頻寫入轉化為了高頻寫入,降低了儲存中碎片資料的比例。

2.x 超級表結構:

最佳化過後,3.x 超級表的結構:

除此之外,3.0 由於底層有很多的重構,因此和 2.0 相比出現了很多的引數改動,可以在 TDengine 官網搜尋官方文件作為參考。

尤其是 3.0 關於資料入庫頻率、資料亂序、更新、建表等處理邏輯的變化,均需要投入一定量的學習測試時間。尤其是在資料量極大的情況下,每一次測試環境的搭建都需要較大的時間人力成本。我們在 TDengine 官方團隊的協助下,斷斷續續大概用了 2 個月的時間才完成這個階段。

最佳化效果顯著

最終最佳化過後,我們的查詢速度得到了進一步提升。尤其是下面這類查詢最佳化效果十分明顯,該查詢的邏輯是:從 6 億行的當天資料中,透過標籤、普通列做出多次篩選,最終返回分頁後的十條結果。其中,最為耗時的便是從標籤過濾之後的 1.5 億條資料的普通列篩選。

在 2.6 版本中,這個過程需要大約 10 秒的時間,升級到 3.x 之後,只需要 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 >= #{beginTime} and ts <= #{endTime} and site_type=#{siteType} and equipment_code = #{equipmentCode} limit 0,10;

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

寫在最後

對於我們這種集快遞、物流、電子商務配送和倉儲服務為一體的快遞企業,掃描槍裝置產生的資料是相當龐大的,而 TDengine 可以輕鬆高效地處理和儲存這些時序資料,它所具備的快速寫入和查詢的能力,使得我們的系統可以輕鬆應對高負載和大規模資料的需求。

落實到業務使用方面,透過實時瞭解包裹狀態、配送進度等資訊,我們能夠更加方便地做出實時決策,物流運營的效率和效果也獲得了大幅提高。

文章最後,祝 TDengine 越來越好,早日成為時序資料庫領域的 NO//1。

來自 “ ITPUB部落格 ” ,連結:https://blog.itpub.net/70014783/viewspace-3001475/,如需轉載,請註明出處,否則將追究法律責任。

相關文章