细想支持谷歌主页搜索框需要的技术：背后的算法，缓存的搜索词，和其他一些随之而来的特性，比如当你输入一个位于数据存储中的查询时，基本相当于绝大多数网络的一个全文本快照。当你和成千上万的其他人同时提交搜索时，这个快照也正在不断地随着这些变化被更新着。与此同时，数据是由数以千计的独立服务器进程处理的，每个都各司其职，从计算出给你提供的相关联广告，到决定搜索结果的排列顺序。
支持谷歌搜索引擎的存储系统必须能够承受每天由运行于数以千计的服务器上的成千上万的独立进程所发出的数百万计的读写请求，几乎不能停机来备份或维护，还必须不断扩容以容纳由谷歌网页抓取机器人添加的日益扩大的众多页面。总体下来，谷歌每天要处理超过20PB。
这可不是谷歌可以从一个现成的存储架构就能完成的。而且对于运行超大规模的数据中心的其他网络和云计算巨头来说也是如此，比如亚马逊和Facebook。虽然大多数数据中心已经通过在一个存储区网络添加更多硬盘容量来解决扩充存储的问题，更多的存储服务器，通常是更多的数据库服务器，因为云环境的性能限制，这些方法却失效了。在云环境下，任何时候都可能有成千上万的活跃用户的数据，而且数据的读写在任何时刻都能达到数千TB。
这不仅仅是一个关于磁盘读写速度的简单问题。以这些卷上的数据流来讲，主要的问题是存储网络的吞吐量;即使有最好的交换机和存储服务器，传统的SAN架构也能成为数据处理的性能瓶颈。
接下来就是老生常谈的扩大存储的成本问题。超大规模网络公司增加容量的频率(举个例子，亚马逊现在每天为其数据中心增加的容量相当于整个公司在2001年全年的容量，根据亚马逊副总裁杰姆斯·汉密尔顿的说法)，用大多数数据中心的同样做法来摆平所需的存储，依照所需的管理，硬件和软件成本，花费将是巨大的。这种花费在关系数据库被添加到混合数据库时甚至更高，这取决于一个组织对它们的分割和复制如何处理。
对于这种不断扩展和持久存储的需求，驱使互联网巨头——谷歌，亚马逊，Facebook，微软等等——采取一种不同的存储解决方案：基于对象存储的分布式文件系统。这些系统至少都部分受到其他分布式集群文件系统的启发，如Red Hat的全局文件系统和IBM的通用并行文件系统。
这些云巨头的分布式文件系统的架构把元数据(关于内容的数据)从它存储的数据中分开。这能通过多个副本对数据进行大量并行读写操作，并且抛掉了像“文件锁定”这样的概念。
这些分布式文件系统的影响远远超出了它们为超大规模数据中心而创建的范畴——它们会直接影响那些使用公共云服务的公司(比如亚马逊的EC2，谷歌的AppEngine和微软的Azure)如何开发和部署程序。公司，大学和政府机构寻找一种快速存储和提供大量数据访问的方法正日益变成受云巨头们启发的数据存储系统的新阶段。因此有必要了解一下它们的发展史和过程中所做的工程折衷方案。