主题：【半原创】Flickr 网站架构研究（1） -- 西电鲁丁

在具体讨论Flickr的文件存储系统设计之前，我们这里先来简要的介绍一下海量文件系统设计时需要考虑的一些基本因素：

１。数据库还是文件系统？

　文件存在哪儿？这个可能是大家问的第一个也可能是最多的问题了，一般来说，业界公认的方法是数据库存放元数据和文件路径（可以是绝对路径，也可以是相对路径＋卷路径），而实际文件则存放在文件系统，大多数大型图片网站如Flickr和企业内容管理(ECM)软件厂商都采用这种方法（或者同时支持数据库和文件系统两种方式），原因在于

　１）数据库系统在增大到一定规模后，比如上TB级后管理维护和效率都是一个很大的挑战（升级硬件是一个办法，如果有钱），例如Flickr现今已有超过６PB的照片文件，全部以BLOB方式存入数据库几乎不可能。当然也有例外，比如微软的Sharepoint 2007就是全部文件都存入SQL SERVER数据库的,微软的建议是一个Sharepoint library的文件数不要超过５百万，如果超过的话则可以采用scale-out方式。记得几年前在MSDN上看过一篇文章，介绍微软采用了几百台sharepoint 2001 server来搭建自己的一个内部知识库网站。采用数据库的方式，虽然有些限制，但也不是绝对不可以。

　２）以BLOB方式存储文件，当文件大小超过一定阀值后数据库的读写响应将急剧下降。下面的图摘自某著名ECM厂商的研究报告，这张是比较不同大小的文件存入数据库和文件系统的响应时间的（蓝线是数据库，红线是文件系统）

这张是比较从数据库和文件系统读取不同大小的文件的响应时间的

从中可以看出，这个阀值是大约500KB-1MB左右，小于这个阀值，数据库的读写效率要高于文件系统，而大于这个阀值，文件系统的优势就体现出来了。不同的测试条件和软硬件下这个阀值会有所不同，但趋势应该是一致的。

　采用文件系统方式的一个主要缺点是难以保证元数据和文件的一致性（在数据库方式下可以通过事务的方式来保证这一点），所以需要定期运行特定的程序进行一致性检查。

２。通用文件系统的问题。

　早期的通用文件系统的设计初始并没有考虑到海量文件的存取，主要的表现为当一个目录下的文件数超过一定时，访问这个目录下文件的时间将大大增加，例如在NT4.0时代，这个值是大约５000，后来的Windows 2000/2003和Unix/Linux要好的多，不过这个限制依然存在。早期的NTFS或基于BSD Fast Filesystem的Unix/Linux文件系统，对于目录/inode的设计是采用采用简单的顺序查找的方式来定位目录下的文件，虽然稍后一些的文件系统设计增加了cache来提高效率，不过还是难以应付一个目录下有大量文件的情况；较为现代的JFS, Reiserfs, XFS, HFS和较新的NTFS版本对于目录结构采用了B-Tree的设计，因而大大提高了效率，但存在的问题是一旦较高层次的父节点数据损害，则可能会丢失所有的子节点。Linux 2.6的ext3和ext4文件系统有鉴于此，采用了一种相对简单但较高效和安全的HTree(Hash Tree)的方法，即可以利用hash table来提高访问效率，又保留了原来的顺序查找的结构，这样一旦hash table的数据丢失也依然可以通过顺序查找的结构来访问和恢复。

　尽管效率有所提高，还是不建议在一个目录和一个文件系统下放置太多的文件。对于NTFS下的目录，个人理解这个临界点大约是30万，微软建议，当一个NTFS目录下文件数超过30万时，关掉短文件名(即DOS兼容模式的8.3)的生成(可通过注册表或fsutil behavior set disable8dot3 1命令)。对于Linux/Unix的目录以及单个文件系统，没有看到过权威的数据。（个人建议不要超过２级目录，总文件数不超过１亿吧。）一个现实的例子就是Youtube.com,Youtube最初采用几台Linux服务器存放所有视频的截屏（一个视频大约４-5个截屏），后来由于目录下文件太多以至大大影响了性能，在被Google收购之后，移植到了Google的BigTable，才最终解决了问题。

　对于类似的照片网站，另一个建议是关掉文件系统的last access time的读写。缺省情况下，每一次文件访问，文件系统都会更新文件的last access time,这样会造成大量的写操作。对于这类网站，其实并不关心每一个文件的最后访问时间。对于Unix/Linux,可以通过在mount时选用noatime参数来关掉last access time;对于NTFS,可通过注册表或fsutil behavior set disablelastaccess 1的命令。但要注意的是，一些备份软件/策略可能根据这个时间来进行备份，在关掉这个选项之前需要仔细考虑替代方案。

　除了通用文件系统之外，也有一些基于通用文件系统加以改造或是干脆重起炉灶重写的分布式文件系统比如Google File system(GFS),IBM 的General Parallel File System (GPFS),和著名的memcached师出同门的MogileFS,以及Facebook新近研发成功的Haystack系统等，这些系统在一定程度上克服了通用文件系统的限制，但在成熟度，开放性和技术支持上还有待观察。

３。存储设备的选择。

　存储设备的选择是个见仁见智的事情，大厂商的存储设备通常有一些独特的功能，比如snapshot,replication，WORM-Like Disk(类似CD-R以满足法律法规的要求)等，缺点当然就是价格昂贵；而通用硬件价格便宜，采购灵活，缺点是应用软件需要实现更多的功能，而且维护成本较高，可能需要几百台服务器来达到同样的存储容量。对比两大网站:Flickr最初采用了通用的硬件而后似乎是基于维护的原因而转向NetApp；而Facebook在砸出大把大把的银子购进NetApp后最近由于性能和TCO的原因开始考虑通用硬件。重要的在于软件和应用系统的设计要不依赖于特定厂商的产品和功能，这样在需要的时候可以有更多的选择，虽然数据移植是一件很痛苦的事。