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...]
    作为一家数据库守业公司，矩阵起源在数据库方面会集了泛滥经验丰富的工程师，分布式数据库内核开发波及计算引擎、存储引擎和分布式这几个方面。
    那这篇讲对象存储的文章会不会有些“偏题”？对象存储和存储引擎是一回事吗？首先它们都跟存储无关，然而各自要解决的问题不同，因此在技术上也各有偏重。对象存储和存储引擎都是比拟大的话题，这篇文章作为铺垫是适合的。
    在前面的文章中，咱们会持续把对象存储和存储引擎放在一起做个简略的比拟。