CN110019048A

CN110019048A - 基于MongoDB的文件处理方法、装置、系统及服务器

Info

Publication number: CN110019048A
Application number: CN201710917092.3A
Authority: CN
Inventors: 王晓涛
Original assignee: Beijing Gridsum Technology Co Ltd
Current assignee: Beijing Gridsum Technology Co Ltd
Priority date: 2017-09-30
Filing date: 2017-09-30
Publication date: 2019-07-16

Abstract

本发明提供的基于MongoDB的文件处理方法、装置、系统及服务器，通过在MongoDB预先设置的多个数据文档集合以及至少一个元数据文档集合，接收到待存储文件后，检测这多个数据文档集合确实未存储该待存储文件，将基于待存储文件的预设属性信息，将其存储到相应的数据文档集合，并将该待存储文件的当前元数据信息更新到元数据文档集合，而不是将元数据信息存储到Name Node的内存中，解决了因Name Node的内存无法存储海量小文件的元数据信息，导致无法存储海量小文件的技术问题，同时本发明通过对文件分类存储，还能够实现对大文件的存储，且便于通过增加数据文档集合实现系统水平扩展。

Description

基于MongoDB的文件处理方法、装置、系统及服务器

技术领域

本发明涉及数据库应用领域，更具体地说是涉及一种基于MongoDB的文件处理方法、装置、系统及服务器。

背景技术

如今，随着互联网技术的迅猛发展，用户在使用计算机设备期间可以接收的数据逐渐成指数倍的增长，单纯通过增加硬盘数量扩展计算机设备文件系统的存储容量的方式，已经无法满足目前海量文件数据的存储需求。

针对这种情况，分布式文件系统(Distributed File System，DFS)能够有效解决数据的存储难题，分布式文件系统将固定于某个地点的某个文件系统，通过互联网扩展到任意多个地方/多个文件系统，形成的多个节点构成一个文件系统网络。用户使用分布式文件系统，不需要了解数据的实际存储位置，能够利用本地文件系统即可实现数据的存取，相当便利。

在实际应用中，分布式文件系统在接收到待存储文件后，通常是将其元数据信息存储到Name Node的内存中，然而，该内存无法存储海量小文件对应的海量元数据信息，导致分布式文件系统无法实现海量小文件的存储。

发明内容

鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的基于MongoDB的文件处理方法、装置、系统及服务器。

本发明实施例提供了一种基于MongoDB的文件处理方法，所述方法包括：

获得待存储文件，检测分布式文档存储数据库MongoDB的多个数据文档集合中是否已存储所述待存储文件；

确定所述多个数据文档集合中未存储所述待存储文件，基于所述待存储文件的预设属性信息，将所述待存储文件存储至相应的数据文档集合；

获得所述待存储文件的当前元数据信息，更新到所述MongoDB的元数据文档集合。

可选的，所述检测分布式文档存储数据库MongoDB的多个数据文档集合中是否已存储所述待存储文件，包括：

利用布隆过滤器验证MongoDB的多个数据文档集合中是否存在所述待存储文件；

如果不存在，执行所述基于所述待存储文件的预设属性信息，将所述待存储文件存储至相应的数据文档集合步骤；

如果存在，确定所述待存储文件的MD5信息；

检测MongoDB的元数据文档集合中是否记录有所述待存储文件的MD5信息；

如果未记录，执行所述基于所述待存储文件的预设属性信息，将所述待存储文件存储至相应的数据文档集合步骤，并更新所述布隆过滤器。

可选的，所述方法还包括：

接收到针对待读取文件的读取指令，解析所述读取指令，确定所述待读取文件的文件标识；

查询所述元数据文档集合存储的与所述文件标识对应的元数据信息，确定出所述待读取文件的文件存储类型；

从与确定的所述文件存储类型对应的数据文档集合中读取所述待读取文件。

可选的，所述方法还包括：

确定所述多个数据文档集合中已存储所述待存储文件，执行所述获得所述待存储文件的当前元数据信息，更新到所述MongoDB的元数据文档集合步骤。

可选的，所述基于所述待存储文件的预设属性信息，将所述待存储文件存储至相应的数据文档集合，包括：

基于所述待存储文件的预设属性信息，确定所述待存储文件对应的目标文件存储类型；

将所述待存储文件存储对应所述目标文件存储类型的数据文档集合。

本发明实施例还提供了一种基于MongoDB的文件处理装置，所述装置包括：

文件获得模块，用于获得待存储文件；

文件检测模块，用于检测分布式文档存储数据库MongoDB的多个数据文档集合中是否已存储所述待存储文件；

文件处理模块，用于确定所述多个数据文档集合中未存储所述待存储文件，基于所述待存储文件的预设属性信息，将所述待存储文件存储至相应的数据文档集合；

元数据更新模块，用于获得所述待存储文件的当前元数据信息，更新到所述MongoDB的元数据文档集合。

本发明实施例还提供了一种服务器，所述服务器包括：

通信接口；

存储器，用于存储实现如上所述的基于MongoDB的文件处理方法的程序；

处理器，用于加载并执行所述存储器存储的程序，包括：

本发明实施例还提供了一种基于MongoDB的文件处理系统，所述系统包括：

分布式文档存储数据库MongoDB，包括多个数据文档集合以及至少一个元数据文档集合，且所述多个数据文档集合用于存储具有对应文件存储类型的文件，所述元数据文档集合用于存储对应于所述文件的元数据信息；

以及，如上所述的服务器。

本发明实施例还提供了一种存储介质，所述存储介质包括存储的程序，其中，在所述程序运行时控制所述存储介质所在设备执行如权利要求1-5中任一项所述的基于MongoDB的文件处理方法。

本发明实施例还提供了一种处理器，特征在于，所述处理器用于运行程序，其中，所述程序运行时执行如上所述的基于MongoDB的文件处理方法。

借由上述技术方案，本发明提供的基于MongoDB的文件处理方法、装置、系统及服务器，通过在MongoDB预先设置的多个数据文档集合以及至少一个元数据文档集合，接收到待存储文件后，检测这多个数据文档集合确实未存储该待存储文件，将基于待存储文件的预设属性信息，将其存储到相应的数据文档集合，并将该待存储文件的当前元数据信息更新到元数据文档集合，而不是将元数据信息存储到Name Node的内存中，解决了因NameNode的内存无法存储海量小文件的元数据信息，导致无法存储海量小文件的技术问题，同时本发明通过对文件分类存储，还能够实现对大文件的存储，且便于通过增加数据文档集合实现系统水平扩展。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了本发明实施例提供的一种基于MongoDB的文件处理方法的流程图；

图2示出了本发明实施例提供的另一种基于MongoDB的文件处理方法的流程图；

图3a示出了一种布隆过滤器验证应用示意图；

图3b示出了另一种布隆过滤器验证应用示意图；

图3c示出了又一种布隆过滤器验证应用示意图；

图4示出了本发明实施例提供的又一种基于MongoDB的文件处理方法的流程图；

图5示出了本发明实施例提供的一种基于MongoDB的文件处理装置的结构图；

图6示出了本发明实施例提供的另一种基于MongoDB的文件处理装置的结构图；

图7示出了本发明实施例提供的又一种基于MongoDB的文件处理装置的结构图；

图8示出了本发明实施例提供的又一种基于MongoDB的文件处理装置的结构图；

图9示出了本发明实施例提供的一种服务器的硬件结构图；

图10出了本发明实施例提供的一种基于MongoDB的文件处理系统的结构图。

具体实施方式

分布式文件系统是一种基于客户机/服务器模式的文件管理系统，其中，分布式文件系统中的客户机为客户端设备，如台式电脑、笔记本电脑、手机、工控机等设备，分布式文件系统中的服务器通常包括存储服务器以及元数据服务器，接收到的数据将存储到存储服务器中，而与数据对应的元数据信息将存储到元数据服务器，从而根据元数据信息根据读取相应的数据。

HDFS(Hadoop Distribute File System)作为目前常用的一种分布式文件系统，通常用来存储超大文件，如几百MB、GB甚至TB级别的文件，一般情况下，大文件会被分割成多个block(数据块)进行存储，每个block默认可以为64MB，每个block上会在多个DataNode(其负责文件存储)上存储多份副本，通常是3份，这样，当某一份数据丢失后，可以利用其他副本恢复数据，保证数据的可靠性以及可用性。

然而，由于HDFS中元数据信息(即文件的基本信息)存储在Name Node(其负责管理文件目录、文件和block的对应关系，以block和Data Node的对应关系)的内存中，而NameNode为单点，在小文件数量达到一定程度时，Name Node的内存就会吃不消，无法再继续存储文件。可见，像HDFS这样的分布式文件系统在存储海量小文件的应用中具有一定局限性，或者说，这种分布式文件系统通常无法实现海量小文件的存储。

为了改善这种情况，本发明的发明人基于分布式文件系统的特点，提出了一种新的分布式文件处理系统，该系统可以基于MongoDB构建而成，实现对海量小文件的存储，同时也能够实现对海量大文件的存储，此外，还能够支持水平扩展，支持文件的快速存取等功能，满足了如今的大数据时代下的海量文件的存储需求。

MongoDB是一个基于分布式文件存储的数据库，由C++语言编写，旨在为web应用提供可扩展的高性能数据存储解决方案，由于MongoDB是一个介于关系数据库和非关系数据库之间的产品，能够存储比较复杂的数据类型，且支持的查询语言非常强大，使其具有高性能、易部署、易使用，存储数据非常方便等特点。

其中，MongoDB能够支持BSON(Binary Serialized Document Forma t)和GridFS两种存储方式，BSON是一种类json的二进制形式的存储格式，具有轻量性、可便利性以及高效性等特点；GridFS可以用于存储和恢复超过预设容量阈值(如BSON文件最大限制16MB(单位：兆字节))的文件。

基于此，本发明实施例在MongoDB数据库中创建至少两个数据文档集合，用来存储海量文件；以及至少一个元数据文档集合，用来存储文件系统的元数据信息。在本发明实施例中，数据文档集合可以包括用来存储小于预设容量阈值的文件的第一数据文档集合，可以采用BSON存储格式或类型实现文件存储；用来存储大于该预设容量阈值的文件的第二数据文档集合，可以采用GridFS存储格式或类型实现文件存储，所以说，不同数据文档集合对应的文件存储类型是不同的。

可见，本发明创建的用来存储接收到的待存储文件的文档集合为多个，且各文档集合对数据的存储格式可以不同，这样，本发明实施例接收到待存储文件后，可以根据待存储文件的容量大小等预设属性信息，将该待存储文件存储至相应的数据文档集合，同时将该待存储文件的元数据信息，更新到元数据文档集合，不仅实现了对海量小文件的存储，也实现了对海量大文件的存储，并且根据需要还可以扩展文档集合，实现分布式存储系统的扩展，过程简单，易于实现。

而且，为了节省存储空间资源，本发明实施例可以在接收到待存储文件后，可以先验证该MongoDB数据库中是否已存在该待存储文件，若是已存在，可以仅保存其元数据信息；若不存在，再按照上述方法完成待存储文件的分类存储，避免了对数据的重复存储。

下面将参照附图更详细地描述本发明公开的示例性实施例。虽然附图中显示了本发明公开的示例性实施例，然而应当理解，可以以各种形式实现本发明公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本发明公开的方案，并且能够将本发明的范围完整的传达给本领域的技术人员。

如图1所示，为本发明实施例提供的一种基于MongoDB的文件处理方法的流程图，该方法可以包括：

步骤S101，获得待存储文件；

其中，待存储文件可以是文本文件、word文件、PDF文件、音视频文件、图片等类型的文件，本发明对该待存储文件的文件类型不做限定。

在本发明实施例中，在接收到客户端上传的待存储文件后，可以根据文件存储需要确定待存储文件的文件类型，文件容量大小、文件ID等属性信息，本发明对此不做限定。

步骤S102，检测当前MongoDB的多个数据文档集合中是否存在该待存储文件，如果否，进入步骤S103，如果是，执行步骤S104；

结合上述描述，本发明实施例中，分布式文档存储数据库MongoDB包含创建的至少两个用来存储文件的数据文档集合，如上述第一数据文档集合和第二数据文档集合，以及至少一个存储元数据信息的元数据文档集合，并且，用来存储文件的各文档集合用来存储文件的存储格式可以不同，或者说是所存储的文件的预设属性信息(比如上述文件容量大小等某一特定的属性信息)可以不同。

在获得待存储文件后，为了避免存储重复文件，可以先检测该MongoDB中的各数据文档集合中是否已经存储了该待存储文件，本发明对检测的具体方法不做限定。

可选的，本发明可以利用布隆过滤器(Bloom Filter)检测待存储文件是否存在，并且，基于此确定待存储文件存在的情况下，还可以进一步查询元数据文档集合是否存在待存储文件的MD5信息，若存在待存储文件的MD5信息，认为待存储文件已经存在，否则，将认为该待存储文件还未被存储，布隆过滤器的检测方式出现了误判的情况。

其中，布隆过滤器实际上是一个很长的二进制向量和一系列随机映射函数，可以用于检索一个元素是否在一个集合中，其空间效率和查询时间远远超过一般校验算法，但存在一定的误判率。

而MD5则是指Message Digest Algorithm5(消息摘要算法第五版，MD5)，是计算机安全领域广泛使用的一种散列函数，用以提供消息的完整性保护。在本发明实施例中，MD5可以将整个文件当作一个大本文信息，通过其不可逆的字符串变换算法，产生对应该文件的唯一的MD5信息，从而利用文件的MD5信息的唯一性特点实现一致性验证，即验证元数据文档集合中是否记录有该待存储文件相应的MD5信息。

需要说明的是，本发明对如何利用布隆过滤器检测文件是否存在，以及如何利用文件的MD5信息进一步验证文件是否存在的具体实现方法不做限定。

步骤S103，基于待存储文件的预设属性信息，将待存储文件存储至MongoDB中相应的数据文档集合；

步骤S104，获得该待存储文件的当前元数据信息，更新到MongoDB中的元数据文档集合。

在本发明实施例中，按照上述方法进行检测判断，确定MongoDB中不存在待存储文件的情况下，可以按照预先设定的该MongoDB包含的各数据文档集合分类存储的标准，将该待存储文件发送至对应的文档集合中。

可选的，如上述描述，MongoDB包含的多个数据文档集合对应的文件存储类型可以不同，而各文件存储类型对应的文件的预设属性信息是不同的，因此，本发明实施例可以根据待存储文件的预设属性信息，确定相应的目标文件存储类型，进而确定对应该目标文件存储类型的目标数据文档集合，并将该待存储文件发送至目标数据文档集合。

需要说明的是，本发明对该预设属性信息的具体内容不做限定，比如文件的容量大小等属性信息，具体可以根据在MongoDB构建多个数据文档集合时所依据的属性信息或文件存类型确定。

按照上述方法进行检测判断，确定MongoDB中存在待存储文件的情况下，为了避免存储空间的浪费，本发明实施例可以不对待存储文件进行保存，而只保存该待存储文件对应的元数据信息，以便后续能够根据该元数据信息，得知当前时刻曾接收到该待存储文件。因此，在上述步骤S102的检测结果为存在时，可以直接获得该待存储文件的当前元数据信息，并更新到元数据文档集合。

需要说明的是，本发明对获得待存储文件对应的元数据信息的具体实现方法不做限定，由于元数据主要是描述数据属性的信息，用来支持如指示存储位置、历史数据、资源查找、文件记录等功能。因此，本发明实施例可以基于本发明希望元数据信息包含的内容，确定获得待存储文件的当前元数据信息，本发明在此不再一一列举。

可选的，本发明实施例中的元数据信息可以包括对应文件的创建时间、数据类型、数据容量大小、存储类型、MD5信息等等。

综上，在本发明实施例中，在接收到客户端上传的待存储文件后，将在MongoDB数据库预先设置的多个数据文档集合中，检测是否存在该待存储文件，确定这多个数据文档集合不存在待存储文件后，才会按照待存储文件的预设属性信息，将待存储文件存储到相应的数据文档集合，同时，将该待存储文件的当前元数据信息存储到元数据文档集合，实现了对不同属性的文件的分类存储，且方便后续根据元数据信息到对应的数据文档集合调取所需文件；若确定任意一个数据文档集合已经存在待存储文件，将不再对该待存储文件进行存储，而是直接将其当前元数据信息更新到元数据文档集合，这样，既避免了存储空间的资源浪费，且保证了对所接收到的各文件的记录，方便后续查询上传文件情况。

如图2所示，为本发明实施例提供的另一种基于MongoDB的文件处理方法的流程示意图，该方法可以包括：

步骤S201，获得待存储文件；

步骤S202，利用布隆过滤器验证MongoDB的多个数据文档集合中是否存在该待存储文件，如果是，进入步骤S203，如果否，执行步骤S205；

布隆过滤器可以利用散列数组很简洁的表示一个集合，并判断一个元素(如上述待存储文件等)是否属于这个集合。初始状态下，如图3a所示的散列数组，空的布隆过滤器可以是一个包含m位的散列数组，每一位都置为0。并且，为了表达S＝{x₁，x₂，…，x_n}这样一个n个元素的集合，布隆过滤器可以使用k个相互独立的哈希函数(Hash Function)，分别将集合中的每个元素映射到{1，2，…，m}的范围中，m不小于n，且n不小于k。如图3b所示散列数组，k＝3，且有两个哈希函数选中同一个位置，即图3b中从左边数的第5个。

其中，对于任意一个元素x，第i个哈希函数映射的位置h_i(x)可以被置为1(1≤i≤k)，若一个位置多次被置为1，第一次会起作用，后面的几次将没有任何效果。基于此，本发明实施例可以通过检测各位置是不是1，来判断该文档集合中是否包含待存储文件。

具体的，参照图3c所示的散列数组，当判断y是否属于这个集合，可以对y应用k次哈希函数，如果所有h_i(y)的位置都是1，可以认为y是这个集合的元素，否则认为y不是这个集合中的元素。如图3c所示，可以认为y₁不是这个集合的元素，y₂可能是这个集合的元素。

步骤S203，确定待存储文件的MD5信息；

在本发明实施例的实际应用中，由于利用布隆过滤器验证一个文件是否在一个集合时，有可能会把不属于这个集合的文件误认为属于这个集合，将会导致验证结果的误判，如上述图3c中的y2的各哈希函数映射的位置虽然都是1，但也不能保证y2就一定是这个集合中的元素。

因此，为了弥补布隆过滤器在判断待存储文件是否存在于预设的多个文档集合时存在的误判，本发明实施例在步骤S202的验证结果为存在待存储文件的情况下，仍需要进一步验证该待存储文件是否属于预设的文档集合，此时，本发明实施例可以利用待存储文件的唯一文件标识实现验证。

其中，该文件标识可以是文件的MD5信息等具有唯一性的标识，但并不局限于MD5信息这一文件标识，本发明实施例在此仅以MD5信息为例进行说明，对于其他文件标识的验证过程类似，本发明在此不再详述。

基于此，本发明实施例可以利用MD5算法的文件一致性校验功能，获取待存储文件的MD5信息，如预设长度的字符串等，本发明生成文件的MD5信息的具体过程不做详述。在本发明中，MD5信息好比是其对应文件的“数字指纹”，每个文件的MD5信息都是不同的，且对该文件进行任何操作后，其对应的MD5信息将会改变，所以说，文件的MD5信息具有唯一性。

步骤S204，检测MongoDB的元数据文档集合是否记录有该待存储文件的MD5信息，如果否，进入步骤S205，如果是，执行步骤S210；

在本发明实施例中，MongoDB中创建的元数据文档集合是由多个元数据信息组合，为了使本发明提供的基于MongoDB文件处理系统能够达到计算机设备文件系统一样的便利性，能够支持目录，快速遍历目录下的文件，元数据信息可以包括以下内容，但并不局限于此。

{

_id:1,

name:"测试目录1",

createTime:"2017-8-31 13:06:11",

type:"directory",

parentId:0

}

{

_id:2,

name:"测试目录2",

createTime:"2017-8-31 13:06:11",

type:"directory",

parentId:1

}

{

_id:3,

name:"测试目录3",

createTime:"2017-8-31 13:06:11",

type:"directory"，

parentId:2

}

{

_id:4,

name:"文件1",

createTime:"2017-8-31 13:06:11",

updateTime:"2017-8-31 13:06:11",

type:"jpeg",

parentId:2,

size:1000,

storeType:"BSON",

md5:"FEA79579EE3D6E4144CAC4F09EDD3524"

}

{

_id:5,

name:"文件2",

createTime:"2017-8-31 13:06:11",

updateTime:"2017-8-31 13:06:11",

type:"MP4",

parentId:2,

size:100000000,

storeType:"GridFS",

md5:"AEF0A1978A6D3AB1EEB5D13B35C1A3F2"

}

由此可见，文件的元数据信息可以包括文件ID即_d，文件名称name，文件创建时间createTime以及结束时间updateTime，文件类型type，如图片jpeg，音频mp4，节点编号parentId，文件容量大小size，存储类型storeType以及MD5信息等等，具体可以根据实际需要确定。并且，上述举例的元数据信息可以表示如下的文件存放格式，以便据此快速查找目标文件。

测试目录1

|

|---测试目录2

||

||---文件1

||

||---文件2

|

|---测试目录3

基于上述对元数据信息包含的内容的描述可知，对应于每一个文件的元数据信息包含MD5信息，由于该MD5信息是基于该文件生成的唯一性标识，所以，若元数据信息包含MD5信息，数据文档集合必然存储有对应的文件。本发明实施例可以基于此，进一步验证数据文档集合中是否存在有待存储文件。

步骤S205，获取该待存储文件的文件容量；

在本发明实施例中，确定元数据文档集合包含的各元数据信息记录的MD5信息，都不同于待存储文件的MD5信息，说明布隆过滤器验证该待存储文件属于数据文档集合的结果属于误判，该待存储文件实际上并未被存储，需要对其进行保存。

为了解决现有的HDFS无法实现对海量大文件的存储，本发明提供基于MongoDB构建新的分布式文件处理系统，具体利用MongoDB支持的两种存储格式，构建了至少两个数据文档集合，分别存储小文件和大文件，同时构建了至少一个元数据文档集合，用来存储对应所存储文件的元数据信息，不再将元数据信息存储到Name Node的内存，避免了由此造成存储海量小文件的情况下，因该内存吃不消而导致无法正常存储的情况发生。

基于此，在确定MongoDB中的各数据文档集合都未存储待存储文件，为了确定将该待存储文件存放到哪个文档集合，本发明实施例可以获取该待存储文件的文件容量。

需要说明的是，若本发明实施例依据文件的其他属性信息，构建多个存储文件的文档集合，此时，可以相应改变获取的待存储文件的属性信息，并不局限于文件容量这一属性信息。

步骤S206，判断待存储文件的文件容量是否大于预设阈值，如果否，进入步骤S207，如果是，执行步骤S208；

在本发明实施例中，可以根据文件容量的大小，设定至少两种文件存储类型，即BSON和GridFS，并针对这两种文件存储类型构建了各自对应的数据文档集合，分别用来存储属于对应文件存储类型的文件，或者说存储属于对应文件容量范围内的文件。因此，本发明实施例确定要存储待存储文件时，可以根据该待存储文件的文件容量，确定其对应的文件存储类型，进而确定应该存储的数据文档集合。

其中，关于文件存储类型的确定，可以根据文件容量是否大于预设阈值的判断结果确定，也就是说，不同的判断结果对应不同的文件存储类型，具体，判断结果为否，对应BSON这一文件存储类型，反之对应GridFS这一文件存储类型。

需要说明的是，本发明还可以根据其他方式划分多个数据文档集合，相应的，根据待存储文件的其他属性信息，确定其对应的数据文档集合，从而实现文件的分类存储，本发明在此不再一一详述。

步骤S207，将待存储文件存储至MongoDB的第一数据文档集合；

步骤S208，将待存储文件存储至MongoDB的第二数据文档集合；

由于待存储文件的预设属性信息可以是文件容量，本发明实施例可以在MongoDB中创建用来存储文件容量小于预设阈值的文件的第一数据文档集合，以及用来存储文件容量大于预设阈值的文件的第二数据文档集合，获得待存储文件的文件容量后，可以按照该文件容量是否达到预设阈值的判断结果，将该待存储文件存储至相应的数据文档集合，从而实现了文件的分类存储。

其中，预设阈值可以根据第一数据文档集合和第二数据文档集合所采用的数据存储格式的文件容量限制确定，如第一数据文档集合采用BSON存储格式，而BSON的文件最大限制是16MB，那么，该预设阈值可以为16MB，但并不局限于这个数值。

步骤S209，更新布隆过滤器；

结合上述步骤S202部分的描述，本发明实施例可以利用布隆过滤器的散列数组中每一位元素的数值，以及哈希函数映射关系，验证集合中是否存在待存储文件。所以，在将上传的新的文件即待存储文件存储到文档集合后，需要更新该布隆过滤器的散列数组等信息，从而保证据此对后续上传的文件的校验。

需要说明的是，本发明对布隆过滤器的散列数组等信息的更新方法不作限定，具体可以根据该布隆过滤器中哈希函数的位置映射关系等确定，本发明实施例在此不做详述。

步骤S210，获得待存储文件的当前元数据信息，更新到MongoDB中的元数据文档集合。

在本发明实施例中，在将上传的待存储文件存储至MongoDB中相应得的数据文档集合后，将会相应更新元数据文档集合，以便今后利用元数据文档集合中的元数据信息，查询相应的文件。

可选的，本发明可以根据待存储文件的各种属性信息，如该待存储文件的ID、文件类型、创建时间、所存储的文档集合的标识或对应的数据存储格式、MD5信息等属性信息，生成该待存储文件的元数据信息，并将其保存到元数据文档集合中。

基于上述描述，在上述文件是否属于文档集合的验证过程中，若布隆过滤器验证MongoDB的多个文档集合都不存在待存储文件，那么，该待存储文件确实未曾被存储过；若布隆过滤器验证MongoDB的多个数据文档集合存在待存储文件，但元数据文档集合中并未记录待存储文件的MD5信息，那么，确定待存储文件并未被存储过，这两种情况下，都将会按照上述方法，将待存储文件存储至相应的数据文档集合中。

其中，在将待存储文件存储至数据文档集合时，本发明将根据待存储文件的文件容量，确定待存储文件是小文件还是大文件，从而将其存储到预设的对应数据文件集合，从而使本发明实施例既实现了对海量小文件的存储，也实现了海量大文件的存储；并且，还能够根据需要扩展文档集合数量，实现分布式文件处理系统的水平扩展，满足更多类型的文件存储需求。

另外，若布隆过滤器验证MongoDB的多个数据文档集合存在待存储文件，且元数据文档集合中记录有待存储文件的MD5信息，这种情况下，才确定该待存储文件已经被存储了，此时，本发明实施例将直接存储该待存储文件当前元数据信息至元数据文档集合，而不再存储待存储文件，避免了对同一文件的多次存储，节省了存储空间资源。

参照图4，为本发明实施例提供的又一种基于MongoDB的文件处理方法的流程图，本方法主要是基于上述实施例描述的文件存储方案，实现的一种文件读取方法，至于被读取的文件如何存储的过程可以参照上述实施例的描述，本发明实施例在此不做赘述。本实施例提供的文件处理方法可以包括以下步骤：

步骤S401，接收到针对待读取文件的读取指令；

在实际应用中，用户可以通过客户端发起针对待读取文件的读取指令，以便从MongoDB获取待读取文件。因此，该读取指令可以包括待读取文件的文件标识，以使得MongoDB能够根据该文件标识识别哪个文件时待读取文件，该文件标识可以包括文件名称、文件ID等一个或多个组合，本发明对该文件标识包含的内容不作限定。

步骤S402，解析该读取指令，确定该待读取文件的文件标识；

步骤S403，查询MongoDB的元数据文档集合存储的与该文件标识对应的元数据信息，确定待读取文件的文件存储类型；

如上述实施例对各文件对应的元数据信息的描述，该元数据信息通常可以包括文件ID、文件类型、文件创建时间、文件存储类型以及文件的MD5信息等内容，所以，在确定待读取文件的文件标识后，可以从元数据文档集合存储的元数据信息中，查找包含有该文件标识的元数据信息，也就是说与该文件标识对应的元数据信息，从而根据查找到的元数据信息，确定出待读取文件的文件存储类型。

可选的，在本发明实施例中，若通过对MongoDB的元数据文档集合存储的元数据信息的查询，并未查询到与该待读取文件的文件标识对应的元数据信息，可以向客户端反馈相应的提示信息，从而使用户根据该提示信息重新发起读取指令。

需要说明的是，本发明实施例对查询与待读取文件的文件标识对应的元数据信息的实现方法不作限定。

步骤S404，从与该文件存储类型对应的数据文档集合中读取该待读取文件。

结合上述对文件存储方案的描述可知，MongoDB中构建的多个数据文档集合对应的文件存储类型是不同的，因此，本发明实施例能够利用文件存储类型，确定待读取文件所在的数据文档集合，进而从中读取该待读取文件，反馈至用户客户端。

综上，在本发明实施例中，基于上述描述的文件存储方案，当需要读取某一文件时，可以先确定该文件对应的文件存储类型，从而到与该文件存储类型对应的数据文档集合中读取该文件，缩小了读取文件的查找范围，提高了文件读取速度。

如图5所示，为本发明实施例提供的一种基于MongoDB的文件处理装置的结构图，该装置可以包括：

文件获得模块510，用于获得待存储文件；

文件检测模块520，用于检测分布式文档存储数据库MongoDB的多个数据文档集合中是否已存储所述待存储文件；

文件处理模块530，用于确定所述多个数据文档集合中未存储所述待存储文件，基于所述待存储文件的预设属性信息，将所述待存储文件存储至相应的数据文档集合；

可选的，如图6所示，该文件处理模块530可以包括：

第一确定单元531，用于基于所述待存储文件的预设属性信息，确定所述待存储文件对应的目标文件存储类型；

存储单元532，用于将所述待存储文件存储对应所述目标文件存储类型的数据文档集合。

元数据更新模块540，用于获得所述待存储文件的当前元数据信息，更新到所述MongoDB的元数据文档集合。

可选的，在本发明实施例中，文件检测模块520确定所述多个数据文档集合中已存储所述待存储文件，触发执行该元数据更新模块540。

综上，本发明实施例通过在MongoDB预先设置的多个数据文档集合以及至少一个元数据文档集合，接收到待存储文件后，检测这多个数据文档集合确实未存储该待存储文件，将基于待存储文件的预设属性信息，将其存储到相应的数据文档集合，并将该待存储文件的当前元数据信息更新到元数据文档集合，而不是将元数据信息存储到Name Node的内存中，解决了因Name Node的内存无法存储海量小文件的元数据信息，导致无法存储海量小文件的技术问题，同时本发明通过对文件分类存储，还能够实现对大文件的存储，且便于通过增加数据文档集合实现系统水平扩展。

可选的，如图7所示，文件检测模块520可以包括：

验证单元521，用于利用布隆过滤器验证MongoDB的多个数据文档集合中是否存在所述待存储文件；

第二确定单元522，用于在第一验证单元的验证结果为是时，确定所述待存储文件的MD5信息；

检测单元523，用于检测MongoDB的元数据文档集合中是否记录有所述待存储文件的MD5信息；

更新单元524，用于检测单元的检测结果为否时，触发执行文件处理模块，并更新所述布隆过滤器。

作为本申请另一实施例，如图8所示，在上述实施例的基础上，装置还可以包括：

读取指令接收模块550，用于接收到针对待读取文件的读取指令；

解析模块560，用于解析所述读取指令，确定所述待读取文件的文件标识；

查询模块570，用于查询所述元数据文档集合存储的与所述文件标识对应的元数据信息，确定出所述待读取文件的文件存储类型；

文件读取模块580，用于从与确定的所述文件存储类型对应的数据文档集合中读取所述待读取文件。

可见，在上述文件存储方案的基础上，当需要读取某一文件时，可以先确定该文件对应的文件存储类型，从而到与该文件存储类型对应的数据文档集合中读取该文件，缩小了读取文件的查找范围，提高了文件读取速度。

上面主要从虚拟装置的角度描述了实现基于MongoDB的文件处理方法的装置结构，从硬件结构来看，该装置可以包括处理器和存储器，上述文件获得模块、文件检测模块、文件处理模块、元数据更新模块、读取指令接收模块、解析模块、查询模块、文件读取模块等均可以作为程序模块存储在存储器中，由处理器执行存储在存储器中的上述程序单元来实现相应的功能。

处理器中包含内核，由内核去存储器中调取相应的程序模块。内核可以设置一个或以上，获得待存储文件，检测分布式文档存储数据库MongoDB的多个数据文档集合中是否已存储所述待存储文件；若未存储，才会基于所述待存储文件的预设属性信息，将所述待存储文件存储至相应的数据文档集合，获得所述待存储文件的当前元数据信息，更新到所述MongoDB的元数据文档集合，而不是将元数据信息存储到Name Node的内存中，解决了因Name Node的内存无法存储海量小文件的元数据信息，导致无法存储海量小文件的技术问题，同时本发明通过对文件分类存储，还能够实现对大文件的存储，且便于通过增加数据文档集合实现系统水平扩展。，

存储器可以是计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)，存储器包括至少一个存储芯片。

本申请实施例提供了一种存储介质，其上存储有程序，该程序被处理器执行时实现上述基于MongoDB的文件处理方法。

本申请实施例提供了一种处理器，所述处理器用于运行程序，其中，所述程序运行时执行基于MongoDB的文件处理方法。

如图9所示，为本发明实施例提供的一种服务器的硬件结构图，该服务器可以包括：

通信接口910；

存储器920，用于存储实现如上所述的基于MongoDB的文件处理方法的程序；

处理器930，用于加载并执行所述存储器存储的程序，包括：

可选的，处理器930还可以执行实现以下步骤的程序：

如果存在，确定所述待存储文件的MD5信息；

可选的，处理器930还可以执行实现以下步骤的程序：

如图10所示，为本发明实施例提供的一种基于MongoDB的文件处理系统的结构图，该系统可以包括：分布式文档存储数据库MongoDB1010以及服务器1020，其中：

MongoDB包括多个数据文档集合以及至少一个元数据文档集合，且所述多个数据文档集合用于存储具有对应文件存储类型的文件，所述元数据文档集合用于存储对应于所述文件的元数据信息；

服务器1020可以是上述服务器实施例描述的服务器，具体组成结构及其功能可以参照上述服务器实施例相应部分的描述，本实施例在此不再赘述。

本申请实施例还提供了一种计算机程序产品，当在数据查询的处理设备上执行时，适于执行初始化有如下方法步骤的程序：

获得所述待存储文件的当前元数据信息，更新到所述MongoDB的元数据文档集合；

可选的，处理器还可以适于执行有如下步骤的程序：

如果存在，确定所述待存储文件的MD5信息；

可选的，处理器还可以适于执行有如下步骤的程序：

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

存储器可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flashRAM)。存储器是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本发明的实施例可提供为方法、系统或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

以上仅为本发明的实施例而已，并不用于限制本发明。对于本领域技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本发明的权利要求范围之内。

Claims

1.一种基于MongoDB的文件处理方法，其特征在于，所述方法包括：

2.根据权利要求1所述的方法，其特征在于，所述检测分布式文档存储数据库MongoDB的多个数据文档集合中是否已存储所述待存储文件，包括：

如果存在，确定所述待存储文件的MD5信息；

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

4.根据权利要求1所述的方法，其特征在于，所述方法还包括：

5.根据权利要求1所述的方法，其特征在于，所述基于所述待存储文件的预设属性信息，将所述待存储文件存储至相应的数据文档集合，包括：

6.一种基于MongoDB的文件处理装置，其特征在于，所述装置包括：

文件获得模块，用于获得待存储文件；

7.一种服务器，其特征在于，所述服务器包括：

通信接口；

存储器，用于存储实现如权利要求1-5中任一项所述的基于MongoDB的文件处理方法的程序；

处理器，用于加载并执行所述存储器存储的程序，包括：

8.一种基于MongoDB的文件处理系统，其特征在于，所述系统包括：

以及，如权利要求7所述的服务器。

9.一种存储介质，其特征在于，所述存储介质包括存储的程序，其中，在所述程序运行时控制所述存储介质所在设备执行如权利要求1-5中任一项所述的基于MongoDB的文件处理方法。

10.一种处理器，特征在于，所述处理器用于运行程序，其中，所述程序运行时执行如权利要求1-5中任一项所述的基于MongoDB的文件处理方法。