对象存储基础概念

1、对象存储基础概念对象存储诞生之初谈到为什么要有对象存储，必须聊聊 对象存储诞生之前的两大存储模型：块存储和文件存储。 块存储主要是将存储介质的空间整个映射给主机使用的，主 机如果需要对这些空间进行读写 IO 操作，需要先进行分区 和格式化处理，形成可以被操作系统识别的逻辑命名空间， 之后主机才能通过操作系统对这些存储介质进行读写操作。 常见的块存储有磁盘， SSD，NAS 、SAN 等，这些物理设备 都或多或少存在物理上的极限，比如存储空间、性能等都存 在物理极限。 文件存储立足于物理存储介质之上，是操作系统对数据管理 操作的抽象，这些抽象最终汇总形成文件系统。一般我们提 到的文件系统都遵循

2、POSIX 标准，而 POSIX 标准定义了操 作系统应该为其上运行的应用程序提供的接口标准。基于这 套接口标准，我们可以非常方便的将数据以文件、文件夹方 式进行管理，但是常见的文件系统都是按目录树进行管理， 在互联网数据爆炸时代，随着文件目录层级不断增加，亦或 是文件数量达到海量以后，文件管理成本会直线飙升，特别 是一些遍历操作会变得非常低效，因此文件存储在面对海量 数据的时候有些力不从心。介绍完块存储和文件存储以后，终于轮到对象存储出场，那 对象存储又是如何克服块存储和文件存储的短板？在介绍 对象存储之前，需要各位特别注意的就是对象存储天生就带 互联网基因，完美适配当前互联网场景下的各种爆

3、炸式数据 需求 ,具体表现为：扁平化的命名空间将数据以对象(Object)形式存储在以桶(Bucket)为命名空间的 两级结构中， 通过新增 Bucket 方式来横向扩展命名空间， 同 时通过在 Bucket 中不断新增 Object 方式来实现海量数据的 存储，这种扁平化的数据管理模型克服了目录树管理的不 足，实现了海量数据简单有效的管理。需要注意的是 Bucket 的名称全局唯一， 通过桶名称 (Bucket name) 对象的键名 (Key name)来定位一个对象的最终存储路径。分布式构架设计 借助扁平化的管理模型设计，使得整个对象存储系统可以按 命名空间规则进行底层数据存储的分区，借

4、助一些哈希算法 最终将需要存储的数据按分区规则均匀分布到多个主机的 多块磁盘上，从而实现数据的分布式存储，从而解决了物理 硬件的扩容及性能问题，为海量数据的存储铺平道路。通用 化的接口标准 在解决了海量数据管理和硬件短板的问题之后，对象存储还 要克服一个关键的问题 :如何实现通用接口标准？通用接口 标准对一个对象存储系统来说至关重要，这个是整个系统与 外围系统打交道的重要窗口。如何兼容各种外围系统，去适配各种开发语言，形成一套围绕对象存储系统的生态标准？ 同样遵循“ Simple is best ！”思想，互联网时代 HTTP 大行其 道，到处都通行的 RESTful 风格被对象存储“一眼相中

5、” ， 目前主流的对象存储在接口标准的实现上都提供 RESTful 风 格的 API ，同时也衍生出各种语言的 SDK ，当然有些对象存 储也实现了 RPC、SOAP 等标准， 这里篇幅有限就不再赘述。 (非)结构化数据与对象存储什么是结构化数据和非结构化数 据?以大家熟知的关系型数据库场景为例： 将一个人的属性抽象出来，分为姓名(name),年龄(age),住址(address)邮箱(email)几个标签，之后将这些信息存储到数据 库中，那么某个人将对应到数据库里的一条记录。 众所周知， 我们现在熟知的数据库主要是关系型数据库，如果能够将数 据按关系模型进行存储和管理，那么这一类数据就是结构

6、化 数据。与之相对立的就是非结构化数据。如果上面需要存储的数据 新增了一个相片(photo)字段，用于存储用户的相片数据，因 为相片数据无法通过关系型数据进行描述，所以一般存储相 片都是以二进制方式 (非结构化方式 )存储在关系数据库中， 但是传统数据库不是万能。当需要比较多张相片的相似度， 并删除重复相片，特别是需要管理海量相片的时候，传统的 关系型数据库，会让你觉得异常痛苦。 对象存储正是为了弥补传统关系型数据库在管理非结构化数据方面的不足。在对象存储模型中，将每一条存储在其中 的非结构化数据抽象成一个“对象” ，一个对象 (Object) 主要 由下面四部分组成 : 键名 (Key):

7、用于标识对象的名称，通过 Bucket name Key 的组合来确定对象最终存储路径。键值 (Value): 用于存储对象的内容数据。 访问控制列表 (ACL): 标识 对象可以被哪些用户或者用户组访问。元数据 (Metadata): 用 于以 key-value 形式存储对象其他额外信息， 比如对象内容的 MD5 校验值，对象的属主 (owner )， atime/ctime/mtime 等。 再来看一下我们熟悉的文件系统下一个文件都有哪些属性 ,以 Linux 下面使用 stat 和 md5sum 命令查看 ceph.conf 例 rootdemo:/home/user# stat ce

8、ph.confFile: ceph.conf Blocks: 8IO Block:Inode: 1409Links: 1Uid: ( 0/root) Gid:Size: 25344096 regular file Device: fe21h/65057d Access: (0644/-rw-r-r-) ( 0/ root)Access: 2016-09-19 06:25:02.294973380 0800Modify: 2017-03-17 11:20:13.736611814 0800Change: 2017-03-17 11:20:13.736611814 0800 Birth: -roo

9、tdemo:/home/user# md5sum ceph.conf1f3695479cf9198e318cd930b91ab97d ceph.conf 通过上面的命令可以很轻松的看到文件的ACL 、MD5 、atime/ctime/mtimed 等，接下来就是将文件系统的这些内容转 换成对象存储里面相应的属性即可， 这里使用一个 s3cmd 工 具实现对象存储的上传，具体操作及效果如下 rootdemo:/home/user# s3cmd put ceph.conf s3:/my-bucket ceph.conf -> s3:/my-bucket/ceph.conf 1 of 1253

10、4 of 2534 100% in0s31.61 kB/s doneceph.conf -> s3:/my-bucket/ceph.conf 1 of 12534 of 2534 100% in0s34.84 kB/s donerootdemo:/home/user# s3cmd info s3:/my-bucket/ceph.conf s3:/my-bucket/ceph.conf (object):File size: 2534Last mod: Tue, 14 Nov 2017 06:45:37 GMTMIME type: text/plainMD5 sum: 1f3695479cf9198e318cd930b91ab97dSSE:nonecors: noneACL:s3user: FULL_CONTROLx-amz-meta-s3cmd-attrs: uid:0/gname:root/uname:root/gid:0/mode:33188/mtime:1489720 813/atime:1474237502/md5:1f36954