对象存储基础概念
摘要: 块存储主要是将存储介质的空间整个映射给主机使用的，主机如果需要对这些空间进行读写IO操作，需要先进行分区和格式化处理，形成可以被操作系统识别的逻辑命名空间，之后主机才能通过操作系统对这些存储介质进行读写 ...
块存储主要是将存储介质的空间整个映射给主机使用的，主机如果需要对这些空间进行读写IO操作，需要先进行分区和格式化处理，形成可以被操作系统识别的逻辑命名空间，之后主机才能通过操作系统对这些存储介质进行读写操作。常见的块存储有磁盘，SSD，NAS、SAN等，这些物理设备都或多或少存在物理上的极限，比如存储空间、性能等都存在物理极限。
文件存储立足于物理存储介质之上，是操作系统对数据管理操作的抽象，这些抽象最终汇总形成文件系统。一般我们提到的文件系统都遵循POSIX标准，而POSIX标准定义了操作系统应该为其上运行的应用程序提供的接口标准。基于这套接口标准，我们可以非常方便的将数据以文件、文件夹方式进行管理，但是常见的文件系统都是按目录树进行管理，在互联网数据爆炸时代，随着文件目录层级不断增加，亦或是文件数量达到海量以后，文件管理成本会直线飙升，特别是一些遍历操作会变得非常低效，因此文件存储在面对海量数据的时候有些力不从心。
介绍完块存储和文件存储以后，终于轮到对象存储出场，那对象存储又是如何克服块存储和文件存储的短板？在介绍对象存储之前，需要各位特别注意的就是对象存储天生就带互联网基因，完美适配当前互联网场景下的各种爆炸式数据需求,具体表现为：
扁平化的命名空间将数据以对象(Object)形式存储在以桶(Bucket)为命名空间的两级结构中，通过新增Bucket方式来横向扩展命名空间，同时通过在Bucket中不断新增Object方式来实现海量数据的存储，这种扁平化的数据管理模型克服了目录树管理的不足，实现了海量数据简单有效的管理。需要注意的是Bucket的名称全局，通过桶名称(Bucket name)+对象的键名(Key name)来定位一个对象的最终存储路径。
分布式构架设计借助扁平化的管理模型设计，使得整个对象存储系统可以按命名空间规则进行底层数据存储的分区，借助一些哈希算法最终将需要存储的数据按分区规则均匀分布到多个主机的多块磁盘上，从而实现数据的分布式存储，从而解决了物理硬件的扩容及性能问题，为海量数据的存储铺平道路。
通用化的接口标准在解决了海量数据管理和硬件短板的问题之后，对象存储还要克服一个关键的问题:如何实现通用接口标准？通用接口标准对一个对象存储系统来说至关重要，这个是整个系统与外围系统打交道的重要窗口。如何兼容各种外围系统，去适配各种开发语言，形成一套围绕对象存储系统的生态标准？同样遵循“Simple is best！”思想，互联网时代HTTP大行其道，到处都通行的RESTful风格被对象存储“一眼相中”，目前主流的对象存储在接口标准的实现上都提供RESTful风格的API，同时也衍生出各种语言的SDK，当然有些对象存储也实现了RPC、SOAP等标准，这里篇幅有限就不再赘述。
(非)结构化数据与对象存储什么是结构化数据和非结构化数据?以大家熟知的关系型数据库场景为例：将一个人的属性抽象出来，分为姓名(name),年龄(age),住址(address),邮箱(email)几个标签，之后将这些信息存储到数据库中，那么某个人将对应到数据库里的一条记录。众所周知，我们现在熟知的数据库主要是关系型数据库，如果能够将数据按关系模型进行存储和管理，那么这一类数据就是结构化数据。
与之相对立的就是非结构化数据。如果上面需要存储的数据新增了一个相片(photo)字段，用于存储用户的相片数据，因为相片数据无法通过关系型数据进行描述，所以一般存储相片都是以二进制方式(非结构化方式)存储在关系数据库中，但是传统数据库不是万能。当需要比较多张相片的相似度，并删除重复相片，特别是需要管理海量相片的时候，传统的关系型数据库，会让你觉得异常痛苦。对象存储正是为了弥补传统关系型数据库在管理非结构化数据方面的不足。在对象存储模型中，将每一条存储在其中的非结构化数据抽象成一个“对象”，一个对象(Object)主要由下面四部分组成:
键名(Key):用于标识对象的名称，通过Bucket name+ Key的组合来确定对象最终存储路径。键值(Value):用于存储对象的内容数据。访问控制列表(ACL):标识对象可以被哪些用户或者用户组访问。元数据(Metadata):用于以key-value形式存储对象其他额外信息，比如对象内容的MD5校验值，对象的属主(owner），atime/ctime/mtime等。再来看一下我们熟悉的文件系统下一个文件都有哪些属性,以Linux下面使用stat和md5sum命令查看ceph.conf文件为例
root@demo:/home/user# stat ceph.conf File: ‘ceph.conf’ Size: 2534 Blocks: 8 IO Block: 4096 regular fileDevice: fe21h/65057d Inode: 1409 Links: 1Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 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: -root@demo:/home/user# md5sum ceph.conf1f3695479cf9198e318cd930b91ab97d ceph.conf通过上面的命令可以很轻松的看到文件的ACL、MD5、atime/ctime/mtimed等，接下来就是将文件系统的这些内容转换成对象存储里面相应的属性即可，这里使用一个s3cmd工具实现对象存储的上传，具体操作及效果如下
root@demo:/home/user# s3cmd put ceph.conf s3://my-bucket'ceph.conf' -> 's3://my-bucket/ceph.conf' [1 of 1] 2534 of 2534 100% in 0s 31.61 kB/s done'ceph.conf' -> 's3://my-bucket/ceph.conf' [1 of 1] 2534 of 2534 100% in 0s 34.84 kB/s doneroot@demo:/home/user# s3cmd info s3://my-bucket/ceph.confs3://my-bucket/ceph.conf (object): File size: 2534 Last mod: Tue, 14 Nov 2017 06:45:37 GMT MIME type: text/plain MD5 sum: 1f3695479cf9198e318cd930b91ab97d SSE: none cors: none ACL: s3user: FULL_CONTROL x-amz-meta-s3cmd-attrs: uid:0/gname:root/uname:root/gid:0/mode:33188/mtime:1489720813/atime:1474237502/md5:1f3695479cf9198e318cd930b91ab97d/ctime:1489720813通过上面的介绍，相信大家已经对对象存储已经有所了解。那么如何解决快速删除重复相片的问题？只需要将每张相片存储在对象存储中，同时以元数据方式记录对应的MD5值，在不读取图片内容的情况下，通过比较每个对象的MD5值是就能快速的筛选出重复的相片。
管理 数据库 模型 存储 Hadoop
对象存储诞生之初谈到为什么要有对象存储，必须聊聊对象存储诞生之前的两大存储模型：块存储和文件存储。块存储主要是将存储介质的空间整个映射给主机使用的，主机如果需要对这些空间进行读写IO操作，需要先进行分区和格式化处理，形成可以被操作系统识别的逻辑命名空间，之后主机才能通过操作系统对这些存储介质进行读写操作。常见的块存储有磁盘，SSD，NAS、SAN等，这些物理设备都或多或少存在物理上的极限，比如存储空间、性能等都存在物理极限。
文件存储立足于物理存储介质之上，是操作系统对数据管理操作的抽象，这些抽象最终汇总形成文件系统。一般我们提到的文件系统都遵循POSIX标准，而POSIX标准定义了操作系统应该为其上运行的应用程序提供的接口标准。基于这套接口标准，我们可以非常方便的将数据以文件、文件夹方式进行管理，但是常见的文件系统都是按目录树进行管理，在互联网数据爆炸时代，随着文件目录层级不断增加，亦或是文件数量达到海量以后，文件管理成本会直线飙升，特别是一些遍历操作会变得非常低效，因此文件存储在面对海量数据的时候有些力不从心。
介绍完块存储和文件存储以后，终于轮到对象存储出场，那对象存储又是如何克服块存储和文件存储的短板？在介绍对象存储之前，需要各位特别注意的就是对象存储天生就带互联网基因，完美适配当前互联网场景下的各种爆炸式数据需求,具体表现为：
扁平化的命名空间将数据以对象(Object)形式存储在以桶(Bucket)为命名空间的两级结构中，通过新增Bucket方式来横向扩展命名空间，同时通过在Bucket中不断新增Object方式来实现海量数据的存储，这种扁平化的数据管理模型克服了目录树管理的不足，实现了海量数据简单有效的管理。需要注意的是Bucket的名称全局，通过桶名称(Bucket name)+对象的键名(Key name)来定位一个对象的最终存储路径。
分布式构架设计借助扁平化的管理模型设计，使得整个对象存储系统可以按命名空间规则进行底层数据存储的分区，借助一些哈希算法最终将需要存储的数据按分区规则均匀分布到多个主机的多块磁盘上，从而实现数据的分布式存储，从而解决了物理硬件的扩容及性能问题，为海量数据的存储铺平道路。
通用化的接口标准在解决了海量数据管理和硬件短板的问题之后，对象存储还要克服一个关键的问题:如何实现通用接口标准？通用接口标准对一个对象存储系统来说至关重要，这个是整个系统与外围系统打交道的重要窗口。如何兼容各种外围系统，去适配各种开发语言，形成一套围绕对象存储系统的生态标准？同样遵循“Simple is best！”思想，互联网时代HTTP大行其道，到处都通行的RESTful风格被对象存储“一眼相中”，目前主流的对象存储在接口标准的实现上都提供RESTful风格的API，同时也衍生出各种语言的SDK，当然有些对象存储也实现了RPC、SOAP等标准，这里篇幅有限就不再赘述。
(非)结构化数据与对象存储什么是结构化数据和非结构化数据?以大家熟知的关系型数据库场景为例：将一个人的属性抽象出来，分为姓名(name),年龄(age),住址(address),邮箱(email)几个标签，之后将这些信息存储到数据库中，那么某个人将对应到数据库里的一条记录。众所周知，我们现在熟知的数据库主要是关系型数据库，如果能够将数据按关系模型进行存储和管理，那么这一类数据就是结构化数据。
与之相对立的就是非结构化数据。如果上面需要存储的数据新增了一个相片(photo)字段，用于存储用户的相片数据，因为相片数据无法通过关系型数据进行描述，所以一般存储相片都是以二进制方式(非结构化方式)存储在关系数据库中，但是传统数据库不是万能。当需要比较多张相片的相似度，并删除重复相片，特别是需要管理海量相片的时候，传统的关系型数据库，会让你觉得异常痛苦。对象存储正是为了弥补传统关系型数据库在管理非结构化数据方面的不足。在对象存储模型中，将每一条存储在其中的非结构化数据抽象成一个“对象”，一个对象(Object)主要由下面四部分组成:
键名(Key):用于标识对象的名称，通过Bucket name+ Key的组合来确定对象最终存储路径。键值(Value):用于存储对象的内容数据。访问控制列表(ACL):标识对象可以被哪些用户或者用户组访问。元数据(Metadata):用于以key-value形式存储对象其他额外信息，比如对象内容的MD5校验值，对象的属主(owner），atime/ctime/mtime等。再来看一下我们熟悉的文件系统下一个文件都有哪些属性,以Linux下面使用stat和md5sum命令查看ceph.conf文件为例
root@demo:/home/user# stat ceph.conf File: ‘ceph.conf’ Size: 2534 Blocks: 8 IO Block: 4096 regular fileDevice: fe21h/65057d Inode: 1409 Links: 1Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 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: -root@demo:/home/user# md5sum ceph.conf1f3695479cf9198e318cd930b91ab97d ceph.conf通过上面的命令可以很轻松的看到文件的ACL、MD5、atime/ctime/mtimed等，接下来就是将文件系统的这些内容转换成对象存储里面相应的属性即可，这里使用一个s3cmd工具实现对象存储的上传，具体操作及效果如下
root@demo:/home/user# s3cmd put ceph.conf s3://my-bucket'ceph.conf' -> 's3://my-bucket/ceph.conf' [1 of 1] 2534 of 2534 100% in 0s 31.61 kB/s done'ceph.conf' -> 's3://my-bucket/ceph.conf' [1 of 1] 2534 of 2534 100% in 0s 34.84 kB/s doneroot@demo:/home/user# s3cmd info s3://my-bucket/ceph.confs3://my-bucket/ceph.conf (object): File size: 2534 Last mod: Tue, 14 Nov 2017 06:45:37 GMT MIME type: text/plain MD5 sum: 1f3695479cf9198e318cd930b91ab97d SSE: none cors: none ACL: s3user: FULL_CONTROL x-amz-meta-s3cmd-attrs: uid:0/gname:root/uname:root/gid:0/mode:33188/mtime:1489720813/atime:1474237502/md5:1f3695479cf9198e318cd930b91ab97d/ctime:1489720813通过上面的介绍，相信大家已经对对象存储已经有所了解。那么如何解决快速删除重复相片的问题？只需要将每张相片存储在对象存储中，同时以元数据方式记录对应的MD5值，在不读取图片内容的情况下，通过比较每个对象的MD5值是就能快速的筛选出重复的相片。
大数据培训、人工智能培训、Python培训、大数据培训机构、大数据培训班、数据分析培训、大数据可视化培训，就选光环大数据！光环大数据，聘请专业的大数据领域知名讲师，确保教学的整体质量与教学水准。讲师团及时掌握时代潮流技术，将前沿技能融入教学中，确保学生所学知识顺应时代所需。通过深入浅出、通俗易懂的教学方式，指导学生更快的掌握技能知识，成就上万个高薪就业学子。 更多问题咨询，欢迎点击------>>>>在线客服！
