2.2 存储服务：对象、块、文件

2.2 存储服务：对象、块、文件

本节摘要：存储服务解决"数据放哪儿"的问题，三大主流形态各擅胜场：对象存储面向海量非结构化数据（图片、视频、文档），按 URL 访问、近乎无限扩展、成本低廉；块存储像"云上的硬盘"，挂给虚拟机做系统盘和数据盘，性能高、延迟低；文件存储提供多台机器共享的目录，适合传统应用与共享工作区。本节给出三者的访问方式对比与选型决策树，帮你把数据放对地方。

本节地图

阅读完本节，你应当能够：

1. 区分对象存储、块存储、文件存储三种形态的访问接口与典型用途。
2. 解释为什么"对象存储适合非结构化数据、块存储适合虚拟磁盘"。
3. 对比三种存储的性能、扩展性、成本特征，并给出选型建议。
4. 说出对象存储、块存储、文件存储各一个典型云产品。

一、问题与直觉

数据是云上最需要"安放"的东西，但"存"这个字其实暗含了三种完全不同的动作：你要存的是一个一个的文件（照片、报告），还是一块一块的磁盘（给虚拟机当硬盘），还是一个大家一起改的共享文件夹？

打个比方：对象存储像"货架仓库"——每件货有个编码（URL），你把它扔上货架，取货时凭编码取，货架可以无限加层；块存储像"你家的冰箱"——挂在厨房（虚拟机）上用，讲究的是制冷快、拿取快，但不能搬来搬去给别家共用；文件存储像"公司公共文件柜"——大家都往里放文件、改文件，讲究的是共享和权限。

选错存储类型是云上返工率最高的操作之一：有人把数据库文件直接丢进对象存储，结果每秒读写几次的性能根本撑不住；也有人拿块存储当备份归档，成本直接爆表。所以花一节能理解清楚三种存储，非常值。

二、核心原理

2.1 对象存储：海量非结构化的归宿

对象存储（Object Storage）把数据作为"对象"保存，每个对象由数据本身、元数据和唯一标识（键/URL）组成。它通过 HTTP API 访问（读、写、列举），没有传统文件系统的目录层级概念，适合图片、视频、日志、备份这类非结构化数据。

对象存储的优势在"规模"与"成本"：近乎无限的扩展能力（桶内对象数以亿计也没问题）、跨区域多副本的高可用、以及远低于块存储的单位成本。劣势是性能——对象存储的延迟以"几十到几百毫秒"计，不适合高频小数据随机读写，也"不能像文件系统那样挂载后直接改"（要整个对象覆盖写）。典型产品如 AWS S3、Azure Blob Storage、Google Cloud Storage。

2.2 块存储：虚拟机的"硬盘"

块存储（Block Storage）以固定大小的"块"为单位组织数据，提供裸块设备接口，通常作为虚拟机或容器的持久化磁盘。它的特点是低延迟、高 IOPS，非常适合数据库、操作系统镜像这类需要高性能随机读写的负载。

块存储的关键属性是"挂载"——它不是一个独立可访问的存储服务，而是"附着"在某台计算实例上的磁盘。停止实例、删除实例时，块存储可以保留（数据盘）也可以随实例删除（临时盘），这取决于你创建时的配置。典型产品如 AWS EBS、Azure Disk Storage、Google Persistent Disk。

2.3 文件存储：共享的"文件柜"

文件存储（File Storage）提供标准的文件共享协议（如 NFS、SMB），让多台机器通过网络挂载同一个目录，所有机器看到的是同一份文件。它适合需要共享工作区、传统应用迁移、以及多实例共同读写同一份数据（如共享配置、媒体素材库）的场景。

文件存储的优点是"符合直觉"：路径、权限、目录结构跟本地文件系统一样，应用几乎不用改就能迁移上来。缺点是性能和扩展性受协议与节点数限制，横向扩展能力不如对象存储。典型产品如 AWS EFS、Azure Files、Google Cloud Filestore。

三、工程实践要点

3.1 三种存储对比

3.2 选型决策树

面对"数据该放哪"，按下面顺序过一遍基本不会错：

⚠️ 常见坑：把数据库文件放进对象存储。对象存储的写入是"整体覆盖"，延迟又高，数据库每秒钟的小事务随机读写会直接卡死。数据库请交给块存储。

💡 关键直觉：选存储先问三个问题——"要挂载吗？要多机共享吗？数据有多大、多频繁读写？" 答案组合几乎总能落到这三种形态之一。

3.3 冷热分层与生命周期

对象存储还引入了一个概念叫"存储分层"：热数据（频繁访问）存在高性能档，冷数据（偶尔访问）存在便宜档，归档数据（几乎不访问）存在最便宜的档。云厂商通常提供生命周期规则，让对象在指定天数后自动从热档降级到冷档。这是一条几乎白拿的成本优化——只要数据有"越放越冷"的特征，就能自动省钱。第 3 章成本管理会再提到它。

四、数据湖与数据仓库：存储家族的另一支

在聊存储时，还有两个名字常被挂在嘴边：数据湖（Data Lake）与数据仓库（Data Warehouse）。它们不算"基础存储形态"，而是建立在对象存储之上的"数据组织形态"，这里先建立概念，第 2.6 节会展开。

数据湖是一个集中存放"所有类型数据"的地方——结构化、半结构化、非结构化，先存下来再说，格式和结构由后续使用方决定。它的底座几乎必然是对象存储，因为它要装下海量原始数据，成本还得压得下来。数据仓库则相反，它存的是"已经清洗、建模好的结构化数据"，为分析与报表服务，讲究的是查询性能。

两者的关系可以这样记：数据湖是"原料库"，什么生料都先收进来；数据仓库是"成品库"，只放洗好切好的半成品。很多团队的实际路径是"数据先进湖，处理后再进仓"。第 2.6 节会把这条流水线完整画出来。

五、常见问题（FAQ）

Q1：对象存储能替代文件存储吗？

看场景。如果应用只是"上传文件、按 URL 下载、不改动"，对象存储完全可以替代，且更省、更能扛量；如果应用依赖文件系统语义（目录遍历、就地修改、文件锁），对象存储就替代不了，得用文件存储。简单说：能改造成"URL 语义"的用对象存储，改不了的就用文件存储。

Q2：块存储的备份怎么做？

块存储通常支持快照（Snapshot）——对磁盘打一个时间点副本，可以随时回滚。快照本身也常存放在对象存储后端。生产数据库的常规做法是：定期快照 + 异地复制，确保数据有多个恢复点。第 3.5 节容灾会详细讲。

Q3：为什么对象存储读写会慢？

因为对象存储的架构是为"海量 + 低成本"设计的，元数据查找和网络往返决定了它不可能像本地盘那样低延迟。把"频繁随机读写的小数据"放对象存储，是用错了场景。它擅长的是"写一次、读多次、偶尔覆盖"的数据。

Q4：临时盘和持久盘有什么区别？

临时盘（ephemeral）附着在物理机上，性能好但机器故障或停止即丢失；持久盘（persistent）是独立于计算实例的网络存储，实例重启或迁移后数据仍在。生产数据必须用持久盘，临时盘只适合缓存、临时文件这类可重建的数据。

Q5：文件存储和块存储能互相转换吗？

通常不能直接转换，因为底层接口完全不同（文件协议 vs 块设备）。迁移需要借助工具把数据拷贝过去。所以选型时更要慎重——云上"换存储类型"往往是数据搬迁工程，不只是配置改一下。这也再次说明：第 3.1 节的"资源管理"里，把数据放对地方有多重要。

六、存储的可靠性真相

存储选型的另一面是可靠性——不是"存了就行"，而是"丢了能不能找回来"。云厂商会在产品说明里写"三个九""十一个九"这样的持久性承诺，但要理解背后的机制。

对象存储通常用多副本或纠删码实现持久性：数据写入时在多个可用区的不同设备上复制多份，个别设备故障不影响整体，丢失概率被压到极低。块存储用快照实现备份：对磁盘打时间点副本，数据损坏或误删时可回滚。文件存储则在协议层之上做多副本。

需要清醒的是：持久性承诺保护的是"硬件故障"，不保护"人为误删"和"应用 BUG"。 一个错误的删除命令、一个跑歪的批处理脚本，能让所有副本一夜之间同步消失。所以任何存储选型，都要配套"版本控制 + 定期备份 + 恢复演练"这三件事。这也是为什么成熟团队会把"备份是否可恢复"列为上线前的必查项——备份存在的意义是"能恢复"，而不是"有备份"这个动作本身。

要点串联

• 对象存储：按 URL 访问、海量扩展、成本低，适合图片/视频/日志/备份。
• 块存储：挂载式低延迟磁盘，适合虚拟机系统盘与数据库文件。
• 文件存储：多机共享目录，符合传统文件系统直觉，适合共享工作区。
• 访问方式差异：API / 块设备 / 文件协议，是三者最本质的区别。
• 性能与成本：块存储性能最高最贵，对象存储最便宜但延迟高。
• 选型口诀：要挂载要低延迟用块，要挂载要共享用文件，要海量便宜用对象。
• 冷热分层：对象存储自动降级冷数据，是低成本的账单优化手段。
• 数据湖与仓库：湖存原始料、仓存成品料，都是建立在对象存储之上的组织形态。
• 临时 vs 持久：生产数据必须用持久盘，临时盘只放可重建数据。

数据安放好了，还得让它们"连得通"——下一节讲网络服务，看看 VPC、负载均衡、DNS、CDN 怎么织起云的街道网。