facebook的图片存储haystack数据结构
Haystack数据结构
Haystack提出了一种通用的基于HTTP的对象存储，它含有指针，映射到存储对象。在Haystack中以指针储存照片，把数以十万计的图像聚集到一个Haystack存储文件，从而消除了元数据负荷。这就使得元数据的开销非常小，并且使我们能够在存储文件和内存索引中存储每个指针的位置。这就使得能用少量的I/O操作来完成图像数据的检索，可以消除一切不必要的元数据开销。
Haystack是一个简单日志结构（只追加）的对象存储，包含描述存储对象的指针。一个Haystack包括两个文件——实际的包含指针的Haystack存储文件，以及一个索引文件。HayStack中的图片顺序的存放在物理卷中，获取图片在物理卷中的偏移即可读取图片，每张图片称为一个needle，图片的存储结构如下所示。其中，key为图片的唯一标示，alternate key为尺寸的标示，flag为删除标志，size为数据大小，data为实际的数据。第一个8KB的Haystack存储由超级块所占用。紧接着超级块的是指针，每个指针由页眉、数据、和页脚组成。一个指针是由其﹤Offset（偏移量）, Key, Alternate Key(替换键),Cookie﹥元组唯一确定，其中偏移量是指在Haystack存储中的指针偏移量。
文件：
Haystack 对象存储结构
HayStack为每张图片在内存中维护图片与其位置的映射表，在图片被写入时更新映射关系，每次系统启动时可通过读取物理卷并构造映射表，但这样做很耗时间，但HayStack通过为每张图片构造index file来简化了系统启动时映射表的构建，index file的结构如下所示，其主要包含key与对应图片位置的映射关系，系统启动时，通过读取index file便能很快的构造映射表。
haystack工作流程
Haystack的写请求(图片上传)处理流程为：Web Server首先请求Haystack Directory获取图片的id和可写的逻辑卷轴，接着将数据写入对应的每一个物理卷轴(备份数一般为3)。Haystack写操作同步添加新的指针到Haystack存储文件中。当指针成功添加到庞大的Haystack存储文件中之后，相应的索引记录也被写入索引文件。由于索引文件不是至关重要的，为了达到更快的性能，该索引记录是异步写。
索引文件还会定期被刷新到下面的存储设备，以便限制由硬件故障所引起的恢复操作的程度。在系统崩溃或突然断电的情况下，Haystack恢复程序丢弃所有存储中的不完整的指针，同时截断Haystack存储文件直到最后一个有效的指针，然后，在Haystack存储文件最后为所有跟踪的孤立指针写入丢失的索引记录。
Haystack不允许覆盖已存在的指针偏移量，因此，如果某个指针的数据需要修改，其修改后的新版本必须使用相同的﹤Key, Alternate Key, Cookie﹥元组。然后应用程序就可以认为，在那些有着多个关键字的指针中，具有最大偏移量的指针就是最新添加的指针。
Haystack图片读取请求大致流程为：用户访问一个页面时，Web Server请求Haystack Directory构造一个URL：http:// CDN/ Cache/ machine/<logic volume,photo >，后续根据各个部分的信息依次访问CDN，Cache和后端的Haystack Store存储节点。Haystack Directory构造URL时可以省略部分从而使得用户直接请求Haystack Cache而不必经过CDN。Haystack cache收到的请求包含两个部分：用户Browser的请求及CDN的请求，Haystack cache只缓存用户Browser发送的请求且要求请求的Haystack Store存储节点是可写的。一般来说，Haystack Store的存储节点写一段时间以后达到容量上限变为只读，因此，可写节点的图片为最近增加的图片，是热点数据。
Haystack 删除操作比较简单，只是在 Haystack 存储的指针上设置一个已删除标志，已经删除的指针和索引的空间并不回收。可通过定期的对物理卷进行合并，以回收已删除的空间。