海量小文件存储

系统 1976 0

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中读写数据:


DoubanFS结构图


海量小文件存储


更多文章、技术交流、商务合作、联系博主

微信扫码或搜索:z360901061

微信扫一扫加我为好友

QQ号联系: 360901061

您的支持是博主写作最大的动力,如果您喜欢我的文章,感觉我的文章对您有帮助,请用微信扫描下面二维码支持博主2元、5元、10元、20元等您想捐的金额吧,狠狠点击下面给点支持吧,站长非常感激您!手机微信长按不能支付解决办法:请将微信支付二维码保存到相册,切换到微信,然后点击微信右上角扫一扫功能,选择支付二维码完成支付。

【本文对您有帮助就好】

您的支持是博主写作最大的动力,如果您喜欢我的文章,感觉我的文章对您有帮助,请用微信扫描上面二维码支持博主2元、5元、10元、自定义金额等您想捐的金额吧,站长会非常 感谢您的哦!!!

发表我的评论
最新评论 总共0条评论