小T導讀：自 2021 年我(wo)(wo)們正(zheng)式使用(yong) TDengine 至今已接近(jin)三年，現(xian)在 TDengine 已經(jing)成(cheng)(cheng)熟應用(yong)于我(wo)(wo)們多(duo)個項目當中，憑借著(zhu)強(qiang)大的(de)讀寫存儲能(neng)力，為(wei)我(wo)(wo)司多(duo)項業務的(de)核(he)心數(shu)據保駕(jia)護航(hang)。近(jin)期我(wo)(wo)們團(tuan)隊剛好完成(cheng)(cheng) TDengine 2.x 到 3.x 的(de)數(shu)據遷移，借此機會將(jiang) TDengine 的(de)使用(yong)/遷移經(jing)驗與(yu)大家(jia)分享(xiang)。

選型過程及業務背景

我司(si)的主要業務(wu)之一就是(shi)基于 3D 打印技術給客戶(hu)提供(gong)整(zheng)體(ti)化(hua)解(jie)決方案，其中一個(ge)(ge)核(he)心場景是(shi)我們要持續(xu)追蹤設(she)備(bei)的運(yun)行(xing)狀態(tai)，存儲(chu)海量的設(she)備(bei)運(yun)行(xing)數(shu)據。這是(shi)一個(ge)(ge)典型的物聯網系統的核(he)心需求(qiu)——以設(she)備(bei)為維度，按照時間(jian)順(shun)序大批量寫入(ru)和查詢設(she)備(bei)的各項數(shu)據。

這個業務場景非常適合時序數據庫（Time Series Database，TSDB），但市場上的(de)(de)時序數(shu)據(ju)庫存在著各(ge)種各(ge)樣的(de)(de)痛點：或是(shi)數(shu)據(ju)讀寫(xie)性能不佳；或是(shi)部署的(de)(de)復(fu)雜(za)性高，或是(shi)難以維護(hu)。經過多方(fang)考察對(dui)比(bi)后，我(wo)們(men)發現 TDengine 是(shi)最適合我(wo)們(men)的(de)(de)選擇。

TDengine 遷移過程

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

a. 新增節點D\E\F：

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

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

#刪除A節點MNODE角色
DROP MNODE ON DNODE A_DNODE_ID;

#添加D節點MNODE角色
CREATE MNODE ON DNODE D_DNODE_ID;

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

典型業務場景分享

由于一(yi)臺設備(bei)每天(tian)有數(shu)(shu)以萬計的數(shu)(shu)據需(xu)要存儲(chu)，世(shi)界各地范圍內的設備(bei)匯集起來(lai)，便產生(sheng)了(le)海量(liang)的數(shu)(shu)據存儲(chu)和查詢需(xu)求(qiu)。關于 TDengine ，我們(men)主要有以下三個方(fang)向的應用：

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

從眾多(duo)的超級(ji)表中，我們(men)取一個百(bai)億級(ji)別的超級(ji)表來(lai)舉(ju)例(li)說明 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 高效的寫入和讀取性能很好的滿足了我們頻繁寫入和讀取數據的迫切需要。而在存儲方面，壓縮率經過計算在 10% 左右，也完全符合我們的存儲需求。

遇到的問題

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

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

2. taosAdapter 無返回問題。在 TDengine 3.x 版本上線后，微服(fu)務(wu)通過 restful 方(fang)式連接 TDengine 時(shi)，taosAdapter 會出(chu)現(xian)無響應但 taosd 服(fu)務(wu)正常的現(xian)象。這(zhe)個問題我們自己排查(cha)了(le)好久(jiu)，后面尋(xun)求官方(fang)技術(shu)團隊的幫忙，經過遠程排查(cha)服(fu)務(wu)器(qi)環(huan)境和(he)日志(zhi)分(fen)析，最(zui)后定位到是我們大量使用”show cluster alive”作為(wei)微服(fu)務(wu)監聽(ting)語句的頻繁(fan)請(qing)求導致。隨后官方(fang)建議我們更換”select 1″作為(wei)健康檢(jian)查(cha)語句，順利(li)解決了(le)這(zhe)個問題。后續(xu)官方(fang)也(ye)優化(hua)了(le)”show cluster alive”這(zhe)個命(ming)令的實現(xian)，避免類似情況出(chu)現(xian)。

未來展望

使(shi)用(yong) TDengine 三(san)年來，TDengine 在我(wo)們(men)的物聯網業務、設(she)備(bei) BI 數據展示等模塊作用(yong)巨大(da)，它直觀地展示了設(she)備(bei)運行狀況(kuang)，幫助我(wo)們(men)快(kuai)速定位和(he)解決設(she)備(bei)問題。接下來，我(wo)們(men)將會繼續探索 TDengine 在智(zhi)能(neng)設(she)備(bei)打印、智(zhi)能(neng)設(she)備(bei)運維等方(fang)面應用(yong)與(yu)實(shi)踐。祝(zhu) TDengine 越來越好(hao)。