還在猶豫要不要用 TDengine 3.0？四大企業應用案例合集給你參考

TDengine 3.0 自 2022 年 8 月於 TDengine 開發者大會正式亮相後，至今已經歷多次更新迭代，不久前釋出的《3.2.1.0 釋出！時間轉換函式+BI 整合+檢視正式上線！》為大家介紹了最新版本 3.2.1.0 的最佳化詳情。可以說，經過產品研發人員和社群使用者的不斷努力，3.0 的穩定性和易用性也在不斷提升。在 3.0 版本中，我們對產品底層進行了全面的變化和調整，除了架構的科學性和高效性外，還將使用者體驗作為重點最佳化方向之一。

為了讓大家更深入地瞭解到 TDengine 3.0 在實際企業環境中的應用和效果，本篇文章彙總了四個真實的企業部署實踐案例，給到有需要的使用者參考。

中國地震臺網中心 x TDengine 3.0

“在地震監控領域的視覺化中，最重要的就是展示資訊的完整性、實時性、可互動性，靈活性。TDengine 高效的查詢能力以及簡單易用的 SQL 語句可以很方便的完成上述工作。透過網頁展示工具呼叫 TDengine 的 SQL，我們完成了展示地震事件的主看板：看板中的地圖可以展示臺站的每秒峰值記錄，點選近期地震事件便可以進行一段時間（例如該地震發生時刻前 1min 和後 2min）內的地震資料回放。”

業務背景

近年來，隨著地震臺站密集建設，臺站儀器採集匯入中國地震臺網中心的地震波形資料也增長了一個數量級。地震波形資料主要是指由國家地震臺站、各省區域地震臺網等地震觀測網路系統中地震計採集並傳回中心的資料，具有典型的時序資料特徵，是開展地震監測預警、資料分析與挖掘、地震異常研判等應用的基礎材料。為滿足地震預警資料儲存、檢索和處理的建設與整合需求，以及響應國家國產軟體自主可控的號召，中國地震臺網中心決定選用國產資料庫 TDengine 來儲存和處理地震波形資料。

架構圖

改造效果

該專案目前使用的是 3.0.6.0 版本的 5 節點叢集，單臺伺服器配置為：48CPU(s)， 192GB 記憶體 ，500GB SSD + 1.2TB *6HDD 硬碟。專案執行至今，TDengine 接入的原始資料包每天約 900GB，每秒大概接入超過 5 萬個地震資料包，每天總資料量約 5000 億條。對於常規的 INT 型別資料，TDengine 壓縮比可達到 5%-10% 之間，對於 VARCHAR 型別的資料，壓縮比可達到 15-20%，極大程度地節約儲存成本。在叢集日常負載上，單臺資料庫服務端 CPU 使用率 40%～50%，記憶體佔用 14%～20%，執行平穩。

中移物聯 x TDengine 3.0

“我們當前使用的是 3.0.2.5 版本，但是由於業務本身不允許停機，所以沒辦法做離線升級，後續會由 TDengine 企業版團隊協助我們線上升級至最新版本。TDengine 3.0 的安裝部署上保留了和 2.0 一樣的簡單易用模式，升級操作只需要備份資料檔案目錄，覆蓋安裝即可，而且寫入速度極高，接近硬碟的連續寫入效能。”

業務背景

在中移物聯網的智慧出行場景中，需要儲存車聯網裝置的軌跡點，還要支援對車輛軌跡進行查詢。為了更好地進行資料處理，他們在 2021 年上線了 TDengine 2.4.0.18 版本的 5 節點 3 副本叢集，一直穩定執行。3.0 釋出後又經過幾度最佳化，中移物聯閘道器注到了這一版本的眾多特性，包括 Raft 協議的引入使 TDengine 擁有了更標準的一致性演算法、儲存引擎的重構最佳化了 2.x 版本的設計、查詢靈活度大幅提升、支援更強大的流式計算等等。在經過進一步調研後，其決定進行從 2.x 到 3.x 的大版本升級。

架構圖

改造效果

目前該專案共有 102 萬張子表，已經累積的總資料量已經達到了 2000 億行，3 副本，磁碟佔用 3.1TB。在遷移到 TDengine 3.0 之後，各方面的表現依然非常不錯：業務的寫入峰值達到了 1.2-1.3w 行/s ，資料遷移的過程中可以達到 20w 行/s，這些情況下 TDengine 都可以輕鬆處理；儲存大約只有 MySQL 的 1/7；讀取資料效能也很突出，其最常用的單裝置單日查詢，可以在 0.1s 內返回結果。

搜狐基金 x TDengine 3.0

“由於‘超級表’的存在，資料建模變得非常清晰，幾乎所有查詢都可以以‘超級表’為核心用簡單的 SQL 完成。此外，基於‘自動建表’這個特色功能，我們可以無需校驗就能夠直接建表，這讓我們得以非常輕鬆地完成各只基金資料的拆分建表以及寫入工作。”

業務背景

對於搜狐基金來說，其所購買的資料來源的基金資料都是混在一起的，包含來自國內的 2 萬隻基金，跨越幾十年（從九幾年至今）的數千萬行較寬的資料。此前他們透過 MySQL 來儲存這些資料，首先要把每個基金的資料分表，有一定程度的工作量，只能先全量儲存這些資料在一張表中，但這種大表會導致查詢的效能非常低下，為了應對這一問題，只能透過離線查詢生成每天的基金資料圖片返回給使用者，無法對外提供自定義查詢服務。在此背景下，搜狐基金決定基於 TDengine 3.0 嘗試一下全新的方案。

建模展示

改造效果

我們使用三臺 4C 16GB 的伺服器組建了 TDengine 的叢集。值得一提的是，基金資料是一日一條，屬於低頻次資料。對於這種資料，預設的配置是不夠的。一開始我們的查詢效能並不快，基本都是在秒級別甚至還有更高。透過文件和部落格以及官方團隊的支援，我們放大了 duration 和 stt_trigger 引數，這樣確保了不會產生過多的檔案碎片影響讀寫效能，後續的查詢全部被最佳化至毫秒級別。

智光電氣 x TDengine 3.0

“當前 TDengine 3.0 已成功應用於我司多個工業專案中，涵蓋數萬臺各類工業裝置的資料儲存與查詢。作為資料中臺，TDengine 為上層應用提供了高效的歷史資料查詢，精確到秒級和分鐘級粒度，幫助我們大幅提升了應用效率，同時減少了硬體和人力資源的消耗。”

業務背景

在使用 TDengine 之前，子公司智光研究院在工業專案中使用基於 Apache Hadoop 的 CDH 叢集來做時序業務資料的處理。但是由於資料量級太大，處理佔用了大量資源，導致叢集的不穩定性增加，有頻繁發生崩潰的風險。經過充分測試後，該團隊最終決定把由 HBase 處理的、資料量最大的時序資料業務抽離出來，引入 TDengine 來降低 Hadoop 叢集的壓力，成為獨立出來的資料中臺。

改造後部分查詢展示

改造效果

寫入儲存方面，同樣是列式儲存，以半年的資料作為比較，三副本的 HBase 的總資料量佔用是 10TB，TDengine 三副本的磁碟佔用只有 2TB，儲存成本僅為 HBase 的 20 %。（由於和其他應用共用，記憶體、CPU 方面不好估算，但成本均大幅降低）

在查詢上，智光研究員的業務主要就是針對 rundata_t1m（分鐘級資料）、rundata（原始資料）這兩張千億級別的大型超級表的篩選、過濾、降取樣。應用的查詢效能和 SQL 篩選的時間範圍相關較大，整體上的耗時大概在毫秒級至 2 秒內。

結語

透過上述案例我們能看到，在經過不斷打磨最佳化後，如今的 TDengine 3.0 已經在效能、功能、穩定性各個方面均有大幅提升，從一款時序資料庫（Time Series Database，TSDB）蛻變成為高效能、雲原生、分散式的物聯網、工業大資料平臺。為此，我們也強烈建議老使用者儘快向 TDengine 3.0 版本進行遷移，以便體驗到 TDengine 更加強大的產品力。

為了幫助大家最短時間內在本地完成自助式版本遷移，除了官方文件以外，我們還準備了大量技術文章，全部彙總在《萬字解讀｜怎樣啟用 TDengine 最高價效比？》中，以供有需要的使用者參考。如果你在遷移工作中遇到任何問題，歡迎新增 小T vx：tdengine 尋求幫助。