成都科汇科技有限公司
Kehui Technology Co., Ltd.
对于大多数文件系统来说,尤其是POSIX兼容的文件系统,提供open、close、read、write和lseek等接口。
而对象存储的接口是REST风格的,通常是基于HTTP协议的RESTful Web API,通过HTTP请求中的PUT和GET等操作进行文件的上传即写入和下载即读取,通过DELETE操作删除文件。
(图片内容来自SwiftStack)
对象存储和文件系统在接口上的本质区别是对象存储不支持和fread和fwrite类似的随机位置读写操作,即一个文件PUT到对象存储里以后,如果要读取,只能GET整个文件,如果要修改一个对象,只能重新PUT一个新的到对象存储里,覆盖之前的对象或者形成一个新的版本。
如果结合平时使用云盘的经验,就不难理解这个特点了,用户会上传文件到云盘或者从云盘下载文件。如果要修改一个文件,会把文件下载下来,修改以后重新上传,替换之前的版本。实际上几乎所有的互联网应用,都是用这种存储方式读写数据的,比如微信,在朋友圈里发照片是上传图像、收取别人发的照片是下载图像,也可以从朋友圈中删除以前发送的内容;微博也是如此,通过微博API我们可以了解到,微博客户端的每一张图片都是通过REST风格的HTTP请求从服务端获取的,而我们要发微博的话,也是通过HTTP请求将数据包括图片传上去的。在没有对象存储以前,开发者需要自己为客户端提供HTTP的数据读写接口,并通过程序代码转换为对文件系统的读写操作。
对比文件系统,对象存储的第二个特点是没有嵌套的文件夹,而是采用扁平的数据组织结构,往往是两层或者三层,例如AWS S3和华为的UDS,每个用户可以把它的存储空间划分为“容器”(Bucket),然后往每个容器里放对象,对象不能直接放到租户的根存储空间里,必须放到某个容器下面,而不能嵌套,也就是说,容器下面不能再放一层容器,只能放对象。OpenStack Swift也类似
这就是所谓“扁平数据组织结构”,因为它和文件夹可以****嵌套不同,层次关系是固定的,而且只有两到三级,是扁平的。每**的每个元素,例如S3中的某个容器或者某个对象,在系统中都有**的标识,用户通过这个标识来访问容器或者对象,所以,对象存储提供的是一种K/V的访问方式。
(图片内容来自华为)
采用扁平的数据组织结构抛弃了嵌套的文件夹,避免维护庞大的目录树。随着大数据和互联网的发展,如今的存储系统中,动辄数百万、千万甚至上亿个文件/对象,单位时间内的访问次数和并发访问量也达到了****的量级,在这种情况下,目录树会给存储系统带来很大的开销和诸多问题,成为系统的瓶颈。反观目录结构的初衷——数据管理,如今作用**有限,我们已经很难通过目录的划分对文件进行归类和管理了,因为一个文件*终只能放到一个文件夹下,作为目录树的叶子节点存在,而文件的属性是多维度的。目前各类应用中广泛采用元数据检索的方式进行数据的管理,通过对元数据的匹配得到一个Index或者Key,再根据这个Index或者Key找到并读取数据,所以,对象存储的扁平数据组织形式和K/V访问方式更能满足数据管理的需求。
不难看出,对象存储有着鲜明的互联网和大数据时代的特点,随着“互联网+”的推进,互联网技术正在渗透到各行各业,数据量也在成指数倍数增长,对象存储将发挥越来越大的作用。
我们也可以从提供服务的角度来看待他们的不同:
对象存储提供的服务类似于hashmap这种数据结构,将对象数据作为一个逻辑单元存储起来,通过key来获取。更多的操作是获取,删除。更新操作频率比较低。相应的,对象存储比较适合于存放静态数据或者更新频率比较低的大容量数据。比如一些多媒体数据,数据备份等。
块存储通常提供的原始块设备,就是裸磁盘空间,比如将逻辑盘映射给主机使用。分布式环境中,一些对实时性要求比较高的存储我们就得用块存储了,比如数据库。
文件存储就比较好理解了,FTP,NFS等。