最近折腾毕设，比较关注文件存储、传输方面的技术，更新网站的时候也有对接云存储相关的东西。

今天在 GitHub 发现了 MinIO，一个兼容 Amazon S3 云存储接口的对象存储开源实现。甚至还可以跑在树莓派上：Minio on a Raspberry Pi 3 with Raspbian (Debian Jessie 8.0) · christianbaun/ossperf Wiki

跑了一下 MinIO 的 Docker 镜像试用了一下，感受到它和我们日常用到的文件系统的一些差异。但我还不太了解它们具体的差别，找了点相关的资料，简单整理概括一下。这里主要讨论上层的抽象，不涉及具体的实现。

1. 数据的定义

之前我有整理过一篇博文，在香农的体系下，计算机最基本的数据单位是比特（bit），为了方便使用，现在的计算机中数据以 8位字节流（octet-stream）的形式来存储、交换和处理。

2. 块存储 Block Storage

在块存储中，数据以 block 为单位做抽象，一个 block 对应若干个 Byte，比如说我的电脑硬盘一个 block 是 4096 个字节。

有了 block 这个概念抽象，也就与底层硬盘的扇区、页等具体实现隔离。于是也可以通过类似 Raid、LVM 等技术做灵活的备份、调整、容错、性能优化等机制。

访问数据流程：block 地址 -> Block -> 具体数据

由于 block 每次存取的数据大小是固定的，面对长度不固定的数据并不灵活。我们一般不会直接操作块存储，而要依赖操作系统的文件系统去访问，有的数据库管理系统（DBMS）会直接通过块存储来存储数据。

3. 文件存储 File Storage

文件存储主要是依赖操作系统提供的 文件系统 的概念来组织数据，这是我们日常接触最多的。

文件系统提供了目录和文件这两个概念，用户基于这两个概念的抽象来实现数据的访问，具体背后的实现则由操作系统负责，可能基于块存储、基于网络、基于内存等等等等。

访问数据的流程：目录 -> ... -> 目录 -> 文件 -> 数据

目录 -> 文件 这个组合我们称为路径（Path）。然后上述流程可以理解为：路径 -> 文件 -> 数据

每一个文件还需要有描述对应 “属性” 的数据（metadata 元数据）（比如说 文件名、修改时间、属性、权限等），文件系统需要指定专门的地方保存它们，频繁读写元数据也是一个开销所在。

这个体系，适合日常大多数情况的数据的存取（比如说我们日常的电脑使用）。在大规模系统应用中存在一个问题：当小文件数目过多，文件系统的组织、元数据读写的开销就成了一个噩梦。

另一个问题是，它的存储机制重度依赖单机硬件，扩容的难度比较大。

4. 对象存储 Object Storage

对象存储简单地说，它把一段数据以一个对象（Object）的概念来看待，这个 Object 包括了具体内容的 字节流、描述这段数据的特征和权限的元数据，还有访问这段数据的 key。若干个 Object 的集合归属到一个 存储桶（Bucket）。

连接上存储桶后，访问数据的流程：key -> Object -> 数据。

在底层足够强大的前提下，一个存储桶理论上可以保存无限个这样的 Object，每个 Object 能保存的数据大小也可以是无限的。在扩容方面具有很大的优势。

云计算的厂商基于此提供存储服务，我们在使用对象存储的时候，虽然说能看到“文件”和“目录”的概念。但实际上是大家默认都把文件系统的 Path 与对象存储中的 key 的概念绑在了一起。这也是为什么对象存储没有“目录操作”的概念，所谓“目录”的形态，不过是 key 里面包含了分隔符 /。

在这个领域亚马逊是最早发力（2006 年）的，名字叫 Amazon Simple Storage Service，简称 Amazon S3，国内阿里云比较早做这块，对应的名字是 OSS （Object Storage Service）。

在接口设计方面，Amazon S3 可以说已经成为了事实标准，绝大部分云存储厂商都会提供 S3 API 的兼容，跟着喝汤。

块存储、文件存储、对象存储三者的大致形态可参考此图（来源）：

5. 参考