海量小文件存储

超、凢脫俗 2022-08-13 15:55 200阅读 0赞

转自：[http://chaoqun.17348.com/2009/04/deal-with-tons-of-small-files/][http_chaoqun.17348.com_2009_04_deal-with-tons-of-small-files]

Web2.0网站，数据内容以几何级数增长，尤其是那些小文件，几K～几百K不等，数量巨多，传统的文件系统处理起来很是吃力，很多网站在scaling的过程中都遇到了这样的问题：磁盘IO过高；备份困难；单点问题，容量和读写无法水平扩展，还存在故障的可能。

YouTube也碰到这样的问题，每一个视频有4个缩微图，这样的话缩微图数量是视频数量的四倍，想象一下YouTube有多少视频，看一下他们遇到的问题：

*  大量的磁盘寻址，在操作系统层面出现inodes cache和page cache的问题
 *  单个目录文件数限制，尤其是Ext3文件系统，采用目录分级的做法，最新的Linux Kernel 2.6优化了Ext3文件系统，单目录能存储的文件数提高了100倍，但是把所有的文件存一个目录不是一个好的方法
 *  高RPS（requests per second每秒请求数），因为一个页面可能要显示60个缩微图
 *  高负载下Apache性能差
 *  Apache前面加一层Squid，能抗一会，但负载上来之后，性能下降厉害，由300RPS降到20RPS
 *  尝试lighttpd，但是lighttpd是单线程，多线程的话也有问题，线程之间缓存不能共享
 *  加一台服务器的话需要24小时，因为文件数太多了
 *  存在“冷却”的问题，重启服务器后需要6～10个小时才能缓存好

YouTube的解决方案是Google的BigTable，一般人没戏。（原文参见：[http://www.hfadeel.com/Blog/?p=127][http_www.hfadeel.com_Blog_p_127]）

Facebook也遇到了同样的问题，他们的方案参见：[http://www.dbanotes.net/arch/facebook\_photos\_arch.html][http_www.dbanotes.net_arch_facebook_photos_arch.html]，他们经历了三个阶段：

1.  NFS共享，挂一个盘阵，APP服务器通过NFS读写
2.  加一个中间层Cachr：eventHttp + memcached(lighttpd + mod\_memcache实现同样的功能)，后端还是通过NFS连盘阵
3.  Haystacks，详细的去读[这里][Link 1]（E文）。

对于一般的网站来说，实用的方案有哪些呢？

一、NFS共享

是的，这个有很多问题，但实施成本低，很多公司都在用（我们也在用），在不是那么多文件，不是那么高并发的情况下还是很不错的，设置Hash目录，不要让一个目录下文件数过多，对于一般的网站来说足够用了。

备份确实是一个问题，如果不是海量的话，根据文件更新时间每天增量备份＋周期性的全量备份应该可以。

二、文件存数据库

真有人这么做，[手机之家][Link 2]用MySQL建了256个表来存储超过1T的文件，前端加一个多级缓存（具体未知，也许就是memcached也许还是文件），数据库做数据备份用，他们用起来觉得还不错。

或者觉得MySQL太重，试试key->value的数据库，比如BDB，Tokyo Cabinet等。

三、分布式文件系统

开源的很多，[好看簿][Link 3]用的是[MogileFS][]，与memcached师出同门。[傲游][Link 4]用[MFS][]来存储用户的收藏夹文件，详细文章参见：[分布式文件系统MFS(moosefs)实现存储共享(一) ][MFS_moosefs_]、[(二)][Link 5]，据说数百万轻松处理。

分布式文件系统好处是可以均衡读写压力，数据可靠性大大增加，某个数据节点挂了也没事。

还不行？自己DIY一个去吧，豆瓣就这么做的，TokyoCabinet做为底层存储，封装了一个memcached协议接口（与[Tokyo Tyrant][]何异？），一致性哈希，应用程序根据哈希规则在node中读写数据:

![DoubanFS][]  
DoubanFS结构图，版权由charlee所有

[http_chaoqun.17348.com_2009_04_deal-with-tons-of-small-files]: http://chaoqun.17348.com/2009/04/deal-with-tons-of-small-files/
[http_www.hfadeel.com_Blog_p_127]: http://www.hfadeel.com/Blog/?p=127
[http_www.dbanotes.net_arch_facebook_photos_arch.html]: http://www.dbanotes.net/arch/facebook_photos_arch.html
[Link 1]: http://perspectives.mvdirona.com/2008/06/30/FacebookNeedleInAHaystackEfficientStorageOfBillionsOfPhotos.aspx
[Link 2]: http://www.imobile.com.cn/
[Link 3]: http://www.haokanbu.com/
[MogileFS]: http://danga.com/mogilefs/
[Link 4]: http://www.maxthon.cn/
[MFS]: http://www.moosefs.org/index.html
[MFS_moosefs_]: http://sery.blog.51cto.com/10037/147756
[Link 5]: http://sery.blog.51cto.com/10037/147761
[Tokyo Tyrant]: http://tokyocabinet.sourceforge.net/tyrantpkg/
[DoubanFS]: http://farm4.static.flickr.com/3377/3428447466_141e4e0a8a.jpg