OSDI 2010 Paper 分布式元数据论文阅读笔记整理
问题
到2010年为止，用户已经在Facebook上传了超过650亿张照片，对于每个上传的照片，Facebook生成并存储四个不同大小的图像，导致目前存储了超过2600亿张图片，相当于超过20PB的数据。用户每周上传10亿张新照片（~60TB），Facebook在峰值时每秒提供超过100万张图片。庞大的数据量为图片存储提出了新的挑战。
挑战
在Facebook图片存储中，数据只写一次，经常读取，从不修改，很少删除。基于POSIX的文件系统的缺点是每个目录和文件的元数据，读取文件时需要先访问元数据，导致元数据成为访问瓶颈。对于利用NFS上的网络连接存储设备，由于元数据查找，读取一张图片需要几个磁盘操作，导致额外成本和吞吐量限制。
本文方法
本文描述了Haystack，为Facebook的照片应用程序优化的对象存储系统，成本更低、性能更高。
-
高吞吐量和低延迟。大幅减少在磁盘上查找照片所需的每张照片的元数据，将所有元数据保存在主存储器中，每次读取最多需要一个磁盘操作来实现高吞吐量和低延迟。
-
故障容忍。在不同地理位置复制每张照片，根据需要复制数据以获得冗余，从而容忍故障。
-
成本效率。考虑每TB可用存储的成本和对每TB可用存储器的标准化读取率。与NAS设备上的等效TB相比，每个可用TB的成本降低了约28%，每秒处理的读取量增加了约4倍。
三大组件
目录服务器：元数据服务器
-
维护逻辑卷到物理卷的映射关系
-
维护照片ID到逻辑卷的映射
-
负载均衡：在逻辑卷之间完成写操作的负载均衡，在物理卷里完成读操作的负载均衡
-
决定用户请求是发送给缓存还是CDN
-
当一个节点故障或者运维操作，或者磁盘空间满，将逻辑卷设为只读状态
存储服务器：数据服务器，大量的数据服务器存储数据
-
以物理卷的形式保存数据，每个物理卷100GB，物理卷即一个物理文件
-
不同存储服务器上的多个物理卷组成一个逻辑卷，形成副本
缓存
-
主要通过缓存系统响应用户请求
-
Web服务器请求目录服务器时，生成http://<CDN>/<Cache>/<Machine>/<Logical Volume, Photo>格式的URL，Web服务器依次请求各组件，直到获取数据
写流程
-
Web服务器请求目录服务器获取可写的逻辑卷
-
逻辑卷中的所有物理卷都追加完成，才算追加成功
-
追加成功后所有物理卷中都有该文件，但偏移可能不同，主要是因为存在多客户端的并发追加写
-
写操作并没有更新缓存
物理卷存储格式
-
每个Photo称之为一个Needle
-
每个Needle的元数据约20字节，常驻内存，但在磁盘上有一份持久化的索引
-
数据删除并不真的删除，而是增加一条删除日志
-
周期定做Compaction，回收空间
总结
针对Facebook海量照片存储，访问模式为数据只写一次，经常读取，从不修改，很少删除。因此设计了Haystack，对象存储系统。（1）大幅减少在磁盘上查找照片所需的每张照片的元数据（20字节），将所有元数据保存在主存储器中，每次读取最多需要一个磁盘操作来实现高吞吐量和低延迟。（2）查询图片时，目录服务器生成http://<CDN>/<Cache>/<Machine>/<Logical Volume, Photo>格式的URL，依次请求各个组件获取数据。