工业时序数据存储选型实战：从PostgreSQL到TDengine，查询从15秒到200ms

分享一个工业时序数据存储的选型和迁移实战经验。

场景描述

某3C代工厂，产线上部署了多台视觉检测设备，每台设备每秒钟产生30-50条检测结果。

业务需求：

  1. 查询任意7天的良率趋势，响应时间1秒以内

  2. 查询某一批次产品的所有检测记录，响应时间500ms以内

  3. 数据保留周期1年

初始方案及问题

最初用PostgreSQL存储。表结构包含时间、产品ID、缺陷类型、判定结果等字段。

数据量达到500万条时，问题暴露：

  • 7天趋势查询（约80万条）响应时间从200ms退化到15秒

  • 批量插入性能从5000条/秒降至2000条/秒

  • 索引膨胀，存储空间从预期50GB增长到100GB+

尝试了索引优化、分区表、SQL优化，效果有限。

原因分析

检测数据是典型的时间序列数据——按时间写入、按时间查询、极少更新。PostgreSQL的存储引擎为通用事务场景设计，不是为高频时序写入+范围查询优化的。

选型对比

对比维度PostgreSQLTDengine
写入速度（条/秒）500030000+
7天趋势查询15秒200ms
单批次查询（1000条）50ms20ms
存储空间（500万条）100GB40GB

TDengine优势：列式存储+时序索引，内置降采样和聚合函数，高压缩比。

迁移方案

渐进式迁移：

  1. 历史数据保留在PostgreSQL，用于长期归档

  2. 新数据（7天内）写入TDengine，用于实时分析

  3. 查询层做路由：7天内走TDengine，7天以上走PostgreSQL

核心代码示意：

public class DataQueryService {

public List<TrendData> queryTrend(Date start, Date end) {

long daysBetween = ChronoUnit.DAYS.between(start, end);

if (daysBetween <= 7) {

return tdEngineDao.queryTrend(start, end);

} else {

return pgDao.queryTrend(start, end);

}

}

}

上线效果

  • 7天趋势查询响应：15秒 → 200ms

  • 存储空间：100GB → 40GB（减少60%）

  • 写入性能：2000条/秒 → 30000条/秒

踩坑提醒

⚠️ TDengine SQL语法与PostgreSQL有差异，迁移时注意函数替换

⚠️ 分区键设计要合理，避免单表数据过大

⚠️ 历史数据迁移建议分批执行，避免一次性写入压力

欢迎在评论区交流你的实战经验，我们一起探讨～