f4: Facebook’s Warm BLOB Storage System——Erasure Code
Facebook在OSDI 2014上发表论文f4: Facebook’s Warm BLOB Storage System，这个系统主要目的就是降低存储成本，在容忍磁盘，主机，机架，数据中心的同时提供2.1倍的存储因子(用户存储的1bit数据实际上占用磁盘2.1bit空间)。本文只讨论f4系统的核心Erasure Code部分，如何降低存储因子。
Facebook热的blob数据依然存在Haystack中，访问不那么频繁的数据(Warm)放入存储系统f4中。Haystack存储blob的思路就是将多个这样的blob数据聚合在一个文件中，每个blob在文件中的位置信息存储在内存中，为了容错，这些位置信息同时会持久化在硬盘上，叫做index file. 和大部分文件系统一样，为了容错，每个数据文件都是3备份，同时单机上做了RAID6(1.2X)，这样实际上，存储因子是3 * 1.2 = 3.6倍。也就是说，逻辑上1个bit的数据实际上在磁盘上存了3.6个bit。对于facebook这样数据量级的公司成本还是太高了。实际上，根据facebook的统计，很多数据比如photo和video随着时间的推移，访问的频度越来越小。对于这样的数据，读性能不需要那么高。facebook的做法就是将这些个访问不那么频繁的数据做EC编码，在单数据中心内，facebook选择经典的Reed-solomon编码，n=10,k=4，f4将数据文件切成一个个的1GB大小的block，对连续的10个data block生成4个parity block，一共14个block，可以同时容忍最多4个block，如果读请求涉及的data block没有丢失，直接访问这个block即可，不需要recover。如果data block丢失，需要访问其他block中任意10个进行恢复。为了容忍机架故障，facebook将这14个block放在不同的机架上。这样，单数据中心内，磁盘，主机，机架故障都可以容忍，这时的存储因子是14/10=1.4。为了容忍数据中心故障，所有的block包括parity block在另外一个数据中心也复制一份，这样下来，整个的存储因子是2.8. 由于数据中心故障比较少见，为了进一步降低成本，f4在数据中心之间使用XOR编码，即3个数据中心A，B，C，数据中心A和B分别各自存储各自的data block和parity block,数据中心A的block和B的block进行XOR编码结果block存在数据中心C中。这样，任意一个数据中心挂掉，数据都可以从另外两个数据中心恢复，存储因子(1.4 * 2 + 1.4)/2=2.1。
