1. 课程导入与数据库存储挑战

数据库工作负载是存储系统中最“挑剔”的一类负载。它不像文件共享那样可以容忍秒级抖动，也不像备份归档那样只关心顺序吞吐。数据库对存储的要求是多维度同时成立：既要低时延，又要高IOPS，还要在故障、扩容、快照、复制等操作下保持数据一致性和可预测的性能。Pure Storage 在数据库场景中的定位，正是围绕“全闪存 + 始终在线 + 数据服务内建”来重新定义数据库存储的交付方式。

传统数据库存储通常面临几个结构性矛盾。第一，机械盘或混合阵列的随机IOPS受限于寻道和旋转延迟，OLTP 场景下每增加一个并发事务，时延就可能从毫秒级恶化到几十毫秒。第二，传统阵列的控制器成为性能瓶颈，扩容往往意味着“换更高端型号”而不是“加盘”。第三，快照、克隆、复制等数据服务通常由数据库或主机层软件实现，消耗CPU和网络，且难以做到秒级恢复。第四，容量与性能绑定，买容量必须买性能，导致资源浪费或性能不足。

Pure Storage 的 FlashArray 与 FlashBlade 产品线分别面向块存储和文件/对象存储，在数据库场景中通常以 FlashArray 承载 Oracle、SQL Server、SAP HANA、PostgreSQL、MySQL 等块级数据库，以 FlashBlade 承载分析型、并行文件系统或数据湖场景。其核心设计理念是：全闪存介质、NVMe 端到端、全局磨损均衡、内建数据缩减、始终在线升级、以及 Purity 操作系统提供的快照、克隆、复制、ActiveCluster 双活等数据服务。这些能力直接对应数据库对 IOPS、时延、吞吐、容量和一致性的需求。

要理解数据库存储设计，先要理解不同负载对存储的“压力画像”。OLTP 以随机小IO为主，典型块大小为 4KB～16KB，读写比例约 70:30 到 90:10，关注 IOPS 和时延，尤其是尾时延（P99、P999）。OLAP 以顺序大IO为主，块大小 128KB～1MB，读多写少，关注吞吐和扫描带宽。混合负载则同时存在事务写入和分析读取，要求存储具备 QoS 隔离能力，避免分析查询把事务时延拉高。此外，数据库还要求写入顺序一致性、日志同步写入的持久性、以及快照/克隆的崩溃一致性。

下面这张图把数据库存储需求与 Pure Storage 的关键能力对应起来，帮助建立课程整体框架。

从图中可以看到，课程的整体逻辑是：先建立负载画像，再把负载翻译成存储需求，然后把需求映射到 Pure Storage 的具体能力，最后通过设计验证和运维优化形成闭环。后续章节会依次展开：OLTP 场景下的卷设计、主机连接与多路径、日志与数据文件布局；OLAP 场景下的吞吐调优、大块IO与并行度；混合负载下的 QoS 策略与性能隔离；以及快照、克隆、复制、双活等数据服务在数据库备份、恢复、测试、容灾中的具体用法。

在进入具体设计之前，需要先明确几个贯穿全课程的基础概念。第一，有效容量不等于物理容量，Pure Storage 的数据缩减（去重、压缩、精简）会显著影响实际可用容量，数据库场景中通常可达到 2:1 到 5:1 甚至更高，但具体比例取决于数据特征，设计时必须按保守值估算。第二，时延要区分平均时延和尾时延，数据库事务更关心 P99 和 P999，因为少数慢请求会阻塞连接池和锁等待。第三，IOPS 与吞吐不是线性关系，小IO看IOPS，大IO看带宽，混合负载要同时约束两者。第四，一致性包括写入顺序一致性、崩溃一致性、快照一致性，Pure Storage 的快照默认提供崩溃一致性，若需要应用一致性则需配合数据库冻结或脚本。

最后需要强调，数据库存储设计不是“买最快设备”那么简单，而是在性能、容量、可用性、成本和运维复杂度之间做权衡。Pure Storage 的价值在于把这些权衡中的很多项从“互相冲突”变成“可以同时满足”：全闪存提供低时延和高IOPS，数据缩减提升有效容量，快照克隆降低测试和备份成本，ActiveCluster 提供双活容灾，在线升级减少停机窗口。理解这些能力背后的原理和边界，才是本课程真正要培养的设计能力。