分享照片是Facebook上最流行的的功能之一。截至目前，用户已经上传超过15亿张照片，这使得Facebook成为最大的照片共享网站。对于每一个上传的照片，Facebook都生成并存储四个大小不同的图像，从而转化为共60亿张照片，总容量超过1.5PB。目前以每周220万新照片的速度增长，相当于每周要额外增加25TB存储。在高峰期每秒需要传输55万照片。这些数字对Facebook的照片存储基础设施的一个重大的挑战。

旧的 NFS 照片架构

老的照片系统架构分以下几个层：

因为每张照片都以文件形式单独存储，这样庞大的照片量导致非常庞大的元数据规模，超过了 NFS 存储层的缓存上限，导致每次请求上传都包含多次I/O操作。庞大的元数据成为整个照片架构的瓶颈。这就是为什么 Facebook 主要依赖 CDN 的原因。为了解决这些问题，他们做了两项优化：

因为每张照片都以文件形式单独存储，大量为目录及文件在NFS 存储层上产生了大量的元数据， 这个规模的元数据量远远超过了超过了NFS 存储层的缓存上限，导致每次招聘请求会上传都包含多次I/O操作。庞大的元数据成为整个照片架构的瓶颈。这就是为什么 Facebook主要依赖 CDN 的原因。为了解决这些问题，他们做了两项优化：

新的 Haystack 照片架构

新的照片架构将输出层和存储层合并为一个物理层，建立在一个基于HTTP 的照片服务器上，照片存储在一个叫做haystack 的对象库，以消除照片读取操作中不必要的元数据开销。新架构中，I/O 操作只针对真正的照片数据（而不是文件系统元数据）。haystack 可以细分为以下几个功能层：

在下面的介绍中，我们会对于上述的每个功能层做详细的讲述。

存储空间

Haystack 部署在商业存储刀片服务器上，典型配置为一个2U的服务器，包含：

每个刀片服务器提供大约10TB的存储能力，使用了硬件 RAID-6, RAID 6在保持低成本的基础上实现了很好的性能和冗余。不佳的写性能可以通过RAID控制器和NVRAM缓存回写解决，写由于读取大多是随机的，NVRAM缓存是完全用于写入的。

文件系统

Haystack 对象库是建立在10TB容量的单一文件系统之上。

图片读取请求需要在读取系统调用这些文件的位置偏移，但是为了执行读取操作，文件系统必须先找到实际物理卷上的数据。文件系统中的每个文件都被一个叫做inode结构标识。inode包含了一个磁盘上逻辑文件偏移和物理区块偏移的映射。在使用的特殊类型文件系统时大文件块映射可能相当大。

基于文件系统的区块为给个逻辑区块和大文件保存映射。这些信息通常不适合保存在inode的缓存中，而是存储在在间接地址块。所以在读取文件的时候必须按照特定的流程。这里可以多个是间接地址块，所以一个读取会产生多个I/O取决于是否间接地址块被缓存。

该系统只为连续范围的区块保持映射。一个连续的大文件的块映射可以只由一个范围的标识，这样是适应inode的系统需求的。但是，如果该文件是一个被切割的不连续的块的话，他的块地图可能非常的大。以上可以通过文件系统主动为大的物理文件分配大块的空间来减少碎片。

目前使用的文件系统为XFS，一个很大程度提供高效的文件预分配系统。