LOSF海量小文件问题解决思路及开源库

"+++++++++++++++ LOSF 海量小文件存储和优化方案 +++++++++++++++++++++++++++++++++++++++++++++"
一.问题产生原因以及解决思路:
对于LOSF而言，IOPS/OPS是关键性能衡量指标，造成性能和存储效率低下的主要原因包括元数据管理、数据布局和I/O管理、Cache管理、网络开销等方面。

从理论分析以及上面LOSF优化实践来看，优化应该从元数据管理、缓存机制、合并小文件等方面展开，而且优化是一个系统工程，结合硬件、软件，从多

个层面同时着手，优化效果会更显著。http://files.cnblogs.com/files/yyx1-1/%E6%B7%98%E5%AE%9D%E5%BC%80%E6%BA%90%E5%BA%93%E6%9C%80%E6%96%B0%E7%89%88TFS.rar

二.成熟方案:
1.Facebook 推出了专门针对海量小文件的文件系统Haystack. (通过多个逻辑文件共享同一个物理文件、增加缓存层、部分元数据加载到内存等方式有效的解决了
Facebook海量图片存储问题)

2.Reiserfs在小文件存储的性能和效率上表现非常出色.(对于小于1KB的小文件，Rerserfs可以将数据直接存储在inode中。)

3.淘宝推出了类似的文件系统TFS(Tao File System)，通过将小文件合并成大文件、文件名隐含部分元数据等方式实现了海量小文件的高效存储。

三.LOSF问题根源
1.传统磁盘本质上一种机械装置，如FC,SAS, SATA磁盘，转速通常为5400/7200/10K/15K rpm不等。影响磁盘的关键因素是磁盘I/O服务时间，即磁盘完成一个
I/O请求所花费的时间，它由寻道时间、旋转延迟和数据传输时间三部分构成。因此可以计算磁盘的IOPS= 1000 ms/ (Tseek + Troatation + Ttransfer)，如
果忽略数据传输时间，理论上可以计算出磁盘的最大IOPS。当I/O访问模式为随机读写时，寻道时间和旋转延迟相对于顺序读写要明显增加，磁盘IOPS远小于
理论上最大值。定义有效工作时间Pt=磁盘传输时间/磁盘I/O服务时间，"由此可知随机读写单个文件效率要低于连续读写多个文件"。

2."对于磁盘文件系统来说，无论读写都存在元数据操作"。以EXTx文件系统写数据为例，向磁盘写入数据进行大量的元数据操作，包括更新inode目录、目录、
inode和数据块位图等。定义有效数据读写率Pd=所需数据/实际磁盘读写数据，其中实际磁盘读写数据为磁盘元数据与所需数据之和。当操作连续大文件时，
对元数据的操作开销可被庞大的数据操作开销分摊，但小文件的有效读写率小于大文件的，当小文件数量急剧增加时，对大量元数据的操作会严重影响系统的性能。

3.从上面对磁盘介质的分析可以看出，磁盘最适合顺序的大文件I/O读写模式，但非常不适合随机的小文件I/O读写模式，这是磁盘文件系统在海量小文件应用
下性能表现不佳的根本原因。前面已经提到，磁盘文件系统的设计大多都侧重于大文件，包括元数据管理、数据布局和I/O访问流程，另外VFS系统调用机制也
非常不利于LOSF，这些软件层面的机制和实现加剧了LOSF的性能问题。

四.Facebook开源库Haystack解决中心思路
1.每个图片存储为一个文件将会导致元数据太多，难以被全部缓存。Haystack的对策是：将多个图片存储在单个文件中，控制文件个数，维护大型文件，我们将
论述此方案是非常有效的。

2.在对Haystack的介绍中，需要区分两种元数据，不要混淆。一种是应用元数据，它是用来为浏览器构造检索图片所需的URL；另一种是文件系统元数据，用于
在磁盘上检索文件。

3.当用户访问一个页面，web服务器使用Directory为每个图片来构建一个URL（Directory中有足够的应用元数据来构造URL）。URL包含几块信息，每一块内容可
以对应到从浏览器访问CDN(或者Cache)直至最终在一台Store机器上检索到图片的各个步骤。一个典型的URL如下：

http://<cdn>/<cache>/<machine id="">/<logical volume,="" photo="">

第一个部分<cdn>指明了从哪个CDN查询此图片。到CDN后它使用最后部分的URL（逻辑卷和图片ID）即可查找缓存的图片。如果CDN未命中缓存，它从URL中删除<cdn>
相关信息，然后访问Cache。Cache的查找过程与之类似，如果还没命中，则去掉<cache>相关信息，请求被发至指定的Store机器(<machine id="">)。如果请求不经
过CDN直接发至Cache，其过程与上述类似，只是少了CDN这个环节。

4."文件系统在只有读或者只有写的情况下执行的更好，不太喜欢同时并发读写."

5.Haystack Store
Store机器的接口设计的很简约。读操作只需提供一些很明确的元数据信息，包括图片ID、哪个逻辑卷、哪台物理Store机器等。机器如果找到图片则返回其真实数据，
否则返回错误信息。
每个Store机器管理多个物理卷。每个物理卷存有百万张图片。读者可以将一个物理卷想象为一个非常大的文件（100GB），保存为'/hay/haystack<logical volume=""
id="">'。Store机器仅需要逻辑卷ID和文件offset就能非常快的访问一个图片。这是Haystack设计的主旨：不需要磁盘操作就可以检索文件名、偏移量、文件大小等元
数据。Store机器会将其下所有物理卷的文件描述符（open的文件"句柄"，卷的数量不多，数据量不大）缓存在内存中。同时，图片ID到文件系统元数据（文件、偏移量、
大小等）的映射（后文简称为"内存中映射"）是检索图片的重要条件，也会全部缓存在内存中。
现在我们描述一下物理卷和内存中映射的结构。一个物理卷可以理解为一个大型文件，其中包含一系列的needle。每个needle就是一张图片。图5说明了卷文件和每个
needle的格式。Table1描述了needle中的字段。

"为了快速的检索needle，Store机器需要为每个卷维护一个内存中的key-value映射。映射的Key就是（needle.key+needle.alternate_key）的组合，映射的Value就是
needle的flag、size、卷offset（都以byte为单位）。如果Store机器崩溃、重启，它可以直接分析卷文件来重新构建这个映射（构建完成之前不处理请求）"

"++++++++++++++++++++ LOSF 海量小文件存储和优化方案 ++++++++++++++++++++++++++++++++++++++++++++++++"