CN111382120A - 一种小文件管理方法、系统和计算机设备 - Google Patents

Abstract

本发明提供了一种小文件管理方法、系统和计算机设备。涉及对象存储技术，解决了小文件数量巨大导致的索引资源消耗过高、查询困难的问题。该方法包括：生成小文件索引树，在所述索引树的中间节点存储小文件的键值Key，在所述索引树的叶子节点里存储小文件的位置信息；裁剪掉所述索引树中的单分支节点。本发明提供的技术方案适用于海量小文件数据管理，实现了高性能的数据查询。

Description

一种小文件管理方法、系统和计算机设备

技术领域

本发明涉及对象存储技术，尤其涉及一种小文件管理方法、系统和计算机设备。

背景技术

当下的信息社会每天都产生大量需要保存的数据，这些数据在刺激海量存储技术发展的同时也带来了新的挑战。比如，海量数据为存储系统增加了大量的小文件，这些小文件的元数据如何管理，如何控制定位某个文件的时间和空间开销，是存储技术领域亟待解决的问题。

随着对数据实时性要求的增加，文件也越来越趋于碎片化，像短视频、直播类的业务，往往一个视频只有几百KB大小，更小的甚至只有几十KB。可以说，一个成熟的对象存储系统最后都会面临巨量元数据管理的挑战，如HDFS、openstack-swift等。

以100TB数据(大约是日常的单机容量)为例，若全部存储10KB的文件(如果文件名<＝1KB)，仅是管理这些文件所需的索引数据就会达到大约10，000GB的内存空间。这是任何成熟的单机存储系统都无法接受的巨大压力。

发明内容

本发明旨在解决上面描述的问题。

根据本发明的第一方面，提供了一种小文件管理方法，包括：

生成小文件索引树，在所述索引树的中间节点存储小文件的键值(Key)，在所述索引树的叶子节点里存储小文件的位置信息；

裁剪掉所述索引树中的单分支节点。

优选的，所述索引树为单词查找(Trie)树。

优选的，该方法还包括：

使用压缩矩阵(Compacted Array)存储所述索引树的数据结构。

优选的，生成小文件索引树的步骤包括：

为多个存储位置相邻的小文件添加同一索引。

优选的，裁剪掉所述索引树中的单分支节点的步骤包括：

对所述索引树进行扫描；

将仅具有左子节点或右子节点的中间节点判定为单分支节点；

对于单分支节点，将所述单分支节点本身裁剪掉。

根据本发明的另一方面，还提供了一种小文件管理系统，包括：

树生成模块，用于生成小文件索引树，在所述索引树的中间节点存储小文件的键值Key，在所述索引树的叶子节点里存储小文件的数据；

树裁剪模块，用于裁剪掉所述索引树中的单分支节点。

优选的，该系统还包括：

树压缩模块，用于使用压缩矩阵Compacted Array存储所述索引树的数据结构。

优选的，所述树生成模块包括：

小文件优化单元，用于为多个存储位置相邻的小文件添加同一索引。

优选的，所述树裁剪模块包括：

特征信息扫描单元，用于对所述索引树进行扫描；

节点筛选单元，将仅具有左子节点或右子节点的中间节点判定为单分支节点；

对于单分支节点，将所述单分支节点本身裁剪掉。

根据本发明的另一方面，还提供了一种计算机设备，包括存储器与处理器，所述存储器上存储有计算机程序，所述程序被所述处理器执行时实现如上述小文件管理方法的步骤。

本发明提供了一种小文件管理方法、系统和计算机设备。生成小文件索引树，在所述索引树的中间节点存储小文件的键值Key，在所述索引树的叶子节点里存储小文件的数据，然后裁剪掉所述索引树中的单分支节点。在树索引数据结构的基础上进行压缩和整合，充分考虑了小文件存储的数据特征，极大的节约了索引内存占用的资源，提升了查询效率，实现了高性能的数据查询，解决了小文件数量巨大导致的索引资源消耗过高、查询困难的问题。

参照附图来阅读对于示例性实施例的以下描述，本发明的其他特性特征和优点将变得清晰。

附图说明

并入到说明书中并且构成说明书的一部分的附图示出了本发明的实施例，并且与描述一起用于解释本发明的原理。在这些附图中，类似的附图标记用于表示类似的要素。下面描述中的附图是本发明的一些实施例，而不是全部实施例。对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，可以根据这些附图获得其他的附图。

图1示例性地示出了一种哈希映射(Hash map)类索引原理；

图2示例性地示出了一种B+Tree实现原理；

图3示例性地示出了本发明的一实施例提供的一种小文件管理方法的流程；

图4示例性地示出了一种Trie树结构；

图5示例性地示出了图3中步骤302的具体流程；

图6示例性地示出了Hash类数据结构的map和Tree类数据结构的索引内存占用对比；

图7示例性地示出了Hash类数据结构的map和Tree类数据结构下查询相同确定存在的key查询时间比较结果；

图8示例性地示出了Hash类数据结构的map和Tree类数据结构下查询相同的确定不存在的key的查询时间的比较结果；

图9示例性地示出了本发明的一实施例一种小文件管理系统的结构；

图10示例性地示出了图9中树生成模块901的结构；

图11示例性地示出了图9中树裁剪模块902的结构。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互任意组合。

随着对数据实时性要求的增加，文件也越来越趋于碎片化，像短视频、直播类的业务，往往一个视频只有几百KB大小，更小的甚至只有几十KB。可以说，一个成熟的对象存储系统最后都会面临巨量元数据管理的挑战，如HDFS、openstack-swift等。

以100TB数据(大约是日常的单机容量)为例，若全部存储10KB的文件(如果文件名<＝1KB)，仅是管理这些文件所需的索引数据就会达到大约10，000GB的内存空间。这是任何成熟的单机存储系统都无法接受的巨大压力。

为了解决上述问题，本发明的实施例提供了一种小文件管理方法、系统和计算机设备。在树索引数据结构的基础上进行压缩和整合，充分考虑了小文件存储的数据特征，极大的节约了索引内存占用的资源，提升了查询效率，实现了高性能的数据查询，解决了小文件数量巨大导致的索引资源消耗过高、查询困难的问题。

为了便于理解本发明的实施例提供的技术方案，首先对基于Hash map的索引方式和基于树(Tree)的索引方式进行说明。

一、基于Hash map的索引方式。

图1所示为一种Hash map类索引示例。Hash map类索引首先会利用hash函数的计算，将要存储的key映射到一个新的hash值，然后再建立索引。查找定位时也需要这一步的计算来定位到真正数据存储的位置。图1简单展示了其结构和工作原理。

基于Hash map的索引方式的优点如下：

1、一次检索定位数据。即，每个key都可以通过一步计算找到所需的值的位置。

2、查找的时间复杂度是O(k)(k是key的长度)。这个特点非常适合用来做单条数据的定位，然而它有一个前提是查找的key必须是等值匹配的，不支持“>”、“<”的操作。

3、范围查找在存储系统中也是一个非常重要的特性，在数据清理，合并等操作时，是必须要支持的一个API。

从图1的示例中也能明显看到基于Hash map的索引方式的缺点，例如：

1、无序。当进行查找操作时，如果不是等值的匹配而是范围查询，比如，想要顺序列出索引中全部的key，最优时间复杂度也需要O(k*n*log(n))，这样的操作消耗的空间和时间代价都是索引系统不可接受的。

2、内存开销大。Hash map要求在内存中保存完整的key，也就是说内存开销是O(k*n)的，相应的查询效率为O(k)，这对单机百亿文件级别的目标来说无疑是致命的缺陷。

二、基于Tree的索引方式。

Tree类索引利用树的中间节点和分支将全量的key分成一个个更小的部分。如图2所示，是一个典型的B+Tree实现，其中间节点只保存了key，数据部分全部保存在叶子节点里。这样的结构在查询时，通过树的中间节点一步一步地缩小查找范围，从而找到要查找的key。

Tree类中代表性的数据结构有:

B+tree，RBTree，SkipList，LSM Tree等。

一般以平衡性最优为特点，适用于数据库中实现索引等场合。

排序数组也可以认为是Tree类的数据结构，它的空间开销、查询性能都跟平衡树相当。

Tree类的索引的特点也很明显:

1、它对保存的key是排序的，如图2所示，通过一个顺序访问数据的指针，就能够方便地顺序列出全部数据，这弥补了Hash类索引不能够范围查询的缺点。

2、Tree类索引有许多成熟的实现，如B树、B+树的设计在查询性能方面也有很好的表现，MySQL的默认索引类型就是B+树。

基于Tree的索引方式也存在如下缺陷：

跟Hash map一样，用Tree做索引的时候，map.set(key＝key，value＝(offset，size))内存中必须保存完整的key，内存开销也很大，为O(k*n)，相应的查询效率为O(k*log(n))。

本发明的一实施例提供了一种小文件管理方法，使用该方法完成小文件存储管理的流程如图3所示，包括：

步骤301、生成小文件索引树。

本步骤中，在所述索引树的中间节点存储小文件的键值Key，在所述索引树的叶子节点里存储小文件的位置信息；

优选的，本发明实施例中的所述索引树为单词查找(Trie)树。

一般Tree结构的顺序性和查询效率都可以满足预期，但空间开销仍然很大。在以字符串为key的索引结构中，Trie的特性刚好可以优化key存储的问题。Trie是一个前缀树，如图4所示，是一个保存了8个key的Trie结构：

"A"，"to"，"tea"，"ted"，"ten"，"i"，"in"，and"inn"。

Trie的特点在于在于原生的前缀压缩，而Trie上的节点数最少是O(n)，但Trie的空间开销比较大，因为每个节点都要保存若干个指针(指针单独要占8字节)，导致它的空间复杂度虽然是O(n)，但实际内存开销很大，因此需要将Trie的空间开销降到足够低。

步骤302、裁剪掉所述索引树中的单分支节点。

为了应对当前环境给存储带来的挑战，本发明实施例中使用一种全新的索引数据结构：轻量单词查找树(SlimTrie)。对Trie索引数据进行了裁剪、压缩和聚合，对索引进行了极大的优化，逼近空间利用率的理论极限。以做到单机100TB数据为例，如果文件都是10KB小文件，那么就有100亿个文件；而使用本发明实施例提供的SlimTrie，最终只需10GB内存空间。

本步骤具体如图5所示，包括：

步骤3021、对所述索引树进行扫描。

在存储系统中，数据生成之后，在使用阶段大部分数据是不修改的，即，需要被索引的数据大部分是静态的。数据的更新是通过Append和Compact这2个操作完成的，一般不需要随机插入一条记录。依赖于这个特征，本步骤中可以对索引进行更多的优化:预先对所有的key进行扫描，提取特征，大大降低索引信息的量。

步骤3022、将仅具有左子节点或右子节点的中间节点判定为单分支节点。

步骤3023、对于单分支节点，将所述单分支节点本身裁剪掉。

通过图5所示的步骤，完成了对索引树的裁剪。索引的目的在于快速定位一个对象所在的位置范围，但不保证定位到的对象一定存在，就像Btree的中间节点，用来确定key的范围，但要查找的key是否真的存在，需要在Btree的叶子节点(真实数据)上来确定。本发明实施例中，用所有的key创建一个标准的Trie树，SlimTrie保证存在的key被正确的定位，但被索引到的key不一定存在。因此，通过在标准Trie树基础上做裁剪，裁剪掉标准Trie中的单分支节点，将索引数据的量级从O(n*k)降低到O(n)；再裁剪掉Trie树中单分支节点，因为单分支节点对索引key没有任何的帮助。这样，就成功的简化的树结构，减少了索引量。

步骤303、使用压缩矩阵(Compacted Array)存储所述索引树的数据结构。

本步骤中，通过一个Compacted Array来存储整个SlimTrie的数据结构，对SlimTrie进行压缩，在实现上将内存开销降低。

由于树形结构在内存中多以指针的形式来实现，但指针在64位系统上占用8个字节，相当于最差情况下，内存开销至少为8*n，这样的内存开销还是太大了，所以本步骤中使用Compacted Array来压缩内存开销。

优选的，在构建Trie时，还可为多个存储位置相邻的小文件添加同一索引。将多个相邻的小文件用1条索引来标识，对小文件存储进行进一步优化，平衡I/O开销和内存开销。

索引的设计以降低I/O和降低内存开销为目的，这两方面有矛盾的地方，如果要降低I/O就需要索引尽可能准确，这将带来索引的容量增加。如果要减小索引的内存开销，则可能带来不准确的对磁盘上文件的定位而导致额外的I/O。磁盘的一次I/O的开销，跟这次I/O读取的数据量大小关系不大，所以可以在一次I/O中读取更多的数据来有效利用I/O，因此将多个小文件添加同一条索引不会影响I/O效率，平衡了降低I/O和降低内存开销两方面的需求。

本发明实施例提供的SlimTrie数据结构具有如下特点：

1、支持顺序查找和遍历key。SlimTrie作为索引的数据结构，支持顺序遍历。

2、SlimTrie的内存开销只与key的个数n相关，不依赖于key的长度k。

3、SlimTrie支持最大16KB的key。

4、SlimTrie查询速度非常快。

本发明的一实施例还提供了一种小文件管理方法，实现了单机百亿级文件的索引，基于标准Trie树基础上做裁剪，裁剪掉标准Trie中单分支的节点，将索引数据的量级从O(n*k)降低到O(n)。

使用Compacted Array来存储整个Trie的数据结构，在实现上将内存开销降低。

使用SlimTrie数据结构的索引相比于使用其他类索引，在保证索引功能的情况下压缩了索引中的key所占用的空间。本发明实施例提供的SlimTrie可以极大的节约内存占用以及高性能的查询。

本发明实施例中，选取Hash类数据结构的map和Tree类数据结构的B-Tree与SlimTrie做对比为例进行说明。在同等条件下，计算各个数据结构建立索引所耗费的内存空间后得到的索引内存占用对比如图6所示，能够看出：

1.SlimTrie作为索引在内存的节省上相较map和B-Tree提升巨大。

2.SlimTrie作为索引其内存占用的决定因素是value的大小，与key的大小无关。

仍以上述情境为例，测量查询相同确定存在的key查询时间比较结果如图7所示，可以看出：存在的key的查找耗时，越小越优。

仍以上述情境为例，查询相同的确定不存在的key的查询时间的比较结果如图8所示，可以看出：SlimTrie的查询效率远好于Btree，也非常接近Hash map的性能。

本发明的一实施例还提供了一种小文件管理系统，该系统的结构如图9所示，包括：

树生成模块901，用于生成小文件索引树，在所述索引树的中间节点存储小文件的Key，在所述索引树的叶子节点里存储小文件的数据；

树裁剪模块902，用于裁剪掉所述索引树中的单分支节点。

优选的，该系统还包括：

树压缩模块903，用于使用Compacted Array存储所述索引树的数据结构。

优选的，所述树生成模块901的结构如图10所示，包括：

小文件优化单元9011，用于为多个存储位置相邻的小文件添加同一索引。

优选的，所述树裁剪模块902的结构如图11所示，包括：

特征信息扫描单元9021，用于对所述索引树进行扫描；

节点筛选单元9022，将仅具有左子节点或右子节点的中间节点判定为单分支节点；

节点裁剪单元9023，对于单分支节点，将所述单分支节点本身裁剪掉。

本发明的一实施例还提供了一种计算机设备，包括存储器与处理器，所述存储器上存储有计算机程序，所述程序被所述处理器执行时实现本发明的实施例提供的小文件管理方法的步骤。

本发明的实施例提供了一种小文件管理方法、系统和计算机设备。生成小文件索引树，在所述索引树的中间节点存储小文件的键值Key，在所述索引树的叶子节点里存储小文件的数据，然后裁剪掉所述索引树中的单分支节点。在树索引数据结构的基础上进行压缩和整合，充分考虑了小文件存储的数据特征，极大的节约了索引内存占用的资源，提升了查询效率，实现了高性能的数据查询，解决了小文件数量巨大导致的索引资源消耗过高、查询困难的问题。

上面描述的内容可以单独地或者以各种方式组合起来实施，而这些变型方式都在本发明的保护范围之内。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制。尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (10)

1.一种小文件管理方法，其特征在于，包括：

生成小文件索引树，在所述索引树的中间节点存储小文件的键值Key，在所述索引树的叶子节点里存储小文件的位置信息；

裁剪掉所述索引树中的单分支节点。

2.根据权利要求1所述的小文件管理方法，其特征在于，所述索引树为单词查找Trie树。

3.根据权利要求1所述的小文件管理方法，其特征在于，该方法还包括：

使用压缩矩阵Compacted Array存储所述索引树的数据结构。

4.根据权利要求1所述的小文件管理方法，其特征在于，生成小文件索引树的步骤包括：

为多个存储位置相邻的小文件添加同一索引。

5.根据权利要求1所述的小文件管理方法，其特征在于，裁剪掉所述索引树中的单分支节点的步骤包括：

对所述索引树进行扫描；

将仅具有左子节点或右子节点的中间节点判定为单分支节点；

对于单分支节点，将所述单分支节点本身裁剪掉。

6.一种小文件管理系统，其特征在于，包括：

树生成模块，用于生成小文件索引树，在所述索引树的中间节点存储小文件的键值Key，在所述索引树的叶子节点里存储小文件的数据；

树裁剪模块，用于裁剪掉所述索引树中的单分支节点。

7.根据权利要求6所述的小文件管理系统，其特征在于，该系统还包括：

树压缩模块，用于使用压缩矩阵Compacted Array存储所述索引树的数据结构。

8.根据权利要求6所述的小文件管理系统，其特征在于，所述树生成模块包括：

小文件优化单元，用于为多个存储位置相邻的小文件添加同一索引。

9.根据权利要求6所述的小文件管理系统，其特征在于，所述树裁剪模块包括：

特征信息扫描单元，用于对所述索引树进行扫描；

节点筛选单元，将仅具有左子节点或右子节点的中间节点判定为单分支节点；

对于单分支节点，将所述单分支节点本身裁剪掉。

10.一种计算机设备，其特征在于，包括存储器与处理器，所述存储器上存储有计算机程序，所述程序被所述处理器执行时实现如权利要求1至5中任意一项所述的方法的步骤。

Images