历史

设计

GFS专门为Google的核心数据即页面搜索的存储进行了优化。数据使用大到若干G字节的大文件持续存储，而这些文件极少、覆盖或者减小；通常只是进行添加或读取操作。它也是针对Google的计算机集群进行的设计和优化，这些节点是由廉价的“常用”计算机组成，这就意味着必须防止单个节点的高损害率和随之带来的数据丢失。其它设计理念包括高数据吞吐率，甚至这带来了访问反应期变差。

节点分为两类： 主 节点和 Chunkservers 。Chunkservers存储数据文件，这些单个的文件象常见的文件系统中的簇或者扇区那样被分成固定大小的数据块（这也是名字的由来）。每个数据块有一个唯一的64位标签，维护从文件到组成的数据块的逻辑映射。每个数据块在网络上复制一个固定数量的次数，缺省次数是3次，对于常用文件如可执行文件的次数要更多。

主服务器通常并不存储实际的大块数据，而是存储与大块数据相关的元数据，这样的数据如映射表格将64位标签映射到大块数据位置及其组成的文件、大块数据副本位置、哪个进程正在读写特定的大数据块或者追踪复制大块数据的“快照”（通常在主服务器的激发下，当由于节点失败的时候，一个大数据块的副本数目降到了设定的数目下）。所有这些元数据通过主服务器周期性地接收从每个数据块服务器来的更新（“心跳消息”）保持最新状态。

操作的允许授权是通过限时的、倒计时“租期”系统来处理的，主服务器授权一个进程在有限的时间段内访问数据块，在这段时间内主服务器不会授权其它任何进程访问数据块。被更改的chunkserver——总是主要的数据块存储器，然后将更改复制到其它的chunkserver上。这些变化直到所有的chunkserver确认才存储起来，这样就保证了操作的完整性和原子性。

访问大数据块的程序首先查询主服务器得到所要数据块的位置，如果大数据块没有进行操作（没有重要的租约），主服务器回答大数据块的位置，然后程序就可以直接与chunkserver进行联系接收数据（类似于Kazaa和它的超级节点）。

批评意见

只能有一个主服务器——代码不允许存在多个主服务器。这看起来是限制系统可扩展性和可靠性的一个缺陷，因为系统的最大存储容量和正常工作时间受制于主服务器的容量和正常工作时间，也因为它要将所有的元数据进行编制，并且因为几乎所有的动作和请求都经过它；但是Google的工程师们辩解说事实并不是这样。元数据是非常紧凑的，仅仅只有数K到数M的大小，并且主服务器通常是网络上性能最好的节点之一；至于可靠性，通常有一个“影子”主服务器制作主服务器的镜像，一旦主服务器失败它将接替工作。另外，主服务器极少成为瓶颈，因为客户端仅仅获取元数据然后将它们缓存起来；随后的交互工作是直接与chunkservers进行。同样，使用单个的主服务器可以大幅度地降低软件的复杂性，如果有多个的主服务器，软件将变得复杂以能够保证数据完整性、自动操作、负载均衡和安全性。

参见

Hadoop－Apache软件基金会的开放源代码项目，提供与Google文件系统类似的功能。

Google产品列表

Gmail文件系统GmailFS使用一个可加载的Linux文件系统，它使用Gmail帐号作为存储媒介。

免责声明：以上内容版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。感谢每一位辛勤著写的作者，感谢每一位的分享。