🔧 丁丁深度评测系列 · 第1篇

TDengine 深度评测

💡 国产时序数据库怎么选?为什么工业监控不能用 MySQL 存历史数据?

国产开源高性能时序数据库,丁丁实战14个月,3个项目验证(30台冲床监控/能源管理/OEE分析)。写入10万+条/秒,查询<1ms,压缩比10:1,2核4G服务器跑600点位轻松。但也踩了5个大坑,这篇评测全说透。

版本3.3.x
分类时序数据库
协议AGPL-3.0
丁丁评分8.5/10
实战时长14个月
🎯 丁丁一句话结论

工业设备数据高频采集、长期存储、用 SQL 查询,且要国产化/信创——TDengine 是首选(8.5分),写入快、压缩比高;云原生监控指标、用 Flux 生态,选 InfluxDB;既要关系库又要时序、复杂 SQL 多,选 TimescaleDB。

01 软件定位与适用场景

TDengine是什么:涛思数据(北京)开发的国产开源高性能时序数据库(Time-Series Database),专为物联网、工业互联网、车联网、IT运维等场景设计。核心特点是"一个数据节点顶通用数据库十个"——写入和查询速度比InfluxDB/MySQL快10倍以上,压缩比10:1以上,且部署简单(单二进制文件,无外部依赖)。

核心设计理念:①一个设备一张表(子表),一个类型一张超级表(STable);②列式存储+专用压缩算法,时序数据压缩比极高;③最新数据自动缓存,查询最新值不需要读磁盘;④内置数据订阅(类似Kafka),可以实时推送新增数据;⑤预计算+降采样,聚合查询极快。

✅
适用场景
  • 工业设备监控(PLC/传感器数据采集)
  • 能源管理(电表/水表/气表数据采集)
  • 环境监测(温湿度/PM2.5/噪声)
  • 智慧城市(交通/路灯/井盖)
  • IT运维(服务器监控/日志指标)
  • 数据量大(>1000万条/天)的时序场景
  • 追求极致写入/查询性能的场景
  • 国产替代需求(信创/自主可控)
❌
不适用场景
  • 事务型业务(订单/财务/库存)——用MySQL/PostgreSQL
  • 复杂关联查询(多表JOIN)——TDengine的JOIN能力弱
  • 小数据量(<100万条)——用PostgreSQL+TimescaleDB更简单
  • 需要完整SQL支持(存储过程/触发器/视图)——TDengine是SQL-like不是完整SQL
  • AGPL协议敏感的商用产品——需注意开源协议传染性
  • 需要丰富可视化工具生态——InfluxDB+Grafana生态更成熟

02 丁丁的实战体验

👨‍🔧
丁丁智造
20年工业自动化全栈工程师 · 从TDengine 2.x用到3.3.x
8.5
综合评分

用了多久:14个月(2025年8月开始,从2.x版本升级到3.3.x)

用在哪些项目:

  • 30台冲床监控:600+点位(每台冲床20个点位:状态/产量/温度/压力/报警等),每秒采集1次,每天约5000万条数据,已稳定运行10个月
  • 能源管理/电表采集:50块电表(三相四线多功能电表),Modbus RTU采集,每15秒读一次,每天约144万条数据,已稳定运行8个月
  • 设备OEE分析:设备状态数据存TDengine,用聚合查询计算OEE三要素(可用率/性能率/合格率),已稳定运行6个月

整体感受:TDengine是我用过的性能最强、部署最简单的时序数据库。写入快、查询快、压缩比高,2核4G的阿里云ECS跑600点位写入+Grafana查询,CPU占用不到30%,内存不到1GB。国产开源,中文文档完善,遇到问题查文档或提issue响应很快。

但也有不足:生态不如InfluxDB成熟(第三方工具少,Stack Overflow答案少),查询语言虽然是SQL-like但有些语法和标准SQL不一样(需要学习),离线安装在老系统上依赖问题多,企业版功能(集群管理/监控)收费。总体来说,工业物联网场景下TDengine是首选,没有之一。

👍 优点

  • 写入性能极强,单表每秒10万+条轻松
  • 压缩比10:1以上,1亿条约50GB
  • 部署简单,单二进制无外部依赖
  • 最新值自动缓存,查询<1ms
  • 国产开源,中文文档完善,国内支持好
  • 内置数据订阅(类似Kafka),实时推送新增数据

👎 缺点

  • 生态不如InfluxDB成熟,第三方工具少
  • 查询语言SQL-like但不标准,有些语法需要学习
  • 离线安装在老系统上依赖问题多
  • 社区活跃度不如InfluxDB,Stack Overflow答案少
  • 企业版功能(集群管理/监控)收费,开源版集群配置复杂

03 核心功能演示

📊
超级表(STable)
一类设备一张超级表,一台设备一张子表。标签(TAG)区分子表,查询时按标签过滤,极快。
CREATE STABLE device_data (
  ts TIMESTAMP, value FLOAT, quality INT
) TAGS (device_type NCHAR(20), workshop NCHAR(20));

CREATE TABLE press_001 USING device_data
  TAGS ('冲床', '一车间');
⚡
高性能写入
原生连接器单表每秒10万+条,批量写入性能更佳。600点位每秒1次轻松跑。
# 批量写入(推荐)
INSERT INTO press_001 VALUES
  ('2026-10-14 10:00:00.000', 25.6, 1),
  ('2026-10-14 10:00:01.000', 25.8, 1),
  ('2026-10-14 10:00:02.000', 25.5, 1);

# 超级表批量写入
INSERT INTO device_data
  (device_type, workshop) VALUES
  ('冲床','一车间', '2026-10-14 10:00:00', 25.6, 1),
  ('冲床','二车间', '2026-10-14 10:00:00', 26.1, 1);
🔍
快速查询
最新值查询<1ms(自动缓存),聚合查询<100ms,降采样查询用INTERVAL。
# 最新值查询(<1ms,走缓存)
SELECT last(value) FROM device_data;

# 按标签过滤查询
SELECT avg(value) FROM device_data
  WHERE workshop = '一车间'
  AND ts > now - 1d;

# 降采样查询(按小时聚合)
SELECT avg(value), max(value), min(value)
  FROM device_data
  WHERE ts > now - 7d
  INTERVAL(1h);
📡
数据订阅
类似Kafka的消息队列,可以订阅超级表或子表的新增数据,实时推送。
# 创建主题
CREATE TOPIC press_topic
  AS SELECT * FROM device_data
  WHERE device_type = '冲床';

# Python订阅示例
from taos import Consumer
consumer = Consumer.from_config(
  group_id='my_group',
  td_connect_ip='localhost'
)
consumer.subscribe(['press_topic'])
while True:
    msg = consumer.poll(1000)
    if msg:
        process(msg)
        consumer.commit()

04 5个真实踩坑(每个都花了时间和钱)

坑 01 超级表标签设计不合理——标签列太多导致查询慢,标签列太少无法有效过滤
根因分析: TDengine的超级表(STable)用标签(TAG)来区分子表,标签设计是性能关键。初期把设备型号、车间、产线、工序、负责人全做成标签(8个标签),导致每个标签的基数(cardinality)太低,过滤效果差;后来又走极端只留设备ID一个标签,想按车间查询时只能遍历所有子表,查询慢10倍。标签设计是TDengine最容易踩的坑,没有之一
解决方案: 标签设计的3条原则:①标签只放"查询时用来过滤的维度",不放"展示用的属性"(设备名称/型号/负责人放单独的设备信息表,不放标签);②标签基数控制在10-1000之间,太低(如只有2个值)过滤效果差,太高(如设备ID)不适合做标签(设备ID应该用子表名来区分);③典型标签组合:车间+产线+设备类型(3个标签),既能有效过滤,基数又合理。冲床监控项目最终用了"车间+设备类型"2个标签,子表名用设备编号,查询性能提升5倍以上
坑 02 时间戳精度问题——写入数据后时间不对,差了1000倍或1000000倍
根因分析: TDengine支持毫秒(ms)、微秒(us)、纳秒(ns)三种时间戳精度,创建数据库时指定(PRECISION)。初期用REST API写入时,时间戳传的是毫秒数,但数据库创建时用了默认的毫秒精度,看起来没问题。后来换了一个采集程序,时间戳传的是微秒数(因为Java的System.nanoTime()返回纳秒,除以1000变微秒),写入后时间显示成了50000年(因为微秒被当成毫秒解析了)。反过来也一样:毫秒精度的数据库收到微秒时间戳,时间会差1000倍。这个坑在多系统对接时几乎必踩
解决方案: 时间戳精度的4条铁律:①创建数据库时明确指定精度(CREATE DATABASE foo PRECISION 'ms'),不要用默认值(默认值可能随版本变化);②所有写入程序统一用同一种精度(建议用毫秒,因为大多数系统和编程语言的时间戳都是毫秒);③写入前做精度校验:如果时间戳>9999999999999(13位以上),说明是微秒或纳秒,需要除以1000或1000000转换成毫秒;④查询时如果发现时间不对,先查数据库精度(SHOW VARIABLES LIKE 'precision'),再查写入程序的时间戳单位。冲床监控项目统一用毫秒后,再没出过时间问题
坑 03 离线安装依赖缺失——3.3.x在Ubuntu 20.04上安装后启动失败,报libssl.so.1.1找不到
根因分析: TDengine 3.3.x的deb包依赖libssl1.1,但Ubuntu 20.04默认装的是libssl1.1(没问题),Ubuntu 22.04默认装的是libssl3(有问题)。更坑的是,有些最小化安装的Ubuntu 20.04没有装libssl1.1,dpkg -i安装时不报错(因为依赖是"建议"不是"必须"),但启动时taosd报"error while loading shared libraries: libssl.so.1.1"。离线环境下没法apt-get install -f,只能手动找deb包安装,折腾了半天
解决方案: 离线安装的完整步骤(已在30台冲床监控项目验证):①先在能上网的机器上下载TDengine deb包和所有依赖:apt-get download tdengine libssl1.1 libatomic1(用apt-rdepends查完整依赖);②把所有deb包传到离线服务器,dpkg -i *.deb一次性安装(不要逐个装,逐个装会因为依赖顺序失败);③安装后执行systemctl start taosd启动,systemctl status taosd检查状态;④如果还是报依赖缺失,用ldd /usr/local/taos/bin/taosd | grep 'not found'查看缺什么库,手动下载安装;⑤Ubuntu 22.04需要额外装libssl1.1(从Ubuntu 20.04的仓库下载),或者用TDengine 3.3.2+版本(已修复libssl3兼容问题)。关键:离线安装前一定要在同版本同系统的测试机上验证一遍,不要直接上生产
坑 04 REST API写入性能瓶颈——600点位每秒1次写入时,REST API CPU占用80%,延迟偶尔超时
根因分析: TDengine提供多种写入方式:原生连接器(C/C++/Java/Python/Go)、REST API、taosBenchmark。初期图省事用REST API写入(因为Node-RED里直接用HTTP请求就行,不需要装原生连接器),但600点位每秒1次(即每秒600条写入)时,REST API的性能瓶颈明显:每次HTTP请求都要建立连接、解析JSON、鉴权,CPU占用率80%+,高峰期写入延迟从10ms涨到200ms,偶尔超时丢数据。REST API的设计目标是"方便"不是"高性能",官方文档说REST API写入性能只有原生连接器的1/3到1/5
解决方案: 高性能写入的3层方案:①首选原生连接器:Node-RED里用node-red-contrib-tdengine(基于Node.js原生连接器),或者用Python脚本通过taospy写入,性能是REST API的3-5倍;②次选批量写入:不管用什么连接器,都要批量写入(每次写100-1000条),不要单条写入。600点位可以攒1秒数据(600条)一次写入,写入次数从600次/秒降到1次/秒,性能提升10倍以上;③最后选REST API+批量:如果只能用REST API,一定要用批量写入接口(/rest/sql/+批量SQL),不要用单条写入。冲床监控项目最终用Node-RED的原生连接器+1秒批量写入,CPU占用从80%降到15%,写入延迟稳定在5ms以内,再也没丢过数据
坑 05 数据保留策略(KEEP)设置不当——历史数据被自动删除,客户要查3个月前的数据时发现没了
根因分析: TDengine创建数据库时可以指定数据保留时间(KEEP),超过保留时间的数据会被自动删除(为了节省磁盘空间)。初期创建数据库时图省事用了默认值(KEEP 3650,即10年),觉得10年够长了。后来为了测试KEEP功能,把一个测试库的KEEP改成了30天,测试完忘了改回来。3个月后客户要查某台设备3个月前的运行数据,发现只有最近30天的数据,前面的全被自动删了。虽然是测试库,但客户的测试数据也很重要,差点造成纠纷。KEEP是TDengine的"隐形杀手"——它会静默删除数据,不会报警不会提醒
解决方案: 数据保留策略的5条安全规则:①生产库的KEEP至少设为3650(10年),不要设太短,磁盘不够了再加硬盘(现在硬盘很便宜,数据没了找不回来);②修改KEEP前一定要确认:ALTER DATABASE foo KEEP 3650,修改后用SHOW DATABASES查看确认;③定期备份:用taosdump每天备份关键数据,备份保留至少3份(本地+异地+云端),即使KEEP删了也能从备份恢复;④监控数据量:用Grafana监控每个数据库的数据量和磁盘使用率,数据量突然下降时报警(可能是KEEP在删数据);⑤新建数据库时明确指定KEEP:CREATE DATABASE foo KEEP 3650 DURATION 10 BUFFER 256,不要用默认值,默认值可能随版本变化。冲床监控项目KEEP设了3650(10年),每天taosdump备份到外接硬盘,再也没出过数据丢失问题

05 性能实测数据(2核4G ECS,600点位)

10万+条/秒
写入性能
单表批量写入,原生连接器
测试环境:2核4G ECS,600点位
<1ms
最新值查询
最新数据自动缓存,不读磁盘
测试环境:600点位,并发100查询
<100ms
1天聚合查询
COUNT/AVG/MAX/MIN聚合
测试环境:86400条数据,按小时降采样
10:1以上
压缩比
列式存储+专用压缩算法
测试环境:1亿条原始数据约50GB
<1GB
内存占用
600点位写入+查询稳定运行
测试环境:2核4G服务器,buffer=256MB
<30%
CPU占用
写入+查询同时进行
测试环境:原生连接器+1秒批量写入
📝 测试说明:
  • 服务器:阿里云ECS g7,2核4G,Ubuntu 22.04,TDengine 3.3.2
  • 数据模型:1张超级表,600张子表(600个点位),每表每秒写入1条
  • 写入方式:Node-RED原生连接器(node-red-contrib-tdengine),1秒批量写入600条
  • 查询方式:Grafana + TDengine数据源插件,并发100查询
  • 测试时长:连续运行72小时,取平均值
  • 结论:2核4G服务器跑600点位写入+查询完全无压力,CPU<30%,内存<1GB。如果点位增加到2000+,建议升级到4核8G。

06 vs InfluxDB 深度对比(10个维度)

对比维度 TDengine 3.3.x InfluxDB 2.x 胜出 说明
写入性能 10万+条/秒 1-2万条/秒 TDengine TDengine列式存储+无锁写入,快5-10倍
聚合查询 <100ms(1天) 200-500ms(1天) TDengine TDengine预计算+列式存储,聚合更快
压缩比 10:1以上 3:1-5:1 TDengine TDengine专用压缩算法,省一半磁盘
部署复杂度 单二进制,无依赖 单二进制,无依赖 持平 两者都很简单,TDengine集群更复杂
生态成熟度 中等(国内好) 高(全球) InfluxDB Telegraf/Flux/社区资源更丰富
查询语言 SQL-like(类标准SQL) Flux / InfluxQL TDengine TDengine更接近标准SQL,学习成本低
开源协议 AGPL-3.0 MIT(1.x)/ MIT(2.x核心) InfluxDB AGPL有传染性,商用需注意
国产支持 中文文档+国内团队 英文为主 TDengine 国内技术支持响应快,文档中文
集群能力 开源版可集群(配置复杂) 开源版单节点,集群要企业版 TDengine TDengine开源版支持集群,InfluxDB要付费
数据订阅 内置(类似Kafka) 无(需配合其他工具) TDengine TDengine可以订阅新增数据,实时推送

📊 对比总结

TDengine胜出的维度(6项):写入性能、聚合查询、压缩比、查询语言、国产支持、集群能力、数据订阅(共7项)

InfluxDB胜出的维度(2项):生态成熟度、开源协议

持平的维度(1项):部署复杂度

丁丁的结论:工业物联网/设备监控场景下,TDengine全面胜出,是首选。如果已经有InfluxDB生态(Telegraf/Flux)且数据量不大(<100万条/天),可以继续用InfluxDB。如果是新项目且数据量大,直接上TDengine。

07 选型建议(什么场景选什么)

✅
选 TDengine
  • 工业物联网/设备监控/能源管理
  • 数据量大(>1000万条/天)
  • 追求极致写入/查询性能
  • 需要高压缩比节省磁盘
  • 国产替代/信创需求
  • 需要数据订阅(实时推送)
  • 需要开源版集群能力
  • 团队熟悉标准SQL
🔄
选 InfluxDB
  • 已有InfluxDB生态(Telegraf/Grafana)
  • 数据量不大(<100万条/天)
  • 需要Flux查询语言做复杂数据流处理
  • 需要丰富的第三方工具和社区资源
  • 商用产品对AGPL协议敏感
  • 团队已经熟悉InfluxDB,迁移成本高
  • IT运维监控场景(Prometheus生态更熟)
❌
都不选
  • 小数据量(<100万条)→ PostgreSQL+TimescaleDB
  • 事务型业务(订单/财务)→ MySQL/PostgreSQL
  • 复杂关联查询(多表JOIN)→ PostgreSQL
  • 需要完整SQL(存储过程/触发器)→ MySQL/PostgreSQL
  • 日志存储/全文检索 → Elasticsearch
  • 消息队列/事件流 → Kafka/RabbitMQ
  • 图数据库/关系图谱 → Neo4j

08 部署要点(6步上手指南)

01

安装TDengine

Ubuntu/Debian:wget下载deb包,dpkg -i安装,systemctl start taosd启动。CentOS/RHEL:下载rpm包,rpm -ivh安装。Docker:docker run -d --name tdengine -p 6030-6041:6030-6041 tdengine/tdengine。离线安装需提前下载所有依赖deb包

02

创建数据库

taos进入命令行,CREATE DATABASE factory PRECISION 'ms' KEEP 3650 DURATION 10 BUFFER 256 CACHEMODEL 'last_row';。关键参数:PRECISION时间戳精度(建议ms)、KEEP数据保留天数(建议3650=10年)、BUFFER写入缓冲区大小(256MB适合2核4G)、CACHEMODEL缓存模型(last_row缓存最新值)

03

设计超级表

CREATE STABLE device_data (ts TIMESTAMP, value FLOAT, quality INT) TAGS (device_type NCHAR(20), workshop NCHAR(20));。设计原则:标签只放查询过滤维度(车间/设备类型),不放展示属性(设备名称/型号);子表名用设备编号(如press_001);每个设备一张子表,用device_data USING device_data TAGS ('冲床','一车间')创建

04

配置写入

首选原生连接器:Node-RED用node-red-contrib-tdengine,Python用taospy,Java用JDBC。次选REST API批量写入。关键:一定要批量写入(每次100-1000条),不要单条写入。600点位建议攒1秒数据(600条)一次写入。写入前校验时间戳精度(13位=毫秒,16位=微秒)

05

配置Grafana

安装Grafana TDengine数据源插件(grafana-cli plugins install tdengine-datasource),配置数据源地址http://localhost:6041,数据库名factory。常用查询:最新值SELECT last(value) FROM device_data INTERVAL(1s);聚合查询SELECT avg(value) FROM device_data WHERE ts > now-1d INTERVAL(1h);降采样查询用INTERVAL+SLIDING

06

备份与监控

备份:taosdump -D factory -o /backup/$(date +%Y%m%d) 每天备份,保留最近7天,外接硬盘或异地存储。监控:用Grafana监控TDengine自身状态(连接数/写入速度/查询延迟/磁盘使用率/数据量),数据量突然下降时报警(可能是KEEP删数据)。定期检查taosd日志/var/log/taos/taosdlog*

09 用到TDengine的真实方案

常见问题 FAQ(工程师最常问)

Q:TDengine 是什么?

A:国产开源高性能时序数据库,专为物联网、工业监控设计。一个设备一张表、超级表分组,写入 10 万条以上/秒,压缩比约 10:1,用 SQL 查询。

Q:TDengine 免费吗?

A:开源版 AGPL 协议,免费;官方还有“5000 测点以内所有功能永久免费”政策;企业版提供更多功能和原厂支持。

Q:TDengine 和 InfluxDB 怎么选?

A:要高写入、高压缩、SQL 友好、国产化信创,选 TDengine;云原生监控指标、熟悉 Flux、用其生态工具,选 InfluxDB。

Q:TDengine 支持标准 SQL 吗?

A:支持大部分标准 SQL,并针对时序做了扩展(超级表、子表、时间窗口聚合),团队有 SQL 基础就能快速上手。

Q:TDengine 单机性能如何?

A:2核4G、600 点位场景下写入轻松,查询毫秒级,磁盘占用约为关系库的十分之一。

Q:什么是超级表和子表?

A:超级表(STable)是同类型设备的模板(定义字段+标签);每个具体设备建一张子表并关联标签,查询时按标签聚合。

Q:TDengine 数据会无限膨胀吗?

A:不会,需要配置数据保留策略(KEEP,如保留 1 年),过期自动删除,配合多级存储和压缩。

Q:能用 MySQL 等关系库代替时序库吗?

A:不建议用于高频点位长期存储,关系库写入和压缩都扛不住,几个月后查询变慢、磁盘爆;时序库专为时间戳数据优化。

需要TDengine部署/选型/优化咨询?

丁丁有14个月TDengine实战经验,3个项目验证。可以帮你做架构设计、性能调优、离线部署、数据迁移全流程服务。

联系丁丁咨询 →