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

导语

据IDC的分析师预测，2025年，全球范围内的数据量将增加到163 ZB，相较于2016年的16.1 ZB，十年间将增加1000%。面对飞速增加的数据量，企业和机构在将来又将如何存储这些数据呢？

本文将与你们一块儿分享、探讨对象存储的进化及发展历程。

当咱们有海量的数据须要存储处理时，首先可能会想到的就是对象存储和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 的性能受制于核心数据库，因此很快又出现了 FastDFS 这类的存储系统，把大量的元信息存储在图片的key(也能够认为是URL)中，大幅度下降了对中心数据库的压力。

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

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

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

小结

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

下期解读，请关注“京东云开发者社区”获取更多详情！ <br/> <br/>

原文连接：https://mp.weixin.qq.com/s/rZ1hOacXkkpve-yg-UspFw