选型的判断顺序
存储选型最有效的做法是先定形态再定产品，而不是先挑品牌再套场景。形态由访问协议决定，协议由应用决定：应用要自己管理文件系统或裸设备，就是块；多台机器要看到同一份目录，就是文件；应用通过 HTTP 接口读写海量键值，就是对象。形态定错之后，无论后端硬件多好，都会表现为「性能不达标」或「运维无法维护」——这两种问题用加硬件通常都治不好。
四个问题定形态
| 判断问题 | 块存储 | 文件存储 | 对象存储 |
|---|---|---|---|
| 命名空间由谁管 | 主机自己管 | 存储侧统一管 | 服务端按键值管 |
| 几台主机同时访问 | 单机为主，多机需集群文件系统 | 天然多客户端共享 | 海量客户端通过接口访问 |
| 读写模式 | 小随机读写、低时延 | 混合读写、含元数据操作 | 顺序写、少改写、大吞吐 |
| 容量规模 | 中等到大 | 中等到大 | 极大，可按需无限扩 |
典型场景的判断结论
- 数据库、虚拟机镜像、需要 fsync 语义的应用：直接选块存储，别绕弯
- 多机协作用同一份文件、容器共享卷、渲染与剪辑素材：选文件存储
- 备份归档、图片视频、日志与数据湖原始层：选对象存储
- 同一业务跨阶段：热数据用块、共享层用文件、归档层用对象，用分层而不是用一种形态硬扛全部
- 不确定时先看应用能否改造：能改成对象接口的互联网应用优先对象，不能改造的传统应用按原协议就近选择
基本信息
| 第一依据 | 应用的访问协议与并发模型，而不是容量大小 |
|---|---|
| 第二依据 | 共享需求：多主机读写同一数据的范围与频率 |
| 第三依据 | 时延与稳定性的硬指标：是否有明确的服务级别目标 |
| 第四依据 | 增长曲线与运维能力：三年内扩到什么规模、谁来维护 |
统一存储类产品可以同时提供块、文件与对象接口，但同一套硬件里三种服务的资源是共享的。并发压力大的场景应明确主用形态并做资源隔离，避免一种服务的突发把另一种拖慢。
形态迁移的代价常被低估：协议变了，应用的文件系统调用、备份方式、权限模型都要跟着改。选型阶段应该把这个改造量算进项目周期，而不是等到性能不达标时再回头换形态。