一台热性能测试机，每 2 秒上报一次温度、转速和电流。
刚接入时，最简单的做法是建一张 device_data 表，把数据都写进去。测试阶段没问题，一天几万条，查起来也快。
后来设备多了。锁螺丝机有扭矩，点胶机有胶量，测试机有曲线，PLC 有状态和报警，视觉设备有图片结果。所有数据都往业务库里塞，几个月后，报工慢了，报表慢了，备份也慢了。
这时候才会意识到：问题不是数据库不够强，而是数据本来就不该放在一起。
设备数据链路一断，现场不会先问你架构。
班长只会问：刚才那几件产品的数据还在不在？质量追溯还能不能查？这台设备到底算不算停机？
所以设备数据链路不能只看“能不能连上”。更要看断了以后怎么补，补上以后怎么判重，晚到的数据怎么归档，和当前生产节拍有没有冲突。
这些细节不提前想，联调时一定会被现场一件件问出来。
一、先问这条数据拿来干什么
现场数据进来以后，不要急着入库。
先问它的用途。
比如同样是测试机数据，可能有三种不同用途：
当前测试状态：看板要立刻看到
测试曲线：质量工程师后面要看趋势
最终测试结果：追溯和判定要长期保存这三类数据不应该都用同一种存储方式。
如果一条温度数据只是用于曲线分析，它更适合进时序库。
如果一个测试结果决定产品是否过站，它就应该进入业务库。
如果当前设备状态要给看板刷新，它更适合进 Redis 或实时状态表。
二、实时状态服务看板
产线看板关心的是“现在”。
比如：
- 当前工单是什么。
- 当前产量是多少。
- 当前良率是多少。
- 哪台设备正在报警。
- 哪个工位节拍变慢。
- 上次数据更新时间是什么。
这些数据不适合每次都从业务库聚合。
我更倾向于让实时处理 Worker 消费设备消息后，把当前状态写到 Redis 或实时状态表。
看板读取的是实时状态，业务库保存的是可追溯记录。
这样看板刷新快，业务库也不会被频繁查询拖慢。
三、高频数据进时序链路
温度、压力、转速、电流、能耗，这类数据通常按时间查询。
现场常见问题是：
这台测试机下午 2 点到 3 点温度有没有波动？
某个 SN 测试期间转速是否稳定？
昨天夜班 line-02 哪些设备频繁停机？这些查询天然按设备、点位、时间范围走。
所以高频数据适合进时序库，或者至少进单独的采集库，并按时间分区。
不要和工单、物料、质检这些业务表混在一起。
否则一开始省事，后面一定会还债。
四、业务事件进业务库
业务库要保存对生产过程有意义的事件。
比如：
event_type: test_completed
sn: F202405260018
work_order_no: WO2024052603
process_code: thermal_test
device_code: tester-01
result: OK
event_time: 2024-05-26 14:23:11这条记录要能支撑追溯、报表、质量分析和客户问题倒查。
设备每 2 秒上报的温度曲线不一定都进业务库，但最终测试结果、上下限、关键指标和判定结果必须进业务库。
这里的取舍很重要。
业务库不是不能存设备数据，而是只存有业务含义的设备事件。
五、图片、报告和日志只存引用
视觉检测图片、测试报告、设备日志，不建议直接塞进业务库大字段。
更好的方式是放文件服务或对象存储，业务库只保存引用：
sn
work_order_no
process_code
file_type
file_url
created_at这样追溯时能查到文件，数据库也不会被文件拖垮。
如果以后要迁移存储，也比把文件塞进业务库容易很多。
六、我会怎么做第一版
如果是小工厂第一版，我不会一开始就把所有组件上满。
可以先这样做：
Redis：当前设备状态和看板数据
业务库：工单、过站、测试结果、报警事件、追溯关系
采集库：高频点位数据，先按时间分表或分区
文件目录 / 对象存储：图片、报告、日志等采集频率和设备数量上来，再把采集库演进到专门的时序库。
关键是边界先留出来。
七、小结
一条设备数据最后去哪，不取决于它来自哪台设备，而取决于它要解决什么问题。
当前状态，给看板。
高频曲线，给时序链路。
业务事件，给业务库。
图片报告，给文件存储。
MES 数据分流不是架构洁癖，而是系统跑久以后能不能继续稳定的基础。
本系列：
暂无评论