#時序數據庫 #TSDB #TDengine #PostgreSQL #降本增效 #國產化替代

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

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

痛點很直接：

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

合規壓力：甲方要求數據必須在本地網關保留 1 年以上，開源版 InfluxDB 的“30天強制過期”策略直接判了死刑。

硬件瓶頸：邊緣網關通常只有 32GB 或 64GB 的 eMMC 存儲，數據庫的壓縮率直接決定了能存多久。

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

參賽選手：

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

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

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

二、 測試環境與場景

為了模擬真實的工業現場，我們沒有用服務器，而是用了一臺常見的工業網關。

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

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

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

總寫入量：持續寫入 24 小時（約 4.32 億條數據點）。

三、 核心戰況：數據不會撒謊

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

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

【技術洞察】：

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

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

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

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

InfluxDB 落盤大小：1.9 GB (壓縮比 3.5:1)

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

TDengine 落盤大小：0.45 GB (壓縮比 15:1)

【結論】：

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

3. 查詢性能 (Query Latency)

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

InfluxDB: 450ms

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

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

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

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

1. TDengine 的“建模門檻”

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

風險：如果你的業務是動態字段（比如傳感器今天發 3 個參數，明天發 5 個參數），TDengine 修改表結構雖然支持，但由于表數量巨大（5000 個設備=5000 張表），DDL 操作會很繁瑣。

2. TimescaleDB 的“維護成本”

坑：它本質上是一個 PostgreSQL。如果數據量過大導致 WAL 日志堆積，或者 Vacuum（垃圾回收）機制配置不當，會把網關的磁盤寫滿導致死機。

風險：你需要一個懂 PG 調優的 DBA，而不是一個只會寫 SQL 的實習生。

3. 生態兼容性

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

五、 選型建議與配置推薦

場景 A：硬件極度受限（如樹莓派/128M內存網關）且網絡帶寬貴

推薦：TDengine。

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

場景 B：業務系統復雜，需要關聯關系型數據（如設備關聯訂單表）

推薦：TimescaleDB。

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

場景 C：不想改代碼，且預算允許（或數據量小）

推薦：繼續用 InfluxDB 1.8 或遷移至 VictoriaMetrics。

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

六、 立即行動

還在對著 64GB 的硬盤發愁嗎？

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

審核編輯 黃宇