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

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