轉(zhuǎn)型驅(qū)動(dòng)：橋科院為何選擇 TDengine TSDB

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

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

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

應(yīng)用成效： TDengine TSDB 帶來的核心收益

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

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

核心業(yè)務(wù)場景與 TDengine TSDB 實(shí)踐

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

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

• 建表語句：

-- 創(chuàng)建傳感器數(shù)據(jù)超級表
CREATE STABLE IF NOT EXISTS bridge_sensor_data (
    ts TIMESTAMP,
    strain_value DOUBLE,  -- 應(yīng)變值/撓度值
    stress_value DOUBLE,  -- 應(yīng)力值
    temperature DOUBLE,   -- 溫度（用于補(bǔ)償）
    vibration DOUBLE      -- 振動(dòng)數(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       -- 車道編號
);

• 查詢語句：

-- 檢測單個(gè)車輛通過速度和車重
SELECT 
  start_ts,
  end_ts,
  peak_strain,
  duration_seconds,  
  100/duration_seconds*3.6 as speed_kmh, -- 估算車速：橋梁長度/通過時(shí)間（假設(shè)橋梁長度100米）
  peak_strain*2.5 as estimated_weight_ton -- 估算車重：峰值應(yīng)變 × 標(biāo)定系數(shù)（需要現(xiàn)場標(biāo)定）
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秒時(shí)間窗口分組
  HAVING MAX(strain_value) - MIN(strain_value) > 10   -- 過濾掉噪聲，閾值可根據(jù)實(shí)際情況調(diào)整
);

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

場景二：通過橋梁風(fēng)速儀、振動(dòng)、撓度數(shù)據(jù)，每 30 秒計(jì)算前 10 分鐘最大風(fēng)力系數(shù)、各方向紊流強(qiáng)度，判斷橋梁產(chǎn)生渦振的報(bào)警值

• 建表語句：

-- 橋梁基本信息表
CREATE STABLE bridges (
  ts TIMESTAMP,
  wind_speed FLOAT,           -- 風(fēng)速(m/s)
  wind_direction FLOAT,       -- 風(fēng)向(度)
  vibration_x FLOAT,          -- X方向振動(dòng)加速度(m/s2)
  vibration_y FLOAT,          -- Y方向振動(dòng)加速度(m/s2)  
  vibration_z FLOAT,          -- Z方向振動(dòng)加速度(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 時(shí)間,
  avg_wind_speed as 平均風(fēng)速,
  max_wind_coefficient as 最大風(fēng)力系數(shù),
  turbulence_intensity as 紊流強(qiáng)度,
  vertical_vibration as 豎向振動(dòng),
  peak_vibration_amplitude as 峰值振幅,
  alert_level as 報(bào)警等級,
  vortex_intensity_index as 渦振強(qiáng)度指數(shù),
  -- 實(shí)時(shí)報(bào)警判斷
  CASE 
     WHEN vortex_intensity_index > 5 THEN '嚴(yán)重渦振報(bào)警'
    WHEN vortex_intensity_index > 3 THEN '中度渦振報(bào)警' 
    WHEN vortex_intensity_index > 1 THEN '輕微渦振注意'
    ELSE '正常'
  END as 實(shí)時(shí)報(bào)警信息
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ā)風(fēng)速區(qū)間
       AND w.turbulence_intensity < 0.2            -- 低紊流條件
       AND v.peak_vibration_amplitude > 0.5        -- 振動(dòng)幅值閾值
       AND v.rms_vibration_y > 0.1                 -- 豎向振動(dòng)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,
    -- 渦振強(qiáng)度指數(shù) (自定義計(jì)算公式)
    (v.peak_vibration_amplitude * w.avg_wind_speed * (1 - w.turbulence_intensity)) as vortex_intensity_index
  FROM
(
-- 計(jì)算10分鐘窗口的風(fēng)力參數(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,
    -- 紊流強(qiáng)度 = 標(biāo)準(zhǔn)差/平均值
    STDDEV(wind_speed) / AVG(wind_speed) as turbulence_intensity,
    -- 計(jì)算10分鐘最大風(fēng)力系數(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秒計(jì)算一次前10分鐘數(shù)據(jù)
) w 
join 
(-- 計(jì)算振動(dòng)參數(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,
    -- 主梁渦振特征頻率(假設(shè)橋梁固有頻率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  -- 忽略無風(fēng)情況
)
WHERE alert_level != 'NORMAL' ORDER BY calc_ts DESC;

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

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

• 建表語句：

CREATE STABLE IF NOT EXISTS construction_monitoring (
    ts TIMESTAMP,
    cable_force FLOAT, -- 索力（kN）
    stress FLOAT,      -- 應(yīng)力（MPa）
    elevation FLOAT    -- 標(biāo)高（m）
) TAGS (
    project_name NCHAR(50), -- 項(xiàng)目名稱：如‘深中通道S08標(biāo)’（標(biāo)簽）
    monitoring_section NCHAR(50) -- 監(jiān)控?cái)嗝妫喝纭瓸12號墩’（標(biāo)簽）
);

• 查詢語句：

# 查詢‘深中通道S08標(biāo)’項(xiàng)目下，所有監(jiān)控?cái)嗝嬖诋?dāng)前時(shí)刻的平均索力，用于指導(dǎo)施工
SELECT
    monitoring_section,LAST(cable_force) as current_cable_force
FROM construction_monitoring
WHERE project_name = '深中通道S08標(biāo)' GROUP BY monitoring_section;

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

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

• 建表語句：

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

• 查詢語句：

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

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

結(jié)語

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

關(guān)于橋科院

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

作者：李鈞

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

EMQX Cloud 配置操作步驟

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

前置準(zhǔn)備

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

步驟 1：TDengine Cloud 準(zhǔn)備?作

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

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

3. 進(jìn)?實(shí)例后，在左側(cè)菜單欄中點(diǎn)擊”數(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. 點(diǎn)擊”新建連接器”，填寫以下信息：

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

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

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

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

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

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

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

3. 點(diǎn)擊”SQL示例”和”啟?調(diào)試”按鈕可以學(xué)習(xí)和測試規(guī)則 SQL 的結(jié)果（可選）

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

步驟 4：配置動(dòng)作

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”選項(xiàng)，確保規(guī)則引擎在變量未定義時(shí)能正確處理 。

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

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

6. 點(diǎn)擊”確認(rèn)”按鈕完成動(dòng)作配置

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

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

1. 在 EMQX Cloud 部署菜單中選擇”在線調(diào)試“，并點(diǎn)擊連接 。

2. 訂閱主題 devices/temp_hum 。

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

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

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

2. 查詢上報(bào)數(shù)據(jù)結(jié)果 。

SELECT * from iot_data7.temp_hum;

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

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

TDengine Cloud 配置操作步驟

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

寫在最后

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

例如，使用以下命令可以將某臺服務(wù)器的?db1?歷史數(shù)據(jù)及實(shí)時(shí)數(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 日志進(jìn)行數(shù)據(jù)訂閱，通過事件驅(qū)動(dòng)順序處理數(shù)據(jù)。無論是實(shí)時(shí)數(shù)據(jù)的插入，還是歷史數(shù)據(jù)的補(bǔ)錄，所有數(shù)據(jù)都能夠?qū)崟r(shí)同步到目標(biāo)集群，確保數(shù)據(jù)完整性和時(shí)效性。

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

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

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

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

結(jié)語

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

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

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

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

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

關(guān)于蒼穹數(shù)碼

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

關(guān)于 TDengine

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

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

上述參數(shù)的設(shè)置，充分參考了下方 TimescaleDB vs. InfluxDB 對比報(bào)告中推薦的配置參數(shù)設(shè)置，以確保寫入性能指標(biāo)的最優(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/

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

寫入性能最高達(dá)到了 TimescaleDB 的 6.7 倍

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

不同場景下寫入性能對比

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

寫入過程資源消耗對比

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

服務(wù)端 CPU 開銷

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

磁盤 I/O 對比

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

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

客戶端 CPU 開銷

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

查詢性能最高達(dá)到了 TimescaleDB 的 28.6 倍

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

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

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

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

下面我們對每個(gè)查詢結(jié)果做一定的分析說明：

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

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

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

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

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

資源開銷對比

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

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

• 服務(wù)器內(nèi)存狀況

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

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

上圖展示了查詢過程中兩個(gè)系統(tǒng)的服務(wù)器端上行和下行的網(wǎng)絡(luò)帶寬情況，可以看到，負(fù)載狀況基本上和 CPU 狀況相似。TDengine 網(wǎng)絡(luò)帶寬開銷較高，因?yàn)樵谧疃痰臅r(shí)間內(nèi)就完成了全部查詢，需要將查詢結(jié)果返回給客戶端。TimescaleDB 開銷較低，但持續(xù)時(shí)間長。

100 devices × 10 metrics 查詢性能對比

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

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

TimescaleDB 占用的磁盤空間最高達(dá)到 TDengine 的 26.9 倍

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

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

寫在最后

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

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

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

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

為了讓企業(yè)能夠更加彈性地運(yùn)用 TDengine 的能力，我們基于 TDengine 開發(fā)出了全托管的時(shí)序數(shù)據(jù)云平臺 TDengine Cloud，它能夠?yàn)橛脩籼峁└唵巍⒏憬?、更安全的時(shí)序數(shù)據(jù)管理服務(wù)。TDengine Cloud 具備以下三點(diǎn)優(yōu)勢：

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

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

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

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

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

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

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

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

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

掃描關(guān)注下方視頻號卡片可進(jìn)行直播預(yù)約：

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

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

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

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

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

活動(dòng)推薦

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

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

在這場直播中，陶建輝將為你詳細(xì)介紹 TDengine Cloud 的功能和優(yōu)勢，并通過實(shí)際演示讓你體驗(yàn) TDengine Cloud 的強(qiáng)大和便捷。請掃描下方二維碼預(yù)約這場直播，不要錯(cuò)過這個(gè)難得的學(xué)習(xí)機(jī)會！

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

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

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

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

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

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

新增兩個(gè)可以動(dòng)態(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ù)訂閱的影響。具體細(xì)節(jié)請參考官方文檔。

5. Python UDF

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

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

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

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

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

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

• OPC UA
• OPC DA
• Pi

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

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

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

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

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

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

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

報(bào)名通道

講師介紹

李宏宇 北京沃東天駿信息技術(shù)有限公司 架構(gòu)師

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

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

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

活動(dòng)議程

按照慣例，直播中我們?yōu)榇蠹覝?zhǔn)備了抽獎(jiǎng)環(huán)節(jié)，中獎(jiǎng)?wù)呖色@得社區(qū)提供的精美周邊禮品，來到直播間就有機(jī)會中獎(jiǎng)~此外，填寫活動(dòng)反饋表也能獲得抽獎(jiǎng)機(jī)會哦：http://whaleops.mikecrm.com/1pxlyDU！

獎(jiǎng)品一覽

社區(qū)介紹

Apache SeaTunnel (Incubating)

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

TDengine

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

我們采用下方 TimescaleDB vs. InfluxDB 對比報(bào)告中推薦的方式配置 InfluxDB，將緩沖區(qū)配置為 80G，以便 1000W 設(shè)備寫入時(shí)能夠順利進(jìn)行，同時(shí)開啟 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/

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

寫入性能最高達(dá)到 InfluxDB 的 10.6 倍

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

不同場景下寫入性能對比

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

寫入過程資源消耗對比

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

服務(wù)端 CPU 開銷

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

磁盤 I/O 對比

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

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

客戶端 CPU 開銷

從上圖可以看到，客戶端上 TDengine 對 CPU 的需求是大于 InfluxDB 的。整體來說，在整個(gè)寫入過程中，InfluxDB 客戶端負(fù)載計(jì)算資源占用較低，對客戶端壓力小，這是因?yàn)槠鋵懭氲膲毫旧贤耆性诜?wù)端，但這種模式很容易導(dǎo)致服務(wù)端成為瓶頸。而 TDengine 在客戶端的開銷最大，峰值瞬間達(dá)到了 56%，然后快速回落。綜合服務(wù)器與客戶端的資源開銷來看，TDengine 寫入持續(xù)時(shí)間更短，在系統(tǒng)整體 CPU 開銷上 TDengine 仍然具有相當(dāng)大的優(yōu)勢。

查詢性能最高達(dá)到 InfluxDB 的 37 倍

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

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

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

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

下面我們對每個(gè)查詢結(jié)果做一定的分析說明：

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

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

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

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

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

資源開銷對比

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

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

服務(wù)器內(nèi)存狀況

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

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

上圖展示了查詢過程中服務(wù)器端上行和下行的網(wǎng)絡(luò)帶寬情況，負(fù)載狀況基本上和 CPU 狀況相似。TDengine 網(wǎng)絡(luò)帶寬開銷最高，因?yàn)樵谧疃痰臅r(shí)間內(nèi)就完成了全部查詢，需要將查詢結(jié)果返回給客戶端。InfluxDB 網(wǎng)絡(luò)帶寬開銷最低，持續(xù)時(shí)間也較長。

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

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

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

InfluxDB 占用的磁盤空間最高達(dá)到 TDengine 的 4.5 倍

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

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

寫在最后

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

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

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