时序数据库架构选型与工业IoT场景落地——从InfluxDB到TDengine的技术决策一个典型的工业IoT场景10万台设备每台设备50个采集点位每秒上报一次写入峰值是500万点/秒。用MySQL存一台机器撑不住一抽屉硬盘也存不下。这篇文章拆解时序数据库的核心架构差异以及我们是怎么在千万点位/秒的写入压力下选型的。一、为什么关系型数据库扛不住IoT时序数据先算一笔账。维度MySQL/PostgreSQL时序数据库TDengine为例写入吞吐~5万行/秒单表最优500万点/秒压缩比1:1.5 ~ 1:31:5 ~ 1:10按时间范围查询全表扫描索引失效时间分区直接剪枝数据保留策略手动删锁表自动降采样TTL多设备查询JOIN地狱标签索引自动分组核心矛盾关系型数据库的 BTree 索引是为随机读写 点查设计的而 IoT 数据的特征是顺序写入 时间范围查询。两者天然不匹配。三个结构性问题问题一写入放大MySQL 每写一行要更新主键索引、二级索引、写 redo log、写 binlog。IoT 数据不需要事务这些开销全部是浪费。时序数据库的 LSM-Tree 或列式存储写入就是 append-only不存在随机 I/O。问题二时间分区缺失查最近 7 天的设备温度趋势即使ts有索引大时间跨度查询仍然要走大量随机 I/O。时序数据库在存储层按时间分片shard/partition查询时直接跳过无关时间片I/O 量减少 90%。问题三数据压缩IoT 数据有两个特征时间维度高度有序 数值维度变化缓慢。Delta-of-Delta 编码能把时间戳从 8 字节压缩到平均 1-2 比特XOR 编码能把双精度浮点从 8 字节压缩到平均 1-2 字节。关系型数据库的 page 压缩根本做不到这个级别。二、时序数据库核心架构2.1 列式存储 时间分区时序数据的存储模型可以抽象为一张无限追加的宽表measurement: device_metrics tags: device_iddev_001, locationhangzhou, typetemperature fields: value23.5, battery87, signal-42 timestamp: 1717584000关键设计tag 列用字典编码压缩field 列用列式压缩timestamp 列用 Delta-of-Delta 压缩。存储布局列式 ┌──────────────────────────────────────────────┐ │ Shard 1: [2024-06-01 00:00 ~ 06:00] │ │ timestamp列: [ΔΔ编码, 极高压缩] │ │ device_id列: [字典编码, 整数化] │ │ value列: [XOR/简单8b编码] │ ├──────────────────────────────────────────────┤ │ Shard 2: [2024-06-01 06:00 ~ 12:00] │ │ ... │ └──────────────────────────────────────────────┘2.2 核心压缩算法Delta-of-Delta时间戳压缩原始时间戳1717584000, 1717584001, 1717584002, 1717584003 → Delta 1, 1, 1 → Delta-of-Delta 0, 0, 0 → 编码后每个时间戳平均 1-2 bitsGorilla/XOR浮点值压缩Facebook Gorilla 论文VLDB 2015提出的 XOR 编码相邻两个 double 值做 XOR前导零和尾随零重复出现时只存一次。工业 IoT 的温度/湿度等慢变数据压缩比可达 10:1 以上。简单8bSimple-8bInfluxDB TSM 引擎使用的整数编码方案将多个小整数打包进 64-bit word适合存储 tag 的字典编码值。2.3 自动降采样Downsampling时序数据库最有价值的功能之一——原始数据自动聚合为不同精度-- InfluxDB: 创建降采样策略CREATECONTINUOUS QUERYcq_10mONiot_dbBEGINSELECTmean(value)ASmean_valueINTOdevice_metrics_10mFROMdevice_metricsGROUPBYtime(10m),device_idENDTDengine 的做法更激进——用超级表Super Table 子表自动分区在写入时直接按时间窗口预聚合查询时自动路由到对应精度。三、主流方案深度对比3.1 InfluxDB存储引擎TSMTime-Structured Merge TreeTSM 是 LSM-Tree 的时序专用变体WAL 保证写入不丢内存中的 Cache 定期 flush 成 TSM 文件不可变后台 Compaction 合并 TSM 文件同一 Series 的数据尽量 compact 到同一个文件查询语言Fluxfrom(bucket: iot_bucket) | range(start: -1h) | filter(fn: (r) r[_measurement] device_metrics) | filter(fn: (r) r[device_id] dev_001) | aggregateWindow(every: 10m, fn: mean) | yield(name: mean)Flux 比 InfluxQL类SQL更灵活但学习曲线陡峭。TICK 技术栈Telegraf数据采集 agent支持 200 input pluginsInfluxDB存储 查询ChronografWeb 可视化Kapacitor实时流计算 告警适用场景中小规模 IoT 平台、DevOps 监控、APM。集群版需 InfluxDB Enterprise。3.2 TDengine超级表模型Super TableTDengine 最核心的架构创新。一张超级表对应一个设备类型每个设备自动建一张子表-- 创建超级表模板CREATESTABLE device_metrics(tsTIMESTAMP,valueDOUBLE,batteryINT)TAGS(device_idBINARY(32),locationBINARY(32));-- 写入数据自动创建子表 dev_001INSERTINTOdevice_metricsUSINGdevice_metrics TAGS(dev_001,hangzhou)VALUES(NOW,23.5,87);-- 查询自动按 device_id 分组SELECTavg(value)FROMdevice_metricsWHEREtsNOW-7dGROUPBYdevice_id;10倍压缩比TDengine 官方 benchmark同样 IoT 数据磁盘占用是 InfluxDB 的 1/5 ~ 1/10。核心原因超级表子表自动分区每个子表独立压缩压缩字典更高效时间戳 Delta-of-Deltafield 使用 XOR/Simple-8b支持 ZSTD 二级压缩适用场景大规模工业 IoT百万设备、对 SQL 兼容性要求高的团队。3.3 TimescaleDB自动分区HypertableTimescaleDB 是 PostgreSQL 扩展插件核心抽象是 Hypertable逻辑表 Chunk物理分区-- 创建 Hypertable自动按时间分区SELECTcreate_hypertable(device_metrics,ts);-- 插入数据和普通 PostgreSQL 完全一样INSERTINTOdevice_metrics(ts,device_id,value)VALUES(NOW(),dev_001,23.5);-- 查询完全兼容 PostgreSQL 语法SELECTdevice_id,avg(value)FROMdevice_metricsWHEREtsNOW()-INTERVAL7 daysGROUPBYdevice_id;最大优势完整 SQL 支持因为底层是 PostgreSQL你可以JOIN 时序数据和业务数据如设备元数据表用窗口函数做复杂分析LAG,LEAD,PERCENT_RANK用 PostGIS 扩展做地理位置分析适用场景团队已有 PostgreSQL 技术栈、需要复杂分析查询、数据量在亿级以内。3.4 ClickHouseMergeTree 引擎族ClickHouse 不是专门的时序数据库但 MergeTree 引擎对时序场景极其友好CREATETABLEdevice_metrics(tsDateTime,device_id String,location String,valueFloat64)ENGINEMergeTreePARTITIONBYtoYYYYMMDD(ts)-- 按天分区ORDERBY(device_id,ts);-- 排序键存储顺序 查询剪枝-- 物化视图自动预聚合CREATEMATERIALIZEDVIEWdevice_metrics_10mENGINEMergeTreePARTITIONBYtoYYYYMMDD(ts)ORDERBY(device_id,ts)ASSELECTtoStartOfTenMinutes(ts)ASts_10m,device_id,avg(value)ASavg_valueFROMdevice_metricsGROUPBYts_10m,device_id;向量化执行引擎ClickHouse 查询速度是列存数据库中最快的之一——一次 CPU 指令处理 64~256 行数据SIMD而非逐行处理。配合预排序ORDER BY范围查询可以直接用二分查找定位。适用场景离线分析为主、对查询延迟要求极高亚秒级、不需要实时写入。3.5 PrometheusTSDB 块存储data/ ├── 01BKGV7JC0RY8A31R6ZVYA.../ # Block不可变2小时数据一个block │ ├── chunks/ # 压缩后的时序数据 │ ├── index/ # 倒排索引metric name → series │ └── meta.json ├── wal/ # Write-Ahead Log未compact的数据 └── tombstones/ # 删除标记倒排索引Prometheus 的查询模式是metric_name{labelvalue}用倒排索引直接定位 series不需要扫描。这是它比 InfluxDB 1.x 查询快的核心原因。WAL 机制写入先写 WAL顺序追加再写内存中的 Head Block每 2 小时 flush 成一个 Block。宕机恢复时重放 WAL。适用场景Kubernetes 监控、微服务可观测性。不适合作为通用工业 IoT 时序数据库高基数问题严重。四、选型决策矩阵维度InfluxDBTDengineTimescaleDBClickHousePrometheus写入吞吐★★★★☆★★★★★★★★☆☆★★★★☆★★★☆☆查询延迟★★★★☆★★★★★★★★☆☆★★★★★★★★★☆压缩比★★★★☆★★★★★★★★☆☆★★★☆☆★★★☆☆SQL兼容性★★☆☆☆★★★★★★★★★★★★★★★☆☆☆☆☆集群能力企业版开源集群需分片原生分布式federation运维成本中低中高高低高基数支持一般好好极好差开源协议MITAGPLApache 2.0Apache 2.0Apache 2.0选型建议场景A工业IoT百万设备千万点位/秒写入 → 推荐TDengine超级表模型天然匹配压缩比最优 场景B中小规模IoT 已有PostgreSQL技术栈 → 推荐TimescaleDB零迁移成本SQL完全兼容 场景CDevOps监控 容器化部署 → 推荐PrometheusK8s原生支持生态最完善 场景D离线分析为主需要复杂聚合查询 → 推荐ClickHouse查询速度最快物化视图灵活 场景E中小规模快速原型单节点够用 → 推荐InfluxDBTICK栈开箱即用社区生态成熟五、实战落地工业IoT场景TDengine架构设计5.1 场景规模设备数10万单设备采集点位50个采集频率1次/秒峰值写入500万点/秒数据保留原始数据7天10分钟精度30天1小时精度1年5.2 集群架构┌──────────────────────────┐ │ TDengine 3节点集群 │ │ (vCPU:32 / 内存:128G) │ └──────┬─────────┬────────┘ │ │ ┌────────────┘ └────────────┐ ▼ ▼ ┌─────────────────┐ ┌─────────────────┐ │ vnode 1~4 │ │ vnode 5~8 │ │ (数据分片) │ ← 复制因子2 → │ (数据分片) │ │ device_00001 │ │ device_50001 │ │ ~device_05000 │ │ ~device_10000 │ └─────────────────┘ └─────────────────┘ │ │ ▼ ▼ ┌─────────────────┐ ┌─────────────────┐ │ mnode (Leader) │ │ mnode (Follower)│ └─────────────────┘ └─────────────────┘关键参数配置# taos.cfg firstEp cluster-node-1:6030 secondEp cluster-node-2:6030 fqdn cluster-node-1 serverPort 6030 dataDir /data/taos/data logDir /var/log/taos # 写入性能调优 maxVgroupsPerDb 200 minTablesPerVnode 1000 tableIncStepPerVnode 1000 maxShellConns 50000 # 存储策略 days 10 keep 3650 keepFloor 75.3 数据模型设计-- 按设备类型创建超级表每个采集指标独立一张超级表CREATESTABLE sensor_temperature(tsTIMESTAMP,temp_valueDOUBLE,qualityTINYINT)TAGS(device_idBINARY(32),factoryBINARY(32),lineBINARY(32));-- 批量写入每次1000~5000行减少网络 round-tripINSERTINTOsensor_temperatureUSINGsensor_temperature TAGS(dev_001,factory_A,line_1)VALUES(NOW,23.5,0);设计要点每个采集指标独立一张超级表避免宽表导致的 NULL 值浪费TAGS 只放低基数字段设备ID、工厂、产线高基数字段放 field批量写入每次 1000~5000 行减少网络开销5.4 查询优化-- 查询某设备最近24小时温度趋势10分钟聚合SELECTtbnameASdevice_id,avg(temp_value)ASavg_temp,max(temp_value)ASmax_temp,min(temp_value)ASmin_tempFROMsensor_temperatureWHEREtsNOW()-24hANDdevice_iddev_001INTERVAL(10m);-- 查询某工厂所有设备最近1小时平均温度跨设备聚合SELECTfactory,avg(temp_value)ASfactory_avg_tempFROMsensor_temperatureWHEREtsNOW()-1hANDfactoryfactory_AGROUPBYfactory;性能关键WHERE 条件必须包含时间范围 tag 过滤才能触发分区剪枝和标签索引。六、架构痛点与避坑指南坑一高基数问题High Cardinality症状查询变慢CPU 飙升内存占用异常增长。原因tag 列用了高基数字段如 URL、UserID、完整 IP导致索引膨胀。Prometheus 和 InfluxDB 1.x 对此尤其敏感。解法TAGS 只放低基数字段设备类型、工厂、产线高基数维度放 field不建索引查询时过滤TDengine 对高基数支持较好但仍需控制 tag 数量坑二数据保留策略配置错误症状磁盘被写满查询性能急剧下降。原因只设置了原始数据保留期没有配置降采样策略历史数据无法自动清理。解法TDengine-- 创建降采样流Stream ProcessingCREATESTREAM stream_temp_10mTRIGGERAT_ONCEINTOdevice_metrics_10mASSELECT_wstartASts,device_id,avg(temp_value)ASavg_tempFROMsensor_temperaturePARTITIONBYdevice_idINTERVAL(10m);坑三跨时间窗口查询性能差症状查询 3 个月的数据耗时超过 30 秒。原因时间范围太大涉及数百个分区文件I/O 并行度不够。解法查询时主动限制时间范围如分页查询每次不超过 7 天对超长历史数据强制走降采样后的低精度表调整maxQueuesPerVnode和maxVgroupsPerDb提升并行度坑四集群扩容数据迁移慢症状新增节点后数据再平衡耗时数小时期间查询性能下降。原因TDengine 的 vnode 迁移是同步的大表迁移会阻塞写入。解法扩容在低峰期操作凌晨 2:00-6:00提前创建足够多的 vgroupmaxVgroupsPerDb让新节点加入时只需创建空 vgroup使用 TDengine 3.x 的group功能将扩容影响控制在单个 vgroup 内七、全文总结时序数据库的本质是用存储结构的专业化换取时序场景下的极致性能。选型的核心判断标准只有一个你的瓶颈在哪里瓶颈类型推荐方案写入吞吐不够TDengine InfluxDB ClickHouse查询延迟太高ClickHouse TDengine InfluxDBSQL兼容要求高TimescaleDB TDengine ClickHouse运维人力有限TDengine InfluxDB Prometheus高基数标签多ClickHouse TDengine TimescaleDB记住一条原则工业 IoT 场景优先 TDengine超级表模型天然匹配DevOps 监控优先 Prometheus离线分析优先 ClickHouse已有 PG 技术栈优先 TimescaleDB。八、行业技术展望8.1 边缘时序数据库随着 5G 边缘计算的普及时序数据的处理正在从云端集中向边缘预处理 云端聚合演进。TDengine Edge、InfluxDB Edge 等边缘版本已经在工业现场部署单机可处理 10 万点位/秒的写入断网时本地缓存联网后自动同步。8.2 时序 AI 预测时序数据库正在从存储查询向实时预测演进。InfluxDB 3.0 集成了 ML 能力可以直接在数据库内运行时序预测模型ARIMA、ProphetTDengine 3.x 支持 UDF用户自定义函数可以将训练好的模型部署为查询函数实现存算一体。一个典型的落地场景设备温度数据写入 TDengine 的同时触发异常检测 UDF温度异常时自动告警比传统定时查询 外部判断模式延迟降低 90%。8.3 存算分离架构传统时序数据库是存算耦合的每个节点既有存储又有计算。新一代架构如 InfluxDB 3.0 基于 Apache Arrow Parquet实现了存算分离对象存储S3/OSS存数据计算节点无状态横向扩展。这使得存储成本降低 60%计算资源可以按需弹性伸缩。参考文献Facebook Engineering.Gorilla: A Fast, Scalable, In-Memory Time Series Database. VLDB 2015.TDengine Official Documentation.Super Table Design. https://docs.tdengine.com/InfluxData.InfluxDB Internals: TSM Storage Engine. https://docs.influxdata.com/ClickHouse Team.MergeTree Engine Family. https://clickhouse.com/docs/engines/table-engines/mergetree-familyTimescale.Hypertable and Chunk Architecture. https://docs.timescale.com/Prometheus Authors.Prometheus TSDB Format. https://prometheus.io/docs/prometheus/latest/storage/陶建辉TDengine 创始人.时序大数据处理从理论到实践. 机械工业出版社2023.关于作者一名经历过MySQL 存时序数据导致磁盘爆炸事故的后端架构师。相信好的技术选型不是追热点而是在约束条件下找到最优解。欢迎在评论区分享你的时序数据库踩坑经历。本文发表于 2026 年 6 月技术方案基于 TDengine 3.x、InfluxDB 2.x、ClickHouse 24.x、TimescaleDB 2.x 版本。
