桶与对象
对象存储只有两层结构：桶是一个扁平的命名空间，对象由键、数据和元数据三部分组成。没有真正的目录，控制台里看到的「文件夹」只是键名里用斜杠拼接出来的前缀。这个模型带来两个直接后果：对象只能整体写入或整体替换，不能像文件那样追加；而海量对象的检索与列举能力，取决于元数据索引的设计而不是目录树。
基本信息
| 核心结构 | 桶 bucket + 对象 object（键、数据、元数据） |
|---|---|
| 访问方式 | HTTP REST 接口，主流实现兼容 S3 协议 |
| 数据分布 | 按键的哈希分散到存储节点，与目录无关 |
| 典型实现 | S3、兼容 S3 的私有对象存储、MinIO 等 |
典型使用场景
- 图片、视频、备份包等非结构化数据的长期存放
- 静态网站与 CDN 源站：对象可缓存、可整块分发
- 数据湖存储层：海量小文件与列式文件统一存放
- 日志与归档：写入即不可变，适合批量清理与生命周期策略
- 应用间数据交换：用预签名链接代替账号权限直连
键与前缀的关系
键与前缀的关系
# 键（Key） -> 真实结构是扁平的一条记录
logs/2026/10/17/app-1.log
logs/2026/10/17/app-2.log
# 控制台显示的目录层级是前缀（Prefix）模拟的视图
# 列举时用前缀过滤，例如 prefix=logs/2026/10/与文件系统的差异
| 能力 | 对象存储 | 传统文件系统 |
|---|---|---|
| 目录语义 | 无，用前缀模拟 | 真实目录树 |
| 修改方式 | 整体替换对象 | 可随机写与追加 |
| 重命名 | 复制加删除，不是原地操作 | 元数据操作，代价低 |
| 扩展方式 | 横向加节点 | 受单机与卷规模限制 |
建模时的关键判断
- 对象是否需要频繁修改：需要就地更新就说明它更适合放在块设备或数据库
- 键的前缀如何设计：直接决定列举性能与能否按业务批量筛选
- 元数据放在键里还是对象的元数据字段：前者可被前缀筛选，后者检索代价更高
- 是否需要版本化：开启后删除与覆盖都会留下历史版本，容量与成本口径随之变化
- 访问模式是顺序大文件还是海量小文件：两者对存储层的要求完全不同
对象的元数据规模常比数据本身更早成为瓶颈：设计键结构时就要考虑单桶对象数量级与列举频率。
多数实现允许用分隔符把前缀列举成层级视图，这只是服务端对键名的切分，不改变底层扁平结构，也不产生额外的目录对象。