轉型驅動：橋科院為何選擇 TDengine TSDB

隨著“橋梁智能與綠色建造全國重點實驗室”的技術推進，橋科院的業(yè)務數(shù)字化程度不斷加深，數(shù)據(jù)環(huán)境呈現(xiàn)出典型的物聯(lián)網(wǎng)特征，我們也面臨著以下的核心挑戰(zhàn)：

1. 海量時序數(shù)據(jù)處理瓶頸：橋梁健康監(jiān)測系統(tǒng)需要在橋梁關鍵部位部署數(shù)百個傳感器（如應變、位移、振動、溫濕度傳感器），以每秒數(shù) Hz 的頻率持續(xù)采集數(shù)據(jù)。傳統(tǒng)關系型數(shù)據(jù)庫（如 MySQL）難以承受這種高并發(fā)、持續(xù)的數(shù)據(jù)寫入壓力，且存儲成本急劇上升。
2. 實時分析與預警延遲：對橋梁狀態(tài)的判斷需要基于實時數(shù)據(jù)進行毫秒級到秒級的計算分析，以便在異常情況（如超限振動）發(fā)生時立即告警。傳統(tǒng)數(shù)據(jù)庫復雜的查詢語句無法滿足低延遲的實時分析需求，導致預警滯后。
3. 多項目、多維度數(shù)據(jù)分析困難：橋科院同時管理多個橋梁項目，每個項目的數(shù)據(jù)結構相似但標簽（如橋梁名稱、傳感器位置）不同。傳統(tǒng)方式需要為每座橋創(chuàng)建大量獨立的數(shù)據(jù)表，難以進行跨項目的統(tǒng)一分析和宏觀態(tài)勢研判。

選型決策：經過對多種時序數(shù)據(jù)庫的對比測試，我們最終選擇了 TDengine TSDB。其超高性能的數(shù)據(jù)寫入/查詢效率、極具創(chuàng)新的超級表數(shù)據(jù)模型以及極低的學習和運維成本，完美契合了橋梁工程領域對時序數(shù)據(jù)管理的苛刻要求。

應用成效： TDengine TSDB 帶來的核心收益

引入 TDengine 時序數(shù)據(jù)庫后，我們構建了統(tǒng)一的橋梁數(shù)字化平臺底座，獲得了顯著收益，主要提現(xiàn)在以下四個方面：

• 性能提升：數(shù)據(jù)寫入速度提升數(shù)十倍，輕松應對每秒數(shù)十萬數(shù)據(jù)點的涌入；復雜查詢響應時間從分鐘級降至秒級，實現(xiàn)了真正的實時數(shù)據(jù)分析。
• 成本降低： TDengine TSDB 的高效壓縮技術將原始數(shù)據(jù)存儲空間降低了 80% 以上，大幅降低了長期數(shù)據(jù)存儲的成本。
• 運維簡化：得益于簡潔的超級表模型和標準 SQL 語法，數(shù)據(jù)模型的設計和日常運維工作變得異常簡單，開發(fā)效率顯著提升。
• 決策增強：基于 TDengine TSDB 的實時數(shù)據(jù)能力，我們能夠為業(yè)主提供從“施工監(jiān)控”到“運營管養(yǎng)”的全生命周期數(shù)字化服務，增強了核心競爭力。

核心業(yè)務場景與 TDengine TSDB 實踐

以下展示的是典型業(yè)務場景的技術實現(xiàn)。

場景一：通過重載鐵路橋的主梁動撓度、主梁跨中頂板動態(tài)應力監(jiān)測數(shù)據(jù)，判斷橋上過車速度、過車重量

• 建表語句：

-- 創(chuàng)建傳感器數(shù)據(jù)超級表
CREATE STABLE IF NOT EXISTS bridge_sensor_data (
    ts TIMESTAMP,
    strain_value DOUBLE,  -- 應變值/撓度值
    stress_value DOUBLE,  -- 應力值
    temperature DOUBLE,   -- 溫度（用于補償）
    vibration DOUBLE      -- 振動數(shù)據(jù)
) TAGS (
    sensor_id NCHAR(32),      -- 傳感器ID
    sensor_type NCHAR(20),    -- 傳感器類型: strain/stress/vibration
    bridge_id NCHAR(32),      -- 橋梁ID
    location NCHAR(20),       -- 安裝位置: mid_span/support等
    lane_number TINYINT       -- 車道編號
);

• 查詢語句：

-- 檢測單個車輛通過速度和車重
SELECT 
  start_ts,
  end_ts,
  peak_strain,
  duration_seconds,  
  100/duration_seconds*3.6 as speed_kmh, -- 估算車速：橋梁長度/通過時間（假設橋梁長度100米）
  peak_strain*2.5 as estimated_weight_ton -- 估算車重：峰值應變 × 標定系數(shù)（需要現(xiàn)場標定）
FROM (
  SELECT 
    FIRST(ts) as start_ts,
    LAST(ts) as end_ts,
    MAX(strain_value) - MIN(strain_value) as peak_strain,
    COUNT(*) as data_points,
    (cast(LAST(ts) as bigint) - cast(FIRST(ts) as bigint))/1e9 as duration_seconds
  FROM bridge_sensor_data 
  WHERE bridge_id = 'bridge_001' 
    AND location = 'mid_span'
    AND sensor_type = 'strain'
    AND ts >= '2024-01-01 00:00:00' 
    AND ts <= '2024-01-01 23:59:59'
  INTERVAL(30s)             -- 按30秒時間窗口分組
  HAVING MAX(strain_value) - MIN(strain_value) > 10   -- 過濾掉噪聲，閾值可根據(jù)實際情況調整
);

在重載鐵路橋梁監(jiān)測場景中，傳統(tǒng)關系型數(shù)據(jù)庫難以在毫秒級內處理大量動態(tài)響應數(shù)據(jù)，導致車輛通過速度、重量等關鍵指標計算延遲嚴重。TDengine TSDB 的時序數(shù)據(jù)模型通過“超級表”結構，實現(xiàn)了巨量傳感器數(shù)據(jù)點的高效聚合與實時關聯(lián)。在計算車輛通過時間與重量時，其原生時間窗口聚合能力與流式計算特性，將原本分鐘級的響應延遲壓縮至毫秒級，同時利用高效壓縮算法，將動輒每日 TB 級的振動數(shù)據(jù)存儲成本降低超過 80%，讓長期高頻監(jiān)測與秒級報警成為現(xiàn)實。

場景二：通過橋梁風速儀、振動、撓度數(shù)據(jù)，每 30 秒計算前 10 分鐘最大風力系數(shù)、各方向紊流強度，判斷橋梁產生渦振的報警值

• 建表語句：

-- 橋梁基本信息表
CREATE STABLE bridges (
  ts TIMESTAMP,
  wind_speed FLOAT,           -- 風速(m/s)
  wind_direction FLOAT,       -- 風向(度)
  vibration_x FLOAT,          -- X方向振動加速度(m/s2)
  vibration_y FLOAT,          -- Y方向振動加速度(m/s2)  
  vibration_z FLOAT,          -- Z方向振動加速度(m/s2)
  deflection FLOAT,           -- 撓度(mm)
  temperature FLOAT,          -- 溫度(℃)
  humidity FLOAT              -- 濕度(%)
) TAGS (
  bridge_id NCHAR(20),        -- 橋梁ID
  sensor_id NCHAR(20),        -- 傳感器ID
  sensor_type NCHAR(20),      -- 傳感器類型: wind/vibration/deflection
  location NCHAR(50)          -- 安裝位置: mid_span/side_span/tower etc.
);

• 查詢語句：

SELECT 
  calc_ts as 時間,
  avg_wind_speed as 平均風速,
  max_wind_coefficient as 最大風力系數(shù),
  turbulence_intensity as 紊流強度,
  vertical_vibration as 豎向振動,
  peak_vibration_amplitude as 峰值振幅,
  alert_level as 報警等級,
  vortex_intensity_index as 渦振強度指數(shù),
  -- 實時報警判斷
  CASE 
     WHEN vortex_intensity_index > 5 THEN '嚴重渦振報警'
    WHEN vortex_intensity_index > 3 THEN '中度渦振報警' 
    WHEN vortex_intensity_index > 1 THEN '輕微渦振注意'
    ELSE '正常'
  END as 實時報警信息
FROM (
SELECT
    w.calc_ts,
    w.avg_wind_speed,
    w.max_wind_coefficient,
    w.turbulence_intensity,
    v.rms_vibration_y as vertical_vibration,
    v.peak_vibration_amplitude,
    -- 渦振發(fā)生條件判斷
    CASE 
      WHEN w.avg_wind_speed BETWEEN 5 AND 15        -- 渦振易發(fā)風速區(qū)間
       AND w.turbulence_intensity < 0.2            -- 低紊流條件
       AND v.peak_vibration_amplitude > 0.5        -- 振動幅值閾值
       AND v.rms_vibration_y > 0.1                 -- 豎向振動RMS閾值
      THEN 'HIGH_ALERT'
      WHEN w.avg_wind_speed BETWEEN 3 AND 20
       AND w.turbulence_intensity < 0.3
       AND v.peak_vibration_amplitude > 0.3
       AND v.rms_vibration_y > 0.05
      THEN 'MEDIUM_ALERT'
      ELSE 'NORMAL'
    END as alert_level,
    -- 渦振強度指數(shù) (自定義計算公式)
    (v.peak_vibration_amplitude * w.avg_wind_speed * (1 - w.turbulence_intensity)) as vortex_intensity_index
  FROM
(
-- 計算10分鐘窗口的風力參數(shù)
SELECT 
    _wstart as calc_ts,
    AVG(wind_speed) as avg_wind_speed,
    MAX(wind_speed) as max_wind_speed,
    STDDEV(wind_speed) as wind_stddev,
    AVG(wind_direction) as avg_direction,
    -- 紊流強度 = 標準差/平均值
    STDDEV(wind_speed) / AVG(wind_speed) as turbulence_intensity,
    -- 計算10分鐘最大風力系數(shù) 
    MAX(wind_speed) * 0.6 as max_wind_coefficient
  FROM bridges
  WHERE bridge_id = 'bridge_001' 
    AND sensor_type = 'wind'
    AND ts >= NOW - 10m
  INTERVAL(30s)  -- 每30秒計算一次前10分鐘數(shù)據(jù)
) w 
join 
(-- 計算振動參數(shù)
SELECT
    _wstart as calc_ts,
    SQRT(AVG(vibration_x * vibration_x)) as rms_vibration_x,
    SQRT(AVG(vibration_y * vibration_y)) as rms_vibration_y, 
    SQRT(AVG(vibration_z * vibration_z)) as rms_vibration_z,
    -- 主梁渦振特征頻率(假設橋梁固有頻率0.5-1.5Hz)
    MAX(ABS(vibration_y)) as peak_vibration_amplitude
  FROM bridges
  WHERE bridge_id = 'bridge_001'
    AND sensor_type = 'vibration'
    AND location = 'mid_span'
    AND ts >= NOW - 10m
  INTERVAL(30s)) v ON w.calc_ts = v.calc_ts WHERE w.avg_wind_speed > 2  -- 忽略無風情況
)
WHERE alert_level != 'NORMAL' ORDER BY calc_ts DESC;

橋梁渦振監(jiān)測對數(shù)據(jù)的時效性、多維度關聯(lián)性要求極高，傳統(tǒng)架構下風速、振動、撓度數(shù)據(jù)分散存儲，跨表關聯(lián)分析效率低下，渦振預警常滯后數(shù)分鐘。TDengine TSDB 憑借其原生多表聚合 JOIN 優(yōu)化，實現(xiàn)了風速、振動等多維度數(shù)據(jù)的秒級同步關聯(lián)分析。通過自定義時間窗口實時計算風力系數(shù)、紊流強度與振動幅值，系統(tǒng)能在 30 秒內完成一次前 10 分鐘的全維度風振評估，真正實現(xiàn)了從“事后分析”到“事中預警”的跨越，為橋梁在惡劣風場中的安全運營提供了“數(shù)字屏障”。

場景三：橋梁施工過程關鍵參數(shù)監(jiān)控，此場景用于在橋梁建造過程中對索力、應力、標高等進行實時監(jiān)控，確保施工精度與安全。

• 建表語句：

CREATE STABLE IF NOT EXISTS construction_monitoring (
    ts TIMESTAMP,
    cable_force FLOAT, -- 索力（kN）
    stress FLOAT,      -- 應力（MPa）
    elevation FLOAT    -- 標高（m）
) TAGS (
    project_name NCHAR(50), -- 項目名稱：如‘深中通道S08標’（標簽）
    monitoring_section NCHAR(50) -- 監(jiān)控斷面：如‘B12號墩’（標簽）
);

• 查詢語句：

# 查詢‘深中通道S08標’項目下，所有監(jiān)控斷面在當前時刻的平均索力，用于指導施工
SELECT
    monitoring_section,LAST(cable_force) as current_cable_force
FROM construction_monitoring
WHERE project_name = '深中通道S08標' GROUP BY monitoring_section;

在橋梁建造過程中，索力、應力、標高等參數(shù)需 24 小時連續(xù)監(jiān)測，傳統(tǒng)數(shù)據(jù)庫在海量實時寫入壓力下容易成為系統(tǒng)瓶頸。TDengine TSDB 針對時序數(shù)據(jù)寫入進行了深度優(yōu)化，單節(jié)點即可支持每秒百萬級數(shù)據(jù)點的穩(wěn)定寫入。其超級表模型通過標簽（Tag）區(qū)分不同項目與監(jiān)測斷面，在保持數(shù)據(jù)統(tǒng)一存儲的同時，實現(xiàn)了毫秒級的多斷面并發(fā)查詢。施工團隊可隨時調取任意斷面最新索力數(shù)據(jù)，指導作業(yè)，將施工監(jiān)控從“定期巡查”升級為“實時閉環(huán)”，有效保障了大跨度橋梁施工的毫米級精度與全過程安全。

場景四：橋梁建筑材料性能試驗數(shù)據(jù)分析，此場景用于存儲和分析大量混凝土、鋼材等材料的力學性能試驗數(shù)據(jù)。

• 建表語句：

CREATE STABLE IF NOT EXISTS material_testing (
    ts TIMESTAMP,
    load FLOAT,    -- 荷載（kN）
    displacement FLOAT -- 位移（mm）
) TAGS (
    material_type NCHAR(20), -- 材料類型：如‘C60混凝土’（標簽）
    sample_id NCHAR(20),     -- 試件編號
    test_type NCHAR(20)      -- 試驗類型：如‘抗壓’，‘抗彎’
);

• 查詢語句：

# 統(tǒng)計分析某批次C60混凝土試件的抗壓強度（通過最大荷載計算）
SELECT
    sample_id,MAX(load) as max_load
    FROM material_testing
WHERE material_type = 'C60混凝土' AND test_type = '抗壓' GROUP BY sample_id;

材料試驗數(shù)據(jù)具有典型的時序特征，但傳統(tǒng)分析方式往往依賴批處理與離線報表，無法實時反饋材料性能趨勢。TDengine TSDB 的靈活時間窗口聚合與標準 SQL 支持，使得我們的研發(fā)人員可直接在數(shù)據(jù)庫中完成試驗曲線的特征提取與統(tǒng)計分析。其內置的高效壓縮與降采樣功能，使得長期保存大量高密度試驗數(shù)據(jù)（如混凝土應力-應變全曲線）在經濟上成為可能。TB 級歷史試驗數(shù)據(jù)的關鍵指標查詢仍可保持在秒級響應，為材料配比優(yōu)化、耐久性研究提供了高效的“數(shù)據(jù)實驗室”，加速了新型建材的研發(fā)與應用驗證。

結語

TDengine TSDB 作為橋科院數(shù)字化轉型的核心數(shù)據(jù)引擎，成功地將物聯(lián)網(wǎng)時序數(shù)據(jù)處理能力深度融入到橋梁的科研、建造和管養(yǎng)全鏈條中。它不僅解決了海量數(shù)據(jù)帶來的技術挑戰(zhàn)，更賦能橋科院持續(xù)引領中國橋梁技術向智能化、綠色化方向邁進。

關于橋科院

中鐵大橋科學研究院有限公司是中國唯一以橋梁科研為主業(yè)的國家級高新技術企業(yè)，致力于橋梁智能與綠色建造前沿技術研究。公司集科學研究、試驗檢測、監(jiān)理咨詢、產品產業(yè)于一體，管理著遍布全國的眾多大型橋梁工程項目，業(yè)務涵蓋橋梁健康監(jiān)測、施工監(jiān)控、材料檢測等多個高數(shù)據(jù)產生場景。

作者：李鈞

在萬物互聯(lián)的數(shù)字化浪潮中，海量設備連接與實時數(shù)據(jù)處理成為諸多企業(yè)面臨的兩大困擾。

EMQX 與 TDengine 作為物聯(lián)網(wǎng)連接與大數(shù)據(jù)處理領域的領軍產品，正在通過技術協(xié)同構建端到端的物聯(lián)網(wǎng)/工業(yè)大數(shù)據(jù)解決方案。為工業(yè)互聯(lián)網(wǎng)、車聯(lián)網(wǎng)、能源管理、運維監(jiān)控等諸多場景提供高效可靠的技術支撐。

EMQX：企業(yè)級 MQTT + AI 平臺

EMQX 是一款云原生分布式 MQTT 接入平臺，兼容多種消息傳輸協(xié)議，具備高可用性和擴展性，單節(jié)點支持 500 萬 MQTT 連接，能夠處理大規(guī)模并發(fā)消息傳輸，并提供端到端數(shù)據(jù)加密和細粒度訪問控制功能，充分利用數(shù)據(jù)價值的同時，全面滿足企業(yè)數(shù)據(jù)的合規(guī)性需求，為物聯(lián)網(wǎng)（IoT）和人工智能應用提供可靠的實時消息傳輸和設備連接解決方案。

TDengine：企業(yè)級時序大數(shù)據(jù)平臺

TDengine 是一款專為物聯(lián)網(wǎng)、工業(yè)互聯(lián)網(wǎng)等場景設計并優(yōu)化的大數(shù)據(jù)平臺，其核心模塊是高性能、集群開源、云原生、極簡的時序數(shù)據(jù)庫。它能安全高效地將大量設備每天產生的高達 TB 甚至 PB 級的數(shù)據(jù)進行匯聚、存儲、分析和分發(fā)，并提供AI 智能體對數(shù)據(jù)進行預測與異常檢測，提供實時的商業(yè)洞察。

強強聯(lián)手，云端合作

作為核心合作伙伴，TDengine 與 EMQX 的私有化部署早已完成深度生態(tài)適配。在 SaaS 領域，雙方合作再進一步：TDengine Cloud 此前已全面支持 MQTT 數(shù)據(jù)源接入，實現(xiàn)與 EMQX/EMQX Cloud 時序數(shù)據(jù)的無縫對接。最新發(fā)布的 EMQX Cloud 5.2.13 版本內置了 TDengine Cloud 原生連接器，補齊了雙方數(shù)據(jù)交互的最后一個環(huán)節(jié)。 該原生連接器的主要優(yōu)勢為：

簡化配置流程：這?功能顯著簡化了時序數(shù)據(jù)接入 TDengine 的流程，使?戶?需再通過繁瑣的 HTTP 連接器配置過程，只需在圖形化界面進行簡單的配置就可以連接兩?云服務平臺，為業(yè)務輕松賦能。

原?協(xié)議?持：直接使? TDengine Cloud 的原?協(xié)議傳輸數(shù)據(jù)，避免了 HTTP 連接的額外開銷，提升了性能與穩(wěn)定性。

?性能數(shù)據(jù)傳輸：優(yōu)化的數(shù)據(jù)傳輸機制，確保物聯(lián)?數(shù)據(jù)能夠快速可靠地存儲到 TDengine Cloud。

靈活的數(shù)據(jù)處理：強?的規(guī)則引擎?持，可根據(jù)業(yè)務需求對數(shù)據(jù)進?篩選、轉換和處理。

?站式配置：?需分別管理 EMQX 和 TDengine 的連接參數(shù)，統(tǒng)?在 EMQX Cloud 控制臺完成所有配置。

可視化監(jiān)控：集成的數(shù)據(jù)流監(jiān)控功能，輕松了解數(shù)據(jù)流轉狀態(tài)與性能指標。

接下來，我們向大家介紹如何使用該連接器實現(xiàn) MQTT 數(shù)據(jù)接入 TDengine Cloud ：

EMQX Cloud 配置操作步驟

以下是配置 EMQX Cloud 與 TDengine Cloud 原?連接的詳細步驟指南：

前置準備

1. EMQX Cloud 專有版部署：需要在 EMQX Cloud 平臺（https://cloud.emqx.com/）注冊并創(chuàng)建 EMQX Cloud 專有版部署 。（可免費體驗）
2. TDengine Cloud 賬戶：需要在 TDengine Cloud 平臺 (https://cloud.taosdata.com/) 注冊并創(chuàng)建數(shù)據(jù)庫實例。（可免費體驗）
3. ?絡配置：需要為 EMQX Cloud 專有版部署開通 NAT ?關，允許 EMQX Cloud 部署通過公?訪問 TDengine Cloud 實例。

步驟 1：TDengine Cloud 準備?作

1. 登錄 TDengine Cloud 控制臺 (https://cloud.taosdata.com/)

2. 創(chuàng)建并部署 TDengine Cloud 服務實例

3. 進?實例后，在左側菜單欄中點擊”數(shù)據(jù)瀏覽器”

4. 創(chuàng)建數(shù)據(jù)庫，例如 “iot_data”

5. 在數(shù)據(jù)庫中創(chuàng)建表：

CREATE TABLE iot_data.temp_hum ( 
 ts TIMESTAMP, 
 clientid NCHAR(256), 
 temp FLOAT,
 hum FLOAT 
); 

6. 在 TDengine Cloud 控制臺獲取連接 URL 和訪問令牌：TDENGINE_CLOUD_URL、TDENGINE_CLOUD_TOKEN的值以備后?。

步驟 2：在 EMQX Cloud 創(chuàng)建TDengine連接器

1. 登錄 EMQX Cloud 控制臺

2. 在部署菜單中選擇”數(shù)據(jù)集成”，在數(shù)據(jù)持久化分類下選擇 TDengine

3. 點擊”新建連接器”，填寫以下信息：

• 連接器名稱：為連接器指定?個名稱，如 “TDengine Cloud”
• 主機列表：填寫 TDengine Cloud 提供的連接 （TDENGINE_CLOUD_URL的值）
• Token：填?從 TDengine Cloud 獲取的訪問令牌 （TDENGINE_CLOUD_TOKEN的值）
• 根據(jù)需要配置?級設置（可選）

4. 點擊”測試連接”按鈕驗證連接狀態(tài)，成功后會顯示”連接器可?”提示 。

5. 點擊”新建”按鈕完成連接器的創(chuàng)建

步驟 3：創(chuàng)建數(shù)據(jù)集成規(guī)則

1. 點擊剛創(chuàng)建的連接器列表中”操作”列下的”新建規(guī)則”圖標，或在”規(guī)則列表”中點擊”新建規(guī)則”

2. 在 SQL 編輯器中輸?規(guī)則，定義需要處理的消息，例如：

SELECT 
 now_timestamp('millisecond') as ts, 
 payload.temp as temp, 
 payload.hum as hum, 
 clientid 
FROM 
"devices/temp_hum" 

3. 點擊”SQL示例”和”啟?調試”按鈕可以學習和測試規(guī)則 SQL 的結果（可選）

4. 點擊”下?步”開始創(chuàng)建動作 ：

步驟 4：配置動作

1. 從”使?連接器”下拉框中選擇您剛才創(chuàng)建的 TDengine 連接器

2. 數(shù)據(jù)庫名字：填寫在 TDengine Cloud 中創(chuàng)建的數(shù)據(jù)庫名稱，如 “iot_data”

3. 配置SQL模板，?于將數(shù)據(jù)寫?TDengine Cloud：

INSERT INTO iot_data.temp_hum(ts, temp, hum, clientid) VALUES (${ts}, ${temp}, ${hum}, ‘${clientid}’)

4. 啟?”未定義變量作為 NULL”選項，確保規(guī)則引擎在變量未定義時能正確處理 。

5. 根據(jù)業(yè)務需求配置?級選項，如同步/異步模式、批量參數(shù)等。（可選）

注：對消息延遲不敏感（延遲?于1s）的情況，可以將最?批量請求??從 1 修改為 100，從?提?寫?性能。

6. 點擊”確認”按鈕完成動作配置

7. 在彈出的”成功創(chuàng)建規(guī)則”提示框中點擊”返回規(guī)則列表”，完成整個數(shù)據(jù)集成配置。

步驟 5：模擬數(shù)據(jù)上報

1. 在 EMQX Cloud 部署菜單中選擇”在線調試“，并點擊連接 。

2. 訂閱主題 devices/temp_hum 。

3. 向主題 devices/temp_hum 發(fā)送溫濕度數(shù)據(jù) ：{"temp": 23, "hum": 90}

步驟 6：在 TDengine Cloud 查詢上報的數(shù)據(jù)

1. 訪問 TDengine Cloud 數(shù)據(jù)瀏覽器 。

2. 查詢上報數(shù)據(jù)結果 。

SELECT * from iot_data7.temp_hum;

可以看到，數(shù)據(jù)已經經由 EMQX Cloud 寫入了 TDengine Cloud 當中。

關于TDengine Cloud 連接器更具體的使用，可以參考：https://docs.emqx.com/zh/cloud/latest/data_integration/tdengine_cloud.html

TDengine Cloud 配置操作步驟

關于 TDengine Cloud 一側，同樣可以通過部署 MQTT 數(shù)據(jù)源實現(xiàn)對 EMQX Cloud 的數(shù)據(jù)接入，具體操作參考TDengine 官方文檔：https://docs.taosdata.com/cloud/data-in/ds/mqtt/，以及該博客：http://m.fjzmyy.cn/tdengine-engineering/27256.html。

寫在最后

目前， EMQX Cloud 只支持通過公網(wǎng)將數(shù)據(jù)接入 TDengine Cloud 當中，后續(xù)還會更新以支持私有連接（private link）方式，進一步提升 EMQX Cloud 和 TDengine Cloud 用戶的使用體驗。

面對數(shù)據(jù)洪流的挑戰(zhàn)與機遇，EMQX 與 TDengine 的深度合作為行業(yè)帶來了突破性的技術解決方案。不僅構建了支撐海量數(shù)據(jù)處理的超高性能技術底座，更通過創(chuàng)新性的架構設計，重塑工業(yè)互聯(lián)網(wǎng)與物聯(lián)網(wǎng)的數(shù)據(jù)基礎設施標準范式，助力企業(yè)在數(shù)智化轉型浪潮中獲得關鍵競爭優(yōu)勢，開啟智能化發(fā)展的新篇章。

為什么需要邊云協(xié)同？

在工業(yè)互聯(lián)網(wǎng)中，邊緣設備的作用是對本地生產數(shù)據(jù)進行實時監(jiān)控和處理，但這只能為決策者提供局部視角，無法形成全局的認知。為了做出全面、準確的決策，邊緣設備采集的數(shù)據(jù)需要上傳至云端平臺（無論是公有云還是私有云）。在云端，數(shù)據(jù)不僅可以被匯聚，還能通過更強大的計算資源進行融合和分析，從而為管理者提供對整個生產系統(tǒng)的宏觀洞察。

邊云協(xié)同架構由此應運而生，它成為工業(yè)互聯(lián)網(wǎng)中不可或缺的支柱，尤其是在需要同時兼顧數(shù)據(jù)實時性和全局視角的復雜場景中。邊緣設備通常負責監(jiān)控生產線上某一項或某幾項關鍵指標，如車間內的生產進度、設備運行狀態(tài)等，并對異常情況進行及時告警。邊緣設備在采集和處理這些數(shù)據(jù)后，會將其傳輸?shù)皆贫说拇髷?shù)據(jù)平臺。此時，邊緣設備可以保證數(shù)據(jù)的實時性，云端則利用更強大的計算能力對這些分散的數(shù)據(jù)進行匯總、分析和深度挖掘。

然而，隨著邊緣設備的數(shù)量迅速增長，數(shù)據(jù)量也呈爆炸式增長。在這種情況下，要讓系統(tǒng)高效運行，邊云協(xié)同的數(shù)據(jù)庫或數(shù)據(jù)存儲系統(tǒng)需要具備選擇性上報和數(shù)據(jù)降采樣的功能。例如，邊緣設備可能每秒鐘采集一次數(shù)據(jù)，但為了減輕數(shù)據(jù)傳輸和存儲的壓力，可以選擇只上傳經過降采樣的數(shù)據(jù)，將采集頻率從一秒降為一分鐘。這不僅減少了數(shù)據(jù)量，還保留了足夠的信息，用于長期的趨勢分析和預測模型。

此外，邊云協(xié)同的需求還源于傳統(tǒng)工業(yè)數(shù)據(jù)采集系統(tǒng)的局限性。傳統(tǒng)的系統(tǒng)通常依賴于從 PLC（可編程邏輯控制器）采集數(shù)據(jù)，并通過工業(yè)實時數(shù)據(jù)庫進行處理。這類系統(tǒng)往往采用主備架構，擴展性差，且依賴于特定的操作系統(tǒng)和軟硬件生態(tài)，導致整個系統(tǒng)的封閉性較高，靈活性和可擴展性有限。

相比之下，邊云協(xié)同架構的優(yōu)勢在于它的高度靈活性和可擴展性，能夠在邊緣和云端實現(xiàn)數(shù)據(jù)的分層處理。邊緣設備處理實時數(shù)據(jù)，快速響應現(xiàn)場需求，而云端則通過強大的計算能力進行數(shù)據(jù)整合和分析，為管理層提供全局的決策支持。這種架構不僅提高了數(shù)據(jù)處理的效率，還能根據(jù)實際需求進行靈活擴展，適應不同規(guī)模的企業(yè)和應用場景。

TDengine 的邊云協(xié)同解決方案

正如前文所說，在工業(yè)互聯(lián)網(wǎng)和制造業(yè)場景中，實時、高效的數(shù)據(jù)同步是企業(yè)優(yōu)化運營、提升決策能力的關鍵。在此背景下，TDengine Enterprise（企業(yè)版）憑借強大的邊云協(xié)同功能，為工業(yè)企業(yè)提供了一個靈活且高效的數(shù)據(jù)處理解決方案。通過該方案，企業(yè)可以實現(xiàn)邊緣側與云端之間的數(shù)據(jù)無縫協(xié)作，滿足各種復雜業(yè)務場景的需求。

TDengine Enterprise 的邊云協(xié)同解決方案具備以下幾大核心特性：

高效數(shù)據(jù)同步

支持每秒數(shù)百萬條數(shù)據(jù)的高速同步能力，確保在邊緣設備和云端平臺之間的數(shù)據(jù)傳輸既快速又穩(wěn)定，無論是在工業(yè)物聯(lián)網(wǎng)設備密集的現(xiàn)場，還是云端的分析平臺，都能保持數(shù)據(jù)的實時同步。

多數(shù)據(jù)源兼容性

TDengine Enterprise 提供了廣泛的數(shù)據(jù)源對接能力，支持主流工業(yè)協(xié)議和標準如 AVEVA PI System、OPC-UA、OPC-DA、MQTT 等，實現(xiàn)對多種外部系統(tǒng)的數(shù)據(jù)接入。這種兼容性極大擴展了其應用場景，無論是傳統(tǒng)的工業(yè)系統(tǒng)還是新興的物聯(lián)網(wǎng)平臺，都能輕松接入。

靈活的同步規(guī)則配置

用戶可以根據(jù)實際業(yè)務需求配置數(shù)據(jù)同步規(guī)則，實現(xiàn)對數(shù)據(jù)同步策略的高度定制化。無論是降采樣、按條件篩選，還是選擇性同步不同級別的關鍵信息，TDengine Enterprise 都能通過配置滿足企業(yè)對數(shù)據(jù)的不同要求，確保同步的數(shù)據(jù)不僅有效，而且最為相關。

斷線續(xù)傳與重新訂閱

在復雜的工業(yè)環(huán)境中，網(wǎng)絡穩(wěn)定性往往難以保障。TDengine Enterprise 支持斷線續(xù)傳和重新訂閱功能，確保即使在網(wǎng)絡中斷時，數(shù)據(jù)的同步也不會丟失，系統(tǒng)能夠在網(wǎng)絡恢復后繼續(xù)完成未完成的傳輸任務，保證數(shù)據(jù)完整性。

歷史數(shù)據(jù)遷移

當企業(yè)需要進行系統(tǒng)升級或更換時，TDengine Enterprise 提供了便捷的歷史數(shù)據(jù)遷移功能。用戶可以輕松將歷史數(shù)據(jù)從舊系統(tǒng)無縫遷移到新系統(tǒng)，確保數(shù)據(jù)的持續(xù)性和一致性，避免因系統(tǒng)變更而造成的數(shù)據(jù)丟失或不兼容問題。

此外，TDengine Enterprise 的數(shù)據(jù)訂閱功能賦予用戶極大的靈活性。用戶可以根據(jù)業(yè)務需求自由選擇訂閱的數(shù)據(jù)范圍，無論是單個數(shù)據(jù)庫、一張超級表，甚至是帶有篩選條件的查詢語句，均可實現(xiàn)選擇性的同步。通過這種方式，用戶可以將真正關心的數(shù)據(jù)，如離線數(shù)據(jù)或亂序數(shù)據(jù)，從邊緣側同步到云端或其他集群，最大限度地優(yōu)化數(shù)據(jù)傳輸效率，減少帶寬占用和資源浪費。

在實際的工業(yè)場景中，比如一個生產車間（以下圖為例），TDengine Enterprise 可以高效地實現(xiàn)邊云協(xié)同架構的應用。生產車間內的設備產生的實時數(shù)據(jù)存儲在邊緣側的 TDengine 中。隨后，部署在分廠的 TDengine 會訂閱車間的生產數(shù)據(jù)，并根據(jù)業(yè)務需求靈活配置同步規(guī)則，如降采樣或僅同步超出閾值的數(shù)據(jù)。同理，集團總部的 TDengine 會進一步訂閱各個分廠的數(shù)據(jù)，完成集團維度的數(shù)據(jù)匯總和分析。這種多層次、分級的數(shù)據(jù)同步架構，保證了從生產車間到集團總部的數(shù)據(jù)流動高效、實時且具備業(yè)務相關性。

與傳統(tǒng)的離線數(shù)據(jù)同步方式相比，TDengine Enterprise 提供了多項顯著的優(yōu)勢：

• 零代碼配置：無需編寫復雜的代碼，用戶只需通過簡單的配置即可實現(xiàn)邊緣和云端的數(shù)據(jù)同步。
• 自動化程度高：跨區(qū)域的數(shù)據(jù)同步可以自動完成，減少了手動操作中的出錯率，顯著提高了運維效率。
• 無緩存需求：TDengine 通過優(yōu)化傳輸機制，避免了大批量數(shù)據(jù)同步時帶來的網(wǎng)絡帶寬阻塞問題，使數(shù)據(jù)傳輸更加平滑、高效。
• 靈活、實時的數(shù)據(jù)同步：通過數(shù)據(jù)訂閱方式實現(xiàn)的同步支持規(guī)則配置，能夠根據(jù)具體業(yè)務需求靈活調整數(shù)據(jù)的傳輸頻率和內容。
• 統(tǒng)一的數(shù)據(jù)模型：邊緣側和云端均使用 TDengine，確保了數(shù)據(jù)模型的一致性，大大降低了數(shù)據(jù)治理的復雜度，提升了管理效率。

針對制造業(yè)企業(yè)普遍面臨的數(shù)據(jù)同步挑戰(zhàn)，TDengine Enterprise 提供了一個具備實時性、靈活性和高效性的解決方案，尤其是在大規(guī)模數(shù)據(jù)同步和網(wǎng)絡環(huán)境復雜的情況下，極大優(yōu)化了數(shù)據(jù)傳輸?shù)男屎头€(wěn)定性，避免了傳統(tǒng)方式中定期傳輸大數(shù)據(jù)量所導致的資源浪費和帶寬擁堵問題。

邊云協(xié)同在某大型油田項目中的應用

在某大型油田的生產管理項目中，用戶需要集成多個系統(tǒng)，如自動化數(shù)據(jù)采集與控制、生產視頻監(jiān)控、工業(yè)物聯(lián)網(wǎng)、生產數(shù)據(jù)服務和智能化生產管理等，同時也需要建設各環(huán)節(jié)的信息化采集標準。然而，隨著時間推移，項目中原先使用的 Oracle 系統(tǒng)在應對大規(guī)模時序數(shù)據(jù)的存儲和處理時，逐漸暴露出一些瓶頸問題：

1. 在面對復雜查詢和大數(shù)據(jù)集的聚合時，寫入和查詢效率顯著下降，系統(tǒng)性能逐漸衰減；
2. 隨著數(shù)據(jù)量的不斷增加，磁盤空間壓力增大，運維成本日益增加；
3. 在分布式企業(yè)管理模式下，數(shù)據(jù)協(xié)同效率較低，難以滿足企業(yè)快速增長的業(yè)務需求。

為了解決這些問題，該項目團隊對多種技術方案進行了深入的驗證，最終選擇將 Oracle 系統(tǒng)中的時序數(shù)據(jù)存儲切換至 TDengine，并借助其邊云協(xié)同技術，實現(xiàn)了邊緣側數(shù)據(jù)到云端的實時匯聚與同步。

具體實施方案中，多個不同的 TDengine 服務將全量的歷史數(shù)據(jù)及后續(xù)產生的數(shù)據(jù)實時同步至云端 TDengine。TDengine 的核心組件之一——taosX，只需在數(shù)據(jù)接收方部署，并通過一條簡單的命令，即可完成包括歷史數(shù)據(jù)遷移、實時同步及兩者混合的處理流程。

例如，使用以下命令可以將某臺服務器的?db1?歷史數(shù)據(jù)及實時數(shù)據(jù)同步到本地的?db2?數(shù)據(jù)庫：

taosx?run -f 'taos://192.168.1.101:6030/db1?mode=all' -t 'taos://localhost:6030/db2' -v

此外，taosX 還支持基于 TDengine 的 WAL 日志進行數(shù)據(jù)訂閱，通過事件驅動順序處理數(shù)據(jù)。無論是實時數(shù)據(jù)的插入，還是歷史數(shù)據(jù)的補錄，所有數(shù)據(jù)都能夠實時同步到目標集群，確保數(shù)據(jù)完整性和時效性。

實施該方案后，多個 TDengine 服務實現(xiàn)了跨省數(shù)據(jù)實時同步，將邊緣數(shù)據(jù)匯聚至云端總部集群。當前總部集群存儲的數(shù)據(jù)量已經達到 36 TB，總數(shù)據(jù)量超過 1034 億條，數(shù)據(jù)壓縮率控制在 10% 以內。通過 TDengine 的高效壓縮技術，大幅節(jié)省了存儲資源。

自項目將 Oracle 切換為 TDengine 后，優(yōu)化效果顯著，主要體現(xiàn)在以下幾方面：

1. 數(shù)據(jù)寫入性能大幅提升，硬件資源占用減少，系統(tǒng)運行更加高效；
2. 集群支持在線水平擴展，能夠輕松應對未來的擴展需求，提升了系統(tǒng)靈活性；
3. 靈活的數(shù)據(jù)生命周期管理，便于過期數(shù)據(jù)的自動清理和歸檔，簡化了數(shù)據(jù)管理流程；
4. 秒級 500 萬測點的同步速率，有效滿足了該項目對邊云協(xié)同場景的高實時性需求。

通過 TDengine 邊云協(xié)同解決方案的應用，該油田項目實現(xiàn)了對海量時序數(shù)據(jù)的高效管理和實時處理，解決了原有系統(tǒng)性能瓶頸問題，為未來的擴展和智能化生產奠定了堅實基礎。

結語

TDengine 邊云協(xié)同解決方案憑借其高效的數(shù)據(jù)同步能力、靈活的配置機制和強大的實時處理性能，成為應對工業(yè)互聯(lián)網(wǎng)場景下數(shù)據(jù)管理挑戰(zhàn)的有力工具。通過統(tǒng)一的邊云架構，時序數(shù)據(jù)庫 TDengine 能夠在滿足邊緣側實時處理需求的同時，將大量數(shù)據(jù)高效匯聚至云端，幫助企業(yè)在數(shù)據(jù)分析和決策上實現(xiàn)全局視角。希望本文能夠幫助企業(yè)更好地理解邊云協(xié)同技術的優(yōu)勢，并為其未來的數(shù)字化轉型和智能化生產提供有價值的參考。

近日，濤思數(shù)據(jù)與蒼穹數(shù)碼已完成產品兼容互認證工作，經雙方共同嚴格測試，濤思數(shù)據(jù)旗下物聯(lián)網(wǎng)、工業(yè)大數(shù)據(jù)平臺 TDengine V3.0 與蒼穹數(shù)碼旗下大型 GIS 基礎平臺-蒼穹地理信息平臺（KQGIS）V8.5 完成產品兼容性驗證，兩款產品能夠互相兼容、順利安裝、運行穩(wěn)定，為企業(yè)進行數(shù)字化轉型提供更全面的技術保障。

作為一款全面支持國產化環(huán)境的大型 GIS 基礎平臺，KQGIS 產品體系完善，包含桌面 GIS、服務 GIS、大數(shù)據(jù) GIS 以及移動 GIS 等專業(yè)應用與二次開發(fā)包，同時其還具備二三維數(shù)據(jù)整合與管理、空間大數(shù)據(jù)分析與可視化、高性能服務發(fā)布與共享以及簡便型二次開發(fā)等能力，能夠為數(shù)字中國、數(shù)字社會、數(shù)字經濟建設提供技術與產品支撐。

此次認證合作并非 TDengine 與蒼穹數(shù)碼的首次接觸。此前，在蒼穹數(shù)碼的地災專業(yè)監(jiān)測物聯(lián)網(wǎng)平臺項目中，由于原本的關系型數(shù)據(jù)庫 Oracle 已經無法滿足實時寫入與高性能查詢要求，他們選擇接入 TDengine 以解決海量時序數(shù)據(jù)的存儲和計算問題。在該項目中，TDengine 展現(xiàn)出了強大的讀寫性能和數(shù)據(jù)壓縮能力，有效降低了機器使用成本。

此次 TDengine 與 KQGIS 完成產品兼容性互認證，相信兩大產品將爆發(fā)強大的協(xié)同作用，為企業(yè)提供更多的工具和資源來挖掘地理信息的潛在價值，以便做出更智能的決策和更高效的業(yè)務運營。

關于蒼穹數(shù)碼

蒼穹數(shù)碼技術股份有限公司成立于 2001 年，是國內領先的時空信息 3S 平臺產品與應用服務提供商，集空間大數(shù)據(jù)分析與融合處理、信息化運維服務及行業(yè)信息化整體解決方案于一體的地理信息全產業(yè)鏈領軍企業(yè)。蒼穹數(shù)碼專注于地理信息系統(tǒng)（GIS）、遙感技術（RS）及衛(wèi)星導航定位定向（GNSS）技術等產品研發(fā)，經過二十余載的沉淀和積累，擁有了一批自主可控的核心關鍵技術，形成了四大平臺體系：地理信息平臺（KQ GIS）、遙感智能服務平臺（KQ RS）、衛(wèi)星導航定位及定向平臺（KQ GNSS）、業(yè)務協(xié)同平臺（KQ CO）。

關于 TDengine

TDengine 核心是一款高性能、集群開源、云原生的時序數(shù)據(jù)庫（Time Series Database，TSDB），專為物聯(lián)網(wǎng)、工業(yè)互聯(lián)網(wǎng)、電力、IT 運維等場景設計并優(yōu)化，具有極強的彈性伸縮能力。同時它還帶有內建的緩存、流式計算、數(shù)據(jù)訂閱等系統(tǒng)功能，能大幅減少系統(tǒng)設計的復雜度，降低研發(fā)和運營成本，是一個高性能、分布式的物聯(lián)網(wǎng)、工業(yè)大數(shù)據(jù)平臺。當前 TDengine 主要提供兩大版本，分別是支持私有化部署的 TDengine Enterprise 以及全托管的物聯(lián)網(wǎng)、工業(yè)互聯(lián)網(wǎng)云服務平臺 TDengine Cloud，兩者在開源時序數(shù)據(jù)庫 TDengine OSS 的功能基礎上有更多加強，用戶可根據(jù)自身業(yè)務體量和需求進行版本選擇。

為確保結果具有可比性，本次測試選用 TimescaleDB 2.6.0 版本。為獲得較好的性能，TimescaleDB 需要針對不同的場景設置不同的 Chunk 參數(shù)，不同場景下參數(shù)的設置如下表所示：

上述參數(shù)的設置，充分參考了下方 TimescaleDB vs. InfluxDB 對比報告中推薦的配置參數(shù)設置，以確保寫入性能指標的最優(yōu)化。

TimescaleDB vs. InfluxDB: Purpose Built Differently for Time-Series Data：https://www.timescale.com/blog/timescaledb-vs-influxdb-for-time-series-data-timescale-influx-sql-nosql-36489299877/

關于系統(tǒng)的配置詳情、如何一鍵復現(xiàn)測試結果及詳細的測試數(shù)據(jù)介紹等內容，大家可參考《一鍵獲取測試腳本，輕松驗證“TSBS 時序數(shù)據(jù)庫性能基準測試報告”》、《TSBS 是什么？為什么時序數(shù)據(jù)庫 TDengine 會選擇它作為性能對比測試平臺？》兩篇文章，本文便不再贅述。

寫入性能最高達到了 TimescaleDB 的 6.7 倍

在 TSBS 全部的 cpu-only 五個場景中，TDengine 寫入性能均優(yōu)于 TimescaleDB。相比 TimescaleDB，TDengine 寫入速度最領先的場景是其 6.7 倍（場景二），最少也是 1.5 倍（場景五），而且對于場景四，如果將每個采集點的記錄條數(shù)由 18 條增加到 576 條，TDengine 寫入速度就達到了 TimescaleDB 的 13.2 倍。此外，TDengine 在寫入過程中消耗的 CPU 資源和磁盤 IO 開銷也是最低的。

不同場景下寫入性能對比

從上圖可以看到，在全部五個場景中，TDengine 的寫入性能全面超越 TimescaleDB。在場景二中 TDengine 寫入性能最大達到了 TimescaleDB 的 6.74 倍，在差距最小的場景五中，也達到了 TimescaleDB 的 1.52 倍。

寫入過程資源消耗對比

但僅憑數(shù)據(jù)寫入速度，并不能全面地反映出 TDengine 和 TimescaleDB 在不同場景下數(shù)據(jù)寫入的整體表現(xiàn)。為此我們以 1,000,000 devices × 10 metrics （場景四）為例，檢查數(shù)據(jù)寫入過程中的服務器和客戶端的整體負載狀況，并以此來對比 TDengine 和 TimescaleDB 在寫入過程中服務器/客戶端節(jié)點的資源占用情況，這里的資源占用主要包括服務器端的 CPU 開銷/磁盤 IO 開銷和客戶端 CPU 開銷。

服務端 CPU 開銷

上圖展示了在場景四寫入過程之中服務器端 CPU 負載狀況?？梢钥吹剑琓Dengine 和 TimescaleDB 在返回給客戶端寫入完成消息以后，都還繼續(xù)使用服務器的資源進行相應的處理工作，這點上，TimescaleDB 尤為明顯，TimescaleDB 在 7x 秒的時候即反饋客戶端寫入完成，但是其服務器端仍然在調用 CPU 資源進行數(shù)據(jù)壓縮和整理工作，當然整個工作帶來的 CPU 負載相對而言并不高，只有其峰值 CPU 開銷的一半左右，但是其持續(xù)時間相當長，接近凈寫入時間的 4 倍，遠長于 TDengine。TDengine 對服務器的 CPU 需求較小，峰值也僅使用了 17% 左右的服務器 CPU 資源。由此可見，TDengine 獨特的數(shù)據(jù)模型不僅體現(xiàn)在時序數(shù)據(jù)的寫入性能上，也體現(xiàn)在整體的資源開銷上。

磁盤 I/O 對比

上圖展示了 1,000,000 devices × 10 metrics （場景四）兩大系統(tǒng)在數(shù)據(jù)寫入過程中服務器端磁盤寫入狀態(tài)。結合服務器端 CPU 開銷表現(xiàn)，可以看到，兩大數(shù)據(jù)庫的 IO 動作與 CPU 均呈現(xiàn)出同步活躍狀態(tài)。

在寫入相同規(guī)模數(shù)據(jù)集的情況下，TDengine 在寫入過程中對于磁盤寫入能力的占用遠小于 TimescaleDB，整體寫入過程只占用了部分磁盤寫入能力（125MiB/Sec. 3000IOPS）。從圖上能看到，對于兩大數(shù)據(jù)庫來說，數(shù)據(jù)寫入過程中磁盤的 IO 瓶頸是確實存在的，但 TimescaleDB 寫入過程對于寫入的消耗遠超過了 TDengine 對磁盤寫入能力的需求。

客戶端 CPU 開銷

從上圖可以看到，客戶端上 TDengine 對 CPU 的需求大于 TimescaleDB ，TDengine 在客戶端峰值瞬間達到了 56%，然后快速回落，其在客戶端的開銷相比于 TimescaleDB 多了 1 倍。但綜合服務器與客戶端的資源開銷來看，TDengine 寫入持續(xù)時間更短，在系統(tǒng)整體 CPU 開銷上 TDengine 仍然具有相當大的優(yōu)勢。

查詢性能最高達到了 TimescaleDB 的 28.6 倍

在場景一（只包含 4 天數(shù)據(jù)）與場景二的 15 個不同類型的查詢中，TDengine 的查詢平均響應時間全面優(yōu)于 TimescaleDB，而且在復雜查詢上優(yōu)勢更為明顯，同時具有最小的計算資源開銷。相比 TimeScaleDB，場景一中 TDengine 的查詢性能是其 1.1 ～ 28.6 倍，場景二中 TDengine 的查詢性能是其 1.2 ～ 24.6 倍。

在查詢性能評估部分，我們使用場景一和場景二作為基準數(shù)據(jù)集。在查詢性能評估之前，對于 TimescaleDB，我們采用上文出現(xiàn)的 TimescaleDB vs. InfluxDB 對比報告中推薦配置，設置為 8 個 Chunk ，以確保其充分發(fā)揮查詢性能。在整個查詢對比中，TDengine 數(shù)據(jù)庫的虛擬節(jié)點數(shù)量（vnodes）保持為默認的 6 個，其他的數(shù)據(jù)庫參數(shù)配置為默認值。

4,000 devices × 10 metrics查詢性能對比

由于部分類型（分類標準參見 TimescaleDB vs. InfluxDB 對比報告）單次查詢響應時間非常短，為了更加準確地測量每個查詢場景的較為穩(wěn)定的響應時間，我們將單個查詢運行次數(shù)提升到 5,000 次，然后使用 TSBS 自動統(tǒng)計并輸出結果，最后結果是 5,000 次查詢的算數(shù)平均值，使用并發(fā)客戶端 Workers 數(shù)量為 8。下表是場景二 （4,000 設備）下兩大數(shù)據(jù)庫的查詢性能對比結果。

下面我們對每個查詢結果做一定的分析說明：

由于 Simple Rollups 的整體查詢響應時間非常短，因此制約查詢響應時間的主體因素并不是查詢所涉及的數(shù)據(jù)規(guī)模，即這一類型查詢的瓶頸并非數(shù)據(jù)規(guī)模。但從結果上看，TDengine 仍然在所有類型的查詢響應時間上優(yōu)于 TimescaleDB，具體的數(shù)值對比請參見上表。

通過上圖可以看到，在 Aggregates 類型的查詢中，TDengine 的查詢性能相比 TimescaleDB 有比較大的優(yōu)勢，其cpu-max-all-8 查詢性能是 TimescaleDB 的 6 倍。

在 Double-rollups 類型查詢中， TDengine 同樣展現(xiàn)出巨大的性能優(yōu)勢，以查詢響應時間來度量，其在 double-groupby-5 和 double-groupby-all 類型下的查詢性能均達到了 TimescaleDB 的 24 倍。

上面兩圖展示的是 threshold 類型的查詢對比，可以看到，TDengine 的查詢響應時間均顯著低于 TimescaleDB。在 high-cpu-all 類型的查詢上，TDengine 的性能是 TimescaleDB 的 1.23 倍。

對于 Complex-queries 類型的查詢，TDengine 兩個查詢同樣均大幅領先 TimescaleDB。在 lastpoint 查詢中TDengine 的查詢性能是 TimescaleDB 的 5 倍，在 groupby-orderby-limit 場景中 TDengine 的查詢性能是 TimescaleDB 的 8 倍。在時間窗口聚合的查詢過程中，針對規(guī)模較大的數(shù)據(jù)集 TimescaleDB 查詢性能不佳（double rollups 類型查詢），對于 groupby-orderby-limit 類型的查詢，TimescaleDB 的性能表現(xiàn)同樣不是太好。

資源開銷對比

由于部分查詢持續(xù)時間特別短，因此我們并不能完整地看到查詢過程中服務器的 IO/CPU/網(wǎng)絡情況。為此我們針對場景二以 Double rollups 類別中的 double-groupby-5 查詢?yōu)槔?，?zhí)行 1,000 次查詢，記錄整個過程中 TDengine、TimescaleDB 兩個軟件系統(tǒng)在查詢執(zhí)行的整個過程中服務器 CPU、內存、網(wǎng)絡的開銷并進行對比。

如上圖所示，兩個系統(tǒng)在整個查詢過程中 CPU 的使用均較為平穩(wěn)。TDengine 在查詢過程中整體 CPU 占用約 80%，使用的 CPU 資源最高，TimescaleDB 在查詢過程中瞬時 CPU 占用約 38%。由于 TDengine 完成全部查詢的時間僅 TimescaleDB 1/20，因此雖然其 CPU 穩(wěn)定值是 TimescaleDB 的 2 倍多，但整體的 CPU 計算時間消耗只有其 1/10 。

• 服務器內存狀況

如上圖所示，在整個查詢過程中，TDengine 內存維持在一個相對平穩(wěn)的狀態(tài)。而 TimescaleDB 在整個查詢過程中內存呈現(xiàn)增加的狀態(tài)，查詢完成后即恢復到初始狀態(tài)。

• 服務器網(wǎng)絡帶寬

上圖展示了查詢過程中兩個系統(tǒng)的服務器端上行和下行的網(wǎng)絡帶寬情況，可以看到，負載狀況基本上和 CPU 狀況相似。TDengine 網(wǎng)絡帶寬開銷較高，因為在最短的時間內就完成了全部查詢，需要將查詢結果返回給客戶端。TimescaleDB 開銷較低，但持續(xù)時間長。

100 devices × 10 metrics 查詢性能對比

對于場景一(100 devices x 10 metrics)，TSBS 的 15 個查詢對比結果如下：

如上表所示，從更小規(guī)模的數(shù)據(jù)集（100 設備）上的查詢對比可以看到，整體上 TDengine 同樣展現(xiàn)出極好的性能，在全部的查詢語句中全面優(yōu)于 TimescaleDB，部分查詢性能超過 TimescaleDB 28 倍。

TimescaleDB 占用的磁盤空間最高達到 TDengine 的 26.9 倍

下圖是TDengine 和 TimescaleDB 數(shù)據(jù)完全落盤以后，比較了兩個系統(tǒng)在不同場景下的磁盤空間占用：

在磁盤空間的占用上，從上圖可以看到，TimescaleDB 在全部五個場景下的數(shù)據(jù)規(guī)模均顯著大于 TDengine，并且這種差距隨著數(shù)據(jù)規(guī)模增加快速變大。TimescaleDB 在場景四和場景五中占用磁盤空間是 TDengine 的 25.6 倍和 26.9 倍。

寫在最后

從上述 TSBS 測試報告中我們可以得出結論，不管是在寫入性能、查詢性能還是存儲性能，TDengine 時序數(shù)據(jù)庫 比 TimescaleDB 時序數(shù)據(jù)庫 都略勝一籌，且不論是服務器的 CPU 還是 IO 抑或是客戶端的開銷統(tǒng)計，TDengine 均遠優(yōu)于 TimescaleDB。尤其本次性能測試還是基于 Timescale 打造的基準性能測試平臺 TSBS 進行的，測試結果的公平公正性可見一斑。

具體到實踐上，在八五信息的新能源電力物聯(lián)網(wǎng)平臺項目，曾經使用的實時數(shù)據(jù)庫便是 TimescaleDB，后面因為種種原因，他們選擇應用 TDengine 升級數(shù)據(jù)架構，關于本次案例的具體信息可以查看《代替 TimescaleDB，TDengine 接管數(shù)據(jù)量日增 40 億條的光伏日電系統(tǒng)》。

為了方便大家驗證測試結果，本測試報告支持運行測試腳本一鍵復現(xiàn)，歡迎各位檢驗。同時，我們也歡迎大家添加 小T vx：tdengine1，加入 TDengine 用戶交流群，和更多志同道合的開發(fā)者一起探討數(shù)據(jù)處理難題。

在此背景下，專為時序數(shù)據(jù)而設計，具有高性能、高可靠、高可擴展等特點的時序數(shù)據(jù)庫（Time Series Database） TDengine 應運而生。TDengine 不僅是一個開源、云原生的時序數(shù)據(jù)庫，還集成了緩存、流式計算、數(shù)據(jù)訂閱等功能，為時序數(shù)據(jù)處理提供了一站式解決方案。目前 TDengine 已經成功運用在西門子、美的、順豐、中通、同花順、蔚來汽車、理想汽車等諸多企業(yè)的數(shù)據(jù)架構改造實踐中（點擊文字超鏈查看詳細解決方案）。

為了讓企業(yè)能夠更加彈性地運用 TDengine 的能力，我們基于 TDengine 開發(fā)出了全托管的時序數(shù)據(jù)云平臺 TDengine Cloud，它能夠為用戶提供更簡單、更便捷、更安全的時序數(shù)據(jù)管理服務。TDengine Cloud 具備以下三點優(yōu)勢：

極簡的時序數(shù)據(jù)管理平臺

除高性能、具有水平擴展能力的時序數(shù)據(jù)庫外，TDengine Cloud 還提供緩存、數(shù)據(jù)訂閱、流式計算等功能，無需再部署 Redis、Kafka、Spark/Flink 等第三方軟件，大幅簡化系統(tǒng)架構、降低運營成本。

便捷且安全的數(shù)據(jù)共享

TDengine Cloud 既支持將一個庫完全開放，設置讀或寫的權限；也支持通過數(shù)據(jù)訂閱的方式，將庫、超級表、一組或一張表、或聚合處理后的數(shù)據(jù)分享出去。這種時序數(shù)據(jù)共享機制能夠幫助企業(yè)各部門以及合作伙伴之間快速洞察業(yè)務運營的變化。

安全可靠的企業(yè)級服務

TDengine Cloud 提供數(shù)據(jù)定時備份、恢復，數(shù)據(jù)從運行實例到私有云、其他公有云或Region 的實時復制；為保證數(shù)據(jù)安全，還會提供基于角色的訪問權限控制、IP 白名單、用戶行為審計等功能，用 7*24 的專業(yè)技術服務保障 99.9% 的 Service Level Agreement。通過安全、專業(yè)、可靠的企業(yè)級服務，用戶可以用最少的精力和成本完成數(shù)據(jù)管理，更加聚焦自身核心業(yè)務的發(fā)展。

在時序數(shù)據(jù)的管理上，TDengine Cloud 能夠幫助物聯(lián)網(wǎng)、工業(yè)互聯(lián)網(wǎng)、金融、IT 運維監(jiān)控等領域的企業(yè)根據(jù)自身業(yè)務需求實現(xiàn)數(shù)據(jù)庫集群自動擴縮容，大大削減了部署、優(yōu)化、擴容、備份、異地容災等工作量，實現(xiàn)了人力成本和運營成本的大幅降低。目前 TDengine Cloud 已經支持在阿里云、Microsoft Azure、AWS、Google Cloud 四大公有云上訪問和部署 TDengine。

為了讓更多的開發(fā)者了解 TDengine Cloud 及其運作方式，4 月 15 日 19:00-20:00，TDengine 創(chuàng)始人 & 核心研發(fā)陶建輝將進行《時序數(shù)據(jù)處理的云端利器：TDengine Cloud 詳解與演示》直播分享。演講大綱如下：

• 簡單介紹 TDengine
• 介紹 TDengine Cloud的三大特點
• 現(xiàn)場演示如何使用 TDengine Cloud（數(shù)據(jù)寫入、數(shù)據(jù)瀏覽器、數(shù)據(jù)導出、數(shù)據(jù)訂閱及數(shù)據(jù)分享等功能）

掃描關注下方視頻號卡片可進行直播預約：

如果你是 TDengine 的關注者，或者對 TDengine Cloud 有一定的興趣，抑或你現(xiàn)在正在為海量時序數(shù)據(jù)處理而發(fā)愁，那就千萬不要錯過這次難得的機會，這場直播一定會讓你有所收獲！直播過程中，還會抽取幸運觀眾送出精美 IP 周邊和云服務500元現(xiàn)金券，一定不要錯過哦~

值得一提的是，濤思數(shù)據(jù)作為 KubeCon + CloudNativeCon Europe 2023 的榮譽贊助商也參與了本次會議，在會議現(xiàn)場，濤思數(shù)據(jù)展位吸引了眾多開發(fā)者的關注，TDengine 創(chuàng)始人 & 核心研發(fā)陶建輝和現(xiàn)場的開發(fā)者們一起討論云原生技術對于數(shù)據(jù)庫發(fā)展的重要性。

近年來，在開源技術的推動下，云原生的發(fā)展進入快車道階段，國內外眾多企業(yè)都開始投入力量深度研究云原生技術，試圖以云技術的無限潛力推動數(shù)字化時代的快速發(fā)展。在此過程中，為了打破信息孤島、實現(xiàn)技術交流，各種云原生大會也逐漸興起，其中 KubeCon可以說是云原生領域最具影響力的會議之一。從 200 人的小會議發(fā)展到近 4000 位云原生和開源領域工程師齊聚一堂的大會，KubeCon 只用了四年時間，作為云原生領域的盛會，每一年的 KubeCon 都會將世界各地知名的云廠商匯聚于此，為參會者分享他們這一年來面向云原生的創(chuàng)新技術和研究成果。

同樣，借助云原生的力量，濤思數(shù)據(jù)旗下的 TDengine 3.0 也發(fā)展成為了一款真正的云原生時序數(shù)據(jù)庫（Time Series Database），解決了困擾時序數(shù)據(jù)庫發(fā)展的高基數(shù)難題，支持 10 億個設備采集數(shù)據(jù)、100 個節(jié)點，支持存儲與計算分離。與此同時，基于 TDengine 打造的全托管的時序數(shù)據(jù)處理云服務平臺 TDengine Cloud 也成功推出，正式支持 Microsoft Azure、AWS、Google Cloud、阿里云四大公有云，未來還將接軌更多的云廠商。

濤思數(shù)據(jù)在云技術上的種種研究成果也成為打開 KubeCon + CloudNativeCon Europe 2023 大門的通行票，相信借助這一云原生盛會的力量，更多國外開發(fā)者能夠了解到云原生時序數(shù)據(jù)庫 TDengine，而 TDengine 的技術創(chuàng)新力量也能夠借此契機更快走出國門、惠及世界各地的企業(yè)和開發(fā)者。

活動推薦

時序數(shù)據(jù)處理有沒有讓你頭疼？想不想找到一個優(yōu)秀的解決方案，讓你輕松應對海量的時序數(shù)據(jù)？2023 年 4 月 25 日 19:00-20:00，TDengine 創(chuàng)始人&CEO 陶建輝 將為大家分享《時序數(shù)據(jù)處理的云端利器：TDengine Cloud 詳解與演示》。

TDengine Cloud 是一個極簡的全托管時序數(shù)據(jù)處理云服務平臺，它是基于開源的時序數(shù)據(jù)庫 TDengine 而開發(fā)的。它是一款極簡的時序數(shù)據(jù)管理平臺，提供便捷且安全的數(shù)據(jù)共享和安全可靠的企業(yè)級服務。

在這場直播中，陶建輝將為你詳細介紹 TDengine Cloud 的功能和優(yōu)勢，并通過實際演示讓你體驗 TDengine Cloud 的強大和便捷。請掃描下方二維碼預約這場直播，不要錯過這個難得的學習機會！

3.0.4.0 版本涉及到的更新內容包括產品穩(wěn)定性的提升、查詢性能提升、參數(shù)使用優(yōu)化、以及多副本情況下的健壯性提升、Python UDF、集群負載再平衡、基于時間段進行數(shù)據(jù)重整等九大方面。具體更新信息如下：

1. 大幅提升產品穩(wěn)定性

在大并發(fā)、高負載的寫入和查詢下的系統(tǒng)穩(wěn)定性有顯著提升：優(yōu)化了對內存的使用，優(yōu)化了有大量并發(fā)查詢下對連接池的控制，修復了一些影響系統(tǒng)穩(wěn)定性的缺陷。

2. 提升了部分查詢場景下的性能

• 提升了當與 interval() 一起使用時 mode() 函數(shù)的性能
• 提升了 percentile() 函數(shù)的性能
• 提升了 last()/last_row() 函數(shù)的性能

3. 可以動態(tài)配置更多數(shù)據(jù)庫參數(shù)

新增兩個可以動態(tài)配置的數(shù)據(jù)庫參數(shù)：stt_trigger 和 minRows，其具體功能請參考官方文檔。

4. 優(yōu)化了 WAL 數(shù)據(jù)保留的行為

WAL 中數(shù)據(jù)的保存僅受參數(shù) WAL_RETENTION_PERIOD 和 WAL_RETENTION_SIZE 的控制，不再受數(shù)據(jù)訂閱的影響。具體細節(jié)請參考官方文檔。

5. Python UDF

應用開發(fā)者可以用 Python 開發(fā)自定義函數(shù)并將其嵌入數(shù)據(jù)庫，從而提升數(shù)據(jù)處理和分析能力。

6. 集群負載再平衡 （企業(yè)版功能）

當集群中某個 dnode 宕機重啟后會出現(xiàn)負載不均衡現(xiàn)象，重新啟動的 dnode 上沒有 leader vnode，所以不承擔任何寫入和查詢負載。通過 rebalance 命令，可以使集群中各個 dnode 之間的負載再次均衡。

7. 基于時間段進行數(shù)據(jù)重整 （企業(yè)版功能）

為了減少數(shù)據(jù)重整所花費的時間，最小化對系統(tǒng)的影響，可以指定時間段進行數(shù)據(jù)重整，只針對確定有亂序數(shù)據(jù)的時間段或者查詢所關注的時間段進行數(shù)據(jù)重整。

8. 能夠將多種工業(yè)互聯(lián)網(wǎng)中的傳統(tǒng)數(shù)據(jù)源接入TDengine （企業(yè)版功能）

• OPC UA
• OPC DA
• Pi

9. 集中控制臺 taosExplorer 管理數(shù)據(jù)源和數(shù)據(jù)接入任務 （企業(yè)版功能）

同步增強了集中控制臺 taosExplorer 以能夠管理所支持的各種數(shù)據(jù)源和與它們所關聯(lián)的數(shù)據(jù)接入任務。

詳細信息可以參考發(fā)布說明(https://github.com/taosdata/TDengine/releases/tag/ver-3.0.4.0)。歡迎大家下載使用 TDengine，有任何問題，都可以添加小T vx：tdengine1 申請加入 TDengine 用戶交流群，及時向我們的解決方案專家尋求支持與幫助。

近日，TDengine 與 Apache SeaTunnel 展開集成合作，雙方將于 4 月 18 日 19:00 聯(lián)合進行直播，分享兩大軟件集成應用的最佳實踐。

（Apache Seatunnel 是一個易用、高性能、支持實時流式和離線批處理的海量數(shù)據(jù)處理產品，架構于Apache Spark 和 Apache Flink之上。）

此前，TDengine 已經與 Kafka、Telegraf、Grafana、Google Data Studio、EMQ X、Prometheus、StatsD 和 collectd 等眾多第三方工具展開集成，之后又連接了工業(yè)英特爾? 邊緣洞見軟件包、數(shù)據(jù)同步工具 DataX，插件也正式上架 Grafana 官網(wǎng)、連接器上線 Google Data Studio 應用商店。此次 TDengine 與 Apache SeaTunnel 展開集成合作，進一步擴大了自身生態(tài)版圖，為用戶帶來應用上的更多選擇。

兩者聯(lián)合將帶來怎樣的驚喜，歡迎大家關注4 月 18日即將到來的線上直播！趕快點擊下方直播卡片預約觀看吧~

報名通道

講師介紹

李宏宇 北京沃東天駿信息技術有限公司 架構師

歷經阿里、京東等多家成熟互聯(lián)網(wǎng)公司及羅輯思維等初創(chuàng)公司。十年后端及數(shù)據(jù)開發(fā)經驗，目前主要聚焦在實時數(shù)據(jù)倉庫領域工作

霍立波 北京濤思數(shù)據(jù)科技有限公司 連接器開發(fā)工程師

熟悉 Java、GO、rust、node 等多種開發(fā)語言，對使用的各個框架與工具底層實現(xiàn)有深入理解。目前主要圍繞 TDengine 做生態(tài)開發(fā)。

活動議程

按照慣例，直播中我們?yōu)榇蠹覝蕚淞顺楠劖h(huán)節(jié)，中獎者可獲得社區(qū)提供的精美周邊禮品，來到直播間就有機會中獎~此外，填寫活動反饋表也能獲得抽獎機會哦：http://whaleops.mikecrm.com/1pxlyDU！

獎品一覽

社區(qū)介紹

Apache SeaTunnel (Incubating)

Apache SeaTunnel (Incubating) 是一個云原生的高性能海量數(shù)據(jù)集成平臺。美國時間 2021 年 12 月 9 日， SeaTunnel以全票通過的優(yōu)秀表現(xiàn)正式成為 Apache 孵化器項目，這也是 Apache 基金會中第一個誕生自中國的數(shù)據(jù)集成平臺項目。目前，SeaTunnel 在GitHub 上Star 數(shù)達 4.1k+，社區(qū)達到5000+人規(guī)模。2017 年對外開源后，SeaTunnel 已經發(fā)布了 30多個版本，并經過大量企業(yè)生產使用，在 Bilibili、新浪、水滴籌、搜狗、趣頭條、唯品會等公司的生產實踐中，廣泛應用于海量數(shù)據(jù)集成、數(shù)據(jù) ETL、數(shù)據(jù)聚合以及多源數(shù)據(jù)處理等場景中，貢獻者 160+。

TDengine

TDengine 是一款開源、云原生的時序數(shù)據(jù)庫（ Time Series Database,TSDB ），專為物聯(lián)網(wǎng)、工業(yè)互聯(lián)網(wǎng)、金融、IT 運維監(jiān)控等場景設計并優(yōu)化，具有極強的彈性伸縮能力。同時它還帶有內建的緩存、流式計算、數(shù)據(jù)訂閱等系統(tǒng)功能，能大幅減少系統(tǒng)設計的復雜度，降低研發(fā)和運營成本，是一個極簡的時序數(shù)據(jù)處理平臺。TDengine 的內核（存儲、計算引擎和集群）已 100% 開源，GitHub Star數(shù)達到 21.1k，且多次在 GitHub 全球趨勢排行榜上排名第一（開源地址：https://github.com/taosdata/TDengine）。目前，TDengine 的運行實例數(shù)已超過 230.6k，用戶遍布全球。

我們采用下方 TimescaleDB vs. InfluxDB 對比報告中推薦的方式配置 InfluxDB，將緩沖區(qū)配置為 80G，以便 1000W 設備寫入時能夠順利進行，同時開啟 Time Series Index（TSI）。配置系統(tǒng)在系統(tǒng)插入數(shù)據(jù)完成 30s 后開始數(shù)據(jù)壓縮。

TimescaleDB vs. InfluxDB: Purpose Built Differently for Time-Series Data：

https://www.timescale.com/blog/timescaledb-vs-influxdb-for-time-series-data-timescale-influx-sql-nosql-36489299877/

關于系統(tǒng)的配置詳情、如何一鍵復現(xiàn)測試結果及詳細的測試數(shù)據(jù)介紹等內容，大家可參考《一鍵獲取測試腳本，輕松驗證“TSBS 時序數(shù)據(jù)庫性能基準測試報告”》、《TSBS 是什么？為什么時序數(shù)據(jù)庫 TDengine 會選擇它作為性能對比測試平臺？》兩篇文章，本文便不再贅述。

寫入性能最高達到 InfluxDB 的 10.6 倍

總體而言，在 TSBS 報告全部的 cpu-only 五個場景中，時序數(shù)據(jù)庫（Time Series Database,TSDB）TDengine 寫入性能均優(yōu)于 InfluxDB。相比 InfluxDB，TDengine 寫入速度最領先的場景是其 10.6 倍（場景五），最少也是 3.0 倍（場景一)。此外，TDengine 在寫入過程中消耗了最少 CPU 資源和磁盤 IO 開銷。下面看一下具體分析：

不同場景下寫入性能對比

從上圖可以看到，在全部五個場景中，TDengine 的寫入性能全面超越 InfluxDB。TDengine 在場景五中寫入性能是 InfluxDB 的 10.63 倍，在差距最小的場景一中也有 3.01 倍。

寫入過程資源消耗對比

數(shù)據(jù)寫入速度并不能夠全面的反映 TDengine 和 InfluxDB 在不同場景下數(shù)據(jù)寫入的整體表現(xiàn)。為此我們以 1,000,000 devices × 10 metrics （場景四）為例，檢查數(shù)據(jù)寫入過程中的服務器和客戶端（包括客戶端與服務器）的整體負載狀況，并以此來對比 TDengine 和 InfluxDB 在寫入過程中服務器/客戶端節(jié)點的資源占用情況，這里的資源占用主要包括服務器端的 CPU 開銷/磁盤 IO 開銷和客戶端 CPU 開銷。

服務端 CPU 開銷

下圖展示了兩大數(shù)據(jù)庫在場景四寫入過程中服務器端 CPU 負載狀況?？梢钥吹?，TDengine 和 InfluxDB 在返回給客戶端寫入完成消息以后，都還繼續(xù)使用服務器的資源進行相應的處理工作，InfluxDB 使用了相當多的 CPU 資源，瞬時峰值甚至使用了全部的 CPU 資源，其寫入負載較高，并且其持續(xù)時間遠長于 TDengine。兩個系統(tǒng)對比，TDengine 對服務器的 CPU 需求最小，峰值也僅使用了 17% 左右的服務器 CPU 資源。由此可見，TDengine 獨特的數(shù)據(jù)模型對于時序數(shù)據(jù)寫入不僅在性能上，在整體的資源開銷上也具有非常大的優(yōu)勢。

磁盤 I/O 對比

下圖展示了 1,000,000 devices × 10 metrics （場景四）數(shù)據(jù)寫入過程中兩大數(shù)據(jù)庫在服務器端磁盤的寫入狀態(tài)?？梢钥吹?，結合著服務器端 CPU 開銷表現(xiàn)，其 IO 動作與 CPU 呈現(xiàn)同步的活躍狀態(tài)。

在寫入相同規(guī)模的數(shù)據(jù)集情況下，TDengine 在寫入過程中對于磁盤寫入能力的占用遠小于 InfluxDB，寫入過程只占用了部分磁盤寫入能力（125MiB/Sec. 3000IOPS）。從上圖能看到，對于兩大數(shù)據(jù)庫，數(shù)據(jù)寫入過程中磁盤的 IO 瓶頸都是確實存在的。但 InfluxDB 長時間消耗完全部的磁盤寫入能力，遠遠超過了 TDengine 對磁盤寫入能力的需求。

客戶端 CPU 開銷

從上圖可以看到，客戶端上 TDengine 對 CPU 的需求是大于 InfluxDB 的。整體來說，在整個寫入過程中，InfluxDB 客戶端負載計算資源占用較低，對客戶端壓力小，這是因為其寫入的壓力基本上完全集中在服務端，但這種模式很容易導致服務端成為瓶頸。而 TDengine 在客戶端的開銷最大，峰值瞬間達到了 56%，然后快速回落。綜合服務器與客戶端的資源開銷來看，TDengine 寫入持續(xù)時間更短，在系統(tǒng)整體 CPU 開銷上 TDengine 仍然具有相當大的優(yōu)勢。

查詢性能最高達到 InfluxDB 的 37 倍

在查詢性能的評估上，我們使用場景一和場景二作為基準數(shù)據(jù)集。為了讓 InfluxDB 發(fā)揮出更好的查詢性能，我們開啟 InfluxDB 的 TSI (time series index)。在整個查詢對比中，TDengine 數(shù)據(jù)庫的虛擬節(jié)點數(shù)量（vnodes）保持為默認的 6 個，其他的數(shù)據(jù)庫參數(shù)配置為默認值。

總體來說，查詢方面，在場景一（只包含 4 天的數(shù)據(jù)）與場景二的 15 個不同類型的查詢中，TDengine 的查詢平均響應時間是全面優(yōu)于 InfluxDB 的，而且在復雜查詢上優(yōu)勢更為明顯，同時具有最小的計算資源開銷。相比 InfluxDB，場景一中 TDengine 查詢性能是其 1.9 ～ 37.0 倍，場景二中 TDengine 查詢性能是其 1.8 ～ 34.2 倍。

4,000 devices × 10 metrics查詢性能對比

由于部分類型（分類標準參見 TimescaleDB vs. InfluxDB 對比報告）單次查詢響應時間非常短，為了更加準確地測量每個查詢場景的較為穩(wěn)定的響應時間，我們將單個查詢運行次數(shù)提升到 5,000 次，然后使用 TSBS 自動統(tǒng)計并輸出結果，最后結果是 5,000 次查詢的算數(shù)平均值，使用并發(fā)客戶端 Workers 數(shù)量為 8。首先我們提供場景二（4,000 設備）的查詢性能對比結果：

下面我們對每個查詢結果做一定的分析說明：

由于 Simple Rollups 的整體查詢響應時間非常短，制約查詢響應時間主體因素并不是查詢涉及的數(shù)據(jù)規(guī)模，即這種類型查詢的瓶頸并不是數(shù)據(jù)規(guī)模。但是 TDengine 仍然在所有類型的查詢響應時間上優(yōu)于 InfluxDB，具體的數(shù)值比較請參見上表中的詳細數(shù)據(jù)表格。

在 Aggregates 類型的查詢中，我們看到 TDengine 查詢性能相比于 InfluxDB 有較大優(yōu)勢，TDengine cpu-max-all-8 類型的查詢性能是 InfluxDB 的 7 倍。

在 Double-rollups 類型查詢中， TDengine 同樣展現(xiàn)出巨大的性能優(yōu)勢，以查詢響應時間來度量，在 double-groupby-5 查詢上 TDengine 是 InfluxDB 的 26 倍，double-groupby-all 上是其 34 倍。

上面兩圖是 threshold 類型的查詢對比，TDengine 的查詢響應時間均顯著低于 InfluxDB。在 high-cpu-all 類型的查詢上，TDengine 的性能是 InfluxDB 的 15 倍。

對于 Complex-queries 類型的查詢，TDengine 兩個查詢均大幅領先 InfluxDB。在 lastpoint 查詢中，查詢性能是 InfluxDB 的 21倍；在 groupby-orderby-limit 場景中查詢性能是 InfluxDB 的 15 倍。

資源開銷對比

由于部分查詢持續(xù)時間特別短，因此我們并不能完整地看到查詢過程中服務器的 IO/CPU/網(wǎng)絡情況。為此我們針對場景二以 Double rollups 類別中的 double-groupby-5 查詢?yōu)槔?，?zhí)行 1,000 次查詢，記錄 TDengine 和 InfluxDB 在查詢執(zhí)行的整個過程中服務器 CPU、內存、網(wǎng)絡的開銷并進行對比。

從上圖可以看到，TDengine 和 InfluxDB 在整個查詢過程中 CPU 的使用均較為平穩(wěn)。TDengine 在查詢過程中整體 CPU 占用約 80%，使用的 CPU 資源較高，InfluxDB 穩(wěn)定的 CPU 占用較小，約 27 %（但是有較多的瞬時沖高）。從整體 CPU 開銷上來看，雖然 InfluxDB 瞬時 CPU 開銷大部分是較低的，但是其完成查詢持續(xù)時間最長，所以整體 CPU 資源消耗最多。由于 TDengine 完成全部查詢的時間僅是 InfluxDB 的 1/20，雖然 CPU 穩(wěn)定值是 InfluxDB 的 2 倍多，但整體的 CPU 計算時間消耗只有其 1/10 。

服務器內存狀況

如上圖所示，在整個查詢過程中，TDengine 與 InfluxDB 的內存均維持在一個相對平穩(wěn)的狀態(tài)。

服務器網(wǎng)絡帶寬

上圖展示了查詢過程中服務器端上行和下行的網(wǎng)絡帶寬情況，負載狀況基本上和 CPU 狀況相似。TDengine 網(wǎng)絡帶寬開銷最高，因為在最短的時間內就完成了全部查詢，需要將查詢結果返回給客戶端。InfluxDB 網(wǎng)絡帶寬開銷最低，持續(xù)時間也較長。

3,100 devices × 10 metrics 查詢性能對比

對于場景一(100 devices x 10 metrics)，TSBS 的 15 個查詢對比結果如下：

如上表所示，在更小規(guī)模的數(shù)據(jù)集（100設備）上的查詢對比可以看到，整體上 TDengine 同樣展現(xiàn)出極好的性能，在全部的查詢語句中全面優(yōu)于 InfluxDB，部分查詢性能超過 InfluxDB 37 倍。

InfluxDB 占用的磁盤空間最高達到 TDengine 的 4.5 倍

在前面三個場景中，InfluxDB 落盤后數(shù)據(jù)文件規(guī)模與 TDengine 非常接近，但是在大數(shù)據(jù)規(guī)模的場景四和場景五中，InfluxDB 落盤后文件占用的磁盤空間顯著超過了 TDengine。下圖比較了 TDengine 和 InfluxDB 在不同場景下的磁盤空間占用情況：

從上圖可以看到，在前面三個場景中，InfluxDB 落盤后數(shù)據(jù)文件規(guī)模與 TDengine 非常接近（在場景二中，TDengine 的數(shù)據(jù)落盤規(guī)模比 InfluxDB 大了 1%）。但是在場景四和場景五中，InfluxDB 落盤后文件占用的磁盤空間分別是 TDengine 的 4.2 倍和 4.5 倍。

寫在最后

基于本次測試報告，我們可以得出結論，在全部的數(shù)據(jù)場景中，TDengine 寫入性能、查詢性能均全面超過 InfluxDB。在整個寫入過程中，TDengine 在提供更高寫入和查詢能力的前提下，不論是服務器的 CPU 還是 IO，TDengine 均優(yōu)于 InfluxDB。即使加上客戶端的開銷統(tǒng)計，TDengine 在寫入開銷上也在 InfluxDB 之下。

從實踐角度出發(fā)，這個報告結果也很好地說明了為什么有很多企業(yè)客戶在 InfluxDB 和 TDengine 的選型調研中選擇了 TDengine，雙匯便是其中之一，在《雙匯大數(shù)據(jù)方案選型：從棘手的InfluxDB+Redis到毫秒級查詢的TDengine》這篇文章中，便闡述了其選型調研過程的具體思考。

為了方便大家驗證測試結果，本測試報告支持運行測試腳本一鍵復現(xiàn)，歡迎大家在評論區(qū)互動交流。同時，你也可以添加 小T vx：tdengine1，加入 TDengine 用戶交流群，和更多志同道合的開發(fā)者一起探討數(shù)據(jù)處理難題。