分享一个工业时序数据存储的选型和迁移实战经验。
场景描述
某3C代工厂，产线上多台视觉检测设备，每台每秒钟产生30-50条检测结果。业务需求：查询任意7天良率趋势（响应1秒以内）、查询某批次产品检测记录（响应500ms以内）、数据保留1年。
初始方案及问题
用PostgreSQL存储。表结构包含时间、产品ID、缺陷类型、判定结果等字段。
数据量到500万条时问题暴露：
|--------|-------------------|
| 问题 | 表现 |
| 7天趋势查询 | 从200ms退化到15秒 |
| 批量写入 | 从5000条/秒降至2000条/秒 |
| 存储空间 | 从预期50GB增长到100GB+ |
尝试索引优化、分区表、SQL优化，效果有限。
原因分析
检测数据是典型时间序列数据------按时间写入、按时间查询、极少更新。PostgreSQL为通用事务场景设计，非为高频时序写入+范围查询优化。
选型对比
|-------------|------------|----------|
| 对比维度 | PostgreSQL | TDengine |
| 写入速度（条/秒） | 5000 | 30000+ |
| 7天趋势查询 | 15秒 | 200ms |
| 存储空间（500万条） | 100GB | 40GB |
TDengine核心优势：列式存储+时序索引，内置降采样和聚合函数，高压缩比。
迁移方案
渐进式迁移，降低风险：
-
历史数据（3个月以上）保留在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);
}
}
}
踩坑提醒
⚠️ TDengine SQL语法与PostgreSQL有差异（如时间函数、分页语法），迁移时需逐一适配
⚠️ 分区键设计要合理，避免单表数据过大影响查询性能
⚠️ 历史数据迁移建议分批执行（每次10万条），避免一次性写入压力
⚠️ 应用层连接池需分别为TDengine和PostgreSQL独立配置
上线效果
-
7天趋势查询：15秒 → 200ms（提升98.7%）
-
存储空间：100GB → 40GB（减少60%）
-
写入性能：2000条/秒 → 30000条/秒（提升15倍）
-
管理层看板实时刷新，不再等报表
目前方案在汽车、锂电、光伏、医药都有落地案例。欢迎同行交流技术，也欢迎有需求的客户联系。