ITPub博客

首页 > 云计算 > 开源云工具 > 从“软件”到“服务“——【对象存储】的发展历程(上)

从“软件”到“服务“——【对象存储】的发展历程(上)

原创 开源云工具 作者:京东云技术新知 时间:2019-03-06 22:33:36 0 删除 编辑



当我们有海量的数据需要存储处理时,首先可能会想到的就是对象存储和Hadoop的HDFS。现在还有一种趋势,就是直接在对象存储上跑 MapReduce、Spark 等工具,不再依赖于HDFS。


其实在对象存储出现之前,也会遇到海量数据存储的问题,那么随着数据量的不断增长,存储技术又发生着怎么样的变化呢?

让我们从不同维度来进行分析。




科学计算领域:glusterfs, lustre, GPFS


在2000年之前 ,也就是互联网还没有真正意义上的大规模崛起时,科学计算应该算是当时真正的大规模存储玩家。在蛋白质模拟、计算化学这类的科学计算领域,它们只消耗计算,对存储的需求不高。 但在气象预测、天文等领域,由于数据采集量巨大,因此也有着大规模存储的需求。撇开专有的存储系统来看,glusterfs、lustre、以及IBM的GPFS(Spectrum Scale) 算是在这个领域的佼佼者,但这些跟后面我们看到的其他存储系统有很大不同的是,这些系统都支持 POSIX 文件系统,方便原有的程序从本地文件系统平滑迁移到分布式文件系统。


但也正是因为需要支持 POSIX 文件系统,这类系统的基础性能会出现一定的问题。比如 glusterfs对于小文件、qps的损失就比较大。除此之外,还经常受到文件系统本身各种限制的影响,比如:单一目录下文件的数目不能太多,深层次目录寻址很慢等。




大数据领域:GFS, HDFS


2003年Google 发表 GFS 论文,  2004年发表了MapReduce 论文。分别解决了Google搜索业务遇到的大规模的存储和计算问题。业界很快就认识到了这个方法在解决大数据问题上的重要性和通用性, 2006年就诞生了Hadoop 项目,并随后衍生了 HBase, HIVE, Pig等Hadoop生态项目。




Hadoop的底层存储引擎叫HDFS,HDFS在设计时充分考虑了离线大文件的存储问题,但对于小文件存储,NameNode容易出现过载的情况。不过对于这个问题也可以有一些变通解决方案,比如把数据存在HBase而不是Hadoop中,或者把小文件拼成大文件,大文件存在HDFS,然后把对应的元信息存在HBase里。


上面的变通方法能改善小文件的存储问题,但由于远离了Hadoop 本身的设计目标,所以还是会被其他问题所限制。除小文件之外,早期Hadoop对于在线应用的支持也是远远不足的,比如数据迁移时会有可用性问题;HBase的数据在数据片切分和合并时也有可用性问题;NameNode 更改时主从是异步更改的,在主节点出故障时甚至有丢失数据的风险。


Hadoop 整个生态,由于自身的设计目标问题,所以很少有人用它来替代对象存储,反而是对象存储本身在逐步考虑支持 HDFS 协议,简化Hadoop生态的存储形态。




图片存储: Mogilefs, GridFS, FastDFS


Web  1.0 时代开始图片存储的问题就已经存在了,内容网站需要图片、论坛/BBS需要支持附件。而这些存储问题的最早方案就是用服务器的文件系统来直接存储,再加上合理的备份机制来防止文件丢失。


随着互联网的进一步发展,网站图片等富媒体的容量快速从TB级增加到PB甚至几十PB的级别。在这种情况下,传统的图片存储方式,不管是可用性、修复成本、还是管理复杂度等问题都无法很好地得到解决。



  • MogileFS


    MogileFS 算是第一个被广泛使用的图片存储系统,曾有报道称豆瓣、大众点评、花瓣等网站都曾经用过 MogileFS 来存储自己的图片。但MogileFS 的性能受制于核心数据库,所以很快又出现了 FastDFS 这类的存储系统,把大量的元信息存储在图片的key(也可以认为是URL)中,大幅度降低了对中心数据库的压力。





  • GridFS


    在图片存储领域有一个不太成功但却值得一提的软件:GridFS。随着4square等网站的崛起,用于支撑这类网站的MongoDB数据库也大红大紫。MongoDB提供了一个GridFS,本意是用来解决少量大于数据库限制的文档存储问题,结果却有不少人用它来解决图片存储的问题。


    这一做法在低压力下还算可用,但在压力稍高的情况下时,就会遇到主从同步速率不足导致主从同步失败,以及在分布式系统中写入压力严重不均等,高压力下自动扩容困难等问题。MongoDB本身的目标不在于提供文件存储,所以对 GridFS 的这些问题并不在意。只不过很多网站因为选型错误,在发展道路上走了不必要的弯路。





图片存储引擎中,mogilefs有严重的性能瓶颈,FastDFS 又无法指定 key 来存储,再加上大量的互联网应用,已经能很好地实现控制流与数据流分离,即所有图片等富媒体的上传下载直接走云上的对象存储服务,而控制流的部分继续用自建IDC或者云虚拟机,用对象存储的上传签名机制来控制权限,利用回调机制来做控制面和数据面的互动。在这种情况下,对开源的存储软件需求就会越来越低。所以最近几年尽管数据存储量剧增,但在开源存储上也少有新的软件出现,选择自建存储系统的公司比例也越来越低。


小结:


在对象存储大规模普及之前,大量的数据存储和处理就已经存在。但这些方案大都专注于解决其中一类问题,缺少足够的普适性。对象存储出现后,很多解决方案已经在向对象存储移植或者靠拢,那么为什么对象存储能有这么大的吸引力?对象存储的优势究竟在哪儿?如何用好对象存储呢?


欢迎点击“ 京东云 ”了解更多精彩内容


*文中图片皆来源于网络*


来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/69912185/viewspace-2637754/,如需转载,请注明出处,否则将追究法律责任。

上一篇: 没有了~
请登录后发表评论 登录
全部评论
京东科技开发者(JD Tech Developer)是京东科技集团旗下为AI、云计算、IoT等相关领域开发者提供技术分享交流的平台。平台将发布京东产品技术信息、行业技术内容、技术活动及大赛等资讯。拥抱技术,与开发者携手预见未来!

注册时间:2019-03-06

  • 博文量
    485
  • 访问量
    236956