对象存储与块存储:哪个更好?

对象存储适合用户上传文件、静态资源、备份和归档——基本上是所有通过 HTTP 访问且很少原地修改的内容。块存储适合需要低延迟随机写入的场景：数据库、启动卷、高事务文件系统。对于文件传输工作负载，对象存储几乎总是正确选择，因为它横向扩展，成本约0.10-0.16元/GB/月，而块存储为0.56-0.88元/GB/月，且无需重新分区即可处理 PB 级存储桶。

底层的实际区别

块存储暴露一个原始设备（LUN 或 EBS 卷），由操作系统格式化为 ext4、XFS 或 NTFS。读写以固定大小的块（通常4KB或16KB）进行，通过 iSCSI、NVMe-oF 或 SCSI 传输。操作系统管理文件系统；块设备对文件一无所知，只知道偏移量。

对象存储暴露一个 HTTP API（S3、Azure Blob、GCS），每个对象有键、字节和元数据。底层没有文件系统——对象是原子单元，整个 PUT 和 GET。写入会生成新版本；你无法修改一个2GB对象的第1,000,000字节而不重写整个对象。这种不可变性是特性：它使多区域复制、版本控制和生命周期规则成为可能，而块存储很难匹配这些。

快速对比

| 维度 | 对象存储 | 块存储 | |------|----------|--------| | 典型 API | S3 HTTP REST | POSIX + iSCSI/NVMe | | 费用（AWS 热层） | $0.023/GB/月 | $0.08/GB/月（gp3） | | 单个最大单元 | 每对象5TB | 每个 EBS 卷64TiB | | 延迟 | 10-100毫秒 | 亚毫秒 | | 并发读取者 | 不限 | 通常一台主机 | | 耐久性承诺 | 11个9（S3） | 5-6个9（EBS） | | 适合 | 文件、媒体、备份 | 数据库、启动磁盘 | | 不适合 | 对大文件的随机写入 | 超过单卷的横向扩展 |

吞吐量与延迟：各有胜者

gp3 EBS 卷在1毫秒内响应4KB读取；S3 对同一4KB的 GET 需要20-80毫秒，取决于区域。对于每秒5000次事务的 PostgreSQL 预写日志，这个延迟差是致命的。对于用户下载500MB .zip 文件，这完全无关紧要，因为首字节延迟淹没在吞吐量中。

在顺序吞吐量方面，对象存储在规模上往往胜出。S3 每前缀支持5500次 GET 请求/秒，通过请求速率分区（哈希前缀键）可达数万次。单个 gp3 卷上限为1000MB/s 和16000 IOPS。对于10个并发用户下载一个10GB文件，对象存储让管道跑满；块存储则成为瓶颈。

规模成本

100TB冷热参半的媒体数据：

S3 Standard：$2,300/月
S3 Standard-IA：$1,250/月
S3 Glacier Instant Retrieval：$400/月
S3 Glacier Deep Archive：$99/月
EBS gp3：$8,000/月
EBS st1（吞吐量优化 HDD）：$4,500/月

块存储没有分层。你按峰值访问价格支付一年只碰一次的数据费用。对象存储生命周期规则自动移动对象：热层30天，Standard-IA 60天，90天后 Glacier。对于存储7天到期上传文件的文件传输服务，带 Expiration 规则的对象存储远比运行 EBS 支持的服务器便宜。

一致性与并发

S3 现在为 PUT 和 DELETE 提供全球强一致性的读后写。Azure Blob 和 GCS 同样如此。这消除了对象存储历史上的一个痛点——过去刚上传的文件可能有几秒的404。

但并发写入仍然重要。块存储通常假设单一写入者；多挂载模式存在但增加复杂性。对象存储允许百万客户端同时 PUT，以最后写入者优先语义（或版本控制保留所有版本）。对于两个用户可能以相同键上传不同文件的文件共享系统，存储桶上的版本控制可同时保留两者。

文件传输应用何时仍需要块存储

需要注意：提供对象存储服务的应用通常运行在块存储后端的主机上。文件上传 API 需要本地磁盘用于临时缓冲（分段块、病毒扫描）、元数据存储（通常在 EBS 上的 PostgreSQL）和日志。对象本身放入 S3/R2/Blob；围绕它们的机制运行在块存储上。

对于高吞吐量流式上传，内存管道比磁盘更好。aws-sdk-js 和 boto3 等库支持从不碰本地磁盘的流式分段上传。调优良好的上传服务可以用不到500MB RAM 和零临时文件，将5GB文件从客户端推送至对象存储。

元数据：被忽视的差异

对象存储随每个对象携带元数据：系统元数据（大小、mtime、etag）、用户元数据（任意键值对，x-amz-meta-* 头部）和标签。你可以通过 S3 Object Lambda、Inventory 报告或与 DynamoDB 配合按元数据搜索。块存储将元数据完全留给文件系统，这意味着给1000万个文件打标签需要一个自定义数据库。

对于需要即时回答"找出上周法国用户上传的所有超过100MB文件"的传输应用，对象元数据加 Parquet 清单让你用 Athena 在秒级查询。对 NFS 挂载的块卷问同样的问题，是一个需要数小时的 find 命令。

加密与访问控制

两种存储类型都支持 AES-256 静态加密。对象存储使得每对象访问控制更简单：存储桶策略、预签名 URL、对象 ACL 和 IAM 条件。块存储访问更粗粒度——整个卷附加或不附加。

对于带时间限制下载链接的安全文件共享，预签名 S3 URL（最长有效期7天）是标准方案。对于零服务端明文暴露的传输，上传前进行客户端加密适用于任何对象存储。HexaTransfer 在浏览器中用 AES-256-GCM 加密，只存储密文——对象后端看到的是无意义字节。

简单决策规则

问三个问题：

你通过文件系统 API（POSIX、SMB、NFS）访问数据吗？如果是，选块存储或文件存储。
你通过 HTTP 访问，很少原地修改，且需要无限扩展吗？如果是，选对象存储。
数据集超过10TB且仍在增长吗？几乎必然选对象存储。

对于文件传输工作负载，第2个问题的答案永远是肯定的。用 S3、R2、Azure Blob 或 GCS 存文件本身，块存储留给管理它们的数据库和 Web 层。

免费试用 hexatransfer.com——无需注册，单次最大10GB。