一个做园区项目的朋友问过我一个问题：甲方要求平台能接 1 万台设备，集成商报了 8 核 16G 三台，这个配置合不合适。
我说得先问一句：这 1 万台设备多久上报一次数据。
他说不知道，甲方也没说。
这就是问题所在。同样 1 万台设备，每 10 秒上报一次，写入是 6000 点/秒（按每台 6 个测点算）；每 30 分钟上报一次，写入是 33 点/秒。两者差 180 倍。前者需要认真规划，后者一台 2 核 4G 的机器跑得飞起，8 核 16G 三台是纯浪费——一年十多万的云资源钱，白花。
反过来也一样。有些项目按「设备数 × 一个经验系数」配了台 4 核 8G，上线三个月硬盘写满、查询卡死，因为没人算过存储和查询侧。
这篇给一套能自己算的算法，四步，每步的系数都有出处。
一、第一步：把设备数换成「点/秒」
设备数不是压力指标，写入吞吐才是。换算公式很简单：
写入点数/秒 = 设备数 × 每台设备测点数 ÷ 上报间隔（秒）
「测点数」是关键，也是最多人含糊的地方。一台电表可能上报电压、电流、功率、电量四个值，这是 4 个测点。一个温湿度传感器上报温度和湿度，2 个测点。一个网关下挂 20 个传感器，网关本身是一个设备，但测点是 40 个。
算的时候要用「测点数」而不是「设备数」，因为时序库的写入压力是按测点算的。这一步算错，后面全错。
举几个真实场景的量级：
2 万台停车设备（道闸、车牌识别、车位相机），每台 6 个测点，10 秒一次心跳，写入 12000 点/秒。听着挺吓人，但这是这个行业里中等偏上的量级。
5 万只智能水表，每只 4 个测点，半小时抄一次，写入 11 点/秒。数据量很大但写入极轻，这是典型的「存储型」项目。
1000 台工业设备，每台 32 个测点，1 秒一次，写入 32000 点/秒。设备不多但压力最大，这是「写入型」项目。
三种项目的服务器配置思路完全不同。存储型的钱花在硬盘上，写入型的钱花在 CPU 和内存上，混着算一定有一头不够。
二、第二步：存储按压缩后算，不是按原始数据算
很多人算存储是这样：一条数据 100 字节，一天 864 万条，就是 864MB，一年 315GB。这个算法有两个错：一是没算压缩，二是没算副本。
时序数据的压缩率非常高，因为它是「同一种设备的同一个测点，随时间连续变化」，相邻数据高度相似。TDengine 官方容量规划文档的原话是「绝大多数场景压缩比不低于 5 倍，有的场合可达 10 倍以上」。官方给的例子：1000 万台电表、每 15 分钟采集一次、每次 128 字节，一年原始数据 44.85TB，压缩后约 8.97TB，正好 5 倍。
做预算建议按 5 倍算，因为你的数据特征不一定有这么好的压缩性——如果测点里混了大量字符串标签、随机浮点、状态码，压缩率会掉到 3 倍甚至更低。按 5 倍算，实际跑出 10 倍是赚了；按 10 倍算，硬盘提前写满就麻烦了。
副本数是第二个容易漏的乘数。单副本省钱但硬盘坏了数据就没了，对外服务的项目基本都要 3 副本。3 副本意味着存储成本直接乘 3——这一步能让总存储从 9TB 变成 27TB，很多预算就是在这里超的。
还有一个常被忽略的：保留期不是「存多久」，是「按什么精度存多久」。监管要求「保存 3 年」，通常指的是原始数据存 3 个月、降采样后的分钟级数据存 1 年、小时级数据存 3 年。全量原始数据存 3 年，存储成本能是分层的十倍以上。这一条要在需求阶段就跟甲方谈清楚，写进技术方案。
三、第三步：内存看子表数，不看数据量
时序库的存储模型是「一个设备一张子表」，子表的标签（设备编号、位置、型号、所属分组）必须常驻内存，不能放磁盘，因为每次查询都要用。
TDengine 容量规划文档给的经验值是每张子表 0.5KB。这意味着：
10 万台设备，光标签就要 50MB，可以忽略。100 万台设备，500MB，还行。1000 万台设备，5GB，这就必须在内存规划里体现了。如果按 3 副本部署，标签内存也要乘副本数。
这里有个坑：设备数要按「累计接入过的设备」算，不是「当前在线设备」。项目运行三年，换过一批硬件、加过一批点位，设备表里可能有 30 万台记录，其中在线只有 8 万台。标签内存是按 30 万算的。规划时按在线数算，上线两年后内存就不够了。
除了标签内存，还要留写入缓存。写入缓存的大小跟 TPS 正相关，一般按每 1 万点/秒给 1 到 2GB 估算。查询侧还要给每个并发连接留内存，看大屏的场景下，每个连接几百 MB 很正常。
三项加起来才是真实的内存需求。很多「内存不足」的故障，不是数据量太大，是并发查询把内存吃光了。
四、第四步：核数要留查询侧余量
纯写入的话，时序库的 CPU 效率极高，单核每秒几万点是常态。所以按写入算核数，往往会算出一个「2 核就够」的荒唐结论。
真实系统的 CPU 消耗分四块：写入、查询、业务逻辑、告警规则。
写入占的比例反而不大。查询是大头——一个「近 30 天各站点能耗对比」的报表，扫的数据量可能等于半年的写入量。业务逻辑（权限校验、设备影子、指令下发）持续占用。告警规则引擎更狠，每条规则都要扫一遍相关设备的最新数据，规则多了 CPU 直接爆。
所以实操上按「每核 1 万点/秒」折算写入所需的核数，再加 2 核给业务和查询，是比较稳的算法。注意这个 1 万点/秒不是时序库的能力上限，是把整体负载摊进去之后的保守值。
还有一个经验：不要把应用和数据库装在同一台机器上。不是性能问题，是运维问题。应用重启会带走数据库的缓存，数据库维护要停整个服务，出故障时你分不清是谁的问题。8 核 16G 拆成两台 4 核 8G，比一台 8 核 16G 混装要好用得多，价格差不多。
五、什么时候必须上集群
三个信号，满足任意一个就该考虑集群：
写入超过 8 万点/秒。这是单机的舒适区上限。超过之后不是不能跑，是写入延迟开始抖动，告警会延迟，用户体验变差。
单表数据量超过单机磁盘。比如视频分析结果、原始报文这类大字段数据，一年几个 TB，单机磁盘装不下，必须分片。
要求高可用，数据库宕机不能停服。这一条跟数据量无关。很多项目 TPS 只有几千，但停服一小时的损失比多买两台机器大得多，那就必须 3 节点集群。这类需求要在合同里写清楚 SLA，别等出了事故才谈。
集群不是「三台机器装一样的软件」这么简单，要考虑副本分布、一致性协议、故障切换时间。3 节点集群的实际可用容量大约是单机的 1.5 到 2 倍，不是 3 倍——因为要留副本。这一点在算成本时经常被算错。
六、配置单怎么写进招标文件
「服务器 3 台，配置不低于 8 核 16G」这种写法，投标方会用最低配满足，验收时你没法说他不响应。
能验收的写法要包含四个要素：
一是性能指标，不是硬件指标。写「平台需支持 2 万台设备接入，在每 10 秒上报一次、每台 6 个测点的条件下，写入吞吐不低于 12000 点/秒，P99 写入延迟不超过 200ms」。这比写「8 核 16G」有用得多——投标方要么配够硬件，要么优化软件，反正得达到这个数。
二是数据保留和查询响应。写「原始数据保留 12 个月，单设备 30 天数据查询响应时间不超过 2 秒，跨 100 台设备 30 天聚合查询不超过 10 秒」。查询指标是最容易被忽略、也最容易在验收时扯皮的。
三是可用性要求。写「平台年可用率不低于 99.5%，数据库单节点故障时服务中断不超过 5 分钟」。这条决定了要不要上集群。
四是压测方法。写清楚用什么工具、跑多长时间、看哪些指标。没有压测方法的性能条款，等于没写。
这四条写进去，投标方就得认真算容量，而不是拍一个配置糊弄。我们做平台容量测算这个工具，就是给不想算的人一个起点：填设备数和上报间隔，四步算法的结果直接出来，包括写入吞吐、存储、内存、服务器档位和年成本区间。系数全部公开，觉得哪项不合适可以按你的实际情况改。
七、最后：钱要花在能看见的地方
容量规划这件事，最容易出的两个错是「配多了」和「配少了」，而配多了往往比配少了更常见——因为配多了没人追责，配少了要背锅。结果是一个 3000 台设备的校园项目，买了三台 16 核 32G，一年十几万云资源费，实际负载不到 5%。
合理的做法是分两步：一期按当前规模加 50% 余量配，二期按实际增长扩。云服务器的好处就是能扩，没必要一次买到位。真正需要一次到位的只有两样：数据库的存储架构（单机还是集群，这个改起来贵）和网络规划（IP 段、VLAN、专线，这个改起来更贵）。
如果还想看平台侧其他成本怎么算，物联网平台报价拆解那篇把软件授权的六个分项拆开了；要对比自建和买云，看自建还是买这篇的三年总成本测算。点位怎么数、设备要多少台，在点位与设备清单生成器里能直接算出来，算完再回来算服务器，两个数对得上，方案就站得住了。