1 · 先选一个接近的场景
选完可以再改下面的数字2 · 你的实际规模
含离线设备。子表和标签常驻内存，离线也占资源。
一台设备一次上报几个测量值。电表常见 4 个（电压/电流/功率/电量），环境传感器 2-3 个。
30 分钟 = 1800 秒。间隔越短，写入压力成倍涨。
监管通常要求 12 个月，水务/电力有的要求 24 个月以上。
看大屏和报表的人数，不是注册用户数。
单副本省一半存储，但硬盘坏了数据就没了。对外服务建议 3 副本。
TDengine 官方容量规划文档的口径是「绝大多数场景不低于 5 倍，部分可达 10 倍以上」。选 5 倍做预算不会超，选 10 倍是多数项目的实际值。
3 · 要不要一起算视频
没有视频就填 0，跳过这一块视频不走时序库，但吃带宽和存储，而且往往是存储的大头。
单路按 4 Mbps 算（1080P H.265 常见值）。
4 · 算出来的量级
应用和时序库分两台的标准起点，也是绝大多数地市级项目的配置。
按每核 10,000 点/秒折算需要 4 核（含 2 核给业务和查询），内存建议 3.0 GB。
这是设备上行汇总带宽。设备走 4G/NB 时不占服务器公网带宽，只有服务端转发或视频回传才需要买公网。
按 2026 年阿里云/腾讯云公开刊例价估的区间。实际采购价受活动、包年折扣、地域影响，能差 3-5 倍。
这是容量基线，不是报价单。真实项目里还有三个变量没算进来：查询侧的复杂报表会额外吃 CPU、规则引擎和告警风暴会在故障时产生写入尖峰、 跨地域部署要额外算专线和多活。拿去立项报批够用，签合同前建议按实际数据再核一遍。
每一个系数都能追溯
不写「行业经验值」这种没法验证的说法。下面六项是工具里全部的计算依据，觉得哪项不符合你的情况，按你的改。
单测点 8 字节
时序库存测量值按 double 类型，8 字节。这是 TSBS 基准测试和 TDengine 文档的默认假设，也是绝大多数时序库的存储单位。
每条消息固定开销 40 字节
时间戳 8 字节 + 设备标签或子表名 + MQTT/自定义协议帧头。实测常见 30-60 字节，取中间值。协议越啰嗦，这部分越大。
压缩比 5:1 起，常见 10:1
TDengine 官方容量规划文档：「绝大多数场景压缩比不低于 5 倍，有的场合可达 10 倍以上」。做预算按 5 倍，不会超。
每张子表常驻内存 0.5KB
设备标签必须常驻内存，不能落盘。公式来自 TDengine 容量规划文档的内存估算：子表数 × (标签大小 + 0.5KB)。
每核 1 万点/秒
写入路径的保守经验值。时序库单机写入能力远高于此，但真实系统还要跑业务逻辑、告警规则和报表查询，核数不能只按写入算。
服务器价格取公开刊例价
按 2026 年阿里云 ECS 通用型 g 系列和腾讯云 CVM 通用型的公开刊例价区间估。活动价、包年折扣、地域差异能让实际采购价差 3-5 倍。
五类场景的典型体量，对号入座
下面每一行都是工具里预设参数算出来的结果。你的项目跟哪行接近，直接用那行的配置往下谈就行。
| 场景 | 典型规模 | 写入吞吐 | 总存储 | 推荐配置 | 服务器年成本 |
|---|---|---|---|---|---|
| 停车 / 道闸 | 200 个场站，2 万设备，10 秒一次心跳 | 12,000 点/秒 | 1.01 TB | 8 核 16G | 6,000 – 12,000 元 |
| 水务 / 户表 | 5 万只表，半小时抄一次，留 2 年 | 111 点/秒 | 0.02 TB | 2 核 4G | 1,200 – 2,400 元 |
| 校园 / 园区 | 3000 台设备，1 分钟一次，留 1 年 | 400 点/秒 | 0.03 TB | 2 核 4G | 1,200 – 2,400 元 |
| 工业 / 高频采集 | 1000 台设备，1 秒一次，每台 32 点 | 32,000 点/秒 | 2.55 TB | 16 核 32G | 14,000 – 26,000 元 |
| 视频为主 | 500 路 1080P，4 Mbps，存 30 天 | 33 点/秒 | 0.00 TB | 2 核 4G | 1,200 – 2,400 元 |
注：水务场景按 5 万只表、半小时抄一次算，存储看着大是因为保留 24 个月且抄表数据条目多；写入吞吐却很低，这就是「存储型」和「写入型」项目的区别。
三个最容易被低估的地方
这三个坑的共同点是：算容量时想不到，上线三个月后才爆。
查询侧比写入侧更吃资源
写入是线性的、可预测的，查询不是。一个「近 30 天各站点能耗对比」的报表，扫的数据量可能等于半年的写入量。很多项目写入 5000 点/秒毫无压力，一上大屏和日报就卡——因为所有查询都在抢同一份内存和 IO。规划时至少留 30% 的算力给查询，或者把只读查询拆到独立节点。
告警风暴会让写入出现尖峰
平时 8000 点/秒，一次区域性断电或网关批量掉线，几万台设备同时重连、补传离线数据，瞬时写入能翻十倍。时序库扛得住持续写入，扛不住的是这种突发。要么在采集侧做限流和批量补传，要么在容量上留出 2-3 倍的余量。按平均值配机器，就是等着半夜被打醒。
视频存储和时序存储是两笔账
500 路 1080P 存 30 天约 648 TB，比 5 万只水表存两年的数据大两个数量级。这两类数据该放在完全不同的介质上：时序数据放云盘或本地 SSD，视频放对象存储或专门的存储服务器。混在一起算，要么视频把云盘写满，要么为了视频买了一堆用不上的高 IOPS 盘。
关于这个测算，你可能想问
Q为什么 2 万台设备算出来只要 4 核 8G？是不是算少了？
因为写的是「点/秒」不是「设备数」。2 万台设备、每台 6 个测点、10 秒上报一次，是 12000 点/秒，时序库对这个量级的写入压力并不大——TDengine 单机公开基准是百万级点/秒。真正吃资源的是查询和业务逻辑：报表、大屏、告警规则。所以配置里额外给了 2 核，也不建议把应用和数据库挤在一台机器上。如果你的场景是每秒级高频采集，结果会完全不同，试试「工业 / 高频采集」预设。
Q压缩比为什么默认按 5 倍，不是 10 倍？
TDengine 官方容量规划文档的原话是「绝大多数场景压缩比不低于 5 倍，有的场合可达 10 倍以上」。做预算按最保守的 5 倍，实际跑出来是 10 倍就当中了彩票；按 10 倍做预算，万一你的数据特征不适合压缩（比如大量随机浮点、字符串标签多），硬盘会提前写满。页面上可以切到 10 倍看乐观值，两个数一起看才靠谱。
Q内存公式里的「每张表 0.5KB」是什么？
时序库按设备建子表，每张子表的标签（设备编号、位置、型号这些元数据）要常驻内存，不能放磁盘。TDengine 容量规划文档给的经验值是每张表 0.5KB。所以 100 万台设备光标签就要 500MB，2000 万台要 10GB——这也是为什么设备数不能只看在线数，历史设备、离线设备、备用点位都要算进去。
Q算出来的年成本能当报价用吗？
不能。这只是「服务器 + 磁盘」的云资源成本，按 2026 年阿里云/腾讯云公开刊例价估的区间，活动价和刊例价能差 3-5 倍。完整项目还要加：软件授权、实施与调试、网络（专线或流量）、等保测评、短信和地图这类第三方服务、以及运维人力。想了解软件部分怎么算，看软件费用测算那个工具。
Q带宽那一项，为什么说设备走 4G 不占公网带宽？
因为 MQTT 是设备主动连服务端，服务端只收不推，不需要买公网带宽做下行。设备流量走的是各自的 4G 卡或 NB-IoT 套餐。只有两种情况要单独买公网带宽：一是视频回传和远程看实时画面，二是要给第三方系统做公网接口。这两项在工具里是分开算的。
Q什么时候必须上集群，单机撑不住？
三个信号：写入超过 8 万点/秒、单表数据量超过单机磁盘、要求高可用（数据库宕机不能停服）。前两个是容量问题，第三个是可靠性问题——很多项目 TPS 不高但必须 3 副本，因为停服一小时比多买两台机器贵得多。工具里副本数选 3 就会把存储成本乘上去，但服务器档位不会自动升，这两个判断是分开的。
机器配好了，下一步通常是数点位和算钱。先用点位与设备清单生成器把每个子系统要多少台设备列出来，再拿软件费用测算按设备台数估软件预算；如果场景里有视频，存储容量和带宽用存储计算器单独核一遍，那个工具按码率和天数算，比这里粗算准。
算完还是不确定？把你的参数发过来
容量规划最容易错的地方不是公式，是「你的实际数据特征」。把设备清单和采集频率发过来，我们按真实项目经验核一遍，告诉你哪一项留的余量不够。
需要按你的实际项目核一遍？
工具算的是基线，真实项目还要看数据特征、查询模式和可用性要求。 把设备规模、采集频率、要不要高可用发过来，我们出一版带余量说明的配置建议。