#時序數(shù)據(jù)庫 #TSDB #TDengine #PostgreSQL #降本增效 #國產(chǎn)化替代

一、 為什么做這次評測？（決策背景）

上周，InfluxData 宣布收緊 Edge 版數(shù)據(jù)保留策略的消息，在集成商圈子里炸了鍋。

痛點很直接：

成本紅線：很多中小項目根本付不起每年 $3,000 的企業(yè)版授權(quán)費。

合規(guī)壓力：甲方要求數(shù)據(jù)必須在本地網(wǎng)關(guān)保留 1 年以上，開源版 InfluxDB 的“30天強制過期”策略直接判了死刑。

硬件瓶頸：邊緣網(wǎng)關(guān)通常只有 32GB 或 64GB 的 eMMC 存儲，數(shù)據(jù)庫的壓縮率直接決定了能存多久。

本次評測目標：尋找一款“開源免費、高性能、極高壓縮率”的替代品。

參賽選手：

守擂者：InfluxDB 1.8 (開源版) —— 老牌霸主，生態(tài)最好，但不僅也是老黃歷了，還不再維護。

挑戰(zhàn)者 A：TDengine 3.3 (開源核心版) —— 國產(chǎn)之光，主打“超級表”模型和極致壓縮。

挑戰(zhàn)者 B：TimescaleDB (基于 PG 17) —— SQL 兼容性之王，許多 IT 背景的開發(fā)者首選。

二、 測試環(huán)境與場景

為了模擬真實的工業(yè)現(xiàn)場，我們沒有用服務(wù)器，而是用了一臺常見的工業(yè)網(wǎng)關(guān)。

測試硬件：瑞芯微 RK3588 (8GB RAM, 128GB eMMC)

操作系統(tǒng)：Ubuntu 24.04 LTS (Docker 部署)

數(shù)據(jù)模型：模擬 5,000 個智能電表，每秒采集 1 次（電壓、電流、功率 3 個字段）。

總寫入量：持續(xù)寫入 24 小時（約 4.32 億條數(shù)據(jù)點）。

三、 核心戰(zhàn)況：數(shù)據(jù)不會撒謊

1. 寫入性能 (Ingest Rate) & CPU 負載

注：工業(yè)現(xiàn)場不僅看寫入速度，更看寫入時 CPU 還能不能干別的事（如跑 PLC 采集協(xié)議）。

【技術(shù)洞察】：

TDengine 的“一個設(shè)備一張表”模型在寫入端具有碾壓優(yōu)勢，幾乎沒有鎖競爭。而 TimescaleDB 由于底層是 PostgreSQL，寫入路徑較長，且極其吃內(nèi)存（PG 的緩存機制），在 8GB 網(wǎng)關(guān)上顯得非常吃力。

2. 磁盤壓縮率 (Disk Usage) —— 最關(guān)鍵指標

這是決定你能不能在 64GB 硬盤里存下 1 年數(shù)據(jù)的核心。

原始數(shù)據(jù)大小 (CSV)：約 6.8 GB

InfluxDB 落盤大?。?.9 GB (壓縮比 3.5:1)

TimescaleDB 落盤大小：4.2 GB (壓縮比 1.6:1，開啟壓縮后優(yōu)化至 2.5 GB)

TDengine 落盤大?。?.45 GB (壓縮比 15:1)

【結(jié)論】：

TDengine 完勝。其列式存儲 + delta-of-delta 壓縮算法，對于電表這種“變化不大”的時序數(shù)據(jù)簡直是魔法。同樣的硬盤，TDengine 能存的數(shù)據(jù)時長是 TimescaleDB 的 10 倍。

3. 查詢性能 (Query Latency)

測試語句：查詢某臺設(shè)備過去 24 小時的平均電壓 (AVG)。

InfluxDB: 450ms

TDengine: 12ms (因其在寫入時就預(yù)計算了 Min/Max/Avg)

TimescaleDB: 800ms (未建立索引前) / 60ms (建立索引后)

四、 避坑指南 (The Pitfalls) —— 遷移必看

別光看數(shù)據(jù)好就腦熱遷移，你需要知道代價是什么。

1. TDengine 的“建模門檻”

坑：TDengine 強推“超級表 (Supertable)”概念。如果你習(xí)慣了 InfluxDB 那種“丟進去一個 JSON 自動建索引”的 Tag 模式，你會很不適應(yīng)。你需要先定義 Schema。

風(fēng)險：如果你的業(yè)務(wù)是動態(tài)字段（比如傳感器今天發(fā) 3 個參數(shù)，明天發(fā) 5 個參數(shù)），TDengine 修改表結(jié)構(gòu)雖然支持，但由于表數(shù)量巨大（5000 個設(shè)備=5000 張表），DDL 操作會很繁瑣。

2. TimescaleDB 的“維護成本”

坑：它本質(zhì)上是一個 PostgreSQL。如果數(shù)據(jù)量過大導(dǎo)致 WAL 日志堆積，或者 Vacuum（垃圾回收）機制配置不當(dāng)，會把網(wǎng)關(guān)的磁盤寫滿導(dǎo)致死機。

風(fēng)險：你需要一個懂 PG 調(diào)優(yōu)的 DBA，而不是一個只會寫 SQL 的實習(xí)生。

3. 生態(tài)兼容性

坑：Grafana 看板。InfluxDB 的插件支持是完美的。TDengine 雖然也有官方插件，但在一些復(fù)雜的 Alerting（報警）配置上，靈活性不如 InfluxDB。

五、 選型建議與配置推薦

場景 A：硬件極度受限（如樹莓派/128M內(nèi)存網(wǎng)關(guān)）且網(wǎng)絡(luò)帶寬貴

推薦：TDengine。

理由：極致的壓縮率能幫你省下巨額的存儲卡和流量成本。它是嵌入式環(huán)境的唯一解。

場景 B：業(yè)務(wù)系統(tǒng)復(fù)雜，需要關(guān)聯(lián)關(guān)系型數(shù)據(jù)（如設(shè)備關(guān)聯(lián)訂單表）

推薦：TimescaleDB。

理由：你能用一個 SQL JOIN 查出“電壓異常且訂單金額大于 1 萬的設(shè)備”。這是 InfluxDB 和 TDengine 做不到的（它們只能存時序數(shù)據(jù)）。

場景 C：不想改代碼，且預(yù)算允許（或數(shù)據(jù)量?。?/p>

推薦：繼續(xù)用 InfluxDB 1.8 或遷移至 VictoriaMetrics。

理由：VictoriaMetrics 兼容 InfluxDB 協(xié)議，不用改一行代碼就能替換后端，且性能優(yōu)于 InfluxDB。

六、 立即行動

還在對著 64GB 的硬盤發(fā)愁嗎？

我們開發(fā)了一個“時序數(shù)據(jù)庫存儲計算器”。輸入您的點位數(shù)、采集頻率和保留時長，引擎將自動對比 InfluxDB、TDengine 和 TimescaleDB 的預(yù)計磁盤占用量和硬件要求*。

審核編輯 黃宇