海量小文件问题综述
海量小文件问题综述
海量小文件LOSF问题是工业界和学术界公认的难题，分析了LOSF问题的由来以及典型的应用场景，并简要阐述了当前文件系统在LOSF优化方面的进展。重点分析LOSF问题的根本缘由，并给出具体的优化方法和策略，指望对LOSF问题的研究和优化实践提供必定的理论指导。html
一、LOSF问题概述
在互联网(尤为是移动互联网)、物联网、云计算、大数据等高速发展的大背景下，数据呈现爆炸式地增加。根据IDC的预测，到2020年产生的数据量将达到40ZB，而以前2011年6月的预测是35ZB。然而，社会化网络、移动通讯、网络视频音频、电子商务、传感器网络、科学实验等各类应用产生的数据，不只存储容量巨大，并且还具备数据类型繁多、数据大小变化大、流动快等显著特色，每每可以产生千万级、亿级甚至十亿、百亿级的海量小文件，并且更多地是海量大小文件混合存储。因为在元数据管理、访问性能、存储效率等方面面临巨大的挑战性，所以海量小文件（LOSF，lots of small files）问题成为了工业界和学术界公认的难题。node
一般咱们认为大小在1MB之内的文件称为小文件，百万级数量及以上称为海量，由此量化定义海量小文件问题，如下简称LOSF。LOSF应用在目前实际中愈来愈常见，如社交网站、电子商务、广电、网络视频、高性能计算，这里举几个典型应用场景。著名的社交网站Facebook存储了600亿张以上的图片，推出了专门针对海量小图片定制优化的Haystack进行存储。淘宝目前应该是最大C2C电子商务网站，存储超过200亿张图片，平均大小仅为15KB，也推出了针对小文件优化的TFS文件系统存储这些图片，而且进行了开源。歌华有线能够进行图书和视频的在线点播，图书每页会扫描成一个几十KB大小的图片，总图片数量可以超过20亿；视频会由切片服务器根据视频码流切割成1MB左右的分片文件，100个频道一个星期的点播量，分片文件数量可达到1000万量级。动漫渲染和影视后期制做应用，会使用大量的视频、音频、图像、纹理等原理素材，一部普通的动画电影可能包含超过500万的小文件，平均大小在10-20KB之间。金融票据影像，须要对大量原始票据进行扫描造成图片和描述信息文件，单个文件大小为几KB至几百KB的不等，文件数量达到数千万乃至数亿，而且逐年增加。算法
目前的文件系统，包括本地文件系统、分布式文件系统和对象存储系统，都是主要针对大文件设计的，好比XFS/EXT四、Lustre、GlusterFS、GPFS、ISLION、GFS、HDFS，在元数据管理、数据布局、条带设计、缓存管理等实现策略上都侧重大文件，而海量小文件应用在性能和存储效率方面要大幅下降，甚至没法工做。针对LOSF问题，出现一些勇敢的挑战者。EXT4主要对EXT3进行了两方面的优化，一是inode预分配，这使得inode具备很好的局部性特征，同一目录文件inode尽可能放在一块儿，加速了目录寻址与操做性能。所以在小文件应用方面也具备很好的性能表现。二是extent/delay/multi的数据块分配策略，这些策略使得大文件的数据块保持连续存储在磁盘上，数据寻址次数大大减小，显著提升I/O吞吐量。所以，EXT4对于大小文件综合性能表现比较均衡。Reiserfs对小文件做了优化，并使用B* tree组织数据，加速了数据寻址，大大下降了open/create/delete/close等系统调用开销。Reiserfs的tail package功能能够对一些小文件不分配inode，而是将这些文件打包，存放在同一个磁盘分块中。对于小于1KB的小文件，Rerserfs能够将数据直接存储在inode中。所以， Reiserfs在小文件存储的性能和效率上表现很是出色。Facebook 推出了专门针对海量小文件的文件系统Haystack，经过多个逻辑文件共享同一个物理文件、增长缓存层、部分元数据加载到内存等方式有效的解决了Facebook海量图片存储问题。淘宝推出了相似的文件系统TFS(Tao File System)，经过将小文件合并成大文件、文件名隐含部分元数据等方式实现了海量小文件的高效存储。FastDFS针对小文件的优化相似于TFS。国防科学技术大学对Lustre进行了小文件优化工做，在OST组件中设计并实现了一种分布独立式的小文件Cache结构：Filter Cache，经过扩展Lustre的OST端的数据通路，在原有数据通路的基础上，增长对小对象I/O的缓存措施，以此来改善Lustre性能。数据库
对于LOSF而言，IOPS/OPS是关键性能衡量指标，形成性能和存储效率低下的主要缘由包括元数据管理、数据布局和I/O管理、Cache管理、网络开销等方面。从理论分析以及上面LOSF优化实践来看，优化应该从元数据管理、缓存机制、合并小文件等方面展开，并且优化是一个系统工程，结合硬件、软件，从多个层面同时着手，优化效果会更显著。缓存
二、LOSF问题根源
衡量存储系统性能主要有两个关键指标，即IOPS和数据吞吐量。IOPS (Input/Output Per Second) 即每秒的输入输出量 ( 或读写次数 ) ，是衡量存储系统性能的主要指标之一。 IOPS 是指单位时间内系统能处理的 I/O 请求数量，通常以每秒处理的 I/O 请求数量为单位， I/O 请求一般为读或写数据操做请求。随机读写频繁的应用，如 OLTP(OnlineTransaction Processing) ，IOPS 是关键衡量指标。另外一个重要指标是数据吞吐量(Throughput)，指单位时间内能够成功传输的数据数量。对于大量顺序读写的应用，如VOD(VideoOn Demand)，则更关注吞吐量指标。性能优化
传统磁盘本质上一种机械装置，如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服务时间，由此可知随机读写单个文件效率要低于连续读写多个文件。对于磁盘文件系统来讲，不管读写都存在元数据操做。以EXTx文件系统写数据为例，向磁盘写入数据进行大量的元数据操做，包括更新inode目录、目录、inode和数据块位图等。定义有效数据读写率Pd=所需数据/实际磁盘读写数据，其中实际磁盘读写数据为磁盘元数据与所需数据之和。当操做连续大文件时，对元数据的操做开销可被庞大的数据操做开销分摊，但小文件的有效读写率小于大文件的，当小文件数量急剧增长时，对大量元数据的操做会严重影响系统的性能。服务器
从上面对磁盘介质的分析能够看出，磁盘最适合顺序的大文件I/O读写模式，但很是不适合随机的小文件I/O读写模式，这是磁盘文件系统在海量小文件应用下性能表现不佳的根本缘由。前面已经提到，磁盘文件系统的设计大多都侧重于大文件，包括元数据管理、数据布局和I/O访问流程，另外VFS系统调用机制也很是不利于LOSF，这些软件层面的机制和实现加重了LOSF的性能问题。网络
(1) 元数据管理低效数据结构
因为小文件数据内容较少，所以元数据的访问性能对小文件访问性能影响巨大。当前主流的磁盘文件系统基本都是面向大文件高聚合带宽设计的，而不是小文件的低延迟访问。磁盘文件系统中，目录项(dentry)、索引节点(inode)和数据(data)保存在存储介质的不一样位置上。所以，访问一个文件须要经历至少3次独立的访问。这样，并发的小文件访问就转变成了大量的随机访问，而这种访问对于普遍使用的磁盘来讲是很是低效的。同时，文件系统一般采用Hash树、 B+树或B*树来组织和索引目录，这种方法不能在数以亿计的大目录中很好的扩展，海量目录下检索效率会明显降低。正是因为单个目录元数据组织能力的低效，文件系统使用者一般被鼓励把文件分散在多层次的目录中以提升性能。然而，这种方法会进一步加大路径查询的开销。架构
(2) 数据布局低效
磁盘文件系统使用块来组织磁盘数据，并在inode中使用多级指针或hash树来索引文件数据块。数据块一般比较小，通常为1KB、2KB或4KB。当文件须要存储数据时，文件系统根据预约的策略分配数据块，分配策略会综合考虑数据局部性、存储空间利用效率等因素，一般会优先考虑大文件I/O带宽。对于大文件，数据块会尽可能进行连续分配，具备比较好的空间局部性。对于小文件，尤为是大文件和小文件混合存储或者通过大量删除和修改后，数据块分配的随机性会进一步加重，数据块可能零散分布在磁盘上的不一样位置，而且会形成大量的磁盘碎片(包括内部碎片和外部碎片)，不只形成访问性能降低，还致使大量磁盘空间浪费。对于特别小的小文件，好比小于4KB，inode与数据分开存储，这种数据布局也没有充分利用空间局部性，致使随机I/O访问，目前已经有文件系统实现了data in inode。
(3) I/O访问流程复杂
Linux等操做系统采用VFS或相似机制来抽象文件系统的实现，提供标准统一访问接口和流程，它提供通用的Cache机制，处理文件系统相关的全部系统调用，与具体文件系统和其余内核组件(如内存管理)交互。VFS能够屏蔽底层文件系统实现细节，简化文件系统设计，实现对不一样文件系统支持的扩展。VFS通用模型中有涉及四种数据类型：超级块对象(superblock object)、索引结点对象(inode object)、文件对象(file object)和目录项对象(dentry object)，进程在进行I/O访问过程当中须要频繁与它们交互(以下图所示)。
进程与VFS对象交互
典型的I/O读写流程是这样：open()àseek()àread()/write()àclose()。其中，文件的open()操做是一项复杂的工做, 文件的打开操做流程大体是这样的: 首先在当前进程的文件描述表fdtale中分配一个空的文件描述符fd , 而后在filp_cachep中建立一个file struct , 调用do_path_lookup()找到文件的inode ,取出inode的文件操做方法file_operations赋给file struct ,并调用f->f_op->open()执行打开的操做；最后根据文件描述符fd将file安装在当前进程文件描述表fdtable对应的位置。这样在以后的read()/write()文件操做时, 只须要根据文件描述符fd,就能够在当前进程的描述表中找到该文件的file对象,而后调用f->f_op操做方法对文件进行操做。用户空间使用路径名来表示文件，而内核中对文件的操做是依据上述四种数据类型对象，所以在open()过程当中须要进行路径查找do_path_lookup，将路径名进行份量解析，转换成对应文件在内核中内部表示。这个工做至关重要，而且很是占用系统开销，尤为是大量频繁open比较深目录下的文件。
对于小文件的I/O访问过程，读写数据量比较小，这些流程太过复杂，系统调用开销太大，尤为是其中的open()操做占用了大部分的操做时间。当面对海量小文件并发访问，读写以前的准备工做占用了绝大部分系统时间，有效磁盘服务时间很是低，从而致使小I/O性能极度低下。
对于大多数分布式文件系统而言，一般将元数据与数据二者独立开来，即控制流与数据流进行分离，从而得到更高的系统扩展性和I/O并发性。数据和I/O访问负载被分散到多个物理独立的存储节点，从而实现系统的高扩展性和高性能，每一个节点使用磁盘文件系统管理数据，好比XFS、EXT四、XFS等。所以，相对于磁盘文件系统而言，每一个节点的小文件问题是相同的。因为分布式的架构，分布式文件系统中的网络通讯、元数据服务MDC、Cache管理、数据布局和I/O访问模式等都会对IOPS/OPS性能产生影响，进一步加重LOSF问题。
(1) 网络通讯开销
相对于磁盘文件系统，分布式文件系统客户端与MDC和I/O服务器之间增长了网络链接，一般为延迟较大的TCP/IP网络。元数据和数据访问都通过网络传输，增长了RPC网络通讯开销，扩大了小文件访问延时。
(2) MDC管理
因为分布式文件系统将元数据和数据分开存储，在读写小文件以前，须要经过与MDC进行通讯获取位置信息。和磁盘文件系统相比，这一过程至关于额外增长一次网络传输开销和元数据服务访问开销。这对小文件I/O来讲，开销影响很是大。
(3) 数据布局和I/O访问模式
对于大文件，分布式文件系统每每采用条带化技术对文件进行切片，并发发在多个数据服务器上进行存储，以此来提升用户对文件访问的并发性，从而提升对大文件的访问性能。而对于小文件，因为其不利于条带化，通常采用将单个文件存储在单个数据服务器上的策略。但当小文件数量达到必定程度后，对小文件的大量地重复访问将会给数据服务器带来性能上的负担和I/O瓶颈问题。
分布式文件系统客户端在访问小文件I/O时，采用大文件请求相同的方式，为每一个文件访问请求分别创建链接或者RPC请求。TCP/IP网络在延迟和传输效率方面比较低，这种I/O访问模式很是不利于小文件，I/O效率低下。
(4) Cache管理
分布式文件系统的Cache设计对小文件I/O性能做用不明显，用户访问小文件时须要额外的I/O带宽。客户端Cache一般只对本机有效，不一样客户端访问同一个文件数据时，每一个用户都须要把数据复制到本地Cache中。对于小文件I/O操做来讲，访问的文件内容只占页内不多一部分，但也须要整个物理页从I/O服务端的磁盘读入操做系统的文件缓存再访问。从服务端读取数据并缓存至Client端的Cache中这一过程须要额外的流量，小文件I/O越频繁，须要的额外总流量就越多，系统的整体I/O性能就越低。
总结一下，经过以上的分析咱们能够看出，无论是磁盘文件系统仍是分布式文件系统，LOSF问题主要源自元数据管理、数据布局、Cache管理、I/O访问流程、网络开销等几个方面。所以，针对问题的根源能够施行特定的优化措施，优化思路大致分为两种：一是减小数据访问次数，二是减小数据访问时间。具体来说，能够从合并小文件、增大Cache命中率、优化元数据管理等方面提升访问效率，从而达到优化海量小文件存储的效果。同时，能够结合硬件和应用优化，进一步加强优化效果。
三、LOSF优化策略
海量小文件因为数量巨大，并且一般须要进行共享和并发访问，目前一般采用分布式系统进行存储，包括分布式文件系统和分布式对象存储系统，每一个存储节点底层采用磁盘文件系统进行管理。所以这里重点介绍分布式存储系统的LOSF优化策略。前面咱们已经提到，Haystack, TFS, FastDFS, Lustre等分布式存储系统在LOSF方面的优化工做实践，结合上面对LOSF问题根源的剖析，咱们认为硬件优化、Cache管理优化、小文件合并存储、元数据管理优化等是几种行之有效的优化方法。固然，性能优化没有黄金法则，必须是在对现有系统充分的测试和分析的基础上，有针对性地选择合适的优化策略，方能有实质性优化效果。
3.1硬件优化
若是不考虑成本问题，硬件优化是最为直接有效的优化方法，按照减小数据访问时间的优化思路，采用更高性能的硬件来提升LOSF性能。好比，使用速度更快的SSD做为所有或部分存储介质，部分部署时做为分层存储或者Cache加速，能够显著提升随机读写场景下的IOPS/OPS性能；采用处理能力更强或更多的CPU，能够提升系统的I/O处理速度和并发性；配置更大空容量的内存，以空间换时间，有效提升数据缓存命中率；采用延迟更小、带宽更高的网络设备优化网络传输效率，好比万兆网络或InfiniBand网络；部署多路径I/O通道提升数据吞吐量和并发访问，如LAN网络和SAN网络。硬件优化的目标是消除I/O物理通道上的瓶颈，保证理论上的性能最大化，为软件层面的优化工做作铺垫。值得一提的是，硬件设备在性能上要作到匹配，尤为是磁盘和网络，不然容易致使性能瓶颈或者成本浪费。
3.2Cache管理
Cache技术普遍应用于存储系统的各个领域，好比CPU L1/L2 Cache、文件系统、分布式存储系统等。Cache技术主要经过空间换时间的策略，利用数据访问的时间和空间局部性，尽可能提升数据访问的缓存命中率，从而提升系统的性能。存储系统中的Cache位于最低层存储介质之上，其中缓存了应用程序须要的数据子集。对子集中的数据的读写先在Cache中异步进行，而后异步存储到低层稳定的介质上。Cache技术经过这种异步的数据I/O模式来解决程序中的计算速度和数据存储速度不匹配的鸿沟，减小了访问底层存储介质的次数，使存储系统的性能大大提升。增大Cache容量能够缓存更多的数据，减少cache的容量失效，从而显著提升Cache命中率。但cache的命中率并不随着容量呈线性增加，当cache容量达到必定阈值时，再增大容量命中率并不会显著提升，所以要根据成本和实际须要来选择cache容量。
分布式存储系统中，多个存储节点、元数据服务以及客户端都经过物理网络互联，客户端和服务器端都会进行数据缓存。根据节点上Cache资源工做方式的不一样，分布式存储系统中的Cache分为分布独立式 Cache和协做式Cache。分布独立式Cache中，每一个存储节点上的文件系统Cache只负责缓存本节点上的I/O数据，Cache中数据的一致性和Cache资源分配等工做由本节点上的Cache管理器负责。这种Cache管理简单，不影响系统的总体结构，系统增删存储节点后，也不须要作额外的Cache配置和管理工做。协做式Cache中，每一个存储节点上的Cache不只负责缓存本节点上的I/O数据，还负责缓存其余节点上的Cache数据。协做式Cache须要各节点之间可以快速的通讯，所以存储节点之间的网络带宽必须足够大。协做式Cache可以充分利用Cache资源，构造容量更大的全局Cache，能够实现Cache资源的负载均衡。两种Cache方式相比较，分布独立式Cache简单、扩展性高，协做式Cache管理复杂、对网络要求高，可是Cache命中率可以大幅提升，对分布式存储系统总体性能提升更加明显。另外，分布式存储系统中客户端缓存会减弱服务器端缓存的局部性，致使基于局部性的LRU缓存替换算法效果不佳，或者多级cache系统部重复缓存。所以，在缓存替换算法方面须要进行特别的优化设计，综合考虑访问最近性、时间局部性、空间局部性、文件关联等因素。
Cache技术利用了数据访问的时间局部性，对访问过的数据进行暂时的保留。但因为缓冲空间大小以及更新算法的制约，当数据频繁更新时。缓存带来的性能改善再也不显著。对于小文件，能够根据局部性原理和I/O访问行为，预测最近可能访问的文件集合，提早预读到Cache系统中，经过减小文件读取时间提升存储系统性能。许多系统把数据访问请求看成是独立的事件，实际上数据请求并不是彻底随机，而是由用户或程序的行为驱动的，存在特定的访问模式。而这种模式经常被缓存系统所忽略。预取是主动缓存技术，它利用了数据的空间局部性，对未来可能发生的数据请求进行预测，在访问以前取出并缓存，以备用户访问，从而减小访问延迟。预测技术主要经过对数据本体或历史访问记录的分析，构造合适的预测模型，据此对将来的访问进行预测。用户执行应用程序去访问数据，连续访问的不一样文件之间必然存在必定的关联。当用户以先前大体相同的顺序去请求数据时，或多或少会访问相同的文件集合，尤为对同一个用户来讲。正确的预测能够提升系统的性能，而错误的预测不只会形成缓存空间和I/O带宽的浪费，并且会增长正常访问的延时。
3.3 小文件合并存储
小文件合并存储是目前优化LOSF问题最为成功的策略，已经被包括Facebook Haystack和淘宝TFS在内多个分布式存储系统采用。它经过多个逻辑文件共享同一个物理文件，将多个小文件合并存储到一个大文件中，实现高效的小文件存储。为何这种策略对LOSF效果显著呢？
首先，减小了大量元数据。经过将大量的小文件存储到一个大文件中，从而把大量的小文件数据变成大文件数据，减小了文件数量，从而减小了元数据服务中的元数据数量，提升了元数据的检索和查询效率，下降了文件读写的I /O操做延时，节省了大量的数据传输时间。LOSF元数据开销所占比重大，大幅减小元数据，将直接致使性能的显著提高。合并后的大文件存储在磁盘文件系统之上，同时也大大下降了磁盘文件系统在元数据和I/O方面的压力，这点能够改善每一个节点的存储性能。小文件的元数据和数据会一并存储在大文件中，并造成索引文件，访问时经过索引进行定位。索引文件采用预加载到Cache的策略，能够实现随机读写小文件只须要一次I/O。
其次，增长了数据局部性，提升了存储效率。磁盘文件系统或者分布式文件系统中，文件的元数据和数据存储在不一样位置。采用合并存储机制后，小文件的元数据和数据能够一并连续存储大文件中，这大大加强了单个小文件内部的数据局部性。小文件合并过程当中，能够利用文件之间的空间局部性、时间局部性以及关联，尽可能将可能连续访问的小文件在大文件中进行连续存储，加强了小文件之间的数据局部性。这直接下降了磁盘上随机I/O比率，转换成了顺序I/O，可以有效提升I/O读写性能。另外，小文件单独存储会造成外部和内部碎片，而合并存储后存储碎片将大大下降，这极大提升了LOSF存储效率。
再次，简化了I/O访问流程。采用小文件合并存储后，I/O访问流程发生了极大变化，主要体如今存储节点磁盘文件系统上。根据以前的阐述，磁盘文件系统读写一个小文件，最大的系统消耗在open系统调用，须要进行路径查找do_path_lookup，将路径名进行份量解析，转换成对应文件在内核中内部表示。这个过程很是占用系统开销，尤为是深目录下的文件。而通过合并，不少小文件共享一个大文件，open操做转换成了开销小不少的seek操做，根据索引定位到大文件内部相应位置便可，也不须要在内核中建立相关VFS数据对象，这节省了原先绝大部分的系统开销。
大文件加上索引文件，小文件合并存储实际上至关于一个微型文件系统。这种机制对于WORM(Write Once Read Many)模式的分布式存储系统很是适合，而不适合容许改写和删除的存储系统。由于文件改写和删除操做，会形成大文件内部的碎片空洞，若是进行空间管理并在合适时候执行碎片整理，实现比较复杂并且产生额外开销。若是不对碎片进行处理，采用追加写的方式，一方面会浪费存储容量，另外一方面又会破坏数据局部性，增长数据分布的随机性，致使读性能降低。此外，若是支持随机读写，大小文件如何统一处理，小文件增加成大文件，大文件退化为小文件，这些问题都是在实际处理时面临的挑战。
3.4元数据管理优化
分布式存储系统架构大体分两种，即有中心架构和无中心架构。在有中心架构的分布式存储系统中，一般有一个元数据服务器MDC来统一管理元数据。而在无中心的架构中，元数据会分散存储于各个存储节点上，经过一致性Hash等算法进行管理和定位。客户端在读写小文件数据以前，须要经过与MDC或存储节点进行通讯获取位置信息，这一过程至关于额外增长一次网络传输开销和元数据服务访问开销。这对小文件I/O来讲，开销影响很是大，尤为是对于延迟较大的网络而言。所以，元数据管理优化主要从减小元数据量、减小元数据访问次数、提升元数据检索效率等几个方面着手。
对于单个小文件，元数据包括位置信息、名称、guid、属主、大小、建立日期、访问日期、访问权限等信息。在分布式存储系统中，根据访问接口和语义须要，能够对元数据进行精简，保留足够的元数据便可，从而达到减小元数据的目的。好比，TFS/FastDFS经过在文件命名中隐含位置信息等部分元数据，对象存储系统能够不须要访问日期、访问权限等元信息，从而节省了元数据量。这带来的好处是，能够减小元数据通讯延迟，相同容量的Cache能够缓存更多的元数据，从而提升元数据的访问效率。
前面刚刚提到TFS/FastDFS在文件名中隐含了位置信息，无需与MDC或存储节点交互就可以对文件进行定位，减小了一次元数据访问。元数据操做在小文件整个I/O过程占了大部分时间，对于大量并发元数据操做，能够对多个RPC请求进行合并，从而大幅减小元数据访问次数。最为重要的，能够在客户端对元数据进行缓存，利用Cache中元数据访问的时间局部性，结合预读策略， 显著减小元数据访问次数。每一次元数据访问都会产生可观的网络开销，所以下降元数据访问次数，可以有效提升元数据操做效率。
在MDC上或者存储节点上，元数据最终持久化存储在数据库、KV存储系统、磁盘文件系统目录上，甚至是单个文件中。同时，为了提升访问性能，会将部分或者所有元数据缓存在Cache中。为了达到高效的元数据检索，须要考虑大容量内存和快速磁盘(好比SAS磁盘或SSD)，Cache系统采用可扩展性Hash等高效数据结构组织缓存的元数据。同时，还能够经过多级索引、BloomFilter等减小元数据操做过程的I/O访问次数，进一步加快元数据访问速度。
四、总结
随着互联网、物联网、云计算、大数据等技术的发展，海量小文件LOSF问题成为了学术界和工业界研究的热点。Facebook和Taobao等紧密结合各自的业务应用特色，在海量小图片存储系统优化方面取得了很是不错的成绩，成功支撑了数百亿级别的线上图片存储。因为LOSF优化须要深刻结合业务数据特色，优化效果才能显著，所以优化策略和方法难以广泛适用，不可推而广之。本文从LOSF问题的源起谈起，重点分析LOSF问题根源，而后给出优化策略和方法，提出硬件优化、Cache管理优化、小文件合并存储、元数据管理优化等是几种行之有效的优化方法，指望对LOSF问题的研究和优化实践提供必定的理论和方法指导，而非具体的实践技术。值得一提的是，性能优化没有黄金法则，必须是在对现有系统充分的测试和分析的基础上，有针对性地选择合适的优化策略，方能有实质性优化效果。
五、参考资料
[1] Findinga needle in Haystack: Facebook’s photo storage
[4] 海量小文件存储文件系统研究综述
做者简介
刘爱贵，中科院毕业，博士，专一于存储技术的研究与开发，目前在存储行业从事云存储相关研发工做，分布式文件系统资深理论研究与实践者。
CSDN博客：http://blog.csdn.net/liuaigui
Email:aigui.liu@gmail.com
QQ:9187434