首页/数据/NoSQL 速查/容量评估:从日增到磁盘预留
选型与架构50 条

容量评估:从日增到磁盘预留

容量评估按链条推算:日均写入乘以保留周期得到逻辑量,再乘索引与副本系数,按实测压缩率折算磁盘,最后加水位余量。任何系数都要标注来源,并在上线后用监控数据持续校准。

NoSQL 速查数据更新于 2026-10-13

容量评估怎么算

容量评估按链条推算:日均写入乘以保留周期得到逻辑量,再乘索引与内部开销系数,按实测压缩率折算磁盘,最后加水位余量。每个系数都要标注来源,并在上线后用监控数据持续校准。LSM 类引擎(ClickHouse、HBase、Elasticsearch 的段)写入后还有合并与重建过程,峰值占用会高于静态估算,磁盘水位建议常留两到三成。

基本信息

输入项日增量、保留周期、副本数、压缩率、预留水位
计算链日增 × 保留周期 × 开销系数 ÷ 压缩率 ×(1 + 水位)
校准手段用真实样本测压缩率、监控增长斜率、定期重估
易漏项写放大、索引体积、备份空间、导入峰值
所属系统容量规划通用方法

典型使用场景

  • 新系统立项:按业务增长预估三年容量
  • 扩容判断:用增长斜率推算剩余可用时间
  • 保留期调整:评估缩短或延长保留期的磁盘影响
  • 成本优化:核对压缩率与副本是否真的需要
  • 压测验证:用真实写入压测校准估算系数

估算示例(含假设)

估算示例(含假设)
# 假设:日志写入 20GB/天(未压缩),保留 30 天,压缩率按 4:1 估算
逻辑量    = 20GB × 30 = 600GB
压缩后    ≈ 600GB ÷ 4 = 150GB
索引与内部开销按 1.3 倍 ≈ 195GB
预留 25% 水位        ≈ 245GB
# 若保留 2 份副本,磁盘占用再乘副本系数(或按副本所在节点分别规划)

容易漏算的项目

易漏项为什么会漏后果
写放大只算净数据磁盘占用高于静态估算
索引体积只算主数据实际占用比预期多
备份空间只规划在线盘备份无处存放
导入峰值只看稳态大批量导入时磁盘告警
副本系数只按单副本算磁盘需求差成倍
任何系数都要标注来源并在上线后用监控数据校准,拍出来的压缩率与实测值往往差别很大。
LSM 类引擎写入后还有合并与重建过程,峰值占用会高于静态估算,磁盘水位建议常留两到三成。
评估时要同时给出增长斜率与告警阈值,只给一个总容量数字无法支撑后续运维决策。

易错点

  • 只按当前数据量买盘,忽略日增与保留策略,数周后触发磁盘告警
  • 把压缩率拍成乐观值(例如按 10 倍估),落地后空间不足需要来回搬数据
  • 忽略写放大与副本系数,实际占用与估算差出一倍以上
  • 导入峰值不在评估范围内,大批量补数时把磁盘写满

数据来源与参考

  • Elasticsearch Guide: Size your shards
  • MongoDB Manual: Production notes
  • ClickHouse Docs: MergeTree
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌