论文阅读笔记（六）：The Google File System

原文链接：The Google File System

---

这次的文章是超级无敌经典的Google File System，与MapReduce和BigTable并称Google三驾马车， 开启了分布式系统的时代。

摘要

由于传统的分布式文件存储不能满足现在和未来的工作环境，因此文章提出了新的分布式文件存储系统，本系统可以供大规模的集群使用，与以前的分布式文件存储设计理念完全不同。

介绍

GFS和以前的分布式系统的实现有许多相同的目标，像性能,可扩展性, 可靠性, 可用性。但是本文是根据观测到的数据，未来可能的方向等又和以前的文件系统不同。所以重新设计了文件系统：

1. 组件失效被当做正常情况。由于以前组件失效被认为是例外情况，所以在以前的系统中，容灾性差。而现在数百个硬盘集群，任何一个硬盘出错都是可能的，甚至人为的bug情况也是存在的，所以将组件的失效看做正常情况，因此GFS将容灾性部署在系统内部。
2. 我们都知道，处理一个大文件所用的时间远远低于处理同样大小的许多小文件。比如1GB的游戏文件，删除它会很快，而1GB的10000个图片文件，删除它会很耗时。我们的网络文件就是一堆小文件组成的，对于I/O来说，处理这些文件会很耗时，从这方面GFS也做出了改进。
3. 文件的写入一般都是追加写入而不是覆盖写入，且一般来说我们写入的文件是只读的。关于这一点可以参考我们的日志文件，一般读日志文件而不是修改他们。所以我们建立在这种访问规则基础上可以对其性能进行优化，保证其原子性。举个MapReduce的例子，我们都知道写锁比读锁更加耗时，因为一般情况下对文件上了读锁，其他用户是可以读取该文件的。但是上了写锁，其他用户就无法访问该文件了。而NapReduce中，Mapper将文件传输给Shuffle，Shuffle将文件传输给Reducer，他们都是不需要对文件进行写入的，而是把文件内容拿出来，放入缓存块修改再传给下一个文件，因此不需要加写锁。这时候另一个程序想实时展示中间层收到的数据，就不用等待写锁结束（因为没有写锁）而可以直接访问，提高并行速度，不破坏原子性。
4. api和文件系统同时设计，那么就考虑到了整体协同性，提高性能。

设计概要

1. 设计前提假设
   • 系统部署在非昂贵的机器上。所谓的非昂贵，意思是随时可能崩溃，不像军方使用的系统，只考虑可靠性不考虑