先讲一次具体到小时的事故。某工业能耗监测平台，接入测点约 4.2 万个，采样频率 1 秒 1 次，数据要求在线保留 12 个月。周二凌晨两点半，值班电话响起：看板上所有曲线全部拉平，采集网关那边一切正常，边缘盒子心跳正常，MQTT 队列里没有堆积，网络延迟正常，但时序库集群拒绝写入，客户端报磁盘相关错误。
运维登上去一看：CPU 使用率 11%，内存占用 43%，负载 0.8，网络出入流量都很平稳——唯独根分区使用率 100%，剩余 0 字节。再往里查，数据目录占用 1.7TB，预写日志目录占用 480GB，剩下的空间被压缩后的临时文件、过期未清理的分片和几份没人删的全量备份吃干净了。
这台机器配的是 2TB 硬盘，规划阶段按"一年大概 1.5TB"算过账，看起来留了 500GB 余量。问题出在三件事上：一是规划时用的压缩比是厂商白皮书里的乐观值，实际入库的压缩比远低于此；二是副本数从 1 调到 3 之后，磁盘占用直接翻了三倍，而这件事没人重新算过容量；三是预写日志和数据文件放在同一块盘上，两者互相争抢写入带宽和剩余空间，一旦清理任务卡顿，日志就会先于数据把盘填满。
更尴尬的是恢复过程。因为磁盘已经 100%，连压缩合并任务都无法落盘，只能通过挂载临时卷、手动迁移部分老数据出去，才腾出空间让服务重新拉起。整个恢复窗口超过三小时，而这期间的历史数据是彻底断的。
这类事故有个很典型的特征：监控平台自己成了被监控盲区。因为它平时太闲了——CPU 常年个位数、内存也不吃紧，运维团队会本能地认为这台机器"很健康"，于是不给它配资源告警，或者配了告警但阈值设得极宽。等到磁盘写满那一刻，服务是以"突然死亡"的方式失败的，而不是渐进式劣化。
时序数据库（TDengine、InfluxDB 以及同类产品）的磁盘规划，本质上不是一个"买多大硬盘"的采购问题，而是一个由写入模型推导出来的算术问题，外加一个日志与数据争抢的工程问题。这篇文章就把这两件事拆开讲清楚。
本篇的核心结论可以先放在前面：决定时序库容量的四个变量是测点数 × 采集频率 × 单条记录字节数 × 保留天数，再除以压缩比；而决定它稳不稳的两个变量是预写日志是否与数据文件分离，以及是否做了降采样之后的冷热分级。前者算钱，后者保命。
很多团队在给时序库做容量规划时，会下意识套用 MySQL、PostgreSQL 那套经验：按表大小估容量、按 QPS 估性能、按 binlog 估增量。这套经验在时序场景下会系统性失灵，因为两者的写入模型完全不同。
传统关系型数据库的写入是随机、事务性、带更新的。一笔订单改一次状态，是一次随机写；一行用户信息更新，是一次原地覆盖。磁盘上的写入 pattern 在大部分业务里是离散的，所以传统数据库的优化重点是 Buffer Pool、索引结构、刷脏页策略，选型时最看重的指标往往是随机读写 IOPS。
时序数据库的写入则是高频率、小批量、近乎纯追加的顺序写。几万个测点每秒上报一次，落到磁盘上就是连续不断的一串追加操作：新的数据永远带新的时间戳，几乎不更新历史数据，删除也是按时间范围整块淘汰，而不是按行删除单条记录。这种模式下，随机写 IOPS 反而不是主要矛盾，真正压在磁盘上的是三件事：
时序库为了保证宕机后数据不丢，同样有预写日志机制。以 InfluxDB 的 WAL（Write Ahead Log）、TDengine 的 WAL 为例，数据先落日志、再进内存表、最后刷成持久化的数据文件。也就是说，同一条原始数据在写入路径上至少被写两遍：一遍进日志（几乎不压缩、纯追加），一遍进数据文件（经过列式压缩）。如果在 WAL 之外还有副本，还要再乘以副本数。日志这部分的量，往往被初次规划的团队完全忽略。
列式压缩不是写入时同步完成的，而是在内存表达到阈值后落盘、再由后台任务做进一步的合并压缩。这意味着磁盘上在一段时间内会同时存在"未压缩的新数据"和"正在合并的老数据"两份冗余。如果你把磁盘规划到刚好等于理论容量，那么连一次完整的压缩合并都跑不完。工程上的经验做法是：有效容量目标不超过磁盘总容量的 60%–70%，剩下的留作压缩工作区与突发余量（属估算口径，具体比例以官方文档与实际压测为准）。
时序数据按保留策略（retention policy / keep 相关参数）整块过期。好处是删除极其高效，不需要像关系库那样 VACUUM；坏处是磁盘占用曲线是一条"斜坡上升到平台期"的直线——它会一直涨到保留周期的临界点才停，中间不会自然回落。如果你的盘是按"半年后大概这么多"规划的，那么它一定会准时在半年左右被写满，不会提前也不会延后。
把这三点合起来看，时序库的磁盘规划必须同时回答两个问题：一是稳态下要多少空间（公式问题），二是峰值瞬间有哪些东西会额外占空间（工程余量问题）。只回答前者即稳态容量的规划，就是本文开头那次事故的标准剧本。
先给公式。原始数据量（未压缩）的估算口径如下：
原始字节数 = 测点数 × 每秒采集次数 × 单条记录字节数 × 86400 × 保留天数
落盘占用 ≈ 原始字节数 ÷ 压缩比 × 副本数 × (1 + 索引与元信息开销系数)
需要强调的是：以上属于估算口径，实际以实测压缩比为准。任何来自白皮书、博客或本文的压缩比数值，都只能用于"先买多大"的粗筛，真正下单前必须用你自己的真实样本跑一遍实测。这一点后面会专门展开。
测点数：不等于设备数。一台工业设备可能有几十个采集点（温度、压力、振动、电流、阀门状态……），一台新能源车可能有几百个信号位。规划时要把"设备数 × 单设备测点数"算清楚，还要预留未来 12 个月的扩点空间——因为测点数是会随着业务推进线性增长的，而你可能不希望半年后再做一次停机扩容。
每秒采集次数：注意区分"采集频率"和"上报频率"。有些采集端做了本地缓存，1 秒采一次但 10 秒打包上报一次，这种情况下写入次数要按上报批次算，但单批次的字节数会变大。还有变化上报（只在数值变化超过阈值时才发）的策略，这种模式下公式里的"每秒采集次数"要替换成"实测平均每秒上报条数"。
单条记录字节数：这是最容易被拍脑袋填错的一项。时序库里一条记录通常包含时间戳、测量值、以及标签（tag / 超级表的标签列）。标签不是每条都重复存的，但标签的基数（cardinality）会影响索引大小和整体压缩效果。粗略地说，一个 floats 类型的测量值在原始（未压缩）形态下按 4–8 字节计，加上时间戳与行开销，单条记录的裸大小可能在十几到几十字节量级——但这是一个极度依赖具体 schema 的数字，必须按你自己的表结构实算，不要照抄。
保留天数：业务侧的合规与查询需求决定，常见区间是 3 到 24 个月。这个变量与容量是严格线性的关系——保留期翻倍，容量翻倍，没有任何规模效应可言。所以这是最值得谈判的一个变量。
副本数：副本数会直接把上面的结果乘以 N。三副本意味着三倍容量。这一点看似显而易见，但在实际项目里经常被忽略，因为副本往往是"后来才加上的"（比如从测试环境迁移到生产时才开启），而最初的容量规划是在副本数为 1 的时候做的。
用一组假设参数走一遍（这里所有数字都是示例场景，不是任何实测结论）：
原始数据 = 40,000 × 1 × 20 × 86,400 × 365 ≈ 2.52 × 1013 字节，约 23TB。除以 10 的压缩比得到约 2.3TB，再加上索引与元信息开销，以及至少 30% 的压缩工作区余量，落盘需求大致落在 3TB 出头的量级。如果副本数改成 3，就是 7TB 起步。
你会发现，在"4 万测点、1 秒 1 次"这种听起来非常朴素的规模下，一年的裸数据就有 20 多TB。这就是为什么时序库必须先把压缩比当成头等大事来对待。
这是本篇想强调的信息增量：压缩比对时序数据的最终结果影响极大，而且不同字段类型之间的差异非常明显,绝不能用一句"时序数据压缩率很高"糊弄过去。
所以正确的做法是：取你自己生产环境里真实的一批数据，按真实表结构入库，静置一段时间（让后台压缩合并跑完），再去看实际占用的磁盘字节数除以原始字节数，得到的才是你的压缩比。这个比值在不同业务之间差几倍是常态。用它去反推容量，误差才能控制在可接受范围内。
回到文章开头的那次事故。它的直接死因是磁盘 100%，但深层原因是：预写日志和数据文件在同一块盘上，形成了空间与带宽的双重争抢。
预写日志（WAL）的作用是保证写入的持久性。数据进来先写日志，日志落盘成功才算写入成功，后面内存表达到阈值再刷成正式的数据文件。WAL 的形态是纯追加的顺序写，写入量等于原始数据量（不压缩或压缩很少），而且它有一个清理周期——只有当对应的数据已经成功落盘之后，日志文件才能被回收删除。
由此可以推出三个结论：
如果每秒进来 10MB 的原始数据，那么 WAL 这一层就是每秒 10MB 落盘，不受压缩比影响。压缩比只作用于数据文件那一层。压缩比优化得再好，也减轻不了 WAL 的写入压力。这一点经常被忽略：团队好不容易把压缩比做上去，发现磁盘写入压力没降，就是因为压力的大头在日志侧。
正常情况下 WAL 占用会被稳定回收，维持在一个较小的窗口内。但如果后台刷盘/合并任务因为任何原因变慢——CPU 被查询打满、磁盘 IO 被备份任务抢走、或者磁盘本身已经接近写满——WAL 就会开始堆积，而且堆积速度是每秒原始写入速率。这时候它和数据文件同盘，就形成了一个正反馈的死亡螺旋：盘越满，压缩越慢；压缩越慢，日志越堆；日志越堆，盘越满。文章开头的那次事故，正是这个螺旋走到了头。
WAL 单独一块盘不是必须的，但有明确的适用条件。判断逻辑可以这样走：
关于具体怎么配置日志目录路径、日志保留的文件数与大小阈值、是否启用日志压缩，不同产品不同版本的参数名和默认值差异较大，请以官方文档对应版本为准。这里刻意不列具体参数值，因为写错一个默认值带来的误导远大于参考价值。
还有一点工程实践上的提醒：给 WAL 盘留的容量，应该按"写入速率 × 你能容忍的清理滞后时间"来算，而不是按天容量比例来算。假设写入 50MB/s，你希望在故障场景下至少有 30 分钟的缓冲，那么日志盘至少留出 90GB。这个数字要比直觉大得多。
如果只能给一条建议，那一定是这条：不要让所有原始数据都享受 SSD 待遇。
时序数据的价值随时间衰减得非常快。最近一小时的秒级数据会被频繁查询、告警规则实时扫描、看板不断刷新；一周前的数据可能只被看一下趋势；三个月前的数据基本只有出事故时才会回头翻。既然访问特征差异这么大，就没有理由让它们躺在同一档存储介质上。
降采样（downsampling，部分产品里对应的机制叫连续查询 / Continuous Query 或流计算任务），意思是：在后台按固定周期自动把高精度数据聚合成低精度数据。比如把 1 秒粒度的数据聚合成 1 分钟粒度的平均值、最大值、最小值、计数，再把 1 分钟的进一步聚合成 1 小时的。
这一步的收益是纯粹的乘法级缩减。1 秒聚 1 分钟是 60 倍缩减，再聚 1 小时又是 60 倍。原始层如果保留 7 天，分钟层保留 90 天，小时层保留 2 年，那么总容量的绝大部分会落在小时层，而小时层的体量可能只有原始层的几百分之一。
这里要提醒一个常见的设计失误：聚合必须保留多个统计量，而不是只留平均值。只留平均会把峰值抹平，而工业场景里峰值往往才是有价值的信息。至少要保留最大值、最小值和计数（计数用于还原求和）。
降采样的第二个收益是查询性能的量级提升。查一年的趋势时扫描小时层，行数可能是原始层的万分之一，响应时间从几十秒降到毫秒级。
分级的核心是把不同访问热度的数据放到不同的存储目录（即冷热分级目录 / tiered storage 相关机制）。热目录放 NVMe 或企业级 SSD，承接写入与近期高频查询；冷目录放大容量 HDD 或大容量对象存储，承接聚合后的历史数据。
判断"何时划算"的分界线其实很清晰：当你的 SSD 容量中超过一半被"很少被查询的历史数据"占据时，冷热分级就一定划算。因为这部分数据迁移到 HDD 之后释放出来的 SSD 空间，可以直接省掉下一块 SSD 的钱，而 HDD 的单位容量成本远低于 SSD。
举个直观的数量感受（属估算口径）：假设 SSD 与大容量 HDD 的单位容量成本相差数倍，那么把 10TB 冷数据从 SSD 挪到 HDD，节省下来的成本足以覆盖好几块 HDD 本身。冷数据越多，账越好看。反过来，如果总数据量只有几百 GB，全 SSD 反而是更简单也更省事的选择——分级带来的管理复杂度收益覆盖不了硬件差价。
在这个环节上，存储介质的选型会直接决定方案的落地成本。一万网络深耕 IDC 19 年（成立于 2007 年），在大陆华西、华东、华南、华北等节点提供可自选磁盘组合的物理机与裸金属，其中大容量存储型配置正是为这类"热数据 SSD + 冷数据 HDD"的混合结构准备的——写入层用 SSD 扛日志与近期数据，归档层用大容量机械盘装聚合后的历史数据，两者在同一台机器上通过不同挂载点管理，运维上不必额外引入一套对象存储。对于冷数据量已经明确超过数 TB、但又希望保持单机运维简单度的团队，这类配置往往比"全部用 SSD 再横向扩容量"更经济。
降采样任务失败、连续查询窗口卡住、过期数据没有被正确淘汰，这些问题在磁盘写满之前是完全静默的。务必对以下指标建立监控与告警：各层数据的实际占用字节数、降采样任务的执行延迟、最老数据的时间戳是否符合保留策略预期、WAL 目录占用。这些指标里的任何一个出现异常，都应该在磁盘到 80% 之前就报警，而不是等到 100%。
副本是从 1 到 3 很容易，但它的代价有三个维度，很多团队只算了容量这一个维度。
这个最直观，三副本就是三倍。注意副本通常是以原始数据或接近原始数据的形态在网络上传输，落到各节点后再各自压缩。所以副本倍数是乘在"压缩后容量"上的，也就是说前面公式算出来的结果要整体乘以副本数。
这一点经常被漏掉。写入节点不仅要自己写一份，还要把数据发给副本节点。在 TDengine 这类有 vnode/副本组概念的架构里，写入路径会经过副本同步环节。这意味着：
因此"加副本"从来不是一个纯粹的容量问题，它同时是一个网络规划问题。评估副本开销时，请把内网带宽、交换机端口速率、跨机架流量一起纳入计算。
副本数提高之后，节点故障时的恢复显得更从容；但代价是每次扩容要成组扩——你不能只给一台机器加一块盘，通常要让副本组内所有成员保持配置对称，否则容量会向最小的那个节点看齐。这个约束在做分期预算时务必提前考虑。
给出条件化判断：
下表把常见测点规模对应的磁盘组合、保留策略与成本属性做了一个横向对照。表中所有容量数字均为估算口径示例，请用你自己实测的压缩比替换后重新套算。
| 测点规模 | 采集频率 | 建议磁盘组合 | 建议保留与降采样 | 成本属性 |
|---|---|---|---|---|
| 5 千测点以内（原始占用约数百 GB/年） | 1 次/秒 或更低 | 单块企业级 SATA SSD / NVMe，1–2TB；WAL 与数据同盘但分目录 | 原始保留 30 天，分钟级聚合保留 12 个月 | 单机即可，成本可控 |
| 1–5 万测点（原始占用数 TB/年） | 1–2 次/秒 | 数据盘 NVMe 2–4TB + 独立 SSD 500GB 专供 WAL | 原始 7–14 天，分钟级 6 个月，小时级 2 年；冷层迁移至 HDD | 建议两副本，内网至少万兆 |
| 5–20 万测点（原始占用十 TB 量级/年） | 1–5 次/秒 | 热层 NVMe 4–8TB 做 RAID/条带 + 冷层 HDD 大容量阵列 + WAL 独立 NVMe | 原始 3–7 天，分钟级 3 个月，小时级 2 年以上；必须做冷热分级 | 集群版，三副本，需单独做网络与扩容预算 |
| 20 万测点以上 / 毫秒级高频 | 10 次/秒 以上 | 多节点分片 + 每节点 NVMe 热写层 + 分布式/对象存储冷层；WAL 独占 NVMe | 原始 1–3 天，秒级聚合只在极短窗口，其余全走分钟/小时层 | 按 TB 级年投入做预算（预估），需专业方案评估 |
| 边缘侧汇聚（单站点数千测点） | 1 次/秒 | 本地 SSD 缓存 + 定时批量回传中心；本地仅保留极短窗口 | 本地保留 1–3 天，中心侧按全量策略归档 | 边缘用低价机型，成本集中在中心集群 |
理论算完之后，落到"具体租什么"。下面给两组典型的落地思路，分别对应中等规模的单机起步与大规模的混合冷热架构，均属示例部署思路，实际请以现场压测结果为准。
适合 1–5 万测点、1 秒 1 次、要求在线保留 12 个月的团队。思路是：先单机把压缩比实测出来，再决定要不要上集群——因为在没测出真实压缩比之前买任何集群都是盲赌。
适合 5 万测点以上、秒级写入密集、要求保留 18–24 个月且不能丢数的场景。
两组配置之间没有优劣，只有阶段差异：不知道压缩比之前，用尽量小的投入把它测出来；测出来之后，再按倍数去买磁盘。这是本文最想传达的采购顺序。一万网络深耕 IDC 19 年（成立于 2007 年），提供 7×24 中文工单、平均 5 分钟响应、硬件故障 10 分钟内自动迁移，以及免费系统盘每日 3 份快照、30 秒回滚，大陆节点还可协助免费网站备案；对于磁盘组合需要按业务定制的场景，可在选型阶段与工程师确认具体的热层/冷层盘型与数量。
为什么坑：白皮书里的压缩比通常是在特定数据集（往往是整型、低频、低基数标签）上取得的。你的业务数据如果是六位小数浮点 + 高基数标签，压缩比可能只有它的几分之一。按乐观值算出来的容量，实际会不够用。更糟的是，这个错误会在半年后以"磁盘突然写满"的形式暴露，那时数据已经几 TB，迁移成本极高。
怎么避：上线前用真实样本做一次至少 72 小时的入库测试，让后台压缩合并充分跑完，测算实际磁盘占用 ÷ 原始字节数。把这个比值作为唯一依据。同时把"估算过程中不确定"的部分写成冗余系数，不要卡着理论值买盘。
为什么坑：HDD 的随机写性能本就有限，日志追加与数据合并同时争抢 IOPS 时，两边都会急剧劣化。进而导致刷盘变慢、日志回收滞后、日志堆积、可用空间下降，最终形成前文描述的正反馈死亡螺旋。
怎么避：数据盘若是 HDD 或 SATA SSD，务必给 WAL 单独一块 NVMe/企业级 SSD，并建立独立的占用告警。即使对端无法分离物理盘，也要至少分离挂载目录，避免单一目录写满直接拖垮整个分区。具体日志目录配置参数以官方文档对应版本为准。
为什么坑：副本数调整往往发生在上线前的最后阶段，而容量规划是在更早的方案阶段做的，两者之间没有回头校验。更隐蔽的是网络：副本同步流量走内网，千兆内网在万点级写入下会被同步流量压满，表现为写入延迟莫名升高。此时大家会去查磁盘、查 CPU，很少想到是内网带宽。
怎么避：把副本数写进容量公式，每次调整都重新算一遍总容量、单机容量与内网流量。内网带宽按"原始写入速率 ×（副本数）"估算并预留至少一倍余量。集群场景建议内网万兆起步。
为什么坑：备份导出、快照制作、版本升级前的数据导出，这些操作都需要和目标数据量相当的临时磁盘空间。规划时只算了在线数据的容量，没算"操作过程中的第二份数据"，于是备份任务执行到一半失败，留下的临时文件还在占空间。
怎么避：把磁盘规划的有效容量目标控制在总容量的 60%–70%，剩余空间明确留作三项用途：压缩合并工作区、备份导出临时区、突发写入缓冲。另外要有独立的 staging 目录与定期清理策略，避免失败任务残留。
为什么坑：时序库平时 CPU、内存都很闲，团队会默认这台机器"没什么事"，告警策略也跟着放松。但磁盘不是一个缓慢劣化的指标，它在接近上限时会因为压缩任务无法完成而急剧恶化。90% 告警意味着留给你的处置时间可能只有几分钟。
怎么避：磁盘使用率告警阈值建议放到 75%–80%，并且分别对数据目录、WAL 目录、备份目录分别设阈值。同时对"降采样任务执行延迟"和"最老数据时间戳"建立监控——后者可以发现保留策略没有生效的情况。监控系统自己也要被监控，建议用独立于被监控集群的另一套告警通道。
判断依据不是"测点数"这一个数字，而是三个数字的组合：稳态写入带宽、总容量需求、副本要求。经验性的分界线可以这样划：写入带宽持续低于单块 NVMe 顺序写能力的三分之一、总容量（含副本）能装进单机的盘位、且不需要多副本容灾时，单机完全够用；一旦总容量超过单机可装配的磁盘容量上界，或者必须上三副本，就应该直接上集群。另外一个更实际的分界信号是：如果未来 12 个月的测点增长会让容量翻倍，那就不要买"刚好够用"的单机，因为集群迁移的代价往往高于提前多买两台机器。
小规模写入场景下 HDD 也能跑，但不推荐。WAL 是纯追加的顺序写，理论上顺序写对 HDD 是友好的；问题在于 WAL 并不是磁盘上唯一的写入者——后台压缩合并、数据文件落盘、查询时的临时空间也在这块盘上，混合之后 HDD 的随机 IOPS 会成为瓶颈，进而拖慢刷盘，日志又回收不掉。如果业务量确实很小（比如每秒写入只有几 MB），HDD 勉强可用；但只要写入上到一个持续的量级，一块独立的企业级 SSD 的成本远低于一次写入中断的业务损失。具体参数与建议以官方文档对应版本为准。
不建议直接使用任何经验值，这是本文反复强调的一点。压缩比在不同数据类型之间的差距可以到好几倍：整型、状态码类字段的效果极好；带多位小数的浮点测量值会显著变差；字符串和 JSON 最差；时间戳因为单调递增通常表现很好。标签基数也是关键变量，高基数标签会让时间序列条数变多、单序列数据点变少，削弱可利用的局部相似性。唯一可靠的做法是拿自己的真实样本、真实表结构跑一次完整入库并等待压缩任务结束，然后实算磁盘占用与原始字节数的比值。
有一个非常直接的判断标准：当 SSD 空间中超过一半被"很少被查询的历史数据"占据时，冷热分级就一定划算。因为冷数据迁移到 HDD 释放的 SSD 空间，可以直接抵消下一块 SSD 的采购，而 HDD 的单位容量成本明显更低。反过来，如果总数据量只有几百 GB，全 SSD 反而是更简单、更省事的选择——分级引入的目录管理、迁移策略、运维监控复杂度收益覆盖不了硬件差价。另一个间接触发条件是：如果冷数据已经明确超过数 TB，且还在按保留周期线性增长，就应该尽快做分级，否则每一期扩容都在为冷数据买单。
关键是把"原始层"和"聚合层"的保留期分开设计，而不是二选一。典型做法是原始秒级数据保留 7–30 天（覆盖故障排查与实时告警所需），分钟级聚合保留数月，小时级聚合保留一到两年。这样既保留了近期的完整精度，又不必为一年前的秒级数据支付 SSD 成本。聚合时务必保留多个统计量——最大值、最小值、平均值、计数——只留平均值会把峰值抹平，而工业与车联网场景里峰值往往才是最有价值的信息。是否可接受最终由业务的查询需求决定，建议先在测试环境用历史查询回放验证。
至少还有两项常被忽略。其一是内网带宽：副本同步流量走内网，需要按原始写入速率乘以副本相关倍数来估算，千兆内网在这个量级下很容易成为新瓶颈，表现为写入延迟升高而 CPU 与磁盘都很闲。第二是扩容对称性：副本组内各成员的配置建议保持一致，否则有效容量会向最小的节点看齐，造成资源浪费。此外，副本节点的磁盘性能也要对齐——一个慢节点会拖慢整个副本组的写入确认。以上均属通用架构原则，具体实现细节请以官方文档对应版本为准。
建议把有效容量目标控制在磁盘总容量的 60%–70%，剩余部分承担三类用途：压缩合并的工作区（数据会短时间内存在两份）、备份导出与版本升级的临时空间、以及突发写入的缓冲。这个比例属于估算口径，具体应以实测的重压缩峰值为准。此外要注意分离挂载：数据目录、WAL 目录、备份与导出目录应该各自有独立的挂载点或至少独立的配额，避免其中任何一个写满时直接拖垮整个分区。告警阈值建议设在 75%–80%，不要等到 90% 再处置。
这是一条很务实的路径，也正是本文推荐的顺序。理由在于：前期最大的未知数是压缩比和真实写入带宽，而这两项在云主机上用一套小规模环境就能测出来，成本远低于直接采购集群。一万网络的弹性云起步价 ¥25 起，可以先用来跑写入压测与降采样链路验证；拿到真实压缩比之后，再据此换算裸金属所需的磁盘组合与台数，此时裸金属 E5-2620 ¥999 起、E5-2698v4×2 ¥3999 起这类明示档位才有明确的选型依据（价格以官网实时价为准）。需要注意迁移时的网络与数据一致性安排，建议提前规划切换窗口。
把全文收敛成几条可以直接执行的判断。
关于"够不够用"：总容量（含副本）能装进单机的盘位、写入带宽在单块 NVMe 能力范围内留有至少三分之二余量、且不需要多副本容灾时，单机足够。反之，一旦容量超过单机盘位上限、或者必须三副本、或者未来一年测点会翻倍，就应该直接上集群。不要买"刚好够用"的单机，因为到时候的迁移代价通常高于提前多买。
关于"用什么盘"：写入层一定要 SSD。NVMe 适用于万点以上、带宽持续上百 MB/s 的场景；SATA SSD 在几千测点的规模下完全够用。HDD 的定位是冷数据层，承接降采样之后的小时级/天级聚合结果，不为原始写入服务。判断冷热分级是否划算的标准很简单：SSD 里超过一半是很少被查询的历史数据时，立刻分级。
关于"谁ände的任务最优先"：如果只能做一件事，就做降采样——它是唯一能把容量需求砍掉一个数量级的手段，且同时改善查询性能。第二件事是把预写日志搬到一块独立的 SSD 上并单独监控占用，这一步直接决定了磁盘会不会突然写满。第三件事才是买更大的盘。
关于"顺序"：先用低成本环境把压缩比和真实写入带宽测出来，再按公式反推容量，最后才下单硬件。跳过实测直接采购，是本文开头那次事故的根本原因，也是绝大多数时序库容量翻车的共同路径。
声明：本文涉及的所有容量数字、压缩比、配比均为估算口径与示例场景，用于说明计算方法，不构成任何实测结论；具体产品参数、默认值与建议配置请以官方文档对应版本为准，价格以官网实时报价为准。
本文的数据与口径来源如下，供交叉校验：
如需进一步核对产品参数与当期活动价格，请以 idc10000.net 官网相关页面实时内容为准。
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
