对象存储基础概念

对象存储诞生之初

谈到为什么要有对象存储，必须聊聊对象存储诞生之前的两大存储模型：块存储和文件存储。块存储主要是将存储介质的空间整个映射给主机使用的，主机如果需要对这些空间进行读写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 file
Device: fe21h/65057d    Inode: 1409        Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2016-09-19 06:25:02.294973380 +0800
Modify: 2017-03-17 11:20:13.736611814 +0800
Change: 2017-03-17 11:20:13.736611814 +0800
 Birth: -
root@demo:/home/user# md5sum ceph.conf
1f3695479cf9198e318cd930b91ab97d  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  done
root@demo:/home/user# s3cmd info s3://my-bucket/ceph.conf
s3://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值是就能快速的筛选出重复的相片。