工业边缘场景的终极选型：实测对比 TDengine 3.0 与 TimescaleDB，谁能胜出？

#时序数据库 #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 采集协议）。

测试项目	InfluxDB 1.8	TDengine 3.3	TimescaleDB	胜出者
写入速度 (点/秒)	85,000	220,000	65,000	TDengine
CPU 占用率 (平均)	45%	12%	68%	TDengine
内存占用 (峰值)	2.1 GB	0.8 GB	3.5 GB	TDengine

【技术洞察】：

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 的预计磁盘占用量和硬件要求*。

审核编辑 黄宇