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

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

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生态的存储形态。

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

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

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