3. 数据库存储需求建模

存储需求建模的本质，是把业务负载翻译成一组可验证的存储指标。很多项目在选型阶段只问“需要多少 TB”，结果上线后才发现瓶颈出现在随机小 IO 的时延上，或者出现在大范围扫描时的带宽上。要避免这种偏差，必须先把数据库工作负载归类为 OLTP、OLAP 或 HTAP，再分别推导 IOPS、时延、吞吐量、容量与一致性这五类需求。

一、先识别负载形态，再谈指标

OLTP 的典型特征是高频、短小、随机、并发。一次事务通常只触及少量行，读写比例可能接近 7:3 或 8:2，单次 IO 尺寸多为 4KB～16KB，对时延极其敏感。OLAP 则相反：查询次数少但单次扫描数据量大，IO 尺寸常为 128KB～1MB 甚至更大，顺序读占比高，更关心吞吐量而非单次时延。HTAP 同时承载事务与分析，既要低时延点查，又要大吞吐扫描，是需求建模中最容易顾此失彼的场景。

判断负载形态时，建议采集三类证据：一是数据库自身的等待事件与 AWR/ASH 报告，看 db file sequential read 与 db file scattered read 的比例；二是操作系统层的 IO 尺寸分布与队列深度；三是业务侧的事务速率与报表并发数。三者交叉验证，才能避免把“看起来像 OLTP”的混合负载误判为纯 OLTP。

二、IOPS 与时延：从业务速率反推

IOPS 不能凭感觉估算。以 OLTP 为例，假设业务峰值事务速率为 3000 TPS，每个事务平均产生 8 次物理 IO（含索引查找、数据页读写、日志写入），则峰值 IOPS 约为 24000。若读写比为 7:3，则读 IOPS 约 16800，写 IOPS 约 7200。这个数字还要乘以一个安全系数，通常取 1.3～1.5，以覆盖突发与后台任务。

时延目标要区分平均值与尾时延。OLTP 场景下，平均时延 0.5ms 但 P99 达到 20ms，用户体验依然会明显劣化。因此需求文档中应写明“P99 读时延 ≤ 1ms，P99 写时延 ≤ 2ms”这类可测量目标。Pure Storage 全闪存阵列在稳定状态下可提供亚毫秒级时延，但前提是卷的 IO 尺寸与队列深度在合理范围内，这需要在建模阶段就与存储侧确认。

三、吞吐量：OLAP 的生命线

OLAP 的吞吐量需求通常由“单查询扫描数据量 × 并发查询数 ÷ 可接受完成时间”推导。例如，一张 2TB 的事实表，单次全表扫描需读取 2TB，若要求 10 个并发查询在 60 秒内完成，则所需吞吐约为 2TB × 10 ÷ 60s ≈ 341 GB/s。这个数字显然超出单台存储的能力，说明必须通过分区裁剪、列式压缩或缓存来降低实际扫描量，而不是盲目堆带宽。

实际建模时，更合理的做法是先估算“有效扫描量”。若分区裁剪后每次只读 5% 的数据，则有效扫描量为 100GB，10 并发 60 秒所需吞吐降至约 17 GB/s，这才是一个可落地的目标。吞吐量需求必须与查询优化策略一起建模，否则会得出误导性的结论。

四、容量：不只是数据量

容量规划常犯的错误是只计算原始数据量。实际所需容量 = 原始数据 × 副本系数 × 索引与元数据膨胀 × 临时空间 × 增长余量。以 10TB 原始数据为例，若采用双副本、索引膨胀 30%、临时空间 20%、年增长 40%，则首年所需容量约为 10 × 2 × 1.3 × 1.2 × 1.4 ≈ 43.7TB。若使用具备去重与压缩能力的全闪存平台，实际物理容量可能显著低于此值，但建模阶段仍应按逻辑容量做保守规划，再根据实测压缩比调整。

五、一致性：被低估的维度

一致性需求直接影响存储的写入确认路径与副本策略。OLTP 要求强一致，写入必须等到日志落盘并确认，这会增加写时延；OLAP 可接受快照读或最终一致，允许异步复制以换取吞吐；HTAP 则最复杂，事务路径需要强一致，分析路径可以读取稍旧的数据，但必须明确“可见性延迟”的上限，例如“分析查询最多看到 5 秒前的数据”。这个上限应作为需求写入基线，而不是留给运维临时判断。

六、HTAP 的折中与隔离

HTAP 建模的关键不是找一个“全能”配置，而是做负载隔离。常见做法是将事务日志与数据文件放在高优先级卷，将分析扫描放在独立卷或独立存储池，通过 QoS 限制分析负载对事务时延的干扰。需求文档中应分别列出两条路径的指标：事务路径 P99 ≤ 1ms、IOPS ≥ 20000；分析路径吞吐 ≥ 5GB/s、时延 ≤ 50ms。两者共享容量，但性能目标独立验收。

最后，所有建模结果都应回到业务语言做一次校验：这套存储能否支撑“双十一”峰值、能否在报表窗口内完成跑批、能否在故障切换后保持一致性。只有通过这层校验，五元组需求才真正完成了从技术指标到业务保障的闭环。