海量小文件存储
2014-06-06 10:14:34 点击:

[转自:http://www.fuchaoqun.com/2009/04/deal-with-tons-of-small-files/]Web2.0网站,数据内容以几何级数增长,尤其是那些小文件,几K~...

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

Facebook也遇到了同样的问题,他们的方案参见:http://www.dbanotes.net/arch/facebook_photos_arch.html,他们经历了三个阶段:

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

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

一、NFS共享

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

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

二、文件存数据库

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

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

三、分布式文件系统

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

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

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

DoubanFShttp://www.fuchaoqun.com/2009/04/deal-with-tons-of-small-files/
DoubanFS结构图,版权由charlee所有



相关热词搜索:海量 文件存储

上一篇:海量小文件存储利器Mogilefs
下一篇:RAID解决方案和RAID的各种优点