从读写模型看对象存储（OSS）与文件存储的本质差异——以及在 Docker 与向量数据库场景下如何正确选择

: john 在知识的海洋中遨游

0 人点赞了该文章 · 59 浏览

一、为什么“对象存储 vs 文件存储”总是被讲糊？

网络上常见的说法是：

“对象存储适合存图片、视频
文件存储适合存数据库文件”

这句话并不错误，但极其不完整，甚至会在真实工程中误导选型。

因为问题的核心根本不在于：

存的是不是图片
是不是数据库文件

而在于：

你的系统“如何读写这些数据”

存储系统，本质上是对“读写模型”的抽象。

二、先把概念彻底澄清：对象 ≠ 文件类型

一个常见但错误的疑问是：

图片文件不也是对象吗？
数据库文件不也是对象吗？

是的，它们都可以是“对象”。

但这里的“对象”指的是：

存储模型里的对象（Object）
而不是编程语言里的对象
也不是文件类型意义上的对象

对象存储中的「对象」由三部分组成：


Object = 数据（Binary） + 元数据（Metadata） + 唯一 Key

数据：一整块二进制（JPG / MP4 / ZIP / DB 备份）
元数据：标签、类型、业务信息
Key：唯一访问标识（通常映射为 URL）

👉 对象存储不理解“文件内部结构”
👉 它只理解“完整对象”

三、真正的本质区别：从「读写模型」看

1️⃣ 文件存储：为“持续读写”而生

文件存储（本地磁盘 / 云盘 / NFS）遵循的是操作系统文件模型：

有目录结构
有路径
支持：
- 随机读
- 随机写
- 文件锁
- 写入偏移
- 部分修改

你可以：


打开文件 → 移动指针 → 写 4KB → fsync → 关闭

📌 这是数据库、程序运行、索引系统的基础

2️⃣ 对象存储：为“整体存取”而生

对象存储遵循的是HTTP / API 模型：

没有目录（目录只是 Key 的“假象”）
没有文件锁
没有随机写
更新 = 整个对象重新上传

操作模型是：


PUT Object
GET Object
DELETE Object

📌 一次操作 = 一个完整对象

🔥 核心对比（决定选型的表）

维度	文件存储	对象存储（OSS）
随机读写	✅ 强	❌ 不支持
部分更新	✅	❌
文件锁	✅	❌
并发扩展	一般	极强
延迟	低	稍高
成本	较高	低
访问方式	POSIX / 挂载	HTTP / API
适合场景	程序运行态数据	归档 / 分发数据

四、什么时候选 OSS？什么时候选文件系统？

✅ 选择对象存储（OSS）的典型场景

你只要满足其中任意两条，就应该认真考虑 OSS：

数据写一次，读多次
很少或不会修改
需要大规模分发
数据量巨大
成本敏感
不需要强一致的随机写

📌 典型例子：

图片、视频、音频
模型权重（AI）
向量数据快照 / 冷数据
日志归档
数据库备份文件
数据集（Dataset）

✅ 选择文件存储的典型场景

只要涉及“运行态数据”，几乎必选文件系统：

数据库正在使用的数据文件
程序运行时需要频繁写入
索引文件
WAL / 日志文件
需要锁和一致性保证

📌 典型例子：

MySQL / PostgreSQL
Redis（AOF / RDB）
Elasticsearch
向量数据库的索引区

五、Docker 横行时代：持久化存储该怎么选？

Docker 的一个残酷现实

容器是“一次性的”，数据不能是

所以必然涉及：

Docker Volume / Bind Mount 的选择

❌ 一个常见误区

“Docker 里能不能直接把数据写到 OSS？”

结论：不行（至少不能作为主存储）

原因不是技术能不能，而是：

Docker 内的程序，几乎全部假设底层是“文件系统”

Docker + 存储的正确打开方式

✅ 场景 1：Docker 里跑 MySQL / PostgreSQL

必须选择文件系统


Docker Container
   |
   |-- /var/lib/mysql
           |
           -> 本地磁盘 / 云盘 / NAS

❌ 不能是 OSS
✔ 可以是云块存储 / NFS / 本地 SSD

✅ 场景 2：Docker 里跑 Web / API 服务


Docker
 ├── 运行态数据 → 文件系统
 └── 静态资源 → OSS

用户上传图片 → OSS
程序配置 / cache → 文件系统

六、关键问题：如果 Docker 部署的是「向量数据库」呢？

我们需要拆成两层来看。

1️⃣ 向量数据库内部到底存什么？

以 Milvus / Qdrant / Weaviate 为例：

向量原始数据
索引文件（HNSW / IVF / PQ）
WAL / 日志
元数据

👉 这些都是高频随机读写数据

2️⃣ 结论（非常重要）

❌ 向量数据库的“主存储”不能是 OSS
✅ 必须是文件系统

否则会出现：

索引构建失败
查询延迟极高
数据一致性问题
WAL 不可用

3️⃣ 那 OSS 在向量数据库里有没有用？

有，而且非常重要，但角色不同。

正确架构是：


向量数据库（Docker）
 ├── 活跃索引 / WAL → 文件系统
 ├── 冷数据 / 分片快照 → OSS
 └── 备份 / 迁移 → OSS

📌 Milvus 官方架构本身就是：

Compute + Local Disk
Object Storage = Data Lake

七、一句话总结

对象存储（OSS）不是文件系统的替代品，而是文件系统的“上游与下游”。
凡是程序“正在运行、频繁读写、依赖一致性”的数据，必须放在文件系统中；
凡是“生成后长期保存、分发、备份、归档”的数据，才适合放入对象存储。
在 Docker 与向量数据库场景下，对象存储更多承担的是数据湖、冷存储与备份角色，而不是运行态存储。