小文件大问题——海量小文件解决方案初探

做者简介：陈闯，花名“战士雷欧”，白山超级工程师。Linux内核、Nginx模块、存储架构资深开发人员，7年以上存储架构、设计及开发经验，前后就任于东软、中科曙光、新浪、美团，擅长独立进行Haystack、纠删码等各类项目研发，爱好不断下降IO、挑战冗余度底线。白山滑板车选手专业十级，会漂移，正积极备战方庄街道第6届动感滑板车运动会，家庭梦想是为爱妻赢得无硅油洗发水。

背景：

当今互联网，数据呈现爆炸式增加，社交网络、移动通讯、网络视频、电子商务等各类应用每每能产生亿级甚至十亿、百亿级的海量小文件。因为在元数据管理、访问性能、存储效率等方面面临巨大的挑战，海量小文件问题成为了业界公认的难题。

业界的一些知名互联网公司，也对海量小文件提出了解决方案，例如：著名的社交网站Facebook，存储了超过600亿张图片，专门推出了Haystack系统，针对海量小图片进行定制优化的存储。

白山云存储CWN-X针对小文件问题，也推出独有的解决方案，咱们称之为Haystack_plus。该系统提供高性能数据读写、数据快速恢复、按期重组合并等功能。

Facebook的Haystack

Facebook的Haystack对小文件的解决办法是合并小文件。将小文件数据依次追加到数据文件中，而且生成索引文件，经过索引来查找小文件在数据文件中的offset和size，对文件进行读取。

Haystack的数据文件部分：

Haystack的数据文件，将每一个小文件封装成一个needle，包含文件的key、size、data等数据信息。全部小文件按写入的前后顺序追加到数据文件中。

Haystack的索引文件部分：

Haystack的索引文件保存每一个needle的key，以及该needle在数据文件中的offset、size等信息。程序启动时会将索引加载到内存中，在内存中经过查找索引，来定位在数据文件中的偏移量和大小。

Haystack面临的问题：

Facebook的Haystack特色是将文件的完整key都加载到内存中，进行文件定位。机器内存足够大的状况下，Facebook完整的8字节key能够所有加载到内存中。

可是现实环境下有两个主要问题：

1. 存储服务器内存不会太大，通常为32G至64G；

2. 小文件对应的key大小难控制，通常选择文件内容的MD5或SHA1做为该文件的key。

场景举例：

• 一台存储服务器有12块4T磁盘，内存为32GB左右。

• 服务器上现需存储大小约为4K的头像、缩略图等文件，约为10亿个。

• 文件的key使用MD5，加上offset和size字段，平均一个小文件对应的索引信息占用28字节。

• 在这种状况下，索引占用内存接近30GB，磁盘仅占用4TB。内存消耗近100%，磁盘消耗只有8%。

因此索引优化是一个必需要解决的问题。

Haystack_plus

Haystack_plus的核心也由数据文件和索引文件组成。

1. Haystack_plus的数据文件：

与Facebook的Haystack相似，Haystack_plus将多个小文件写入到一个数据文件中，每一个needle保存key、size、data等信息。

2. Haystack_plus的索引文件：

索引是咱们主要优化的方向：

• 索引文件只保存key的前四字节，而非完整的key；

• 索引文件中的offset和size字段，经过512字节对齐，节省1个字节；并根据整个Haystack_plus数据文件实际大小计算offset和size使用的字节数。

3. Haystack_plus的不一样之处：

数据文件中的needle按照key的字母顺序存放。

因为索引文件的key，只保存前四字节，若是小文件key的前四字节相同，不顺序存放，就没法找到key的具体位置。可能出现以下状况：

例如：用户读取的文件key是0x ab cd ef ac ee，但因为索引文件中的key只保存前四字节，只能匹配0x ab cd ef ac这个前缀，此时没法定位到具体要读取的offset。

咱们能够经过needle顺序存放，来解决这个问题：

例如：用户读取文件的key是0x ab cd ef ac bb，匹配到0x ab cd ef ac这个前缀，此时offset指向0x ab cd ef ac aa这个needle，第一次匹配未命中。

经过存放在needle header中的size，咱们能够定位0x ab cd ef ac bb位置，匹配到正确needle，并将数据读取给用户。

4. 索引搜索流程为：

5. 请求不存在的文件：

问题：咱们应用折半查找算法在内存查找key，时间复杂度为O(log(n))，其中n为needle数目。索引前缀相同时，须要在数据文件中继续查找。此时访问的文件不存在时，容易形成屡次IO查找。

解决方法：在内存中，将存在的文件映射到bloom filter中。此时只须要经过快速搜索，就能够排除不存在的文件。

时间复杂度为O(k)，k为一个元素须要的bit位数。当k为9.6时，误报率为1%，若是k再增长4.8，误报率将下降为0.1%。

6. 前缀压缩，效果如何：

Haystack_plus与Facebook Haystack内存消耗的对比，场景举例，文件（如：头像、缩略图等）大小4K，key为MD5：

内存消耗对比	Key	offset	size
Haystack	全量key，16字节	8字节	4字节
Haystack_plus	4字节	4字节	1字节

注：Haystack的needle为追加写入，所以offset和size大小固定。Haystack_plus的key使用其前4字节，offset根据Haystack_plus数据文件的地址空间计算字节数，并按512字节对齐；size根据实际文件的大小计算字节数，并按512对齐。

从上图能够看出在文件数量为10亿的状况下，使用Facabook的Haystack消耗的内存超过26G，使用Haystack_plus仅消耗9G多内存，内存使用下降了2/3。

7.索引优化根本就停不下来

10亿个4K小文件，消耗内存超过9G。Key占用4字节，Offset占用4字节，还须要再小一些。

索引分层：

根据文件key的前缀，进行分层，相同的前缀为一层。

分层的好处：

减小key的字节数：

经过分层，只保存一份重复的前缀，节省key的字节数。

减小offset的字节数：

优化前的offset，偏移范围为整个Haystack_plus的数据文件的地址空间。

优化后，只需在数据文件中的层内进行偏移，根据最大的层地址空间能够计算所需字节数。

分层后的效果：

从上图能够看出，进行分层后，内存消耗从优化前的9G多，下降到4G多，节省了一半的内存消耗。

Haystack_plus总体架构

1. Haystack_plus组织：

每台服务器上，咱们将全部文件分红多个group，每一个group建立一个Haystack_plus。系统对全部的Haystack_plus进行统一管理。

读、写、删除等操做，都会在系统中定位操做某个Haystack_plus，而后经过索引定位具体的needle，进行操做。

2. 索引组织

以前已经介绍过，全部needle顺序存放，索引作前缀压缩，并分层。

3. 文件组成：

• chunk文件：小文件的实际数据被拆分保存在固定数量的chunk数据文件中，默认为12个数据块；

• needle list文件：保存每一个needle的信息(如文件名、offset等)；

• needle index和layer index文件：保存needle list在内存中的索引信息；

• global version文件：保存版本信息，建立新version时自动将新版本信息追加到该文件中；

• attribute文件：保存系统的属性信息(如chunk的SHA1等)；

• original filenames：保存全部文件原始文件名。

A、Haystack_plus数据文件被拆分为多个chunk组织，chunk1，chunk2，chunk3……
B、分红多个chunk的好处：
 1. 数据损坏时，不影响其它chunk的数据；
 2. 数据恢复时，只需恢复损坏的chunk。
C、每一个chunk的SHA1值存放在attribute文件中。

4. 版本控制：

因为needle在数据文件中按key有序存放，为不影响其顺序，新上传的文件没法加入Haystack_plus，而是首先被保存到hash目录下，再经过按期自动合并方式，将新文件加入到Haystack_plus中。

合并时将从needle_list文件中读取全部needle信息，将删除的needle剔除，并加入新上传的文件，同时从新排序，生成chunk数据文件、索引文件等。

从新合并时将生成一个新版本Haystack_plus。版本名称是全部用户的文件名排序的SHA1值的前4字节。

每半个月系统自动进行一次hash目录检查，查看是否有新文件，并计算下全部文件名集合的SHA1，查看与当前版本号是否相同，不一样时说明有新文件上传，系统将从新合并生成新的数据文件。

同时，系统容许在hash目录下超过指定的文件数时，再从新建立新版本，从而减小从新合并次数。

版本的控制记录在global_version文件中，每次建立一个新版本，版本号和对应的crc32将追加到global_version文件（crc32用于查看版本号是否损坏）。

每次生成新版本时，自动通知程序从新载入索引文件、attribute文件等。

5. 数据恢复：

用户的文件将保存成三副本存放，所以Haystack_plus也会存放在3台不一样的机器上。

恢复场景一：

当一个Haystack_plus的文件损坏时，会在副本机器上，查找是否有相同版本的Haystack_plus，若是版本相同，说明文件的内容都是一致，此时只需将要恢复的文件从副本机器下载下来，进行替换。

恢复场景二：

若是副本机器没有相同版本的Haystack_plus，但存在更高版本，那此时能够将该版本的整个Haystack_plus从副本机器上拷贝下来，进行替换。

恢复场景三：

若是前两种状况都不匹配，那就从另外两台副本机器上，将全部文件都读到本地上的hash目录下，并将未损坏的chunk中保存的文件也提取到hash目录下，用全部文件从新生成新版本的Haystack_plus。

Haystack_plus效果如何

在使用Haystack_plus后一段时间，咱们发现小文件的总体性能有显著提升，RPS提高一倍多，机器的IO使用率减小了将近一倍。同时，由于优化了最小存储单元，碎片下降80%。

使用该系统咱们能够为用户提供更快速地读写服务，而且节省了集群的资源消耗。