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

一、 為什么做這次評(píng)測(cè)？（決策背景）

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

痛點(diǎn)很直接：

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

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

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

本次評(píng)測(cè)目標(biāo)：尋找一款“開(kāi)源免費(fèi)、高性能、極高壓縮率”的替代品。

參賽選手：

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

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

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

二、 測(cè)試環(huán)境與場(chǎng)景

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

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

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

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

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

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

1. 寫(xiě)入性能 (Ingest Rate) & CPU 負(fù)載

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

【技術(shù)洞察】：

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

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

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

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

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

TimescaleDB 落盤(pán)大?。?.2 GB (壓縮比 1.6:1，開(kāi)啟壓縮后優(yōu)化至 2.5 GB)

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

【結(jié)論】：

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

3. 查詢性能 (Query Latency)

測(cè)試語(yǔ)句：查詢某臺(tái)設(shè)備過(guò)去 24 小時(shí)的平均電壓 (AVG)。

InfluxDB: 450ms

TDengine: 12ms (因其在寫(xiě)入時(shí)就預(yù)計(jì)算了 Min/Max/Avg)

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

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

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

1. TDengine 的“建模門(mén)檻”

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

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

2. TimescaleDB 的“維護(hù)成本”

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

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

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

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

五、 選型建議與配置推薦

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

推薦：TDengine。

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

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

推薦：TimescaleDB。

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

場(chǎng)景 C：不想改代碼，且預(yù)算允許（或數(shù)據(jù)量小）

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

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

六、 立即行動(dòng)

還在對(duì)著 64GB 的硬盤(pán)發(fā)愁嗎？

我們開(kāi)發(fā)了一個(gè)“時(shí)序數(shù)據(jù)庫(kù)存儲(chǔ)計(jì)算器”。輸入您的點(diǎn)位數(shù)、采集頻率和保留時(shí)長(zhǎng)，引擎將自動(dòng)對(duì)比 InfluxDB、TDengine 和 TimescaleDB 的預(yù)計(jì)磁盤(pán)占用量和硬件要求*。

審核編輯 黃宇