3. 数据库工作负载特征分析

在存储设计开始之前,必须先回答一个比“容量多大”更关键的问题:这套数据库到底在做什么样的工作。OLTP、OLAP、HTAP 这三类负载,对存储系统的要求几乎处在光谱的两端甚至同时跨越两端。如果只按“数据库”三个字统一配置,结果往往是 OLTP 被高延迟拖垮,或者 OLAP 被小 IO 限制住扫描带宽。本节从 I/O 模式、读写比例、延迟敏感度、吞吐需求和并发特征五个维度,把三类负载拆开分析,并给出可落地的判断方法。

一、五个维度是存储设计的“坐标系”

这五个维度不是并列的标签,而是相互制约的。I/O 模式决定单次请求的大小和随机性;读写比例决定缓存策略和写路径压力;延迟敏感度决定能否容忍排队;吞吐需求决定带宽和并行度;并发特征决定队列深度和连接压力。任何一项判断错误,都会让后续的 RAID 级别、介质选型、缓存分配和 QoS 策略偏离实际。

需要先明确一个参照约定:本文所说的“延迟”指从主机发出 I/O 到收到完成的端到端时间,包含网络、控制器、介质和排队;“吞吐”指单位时间内成功完成的数据量;“IOPS”指单位时间内完成的 I/O 次数。小 IO 场景看 IOPS 和延迟,大 IO 场景看带宽,两者不可混用。

OLTP / OLAP / HTAP 五维负载特征对照 维度 OLTP OLAP HTAP I/O 模式 8K 随机小 IO 1M+ 顺序大 IO 小 IO + 大扫描混合 读写比例 读 70% / 写 30% 读 95%+ / 写 5%- 写密集 + 实时读 延迟敏感度 极高,亚毫秒级 较低,秒级可接受 事务高、分析中 吞吐需求 高 IOPS,低带宽 高带宽,GB/s 级 IOPS 与带宽双高 并发特征 数千短连接、高并发 少量长查询、低并发 混合并发、隔离要求高 存储设计取向 OLTP:低延迟优先,全闪 + 写缓存 + 高 IOPS 队列,RAID10 或三副本 OLAP:带宽优先,大条带 + 顺序预取 + 高吞吐,RAID6 或纠删码 HTAP:分层隔离,热数据低延迟层 + 冷数据高吞吐层,QoS 限流防干扰

二、OLTP:小 IO、高并发、延迟就是生命线

OLTP 的典型代表是订单、支付、账务类系统。它的 I/O 模式高度随机:一次事务通常只读写几行记录,落到存储层就是 8K 或 4K 的随机读和随机写。读写比例大致在 7:3 到 6:4 之间,但写路径更敏感,因为每次提交都要保证日志落盘(WAL/redo),写延迟直接决定事务提交时间。

延迟敏感度是三类中最高的。用户点击“提交订单”后,前端等待的就是这条链路。行业经验值通常要求存储侧写延迟稳定在 1ms 以内,读延迟在亚毫秒级。注意“稳定”二字:平均值好看没有意义,P99 延迟才是关键。一个平均 0.5ms、P99 达到 20ms 的存储,会让 1% 的事务明显卡顿。

吞吐需求表现为高 IOPS 而非高带宽。假设一套订单系统峰值 8000 TPS,每个事务平均产生 6 次物理 I/O,则峰值 IOPS 约 48000。这个量级用全闪存阵列配合合适的队列深度即可满足,但如果用大容量近线盘,随机 IOPS 会迅速成为瓶颈。

并发特征是“短连接、高并发”。连接池里可能同时有数千个活跃会话,每个会话的 I/O 都很小但频率高。存储侧要关注队列深度和 IOPS 的线性度:当并发从 64 升到 256 时,IOPS 是否还能线性增长,延迟是否急剧上升。这是判断存储能否承载 OLTP 峰值的直接依据。

三、OLAP:大 IO、顺序扫描、带宽决定一切

OLAP 面向分析查询,典型操作是全表扫描、大范围聚合、多表关联。I/O 模式以顺序大 IO 为主,单次请求常在 128K 到 1M 甚至更大。读写比例极度偏读,通常在 95% 以上,写入主要来自批量加载(ETL)和分区导入。

延迟敏感度相对较低。一个报表查询跑 8 秒还是 10 秒,业务通常可以接受,因此存储设计更关注“单位时间能扫多少数据”。吞吐需求以带宽衡量,一套中等规模的分析集群,扫描带宽需求常在 2GB/s 到 10GB/s 之间。此时瓶颈往往不在介质本身,而在控制器、链路和条带宽度。

并发特征是“少量长查询、低并发”。可能只有几十个并发查询,但每个查询持续数秒到数分钟,占用大量带宽。存储侧要避免的是单个大查询把带宽吃满,导致其他查询排队。因此 OLAP 更适合大条带、顺序预取、以及能提供稳定带宽的 RAID6 或纠删码配置。

四、HTAP:两类负载叠加,隔离比性能更重要

HTAP 的难点不是“既快又大”,而是两类负载在同一套系统上互相干扰。事务写入产生的小 IO 会打断分析扫描的顺序性,分析扫描的大 IO 又会挤占事务的延迟预算。读写比例、I/O 大小、并发特征都呈现混合状态,没有单一优化方向。

实际设计中通常采用分层思路:热数据放在低延迟层,保证事务提交;冷数据或历史分区放在高吞吐层,服务分析扫描。同时用 QoS 或资源组限制分析查询的 IOPS 和带宽上限,防止它拖垮事务路径。判断 HTAP 是否健康,可以观察两个指标:事务 P99 延迟是否被分析查询拉高,以及分析查询的扫描带宽是否被事务写入压缩。

五、把特征落到可测量的判断上

仅凭“我们是 OLTP”这样的描述不足以指导设计。更可靠的做法是从现有系统采集真实数据,形成一张负载特征表。下面给出一个可直接填写的示例模板,字段和取值都围绕本节五个维度设计。

采集项 OLTP 示例值 OLAP 示例值 HTAP 示例值
平均 I/O 大小 8 KB 512 KB 8 KB ~ 1 MB
随机/顺序占比 随机 90% 顺序 85% 混合
读:写 70:30 95:5 80:20(波动大)
峰值 IOPS 48000 6000 30000
峰值带宽 400 MB/s 6 GB/s 3 GB/s
P99 延迟目标 < 1 ms < 50 ms 事务 < 2 ms
活跃并发会话 2000+ 30 ~ 80 500+

采集时建议使用数据库自带的性能视图或操作系统级工具,例如通过 iostat -x 1 观察 r/s、w/s、rkB/s、wkB/s 和 await,再结合数据库的等待事件统计,判断 I/O 是随机还是顺序、延迟集中在读还是写。注意区分“平均值”和“峰值”:存储设计要按峰值留出余量,通常建议峰值不超过存储能力的 70%。

判断负载类型时,不要只看业务名称。一个“报表系统”如果每 5 分钟被 BI 工具轮询一次小查询,它的实际特征可能更接近 OLTP;一个“交易系统”如果每天凌晨跑大批量对账,它也会在特定时段表现出 OLAP 特征。以实测 I/O 特征为准,而不是以系统命名归类。
HTAP 场景下最常见的错误,是把事务和分析放在同一组无隔离的 LUN 上,并期望“全闪存能扛住”。全闪存提升的是介质能力,不能自动解决两类负载的排队冲突。没有 QoS 或分层,分析查询的突发大 IO 会直接抬高事务 P99 延迟。

把上述五个维度和采集结果对齐后,存储设计才有明确输入:OLTP 指向低延迟、高 IOPS、写缓存保护;OLAP 指向大条带、高带宽、顺序预取;HTAP 指向分层与隔离。下一阶段选择 RAID 级别、介质类型和缓存策略时,都应回到这张特征表来验证,而不是凭经验拍板。