共计 4695 个字符，预计需要花费 12 分钟才能阅读完成。
Part 1 引言
从结绳记事到竹简成书，再到纸张的呈现，数据记录形式的变革随同着人类文明的每一个提高。随着计算机和通信技术的倒退，人类产生和共享数据的速率呈指数级增长。如何无效的保留和治理这些数据是计算机存储技术首先要解决的问题。很多人都听过对象存储这种说法，然而到底什么是对象存储？对象存储如何实现呢？
Part 2 对象存储
01 什么是对象存储？
对象存储 (Object Storage) 不是新技术，很多人都听过对象存储这种说法，然而到底什么是对象存储？这个问题可能会让一些人手足无措。除了对象存储，你可能还据说过文件存储 (File Storage) 和块存储(Block Storage)，咱们把三者放在一起比拟：
1. 文件存储 – 数据保留在文件中，按目录（文件夹）进行组织，当须要拜访文件时，用户须要晓得它残缺的门路；
2. 块存储 – 块存储提供了文件存储的代替计划，它将文件分成大小相等的数据块，而后将数据块存储在惟一的地址。块存储能够提供比文件存储更好的性能；
3. 对象存储 – 对象存储不应用文件夹、目录或更简单的层次结构，每个文件作为一个对象保留在扁平的命名空间中。
实质上，文件存储、块存储和对象存储是不同的数据拜访模式，它们别离适宜于不同类型的数据：
文件存储和块存储非常适合解决结构化数据；
对象存储实用于解决大量非结构化数据的数据。
明天的互联网通信数据很大水平上是非结构化的，包含电子邮件、视频、照片、网页、音频文件以及其余类型的媒体和 Web 内容。这些内容从社交媒体、搜索引擎、挪动设施和“智能”设施源源不断地流出。
市场钻研公司 IDC 预计，到 2025 年，非结构化数据可能占寰球所有数据的 80%。
基于对象的存储已成为数据归档和备份的首选办法，它能够提供传统基于文件或基于块的存储无奈提供的可扩展性。
02 对象存储工作形式
对象 (Object) 保留在扁平的命名空间中，没有文件夹、目录或简单的层次结构。
对象数据分为数据 (data) 和元数据 (metadata) 两局部，每个对象都有惟一的标识符 (ID)，用于定位和拜访对象。
对象存储系统提供基于 HTTP 的 RESTful 服务，用户通过 HTTP 命令拜访对象存储，例如 PUT 或 POST 上传对象，GET 检索对象，DELETE 删除对象。
此外，还有其余 RESTful API 规范，容许用户治理对象存储、帐户、多租户、安全性、计费等。
基于对象的存储人造符合以后云原生畛域蓬勃发展的趋势，是存储、归档、备份和治理大量动态或非结构化数据的现实解决方案。
Part 3 对象存储实现
计算机存储技术涵盖宽泛的领域，从存储硬件到存储网络，从操作系统到分布式系统。
一个性能齐备的存储系统须要思考数据的可用性、一致性和持久性，须要具备灾备和恢复能力，并且运维敌对。
要把这些说分明，大略须要“一千零一夜”，好在业界有不少成熟的计划，上面咱们通过剖析一些开源我的项目的架构来理解对象存储系统是如何实现的。
01 对象存储开源我的项目
基于对象的存储系统，业界有几种可用的开源解决方案，例如 Ceph、MinIO、Openio.io、OpenStack Swift 等等。
这些我的项目在其性能上不尽相同，然而都有雷同的设计指标——实现非结构化数据的大规模存储。
在对象存储的倒退中，有两个对象存储协定值得一提：Swift 和 S3 (Simple Storage Service)。前者源于 OpenStack 我的项目，后者来自于 Amazon 公司。
现在作为对象存储协定，Swift 很少被提及，而 Amazon 的 S3 曾经成为业界的事实标准，每个对象存储系统都会提供与 Amazon S3 RESTful API 兼容的服务。
例如，OpenStack Swift 除了提供本人的 Swift Open API 和一些独特的性能，还反对 Amazon 的 S3 API；Ceph 对象存储和 Openio.io 与 S3 兼容。
02Ceph 存储系统实现
基于同一套存储基础设施，Ceph 同时提供了文件、块、对象三种数据拜访接口，Ceph 逻辑档次如下图所示：
- RADOS 自身是一个残缺的对象存储系统，所有存储在 Ceph 中的数据最终都是由这一层来存储的。Ceph 的高牢靠、高可扩大、高性能、高自动化等个性，实质上也是由这一层提供的；
- LIBRADOS 是对 Ceph 客户端与 RADOS 集群交互协定的封装，基于 librados，咱们能够创立本人的客户端；
- RADOS GW、RBD、CEPH FS 属于高层接口，它们在 librados 库的根底上别离提供对象存储接口、文件接口和块存储接口。
其中 RADOS GW 为利用拜访 Ceph 集群提供了一个与 Amazon S3 和 Swift 兼容的 RESTful 格调的网关，其逻辑档次如下：Ceph RADOS 存储集
RADOS 集群次要有两种节点 ：为数众多的 OSD 节点，负责实现数据的存储和保护；若干 Monitor 节点，负责实现零碎状态检测和保护。
OSD 和 Monitor 之间相互传递节点的状态信息，独特得出零碎的总体运行状态。
而依据集群总体运行状态，基于 CRUSH 算法，用户上传的数据通过层层映射，最终会送到不同的 OSD 下面：
- 用户上传的数据被切割为固定大小的分片；
- 依据规定，每个数据分片都有其惟一的 ID，每个数据分片独立的映射到不同的逻辑归置组(PG)；
- 基于 CRUSH 算法，确定逻辑归置组锁对应的 OSD。
Ceph ObjectStore
数据切片后，最终会落到不同的 OSD 上，Ceph OSD 通过 ObjectStore 实现数据的理论存储。ObjectStore 由不同的实现形式，有 FileStore、BlueStore、MemStore 等等。
其中 MemStore 次要用于测试目标。
FileStore 基于 Linux 现有的文件系统，利用传统的文件系统操作实现 ObjectStore API：每个 Object 被 FileStore 看做是一个文件，Object 的属性会作为文件的属性 (xattr) 存取，而超出文件系统限度的属性会作为 omap 存储。
FileStore 最后是针对机械盘设计的，写数据之前先写 journal 带来了写放大问题。为了解决 FileStore 存在的问题，Ceph 社区推出了 BlueStore。
BlueStore 去掉了 journal，通过间接治理裸设施的形式来缩小文件系统的局部开销。
和传统的文件系统一样，BlueStore 由 3 个局部组成：数据管理、元数据管理、空间治理(Allocator)。
BlueStore 不再基于本地文件系统，而是间接治理裸设施，为此在用户态实现了 BlockDevice，应用 Linux AIO 间接对裸设施进行 I / O 操作，并实现了 Allocator 对裸设施进行空间治理。
BlueStore 的元数据则以 Key/Value 的模式保留在 KV 数据库中，默认 RocksDB。但 RocksDB 并不是基于裸设施进行操作的，而是基于文件系统进行操作的，为此 BlueStore 还实现了一个小的文件系 BlueFS。
- Ceph 的强一致性实现依赖于 RocksDB 提供的事务个性。
03 OpenStack Swift 存储系统实现
Swift 架构能够划分为两个档次：拜访层(Access Tier) 和存储层(Storage Nodes)。
拜访层的性能相似于网络设备中的 Hub，次要负责 RESTful 申请的解决与用户身份的认证。
存储层由一系列的物理存储节点组成，负责对象数据的存储。
- Storage Node 上存储的对象在逻辑上分层 3 个档次：Account、Container 以及 Object。为了对应这 3 个档次，每个 Storage Node 上运行了 3 种服务：
- Account Server – 提供 Account 相干服务，包含 Container 列表以及 Account 的元数据等。Account 的信息被存储在一个 SQLite 数据库中；
- Container Server – 提供 Container 相干服务，包含 Object 列表以及 Container 的元数据。Conainer 的信息也被存储在一个 SQListe 数据库中；
- Object Server – 提供 Object 的存取和元数据服务。对象的内容以二进制文件的模式存储在文件系统中，元数据作为文件的扩大属性来存储。
为了保证数据在某个存储硬件损坏的状况下也不会失落，Swift 为每个对象建设了肯定数量的正本，默认为 3，并将每个正本放在不同的逻辑区域中。
Swift 通过 3 种服务来解决数据一致性问题： - Auditor – 继续扫描磁盘查看 Account、Container 和 Object 的完整性，如果发现数据有损坏的状况，就会对文件进行隔离，而后通过 Replicator 从其余节点上获取对应的正本以复原本地数据；
- Updater – 创立一个 Container 或者 Object 时，更新 SQLite 中相应的信息。更新并不总是胜利，对于那些没有胜利更新的操作 Swift 会通过 Updater 服务持续解决；
- Replicator – 负责检测各个节点上的数据及其正本是否统一，当发现不统一时会将过期的正本更新为最新版本，并负责将标记为删除的数据真正从物理介质上删除。
Swift 通过 Consistent Hash Ring 来实现对集群中物理节点的治理。因为没有条带化，Swift 解决几个 G 的大文件时性能会比拟差，不过作为对象存储，Swift 的劣势在于它能与 OpenStack 社区的其余我的项目无缝联合。
Part 4 结语
计算机世界里没有“银弹”，任何设计都有其取舍，存储系统亦是如此。基于其特定的利用场景，不同的存储实现提供了不同的数据拜访形式以及存储能力。
然而实质上，所有的存储系统都在解决“数据如何保留”和“数据如何拜访”的问题。只管 Ceph 和 OpenStack Swift 呈现已久，然而它们的设计仍值得借鉴。本文仅剖析了 Ceph 和 OpenStack Swift 的宏观架构，感兴趣的敌人能够从文章开端给出的参考链接中获取更多细节。
目前，矩阵起源的对象存储正在设计和原型阶段，将来还会分享咱们在这方面的一些实际，敬请关注。
Part 5 参考链接
- IBM Cloud Learn Hub: Object Storage [https://www.ibm.com/cloud/lea…]* Object Storage: Everything You Need to Know [https://lakefs.io/object-stor…]
- Amazon S3 REST API Introduction [https://docs.aws.amazon.com/A…]
- OpenIO on Github [https://github.com/open-io]
- Ceph on Github [https://github.com/ceph/ceph]
- Ceph Documents [https://docs.ceph.com/en/latest/]
- Swift Document [https://docs.openstack.org/sw…]
- Linux 开源存储全栈详解 [https://book.douban.com/subje…]
作为一家数据库守业公司，矩阵起源在数据库方面会集了泛滥经验丰富的工程师，分布式数据库内核开发波及计算引擎、存储引擎和分布式这几个方面。
那这篇讲对象存储的文章会不会有些“偏题”？对象存储和存储引擎是一回事吗？首先它们都跟存储无关，然而各自要解决的问题不同，因此在技术上也各有偏重。对象存储和存储引擎都是比拟大的话题，这篇文章作为铺垫是适合的。
在前面的文章中，咱们会持续把对象存储和存储引擎放在一起做个简略的比拟。
