http://blog.csdn.net/BU_BetterYou/archive/2008/07/14/2647254.aspx
Facebook存储65亿张照片的存储框架 收藏 Facebook存储65亿张照片的存储框架 从未用过Facebook,但是还是对Facebook应对大容量的非结构化数据存储方案感兴趣。本文是通过在线网络广播(webcast)经本人翻译得来的,因此,本人并不能确保本文中叙述的内容与原文webcast不存在偏差。 本文严禁在未征得本人同意的情况下以任何形式进行转载。本人直接受在邮件中的转载申请,如需转载,请发送邮件至 betteryou@126.com。 Facebook概况· Facebook目前拥有65亿张照片,每张照片分别会保存为4~5种尺寸的文件,所以大概会有300亿个文件,大约占据540TB的存储空间。· Facebook平均的请求流量是475,000张图片/秒;其中,关于概况(Profile)的照片请求量大约是200,000张/秒。· Facebook每周大约会收到1亿次上载请求。所以,Facebook需要在海量的数据存储中高效读取和存储数据。Facebook目前有25名开发工程师负责开发,他们大部分的工作都集中在如何让Facebook的数据库性能更优化,如何让Facebook的数据库可扩展性更好,等等方面的工作上。 目前,Facebook拥有数千台服务器(虽然webcast的片子上有一则新闻说已经达到10,000台服务器,但webcast上Jason还是说的是数千台——thousands of servers),这些服务器大部分都有明确的分工,各司其职;使用MySQL数据库;PHP运行在Apache上,并且用C开发了一些扩展和封装;在Facebook的应用层和数据库层之间,他们使用了Memcached技术,作为缓存。 小贴士:何谓Memcached? Memcached是首先由Danga Interactive为Live Journal开发的通用分布式内存缓存系统。它通常通过将对象和数据缓存至内存的方法来加快动态数据库驱动网站的速度,减少了数据库访问的次数。Memcached缺少安全认证特性,这就意味着它必须在正确配置的防火墙内运行。Memcached的API提供了分布在多台计算机上的巨大哈希表(Hash Table)。当哈希表满了之后,新插入的数据会使用LRU算法(最近最少使用算法)将较老的数据擦洗掉。YouTube、LiveJournal、Wikipedia、SourceForge、Facebook、NYTimes.com等知名网站都使用了Memcached。 Facebook当前存储架构 注:我暂且称之为当前存储架构,原因有二:第一是webcast的PPT当中出现的是”State of the World”字样,表明现在的状况;第二是新的存储架构Haystack并未在webcast中明确表示已经进入生产环境。如描述有错误,欢迎各位积极指正。 Facebook的存储架构需要应对两方面的问题:读和写。我们分开来观察。 写: 当用户需要上载照片,也就是对Facebook的存储进行写入操作的时候,Facebook会指定一台上载服务器来进行工作。上载服务器会对上载的照片进行处理,每张照片会按照4~5种不同的尺寸进行存储。 读: 当用户需要对照片进行读取时,架构会稍微复杂一些: 当用户点击某张照片后,请求将通过HTTP传到CDN (Content Delivery Network),CDN中已经缓存了一些照片,如果请求的照片在CDN中,就可以将照片返回给用户。如果照片未在CDN中,那么就有两种情况发生。 如果请求的是普通照片,则请求会传递到不同的照片服务器(Photo Server),照片服务器去读取后台Netapp存储的数据。 如果请求的是基本资料(Profile)上的照片,那么读取该照片的请求会到一个叫“Cachr”,Cachr是一个超轻量级的服务器,专门负责缓存基本资料相关的照片。如果在Cachr中依然没有找到照片,就需要通过照片服务器(Photo Server)去读取后台Netapp存储的数据了。 目前,Facebook的Cachr可扩展性和稳定性良好,对基本资料(Profile)上照片的请求大概在200,000次/秒,占总请求数量的一半还强,Facebook大约有40个Cachr节点,运行了4年多,并未出现大问题。照片服务器(Photo Server)采用文件处理缓存(File Handle Cache)技术,旨在提高照片的读取性能。 架构上的问题 刚才简单介绍了整个Facebook存储架构,但这个架构存在着一些问题: 第一,无论是Netapp还是别的文件系统都会造成元数据(metadata)爆炸性增长。他们使用一个文件一个元数据(metadata)的方式,而且每个文件系统都强制使用目录等层次性结构,这样就势必增加了与真正所需数据无关的内容。所以,对于Facebook来说,大约需要进行3次磁盘IO才能成功读取一张图片(在刚刚设计之初,IO的次数需要达到15次,所以3次已经是非常优化的结果了)。 第二,正是由于对文件系统中图片读取的代价增大,所以Facebook不得不更加依赖于高效的数据缓存来解决磁盘IO造成的矛盾。目前,Facebook的CDN中的基本资料访问命中率达99.8%,普通图片的访问命中率达92%,这样才降低了对文件系统的访问量 Haystack Facebook引入Haystack的原因是为了减少元数据(metadata)的使用。对于Haystack来说,可以将一些图片捆绑在一起,然后这些文件统一使用一个单独的元数据(metadata)。那么这样的话,怎么能够保证真正从这些文件中读取到真正需要的数据呢?Haystack使用独立索引文件来对文件系统的数据建立索引。所以这样的话,就可以通过索引里的键(Key)指向所需要的图片文件了。通常,1GB的图片数据需要RAM中的1M元数据(metadata)内存缓存。因为Haystack能确保索引内容肯定驻留在RAM中,所以Facebook就能确保对每张图片的IO次数最多为1次。 Haystack的存储模式 Haystack在磁盘上表现为一系列重复的数据块,包含数据头(Header)和数据段(Segment)两个部分。下图是Facebook中使用Haystack的存储方式。 下图是Haystack中的索引情况: 其中,start代表了在Haystack文件系统中该文件的起始地址,length就是文件的长度。 新的存储架构 如果放弃使用Netapp,转而使用Haystack,那么Facebook的读取场景就会发生一定的变化。我们重新来观察一下: 写: 读取: 原webcast观看:Facebook – Needle in a Haystack: Efficient Storage of Billions of Photos 本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/BU_BetterYou/archive/2008/07/14/2647254.aspx
分享到:
相关推荐
facebook的照片存储量级是PB级的,本文介绍了这种巨量级的照片存储方式,做图片服务器的同学可以参考参考
facebook源代码框架,学习框架和多用户客户端的好例子
Facebook Pop 框架简单例子,项目利用了CocoaPods来管理框架
facebook源代码框架.zip,太多无法一一验证是否可用,程序如果跑不起来需要自调,部分代码功能进行参考学习。
里面将现在主流的集中图片开源框架的图片加载时间,内存消耗等做了对比,eclipse (别人已经明确说了不支持了)和编译没通过的(墙内的)攻城狮们,来看看大婶Facebook 的开源框架Fresco 的示例吧
Fresco是Facebook开源Android平台上一个强大的图片加载库。
Facebook, 面向Nette框架的Facebook kdyby/facebook 具有Nette框架授权的Facebook SDK要求kdyby/facebook要求启用cUrl扩展的PHP 5.3.2或者更高版本。Nette框架Composer CA安装
Facebook 数据库 java 用户信息存储提取
因此 Facebook 需要大量的存储基础设施来容纳其巨大的照片储存,其中稳定增长的是每一天用户都要新增 100 万个新的照 片。每月人们在 Facebook 上分享超过 300 亿条内容。此外,Facebook 的基础设施必须支持超过 1 ...
Android基于Facebook Rebound的动画效果框架是一个基于Facebook Rebound的动效框架Backboard,封装了一些API,便于开发者更方便的把View与Motion结合起来,一些效果很棒
Django-facebook, 在 python 中,Facebook开放图api使用 Django 框架实现了 基于 Thierry Schellenbach ( mellowmorning.com ) 的 Django 状态现在,Django 和Facebook都在迅速改变。 同时,我在一个初创公司上班,...
适用于iOS的照片库, 与Facebook照片浏览器类似的功能。.zip,iOS的照片库,具有现代功能集。类似于Facebook照片浏览器的功能。
此程序主要实现了基于SSM框架的JAVAWEB的Facebook程序,可以作为一个学习SSM框架时的例子,具有很好的代表性,文件中包含了程序所需要的数据库文件,本人建议数据库用MYSQL5.0,tomcat用9.0.在学习时用了好多的...
NVIDIA与Facebook携手强化Caffe2深度学习框架.pdf
facebook开源目标检测框架所用到的R-101预训练的backbone,直接跑代码自动下载总是断掉,被墙了,直接去官网下载也很慢,这里下载好了分享
facebook架构
Facebook(脸书)是美国的一个社交网络服务网站 ,创立于2004年2月4日,总部位于美国...Facebook是世界排名领先的照片分享站点,截至2013年11月每天上传约3.5亿张照片。截至2012年5月,Facebook拥有约9亿用户。
facebook 架构 大流量 ,架构师必看。。。。。。
This project is a tutorial on how to use the popular through Facebook framework. It is very easy and efficient framework that can help you make a decent movie in no time. In this project, you will ...
facebook app for graph api