本篇文章詳細講述了七云團隊在運維平臺中如何利用 TDengine 解決海量時序數據存儲與查詢的實際業(yè)務需求。內容涵蓋了從數據庫選型、方案落地到業(yè)務挑戰(zhàn)及解決辦法的完整過程，特別是分享了升級 TDengine 3.x 時的實戰(zhàn)經驗，給到有需要的小伙伴參考閱讀。

此前，我?guī)ьI的團隊負責過一個 AIOps 項目，核心任務是存儲和查詢大量時序數據，包括各種系統(tǒng)和性能指標。經過深入調研，我們最終選擇了 TDengine 作為指標數據的存儲引擎。目前，相關業(yè)務已穩(wěn)定運行數年。本文將重點分享我們如何利用 TDengine 實現業(yè)務落地，以及過程中遇到的挑戰(zhàn)與解決方案。

項目介紹

在展開分享之前，我先簡單介紹一下指標采集業(yè)務和 TDengine，以便幫助大家更好地理解背景和技術選型。

1. 指標采集業(yè)務

在運維平臺中，核心的三大基礎功能包括：采集、監(jiān)控和告警。采集是首要環(huán)節(jié)，需要通過多種方式將服務器、應用等關鍵指標數據匯集到平臺中，隨后實現監(jiān)控圖表展示、告警策略觸發(fā)等一系列運維操作。

2. TDengine

TDengine 是一款開源、高性能、云原生的時序數據庫。它針對物聯網、車聯網、工業(yè)互聯網、金融和 IT 運維等場景進行了專門優(yōu)化設計，同時集成了緩存、流式計算、數據訂閱等系統(tǒng)功能。這些特性不僅顯著降低了系統(tǒng)設計的復雜度，還有效減少了研發(fā)和運維成本，是一個極簡高效的時序數據處理平臺。

為什么選擇 TDengine

由于采集業(yè)務的點位眾多且頻率較高，數據存儲需要處理高并發(fā)的寫入（TPS）和監(jiān)控、告警等場景下較高的查詢并發(fā)（QPS）。因此，選擇一個高性能、時序化、且易于橫向擴展的數據存儲引擎是必然的需求。

在調研了常見的時序數據庫解決方案（如 InfluxDB、TimescaleDB、OpenTSDB 和 TDengine）后，我們最終選擇了 TDengine，主要基于以下幾點考慮：

1. 設計理念契合

TDengine 的設計高度貼合我們的數據采集需求：每個設備對應一張超級表，每個指標對應一張子表。這種設計極大簡化了數據存儲和管理的復雜度，讓我們能夠更高效地組織和處理數據。

2. 卓越的性能表現

在性能方面，TDengine 明顯優(yōu)于其他主流時序數據庫。我們參考了官方文檔中基于 TSBS 標準數據集的測試報告，數據顯示 TDengine 在寫入和查詢性能上都具有顯著優(yōu)勢。

報告鏈接：http://www.fjzmyy.cn/performance-comparison-influxdb-and-timescaledb-vs-tdengine

3. 強大的分布式架構

TDengine 從設計之初便以分布式高可靠架構為核心，具備天然的橫向擴展能力。正如官方文檔所述：

TDengine 的設計是基于單個硬件、軟件系統(tǒng)不可靠，基于任何單臺計算機都無法提供足夠計算能力和存儲能力處理海量數據的假設進行設計的。因此 TDengine 從研發(fā)的第一天起，就按照分布式高可靠架構進行設計，是支持水平擴展的，這樣任何單臺或多臺服務器發(fā)生硬件故障或軟件錯誤都不影響系統(tǒng)的可用性和可靠性。同時，通過節(jié)點虛擬化并輔以負載均衡技術，TDengine 能最高效率地利用異構集群中的計算和存儲資源降低硬件投資。

業(yè)務落地方案

1. 庫設計

我們采用以用戶為單位進行庫的拆分，每個用戶對應一個獨立的數據庫。在創(chuàng)建庫時，建議對相關參數進行手動指定，確保對每個配置項的含義和用途有明確的了解。使用默認配置可能在未來使用中因缺乏規(guī)劃而引發(fā)問題。

如果庫中的表數量非常多，建議適當增加 vgroup 參數的值（默認僅為 2）。合理規(guī)劃 vgroup 的數量，可以有效提高系統(tǒng)性能并降低后續(xù)擴展和維護的復雜性。

2. 表設計

我們的設計方案是一個設備創(chuàng)建一張超級表，一個指標創(chuàng)建一張子表。

3. 集群方案

根據不同業(yè)務體量我們劃分了不同的集群設施，我以其中一個集群的要求舉例說明：

•   寫入TPS大約在3w/s
•   查詢QPS大約在1k/s
•   單條指標數據的大小約為0.5KB
•   庫中存儲的數據保留1年

在容量規(guī)劃上，我們主要參考了官方提供的規(guī)劃方案——https://docs.taosdata.com/operation/planning/

做了下面的規(guī)劃內容：

• 內存規(guī)劃

官方推薦的計算公式：vgroups × replica × (buffer + pages × pagesize + cachesize) 參數對號入座，10 * 1 * (32MB + 256MB * 4KB + 1MB) = 340MB 還需要再加上 OS 自身的一些內存消耗，并且冗余一定的 buffer 空間。我們最終每臺節(jié)點分配了 8GB 內存。

• CPU 規(guī)劃

我們來大概計算一下數據分片 & 數據寫入所需要的 CPU 資源：3w/s ÷ 單核1w/s = 3，即只考慮寫入請求次數（每次寫入只寫1條數據，無批量寫入）只需要 3 個 CPU 核心即可。再給幾個用來滿足查詢需求的計算資源冗余，并且保持 CPU 使用率不超過 50%，我們最終每臺節(jié)點分配了 8 個 CPU 核心。

• 磁盤規(guī)劃

在不考慮 TDengine 對落盤數據進行壓縮的情況下，那么每秒的寫入速率是 30000/s * 0.5KB = 15000KB/s，約等于 14.65MB/s，這個數量級的磁盤 IO，哪怕是機械硬盤也很容易滿足性能要求，所以只需要保證磁盤總量足夠即可。我們最終每臺節(jié)點先給了 500GB 的數據盤，隨著數據的增長還在擴容。

• 網絡帶寬規(guī)劃

由于業(yè)務與服務器均部署在同一內網環(huán)境中，數據傳輸可以直接使用內網帶寬。根據上述寫入速率計算，集群間的流量需求完全可以由常見的千兆網卡輕松滿足，無需額外升級網絡配置。

• 節(jié)點數量規(guī)劃

我們根據多個 vgroup 的資源需求，對總資源進行了均衡分配，同時在生產環(huán)境中預留了充分的冗余。最終選用了 3 臺配置為 8 核 CPU / 8 GB 內存 / 500 GB 存儲 的服務器，確保系統(tǒng)的高可用性和穩(wěn)定性。

自制小工具：TD-GUI

基于 TDengine 提供的 REST-API，我開發(fā)了一款便捷的查詢小工具，專為業(yè)務需求設計。同事們在實際工作中廣泛使用這一工具，大大提升了工作效率，并獲得了普遍好評。其實現原理非常簡單：通過拼接 SQL 請求，利用 REST-API 向 TDengine 發(fā)送查詢請求并解析響應結果。雖然工具設計輕量，但在實際應用中展現了強大的實用性。

遇到的挑戰(zhàn)&解決辦法

1. 老版本集群 2.x 存在庫、表信息異常的現象

在使用 TDengine 2.x 集群時，我們偶爾會遇到庫和表信息異常的現象。經過反饋至開源社區(qū)，問題可能源于元數據管理的 Bug。短期解決方案是重啟 TDengine 恢復正常運行，長期是通過升級到 3.x 版本徹底解決了問題，目前已不再復現。

2. 老版本集群 2.x 遷移至新版本 3.x

由于 2.x 和 3.x 版本之間存在不兼容情況，遷移需要將 2.x 數據導出后重新導入至 3.x 集群。然而，面對 2.x 的海量數據，導出速度和數量難以接受，同時還需保證生產系統(tǒng)正常運行。我們采用了數據雙寫策略：新上報的數據同時寫入 2.x 和 3.x 兩套集群，并通過后臺程序逐步將 2.x 的歷史數據讀取并寫入到 3.x 集群，最終實現了數據的平滑遷移。

在雙寫過程中，我們開發(fā)了一個后臺程序，從 2.x 集群中逐步讀取歷史數據，并慢慢寫入到 3.x 集群，實現了對 2.x 的平滑替換。最終，順利完成了版本遷移。這種方法不僅保證了生產系統(tǒng)的正常運行，還有效規(guī)避了 2.x 和 3.x 數據格式不兼容的問題。升級到 3.x 后，我們還遇到了一些小問題，簡單總結如下：

1. 老代碼與新版本兼容性問題遷移過程中，部分代碼需要調整。例如，由于 value 成為保留關鍵字，如果字段名為 value，則在 SQL 中需要使用反引號進行引用。不過，這類問題對整體遷移影響不大。
2. 新版本配置項變動問題雖然 3.x 的大部分配置項與 2.x 基本相同或相似，但仍存在一些細微差異。經過適當調整后，對業(yè)務運行未造成實質性影響。

結語

通過實踐，我們成功將 TDengine 應用于高頻時序數據的存儲與查詢，并在版本遷移和性能優(yōu)化中積累了豐富的經驗。這不僅幫助我們提升了業(yè)務系統(tǒng)的穩(wěn)定性和效率，也驗證了 TDengine 在應對復雜運維場景時的強大能力。希望我們的經驗能為更多技術團隊提供有價值的參考，共同探索時序數據處理的無限可能。

關于七云網絡

七云網絡（上海疊念信息科技有限公司）于 2017 年 1 月份成立于上海，是一家創(chuàng)新型 SDWAN 及網絡運維解決方案服務商。企業(yè)核心成員源自阿里巴巴、思科、中國電信等技術型企業(yè)，擁有豐富的互聯網及企業(yè)信息化服務的經驗。

關于作者

王凱（kaamil Wang），七云網絡 AIOps 產品部主管，熱愛開源，立志成為一名 IT 武林高手。