浅析Facebook软件架构：Tao和BLOB的实现原理

分享到

作者伍昆火龙果软件发布于 2014-10-29

用户数达10亿级别，Facebook每天需要存储多达4千亿的照片，面对如此庞大的数据，Facebook采用了 Tao和暖性BLOB存储系统。那么，这些存储架构是如何实现的？采用了哪些原理呢？且看本文解析。

Tao是一套针对读取进行优化的数据存储机制，并以单一地理分布实例的方式部署在Facebook当中。和Google的Megastore，Spanner地位等同，它底层持久化采用的是MySql，上层的Cache Server使用的是分布式的Memcached。 Tao系统的设计初衷在于为“数PB级别”的庞大数据集提供每秒超过十亿次读取操作。

用户数达10亿级别的Facebook是如何使用这些存储系统的呢？原文作者Murat针对图形数据库TAO和BLOB 存储系统进行解析。

以下为译文：

图形数据库TAO

TAO是Facebook一种用来处理社交图形信息的分布式数据库。每天达千亿级别的图片处理量，必须采用一种高效，稳定，扩展性好的图形数据存储策略才能很好地对此进行处理。

在TAO之前，Facebook的Web服务器是直接访问MySql来进行图片数据读写操作，高度依赖分布式存储系统memcache作为旁视缓存。而TAO数据存储实现了直接的图形抽象处理，从而避免了旁视缓存架构的某些基础弊端。它使用了一种对象和关联模型，采取MySql做连续存储，对数据库的访问进行调整处理，使用自有的图形感知缓存。考虑到跨地域的扩展性需求，在数据复制方面使用了主每记录(per-record master)方法。

F4—暖性*BLOB 存储系统(OSDI’14)

Facebook已经在其近线存储体系当中彻底弃用RAID与复制机制，转而采用分布式擦除编码以隔离其所谓的“暖性BLOB”。目前，Facebook新的架构把多媒体数据划分为两个类别：

存储在Haystack的热/新添加的媒体数据；
存储在F4的暖性数据，暖性相对于沉没/使用率低但非新添加而言。

*注：BLOB即binary large object，二进制大型物件。暖性——是指那些必须进行保存，访问频率低于热门数据但却又高于归档或者冷门数据的信息。通常情况下，这些数据已经产生了一周以上。热门BLOB的访问频率仍然较高。

Facebook每天需要存储多达4千亿的照片，所以根据不同数据热度来采取相应的存储策略与方式是很有必要的。Facebook发现不同时期的BLOB与热度之间有一种强联系。新创建的BLOBs被调用的频率远高于旧的BLOBs，简单说就是使用热度高。实践证明，九成以上的当日新增数据比已创建一周的旧数据的访问请求率要高得多。此外，不同的创建时期与删除率之间也有强联系。旧BLOBs的删除率远低于新BLOBs的删除率，这些旧数据就是前述的暖性数据。

他们还发现暖性内容在整个数据库中占据较大的比重。他们尝试把最近九个月的数据划为三段：0-3个月，3-6个月，6-9个月。第一段分区的暖性数据占比超过80%，第三段分区的暖性数据占比超过89%，暖性数据呈增长趋势。根据这些分析，Facebook为BLOB数据存储进行了划分设计，引入F4存储系统，以区别于存放在Haystack的热数据。相对冷数据，一般要花费数个小时甚至数天才能读取而言，暖性数据的提出是为了照顾用户的需求。

F4是一款新型系统，能够在降低暖性BLOB有效复制因素的同时保持其容错性以及对较低数据吞需求的支持能力，专门用于保存这些暖性BLOB。

F4提供了一种简单，高效，容错的暖性数据存储方案，把有效复制因子(effective-replication-factor)从3.6减到2.8甚至2.1。使用奇偶区或条块检验的纠错码。

F4的数据和索引文件与Haystack相同，日志文件却是新类型。这是一种写前日志，附有tombstones(墓碑)对已删除BLOBs进行追踪。

F4有专门的backoff(后备)节点来帮助BLOB在线重建，这类似于memcache中gutter(水槽)节点的容错能力。在引入F4 19个月后，现在F4的逻辑数据量达到65PB，数据存储量达53PB。

分享到