工业时序数据存储选型实战：从PostgreSQL到TDengine，查询从15秒到200ms
分享一个工业时序数据存储的选型和迁移实战经验。
场景描述
某3C代工厂，产线上部署了多台视觉检测设备，每台设备每秒钟产生30-50条检测结果。
业务需求：
查询任意7天的良率趋势，响应时间1秒以内
查询某一批次产品的所有检测记录，响应时间500ms以内
数据保留周期1年
初始方案及问题
最初用PostgreSQL存储。表结构包含时间、产品ID、缺陷类型、判定结果等字段。
数据量达到500万条时，问题暴露：
7天趋势查询（约80万条）响应时间从200ms退化到15秒
批量插入性能从5000条/秒降至2000条/秒
索引膨胀，存储空间从预期50GB增长到100GB+
尝试了索引优化、分区表、SQL优化，效果有限。
原因分析
检测数据是典型的时间序列数据——按时间写入、按时间查询、极少更新。PostgreSQL的存储引擎为通用事务场景设计，不是为高频时序写入+范围查询优化的。
选型对比
| 对比维度 | PostgreSQL | TDengine |
| 写入速度（条/秒） | 5000 | 30000+ |
| 7天趋势查询 | 15秒 | 200ms |
| 单批次查询（1000条） | 50ms | 20ms |
| 存储空间（500万条） | 100GB | 40GB |
TDengine优势：列式存储+时序索引，内置降采样和聚合函数，高压缩比。
迁移方案
渐进式迁移：
历史数据保留在PostgreSQL，用于长期归档
新数据（7天内）写入TDengine，用于实时分析
查询层做路由：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有差异，迁移时注意函数替换
⚠️ 分区键设计要合理，避免单表数据过大
⚠️ 历史数据迁移建议分批执行，避免一次性写入压力
欢迎在评论区交流你的实战经验，我们一起探讨～