2014如何处理海量图片存储.docVIP

Facebook如何处理海量图片存储Facebook 用户已经上传了150亿张照片，加上每张照片有四个不同尺寸的缩略图，就共有600多亿张图片，总容量超过1.5PB，而每周新增的照片为2亿2000万张，约25TB，高峰期，Facebook 每秒处理55万张照片，这些数字让如何管理这些数据成为一个巨大的挑战。旧的 NFS 照片架构老的照片系统架构分以下几个层存储在 Netapp NAS上：上传层接收用户上传的照片并保存在 NFS 存储层。 照片服务层接收 HTTP 请求并从 NFS 存储层输出照片。 NFS存储层建立在商业存储系统之上。 图片写入 图片读取 因为每张照片都以文件形式单独存储，这样庞大的照片量导致非常庞大的元数据规模，超过了 NFS 存储层的缓存上限，导致每次照片请求会上传都包含多次I/O操作。庞大的元数据成为整个照片架构的瓶颈。这就是为什么 Facebook 主要依赖 CDN 的原因。为了解决这些问题，他们做了两项优化：Cachr: 一个缓存服务器，缓存 Facebook 的小尺寸用户资料照片。 NFS文件句柄缓存：部署在照片输出层，以降低 NFS 存储层的元数据开销。 新的 Haystack 照片架构新的照片架构将输出层和存储层合并为一个物理层，建立在一个基于 HTTP 的照片服务器上，照片存储在一个叫做 haystack 的对象库，以消除照片读取操作中不必要的元数据开销。新架构中，I/O 操作只针对真正的照片数据（而不是文件系统元数据）。haystack 可以细分为以下几个功能层：HTTP 服务器 照片存储 Haystack 对象存储 文件系统 存储空间 存储Haystack 部署在商业存储刀片服务器上，典型配置为一个2U的服务器，包含：两个4核CPU 16GB – 32GB 内存 硬件 RAID，含256-512M NVRAM 高速缓存 超过12个1TB SATA 硬盘 每个刀片服务器提供大约10TB的存储能力，使用了硬件 RAID-6, RAID 6在保持低成本的基础上实现了很好的性能和冗余。不佳的写性能可以通过高速缓存解决，硬盘缓存被禁用以防止断电损失。文件系统Haystack 对象库是建立在10TB容量的单一文件系统之上。文件系统中的每个文件都在一张区块表中对应具体的物理位置，目前使用的文件系统为 XFS。Haystack 对象库Haystack 是一个简单的日志结构，存储着其内部数据对象的指针。一个 Haystack 包括两个文件，包括指针和索引文件： Haystack 对象存储结构 指针和索引文件结构 Haystack 写操作Haystack 写操作同步将指针追加到 haystack 存储文件，当指针积累到一定程度，就会生成索引写到索引文件。为了降低硬件故障带来的损失，索引文件还会定期写道存储空间中。 Haystack 读操作传到 haystack 读操作的参数包括指针的偏移量，key，代用Key,Cookie 以及数据尺寸。Haystack 于是根据数据尺寸从文件中读取整个指针。 Haystack 删除操作删除比较简单，只是在 Haystack 存储的指针上设置一个已删除标志。已经删除的指针和索引的空间并不回收。 照片存储服务器照片存储服务器负责接受 HTTP 请求，并转换成相应的 Haystack 操作。为了降低I/O操作，该服务器维护着全部 Haystack 中文件索引的缓存。服务器启动时，系统就会将这些索引读到缓存中。由于每个节点都有数百万张照片，必须保证索引的容量不会超过服务器的物理内存。对于用户上传的图片，系统分配一个64位的独立ID，照片接着被缩放成4种不同尺寸，每种尺寸的图拥有相同的随机 Cookie 和 ID，图片尺寸描述（大，中，小，缩略图）被存在代用key 中。接着上传服务器通知照片存储服务器将这些资料联通图片存储到 haystack 中。每张图片的索引缓存包含以下数据 Haystack 使用 Google 的开源 sparse hash data 结构以保证内存中的索引缓存尽可能小。 照片存储的写/修改操作写操作将照片数据写到 Haystack 存储并更新内存中的索引。如果索引中已经包含相同的 Key，说明是修改操作。 照片存储的读操作传递到 Haystack 的参数包括 Haystack ID，照片的 Key, 尺寸以及 Cookie，服务器从缓存中查找并到 Haystack 中读取真正的数据。 照片存储的删除操作通知 Haystack 执行删除操作之后，内存中的索引缓存会被更新，将便宜量设置为0，表示照片已被删除。 重新捆扎重新捆扎会复制并建立新的 Haystack，期间，略过那些已经删除的照片的数据，并重新建立