需求先量化
30 台设备，假设每台 50 个监控点、每 2 秒采一次：
- 总点位：30 × 50 = 1500 点
- 写入频率：1500 ÷ 2 = 每秒 750 条
- 一天数据量：约 6480 万条（含质量戳）
这个量级，普通关系库会越来越吃力，但对时序数据库非常轻松。
推荐架构（四层）
第一层：采集。每台设备走 Modbus TCP / MC / S7 协议，用统一的采集服务或网关（Neuron / Node-RED / 自研驱动工厂）轮询，做断线重连和数据归一化。
第二层：消息缓冲。采集结果统一发到 MQTT（EMQX 或 Mosquitto），实现采集和入库解耦，消费端宕机不影响采集。
第三层：存储。用 Telegraf 订阅 MQTT 写入 TDengine 或 TimescaleDB，按设备建子表/超表，设置数据保留策略。
第四层：展示。Grafana 做实时看板和报警，自研 Web HMI 做工艺画面，需要时再向 MES 提供接口。
为什么中间要加 MQTT
很多初学者让采集程序直接写库，结果入库一抖动，采集循环就被拖慢。加一层消息总线后：
- 采集只管采，不被下游拖累
- 可以有多个消费端（入库、报警、转发）同时订阅
- 消费端重启时，靠消息队列或重采补齐数据
容量与服务器估算
- 上述量级，2 核 4G 的服务器跑「采集 + MQTT + 时序库 + Grafana」足够
- 磁盘按压缩后每点每天约 1～2KB 估算，1500 点一天约 2～3MB，一年不到 1GB（时序库列存压缩优势明显）
- 若点位扩大到上万点或要做高可用，再考虑独立部署和集群
落地顺序建议
- 先打通 1 台设备的采集→入库→看板全链路
- 验证稳定后，用配置化方式批量复制到 30 台
- 最后补报警、权限、历史追溯和对外接口
先跑通一条链路再复制，比一上来就搭大平台风险小得多。