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

导语

据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 来存储自己的图片。但MogileFS 的性能受制于核心数据库，所以很快又出现了 FastDFS 这类的存储系统，把大量的元信息存储在图片的key(也可以认为是URL)中，大幅度降低了对中心数据库的压力。
![在这里插入图片描述](

)

• GridFS

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

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

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

小结：

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

我们下期文章再详细解读！