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，依次请求各个组件获取数据。