工业数据到底该存哪里？——InfluxDB和TDengine的真实对比

一个中等规模的工厂，1000个传感器，每秒采集一次，一年产生约315亿条数据-26。

用MySQL存？一张表315亿行，查询最近1小时的数据要扫描数十万行索引，响应时间从秒级到分钟级-26。写入吞吐量约2万条/秒，加上索引维护和查询并发，实际写入能力急剧下降-26。

所以必须用时序数据库。但时序数据库有好几种，选哪个？

我用了两年InfluxDB，后来迁到了TDengine，说一下真实感受。

InfluxDB：开创者，但有硬伤

InfluxDB是最早被工业领域广泛采用的时序数据库之一。存储引擎TSM针对时序数据的写入模式做了优化，InfluxQL查询语言类似SQL，入门门槛低-29。

优点很明确： 部署简单，一个二进制文件跑起来就行。生态成熟，Grafana、Telegraf这些工具原生支持。查询语法灵活，Flux语言功能强大。

但在工业大规模部署中，InfluxDB有几个绕不过去的硬伤。

第一个是内存占用。InfluxDB在处理高基数数据时，内存消耗急剧增长。工业场景中，测点标识（设备编号+传感器编号的组合）数量可能达到数百万，InfluxDB的索引结构在处理高基数时性能下降非常明显-29。

第二个是集群能力。InfluxDB的开源版本不支持集群，企业版集群功能收费高昂。单节点的存储和写入能力上限大约在每天1到2TB，对于超大规模工业部署不够用-29。

第三个是压缩比。工业传感器数据通常是浮点数，变化缓慢且存在大量重复值，理论上具有极高的压缩比。但InfluxDB的通用压缩算法未能充分利用这一特性，存储成本较高-29。

我当时的场景：2000个测点，1秒采集一次。InfluxDB跑了一个月之后，查询"最近一小时的平均值"开始变慢。数据量到了几亿条之后，查询时间从几百毫秒涨到了几秒。

能用，但不够好。

TDengine：为工业场景设计的时序数据库

TDengine的核心设计跟InfluxDB完全不一样。

数据模型：一个设备一张表。

这是TDengine最核心的创新。每个设备的数据存储为一张独立的子表，所有设备的子表通过超级表统一管理。查询特定设备的历史数据时可以高效定位，避免全表扫描-29。

写入性能：单核每秒100万条。

这是官方宣称的数字。实际测试中，单线程约50万条/秒，开启多线程后可达150万条/秒-26。InfluxDB的单线程写入约20万条/秒，多线程约50万条/秒-26。

压缩比：10:1到50:1。

TDengine针对工业数值型数据采用了二阶差分编码和游程编码。在实际工业部署中，2TB的原始数据在TDengine中可能仅占用40到200GB存储空间。InfluxDB的典型压缩比约为3:1-29。

这意味着什么？同样的数据量，TDengine的存储成本可能只有InfluxDB的五分之一甚至更低。

内置边缘-云端同步。

这一点对工业场景特别重要。边缘网关通常需要本地存储数据以应对网络中断，网络恢复后再同步到中心数据库。TDengine的跨节点自动复制功能原生支持这个场景，不需要额外的数据同步中间件-29。

我之前那个2000测点的项目，从InfluxDB迁到TDengine之后，查询"最近一小时的平均值"从几秒降到了几十毫秒。存储空间从原来的几百GB降到了几十GB。

查询性能实测对比

测试环境：16核CPU、64GB内存、NVMe SSD。1000个设备，每个设备10个传感器，1秒采集间隔，写入1亿条数据。

查询场景一：100个设备最近1小时的平均值。

TDengine：约50ms
InfluxDB：约200ms
TimescaleDB：约300ms
IoTDB：约80ms-26

查询场景二：1个设备最近30天的原始数据（约260万条）。

TDengine：约1.2秒
InfluxDB：约3.5秒
TimescaleDB：约5秒
IoTDB：约1.8秒-26

那到底选哪个？

选TDengine的场景：

测点数超过1万个

数据量超过每天1000万条

需要集群部署（高可用）

存储成本敏感

有边缘-云端同步需求

选InfluxDB的场景：

测点数少于1万个

数据量不大，单节点够用

团队已经熟悉InfluxQL和Flux

需要跟现有的InfluxDB生态（Telegraf、Kapacitor）集成

如果让我给一个简单建议：新项目直接用TDengine。

除非你有明确的理由必须用InfluxDB，否则TDengine在工业场景下的综合表现更好——写入更快、压缩更高、支持集群、资源占用更低。

从InfluxDB迁移到TDengine的注意事项

第一，数据模型要重新设计。 InfluxDB的measurement+tag+field模型跟TDengine的超级表+子表模型不一样。迁移之前要把数据模型重新设计一遍。

第二，查询语句要重写。 InfluxQL和TDengine的SQL虽然看起来相似，但细节有很多差异。复杂的子查询和窗口函数在TDengine里可能不支持。

第三，客户端代码要改。 InfluxDB的客户端库跟TDengine的不一样。如果用了InfluxDB的Java/C#/Python客户端，迁移的时候要换成TDengine的对应库。

第四，数据迁移要分批做。 不要一次性把几亿条数据从InfluxDB导到TDengine。分批迁移，每批验证数据一致性。

关于工具

EdgeLiteGateway内置了数据转发的功能，支持转发到InfluxDB和HTTP Webhook。如果需要在边缘侧做数据缓存、断网重传，再统一转发到中心时序数据库，这个项目可以省掉自己写采集和转发逻辑的功夫。

GitHub：suoten/EdgeLiteGateway
Gitee：suoten/EdgeLiteGateway