实时数据点位 / 带宽估算器

估算模型与假设条件

这是量级估算，不是精确容量规划。 结果只保留两位有效数字， 就是为了提醒你别把它当成精确值。背后的假设如下：

• 每秒消息数 = 秒级点位数 ÷ 1 + 分钟级点位数 ÷ 60 + 小时级点位数 ÷ 3600。
• 带宽 = 每秒消息数 × 单点报文字节数 × 8。未计入协议头、TLS 与重传开销，实际占用更高。
• 死区模式按一个变化率系数折减消息数，变化率需按现场工况估。
• 存储按每条记录一个参考字节数估算。未计入索引、副本与压缩，时序库通常有可观压缩率、实际落盘往往更低。
• 时间分布假设各点位上报均匀摊开。真实系统常有整点集中上报的尖峰，峰值会明显高于这里的平均值。

「建议上边缘网关 / 时序库」的判断线是经验量级分界，不是行业标准。落在线附近时， 链路可靠性、断网续传要求、运维团队熟悉的技术栈往往比这个数字更该作为决策依据。以现场压测为准。

常见问题

为什么点位要分三档填，不能填一个总数？

因为采集周期对数据量的影响是成倍数的，而不是加法关系。一个秒级点位产生的消息量，等于六十个分钟级点位，等于三千六百个小时级点位。把点位按周期分开填，你才能直观看到「把趋势类点位从秒级降到分钟级」能省掉多少——这往往比任何技术优化都立竿见影。实际项目里最常见的浪费，就是不分青红皂白全部按秒级采集：告警类确实需要秒级，但环境温湿度、能耗累计值这些，分钟级甚至更慢完全够用，硬拉到秒级只是白白撑大链路和存储。

变化上传（死区）是什么？变化率该填多少？

死区是指只有当数值变化超过某个阈值时才上报，没变化就不发。对大多数工业和楼宇场景，这比提高采集频率更有价值——因为绝大部分时间数据是平稳的，全量上报等于反复发同一个值。变化率没有通用值，要按现场工况估：状态量（开关、启停、故障位）变化很稀疏，变化率通常很低；模拟量（温度、压力、流量）则取决于死区阈值定得多宽，阈值宽变化率就低。这个数填不准没关系，可以填两个值对比一下上下界，看结论会不会翻转。要注意死区有代价：它会漏掉缓慢漂移和短暂尖峰，所以通常还要配一个「最长上报间隔」做兜底。

算出来的带宽和存储，和实际会差多少？

两个方向都会差，而且方向相反，要分开看。带宽方面，这里只算了报文本身的净荷，没有计入协议头、TLS 握手与加密开销、以及重传——实际占用会比估算值高，走公网或无线链路时差距更明显。存储方面则通常相反：估算按每条记录一个固定字节数算，没有计入压缩，而时序数据库对这类规律性数据往往有相当可观的压缩率，实际落盘常常明显低于估算。所以这个工具适合用来判断量级和架构方向，不适合直接当采购依据，真要定容量还是得按实际报文格式做一次压测。

「建议上边缘网关」和「建议上时序库」的判断线是怎么定的？

是按经验量级设的分界，不是行业标准，也不存在这样的标准。判断逻辑很朴素：消息速率高到一定程度，让每个点位直连中心就不合理了，应该在现场先做一层汇聚、预处理和批量上送；日写入条数大到一定程度，普通关系型数据库的写入和时间范围查询就会吃力，该换成时序库并配好降采样与保留策略。但这两条线附近是渐变的，不是过了就崩、没过就稳。落在线附近时，更该看的是别的因素：现场到中心的链路是否可靠、有没有断网续传的要求、运维团队熟悉什么技术栈。

延伸阅读

想把整条数据链路怎么打通、以及刷新频率怎么按状态价值分级讲透，可以读 《孪生数据怎么接进来：从 Modbus / BACnet / OPC UA 到 MQTT 与时序库》与 《孪生数据的实时刷新策略：轮询、订阅与降频怎么定》， 或看数字孪生专题。