块存储、文件存储、对象存储到底怎么选？一文读懂 S3、Ceph 与 MinIO

如果你在 2010 年告诉一个运维工程师：以后咱们公司几十亿张图片、几百万小时视频、还有上 TB 的 AI 训练集，都不放在文件夹里了，而是统统塞进一个叫 Bucket 的桶里，用网址去取。他大概率会觉得你疯了。毕竟从 DOS 时代起，人类存储数据的直觉就是文件夹套文件夹：C 盘、Documents、Photos、2024……这套树状结构我们用了几十年，几乎成了肌肉记忆。

延伸阅读

更多相关攻略推荐：泛域名 SSL 证书自动化避坑：Acme.sh + DNS API 、BGP 是互联网的"高德地图"：打开网页时，数据是这样找路的、【优化线路 02】BGP / AS4837 常规线路年付 10 美元、高级玩家玩出花：如何在 VPS 上广播自己的 IP 地址？BYOIP、计算机科学两大难题之一：缓存失效与 CDN 瞬时刷新奥秘。

一、先讲个故事：文件夹树是怎么被撑爆的

想象一个大型短视频平台，每天新增上千万个视频文件。早期它们确实都存在本地磁盘的目录树里。但问题很快来了：当单个目录下的文件数量突破百万，传统文件系统（比如 ext4、NTFS、XFS）的元数据操作会急剧变慢——你要列个目录、查个文件属性，操作系统得先遍历一大堆索引节点（inode）。更致命的是，目录树天生是一棵树，根节点和父目录都是单点，横向扩展极其困难。

某视频平台公开分享过：把热数据迁到对象存储后，存储成本直接降了约 70%，还顺手用生命周期策略把 30 天前的冷视频自动降级到低频访问层。这不是玄学，而是对象存储从设计上就抛弃了目录树这个包袱。

到了 AI 时代，这个矛盾更尖锐。一个图像训练集动辄上亿张小图，如果还用文件夹管理，光是遍历元数据就能让训练任务卡在磁盘 I/O 上。对象存储用扁平命名空间加唯一 Key 的思路，正好化解了这场危机。

二、三种存储，三种世界观：块、文件、对象

存储圈有个经典三分法，理解了它就理解了现代云架构的底层逻辑。

• 块存储（Block Storage）：把磁盘切成固定大小的块，通过 iSCSI、FC 或 NVMe-over-Fabrics 协议暴露给操作系统，操作系统把它当成一块裸硬盘。它延迟最低（NVMe 可低于 100 微秒）、IOPS 最高，是数据库和虚拟机的标配。代表：AWS EBS、Ceph RBD。缺点是共享能力弱，通常只能挂给一台主机。
• 文件存储（File Storage）：标准的目录树，通过 NFS、SMB/CIFS 协议让多台机器同时挂载共享。兼容性极佳，老应用无需改造。代表：AWS EFS、CephFS、GlusterFS。缺点是元数据服务器容易成为扩展瓶颈。
• 对象存储（Object Storage）：数据以对象为基本单元，每个对象包含数据本体、自定义元数据和全局唯一 ID，通过 HTTP REST API（典型就是 S3 接口）访问。它天然支持无限扩展、成本最低，是海量非结构化数据的归宿。代表：AWS S3、MinIO、Ceph RGW。

一句话总结它们的性格：块存储追求快，文件存储追求共享，对象存储追求大和省。

三、对象存储的核心：扁平命名空间与 HTTP API

对象存储最反直觉的设计，是它没有文件夹这个概念（虽然 S3 用斜杠前缀模拟层级，比如 photos/2024/cat.jpg，本质还是靠 Key 字符串，不是真正的树）。所有对象都平铺在一个 Bucket 里，靠一段全局唯一的 Key 来寻址。

这个设计带来三个好处。第一，扩展无上限：新增硬盘或节点时，系统用一致性哈希算法把数据重新分布，迁移量最小，轻松扩展到 EB 级。第二，访问简单：任何语言只要能发 HTTP 请求（PUT/GET/DELETE）就能读写，不需要装专门的客户端驱动。第三，元数据自由：你可以给每个对象贴任意标签（拍摄时间、所属用户、ContentType），这些元数据独立于内容存储，检索时极为灵活。

权限也不靠操作系统账号，而是靠 Bucket Policy（桶策略）和 IAM 角色。比如你可以让公开读、私有写，也可以给某个 CDN 单独签一个临时访问 URL，精细度远超文件系统的 chmod。

四、高可用与海量扩展：多副本、纠删码与一致性哈希

数据放这么松散，会不会丢？这是新手最常问的。恰恰相反，对象存储的可靠性往往高于你机柜里那块 RAID 硬盘。

常见做法是多副本：默认三副本，数据被打散到不同机架甚至不同可用区（AZ），单点甚至多点故障都不丢数据。但三副本意味着存储效率只有 33%（3 份占 3 倍空间）。于是冷数据场景流行纠删码（Erasure Coding）：把数据切成 k 份、再算 m 份校验，例如 4+2 或 9+3 模式，允许同时坏 m 块盘而不丢数据，存储效率从 33% 提升到 75% 甚至更高，代价是重建数据时要多读几块盘、吃一点 CPU 算力。

当访问频率低、但数据量惊人是对象存储的主场。它通常采用最终一致性模型：你刚上传一个对象，立刻去读可能短暂读不到，但最终一定一致。配合版本控制（Versioning），你还能防误删、做时间点回滚。

五、开源对象存储双雄：Ceph 与 MinIO

想自建一套私有版 S3？开源界有两座绕不开的大山：Ceph 和 MinIO。它们都实现了 S3 兼容接口，但走的是完全不同的路线。

六、Ceph：存储界的航母舰队

Ceph 用 C++ 写成，定位是统一存储：一个集群同时提供块（RBD）、对象（RGW）和文件（CephFS）三种接口。它的底层是 RADOS 分布式对象存储，靠 CRUSH 算法（Controlled Replication Under Scalable Hashing，可扩缩哈希下的受控复制）计算数据该放哪，不需要中心化的元数据服务器，因此能平滑扩展到 EB 甚至 Exabyte 规模。

代价是复杂度。Ceph 有 MON（监视器）、OSD（对象存储守护进程）、MDS（元数据服务器）等多个角色，要管理 CRUSH 图、PG（归置组）数量，最小可用集群也得 3 个 MON 加 3 个 OSD。社区里常说，调优一个生产级 Ceph 可能要花运维团队好几个月。好消息是，有了 Rook 这个 Kubernetes Operator，声明式地管理 Ceph 已经方便很多。

授权方面 Ceph 是 LGPL，完全开源、无商业授权风险，很多 Linux 发行版自带，长期持有最稳妥。

七、MinIO：专注对象存储的瑞士军刀

MinIO 用 Go 语言写成，是个单二进制文件的轻量选手，专注把对象存储这一件事做到极致。它的部署快得离谱：有团队实测在 200 节点的 K8s 上，MinIO 的部署时间比 Ceph 快了约 47 倍；在树莓派集群上，4 节点 MinIO 十分钟内就能跑起来。

性能上，MinIO 在小规模、高并发场景常胜一筹：基准测试里单节点 GET 能到 2.5 GB/s，DELETE 高达约 1.8 万 ops/秒，因为它没有 RADOS 那层共识开销。它默认用纠删码（常见 4+4，最高 8+8）保证可靠，并支持站点级双活复制（Site Replication）做异地容灾。

但要敲黑板提醒：MinIO 自 2022 年起改用 AGPLv3 加商业授权。如果你做的是 SaaS、会把它的代码能力直接暴露给外部用户，商用不买授权可能有合规风险——这是很多团队选型时容易忽略的暗坑。此外单节点模式有单点故障，生产集群至少 4 节点起步。

八、选型实战：你该自建哪一套

• 只想要对象存储、追求最简单运维和最高吞吐：选 MinIO，一个二进制、一条命令就能起。
• 需要块、文件、对象三合一，且体量会冲到 PB 级以上、看重多租户和企业级特性：选 Ceph，它内置细粒度 ACL、配额、多站点复制，长期拥有成本更低。
• 还想省钱省心：直接用云厂商的 S3（如 AWS S3、阿里云 OSS），把运维包袱甩给厂商，只付流量和存储费。

现代应用往往是混合存储：块存储放数据库事务日志（要低延迟恢复），文件存储放训练集共享目录（要多节点并行读），对象存储归档训练好的模型（要长期便宜保存）。用 CSI 接口和 s3fs 这类 FUSE 工具，还能把对象存储挂载成本地目录，灵活得很。

#对象存储 #S3 #Ceph #MinIO #云存储 #分布式存储 #VPS建站