Facebook存储技术方案:找出“暖性BLOB”数据

Facebook公司已经在其近线存储体系当中彻底弃用RAID与复制机制,转而采用分布式擦除编码以隔离其所谓的“暖性BLOB”。

  暖性?BLOB?这都是些什么东西?大家别急,马上为您讲解:

  BLOB——也就是二进制大对象,包括Facebook用户的图片以及视频等等。

  暖性——是指那些必须进行保存,访问频率低于热门数据但却又高于归档或者冷门数据的信息。通常情况下,这些数据已经产生了一周以上。当然,热门BLOB的访问频率仍然较高。

  擦除编码——向一条字节串中添加经过计算的奇偶校验值(即里德所罗门码,简称RS),这样由于错误删除或者损坏了完整内容之后、该字符串仍能被恢复为原样。一般来讲,这种机制能够比RAID更为有效地对数据加以保护、并且无需占用太多存储空间。

  Facebook公司面临的一大特殊问题在于,其拥有三种主要用户数据类型外加与之相关的元数据,而且这三种类型都要求拥有庞大的存储空间作为支撑。Facebook最为主要且访问频率最高的数据集是那些生成时间不长,且在用户时间表中留存时间不足一周的发布信息。这些内容往往会受到该用户“好友”们的大量访问。

  Facebook利用其Haystack存储系统处理这些数据,这套方案采用三级复制机制对数据中以保护、确保这部分数据能够始终接受访问且具备快速的响应能力,同时尽可能将访问指向单一磁盘(当元数据计算开始运行之后)。

  当这部分数据逐渐陈旧之后,其访问频率通常也会有所降低——也就是前面提到的由热门转向“暖性”,但我们仍然需要为其提供较快的访问速度、从而切实满足调用需求。这就产生了新的问题,数据总量一直处于规模膨胀态势当中。举例来说,截至今年一月份,Facebook所保存的照片总数已经超过4000亿张。

Facebook存储技术方案:我们使尽浑身解数找出“暖性BLOB”数据

  根据时间推移,请求的相对频率也如图示发生衰减。每一条只对应单独一类存储对象,图中取其绝对值以增加易读性。另外圆点部分代表着访问请求频率降低至下一数量级的转折位置。

  在对每TB数据IO次数进行计算之后,我们可以看到这种暖性型数据的IO密度要远低于热门数据,这意味着此类数据已经不再需要利用三级复制机制加以保存,但却仍然需要具备可以接受的访问速度,同时拥有必要的保护手段以避免遭受磁盘、主机以及机架故障的影响。

  Facebook公司的工程师们已经打造出一款新型存储系统,也就是f4,专门用于保存这些暖性BLOB。工程师们在一篇论文中解释道:“f4是一款新型系统,能够在降低暖性BLOB有效复制因素的同时保持其容错性以及对较低数据吞需求的支持能力。”

Facebook存储技术方案:我们使尽浑身解数找出“暖性BLOB”数据

  Facebook的工程师们指出:

  f4采用里德所罗门编码机制并将数据块排布在多台不同机架之上,从而确保单一数据中心内部的磁盘、主机以及机架故障不会对数据可用性造成影响。它还在广域层面利用XOR编码机制以确保数据中心的故障弹性。f4已经在Facebook的生产环境之下运行了超过19个月。f4目前保存的逻辑数据超过65PB,帮助公司节约的存储空间则超过53PB。

  BLOB与聚合文件系统元数据共同被汇聚在以100GB为单位的逻辑分卷当中。这类逻辑分卷由数据文件、索引文件以及日志文件共同构成。其中索引文件其实是一套针对内存内存储主机查找结构的快照。当所有分卷都被锁定时,则不允许再创建新的分卷。

  这些分卷构成多个cell单元并被保存在数据中心内部,其中每个单元由包含15台主机的14套机架构成、每台主机配备30块4TB磁盘驱动器。每个分卷/字符串/数据块都拥有一个位于其它不同地理位置的对应分卷/字符串/数据块。Facebook公司还会在独立的第三个区域另行保存一套XOR数据内容。这套体系能够保证任意区域出现故障时,用户仍能顺利访问所需数据信息。

  那么一般性企业用户是否需要建立这样一套存储体系来打理自己的近线数据呢?基本上用不着,毕竟大部分企业用户根本不需要像Facebook那样面对如此庞大的数据总量,也不可能遇到同等规模的数据增长速度或者信息不变性。

原文出自【比特网】,转载请保留原文链接:http://storage.chinabyte.com/215/13106215.shtml

上一篇:关于更新Ubuntu14.04内核后,virtualbox无法开机vm的问题


下一篇:java面向对象下:JavaXML解析技术