“雙十一、二” 業務高峰如何扛住?韻達快遞選擇 TDengine
小 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 時期後,我們和官方團隊反覆除錯,選擇了“一個站點一張表”的建模方式。這樣一來,表數量從百萬級直接縮減到了萬級。
做這個改動的核心原因有兩個:
- 我們有很多臨時的虛擬掃描槍,由於只是臨時使用,所以沒有幾條資料,但卻單獨佔據了一個表。
- 雖然掃描槍寫入頻率較低,但是整個站點有很多掃描槍,這樣的建模方式使得低頻寫入轉化為了高頻寫入,降低了儲存中碎片資料的比例。
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/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 韻達快遞要如何批次匯出到表格呢?
- 如何扛住遊戲流量高峰?Evil Dead 主創這樣說遊戲
- 扛住阿里雙十一高併發流量,Sentinel是怎麼做到的?阿里
- 特殊時期,釘釘如何透過單元化扛住流量高峰?
- go-zero 如何扛住流量衝擊(二)Go
- GitHub 標星 11000+,阿里開源的微服務元件如何連續 10 年扛住雙十一大促?Github阿里微服務元件
- “一個掃描槍一張表”,韻達選擇 TDengine 應對每日億級資料量
- 怎麼快速匯出大量韻達快遞到表格?
- 2022年4月快遞公司單量普降 韻達快遞完成單量同比下滑19.37%
- APIshop精選介面助力雙十一電商業務API
- 韻達快運宣佈新增“韻重貨”JRF
- 除了官網還有哪裡可以查詢快遞?支援韻達、百世等多家快遞
- 服務鄉村電商,韻達快遞助力秭歸臍橙秭拓銷全國
- 國家郵政局:2024年雙十一全國郵政快遞企業共處理快遞包裹7.01億件 是日常業務量的151%
- 韻達快遞高品質冷鏈服務,助力各類生鮮產品高效運輸
- 58同城:解讀2021年雙十一快遞行業招聘求職情況行業求職
- go-zero 如何扛住流量衝擊(一)Go
- SEO業務如何選擇代理IP?
- 應對快遞流量高峰,豐網快遞這樣提升配送效率
- 國家郵政局:2021年“雙11”期間全國快遞業務量達68億件
- 支援新疆鄉村振興,韻達快遞助力新疆特產賣向全國
- TDengine 社群問題雙週精選 | 第二期
- 使用阿里雲PolarDB替代Oracle資料庫,申通完美扛過618業務高峰阿里Oracle資料庫
- 述說韻達快遞小哥的故事,致敬每一個平凡工作的普通人
- 起底快遞上市企業薪資水平 順豐申通韻達員工平均工資多少介紹
- 化工企業如何選擇雙重預防機制數字化服務商
- 快取之美——如何選擇合適的本地快取?快取
- 電商小白該選擇怎樣的快遞查詢工具?
- 快遞都比外賣快了?快遞按下“加速鍵” 今年雙11快遞為什麼這麼快?
- 流的操作(二)如何選擇流?
- 教你批次查詢快遞並篩選出快遞公司
- 韻達基於雲原生的業務中臺建設 | 實戰派
- 申通快遞:2022 年 12 月快遞服務業務收入 30.5 億元 同比增長 8.31%
- 企業如何選擇代理IP?
- 2022年5月韻達完成業務量14.85億票 同比下滑7.88%
- 詳解快取更新策略及如何選擇快取
- 弘遼科技:雙十一再創高峰,剁手黨成就電商傳奇
- 今日資料行業日報(2020.11.13)『2020年雙11快遞量達6.75億件 創歷史新高』行業