小T導讀：自 2021 年我們正式使用 TDengine 至今已接近三年，現(xiàn)在 TDengine 已經成熟應用于我們多個項目當中，憑借著強大的讀寫存儲能力，為我司多項業(yè)務的核心數(shù)據保駕護航。近期我們團隊剛好完成 TDengine 2.x 到 3.x 的數(shù)據遷移，借此機會將 TDengine 的使用/遷移經驗與大家分享。

選型過程及業(yè)務背景

我司的主要業(yè)務之一就是基于 3D 打印技術給客戶提供整體化解決方案，其中一個核心場景是我們要持續(xù)追蹤設備的運行狀態(tài)，存儲海量的設備運行數(shù)據。這是一個典型的物聯(lián)網系統(tǒng)的核心需求——以設備為維度，按照時間順序大批量寫入和查詢設備的各項數(shù)據。

這個業(yè)務場景非常適合時序數(shù)據庫（Time Series Database，TSDB），但市場上的時序數(shù)據庫存在著各種各樣的痛點：或是數(shù)據讀寫性能不佳；或是部署的復雜性高，或是難以維護。經過多方考察對比后，我們發(fā)現(xiàn) TDengine 是最適合我們的選擇。

TDengine 遷移過程

為順利升級到 TDengine 3.x 版本，我們先把數(shù)據從 2.x 抽出寫入到了一個 3.x 版本的臨時集群，驗證無誤之后，再利用如下方案實現(xiàn)了無需停機、不影響業(yè)務寫入的 3.x 版本之間的數(shù)據庫遷移工作。過程如下：

a. 新增節(jié)點D\E\F：

CREATE DNODE "D";
CREATE DNODE "E";
CREATE DNODE "F";

b. 逐個刪除節(jié)點A\B\C（以 A 為例）：

#刪除A節(jié)點MNODE角色
DROP MNODE ON DNODE A_DNODE_ID;

#添加D節(jié)點MNODE角色
CREATE MNODE ON DNODE D_DNODE_ID;

#刪除A節(jié)點，節(jié)點A刪除過程，節(jié)點A的數(shù)據會同步到接口D\E\F中
DROP DNODE A_DNODE_ID;

典型業(yè)務場景分享

由于一臺設備每天有數(shù)以萬計的數(shù)據需要存儲，世界各地范圍內的設備匯集起來，便產生了海量的數(shù)據存儲和查詢需求。關于 TDengine ，我們主要有以下三個方向的應用：

• 在設備運行出現(xiàn)問題時，根據消息定位具體的問題；
• 以設備長時間運行的數(shù)據作數(shù)據分析，解決設備運行存在的隱患；
• 生成 BI 報表，展示設備各種傳感器最近一段時間的狀態(tài)。

從眾多的超級表中，我們取一個百億級別的超級表來舉例說明 TDengine 的應用過程，具體表結構如下：

當我們對這張設備消息表 s_mqtt 查詢 ‘2023-12-15 00:00’ 至 ‘2023-12-15 02:50:00’ 時間段的 ‘1011’ 類型，設備序列號為 ‘xxxxxxx’ 的所有消息內容，可以看到，查詢結果是毫秒級返回的：

select * from s_mqtt where ts>'2023-12-15 00:00:00.000' and ts<'2023-12-15 03:00:00.000' and device_sn='xx' and kind=1011 ;

TDengine 高效的寫入和讀取性能很好的滿足了我們頻繁寫入和讀取數(shù)據的迫切需要。而在存儲方面，壓縮率經過計算在 10% 左右，也完全符合我們的存儲需求。

遇到的問題

在 2.x 升級到 3.x 的過程中，我們遇到了以下兩個比較棘手的問題，得到了 TDengine 官方技術團隊的技術講解和遠程排查問題等支持，在此衷心表達感謝。

1. vgroups 設置問題。TDengine 3.x 版本增加了 vgroups 參數(shù)，代表了數(shù)據庫讀寫數(shù)據的一個并行度，合理的設置可以最大程度的激發(fā)讀寫性能。我們在測試環(huán)境測試時，發(fā)覺表的讀寫比 2.x 版本慢了好多，經 TDengine 技術團隊排查，發(fā)現(xiàn)我們只使用了默認的 2 個 vgroups，具體使用規(guī)則可以參考參考《體驗 TDengine 3.0 高性能的第一步，請學會控制建表策略》。

2. taosAdapter 無返回問題。在 TDengine 3.x 版本上線后，微服務通過 restful 方式連接 TDengine 時，taosAdapter 會出現(xiàn)無響應但 taosd 服務正常的現(xiàn)象。這個問題我們自己排查了好久，后面尋求官方技術團隊的幫忙，經過遠程排查服務器環(huán)境和日志分析，最后定位到是我們大量使用”show cluster alive”作為微服務監(jiān)聽語句的頻繁請求導致。隨后官方建議我們更換”select 1″作為健康檢查語句，順利解決了這個問題。后續(xù)官方也優(yōu)化了”show cluster alive”這個命令的實現(xiàn)，避免類似情況出現(xiàn)。

未來展望

使用 TDengine 三年來，TDengine 在我們的物聯(lián)網業(yè)務、設備 BI 數(shù)據展示等模塊作用巨大，它直觀地展示了設備運行狀況，幫助我們快速定位和解決設備問題。接下來，我們將會繼續(xù)探索 TDengine 在智能設備打印、智能設備運維等方面應用與實踐。祝 TDengine 越來越好。