文件存储中的索引实现方法和系统与流程

本发明涉及计算机应用技术领域，特别涉及一种文件存储中的索引实现方法和系统。

背景技术：

海量规模下的文件存储将是通过分布式存储集群实现的，并且为该分布式存储集群建立相关的数据中心，以将实现文件读写服务的索引存储于数据中心。

通过数据中心以及索引的设置维护了各个文件在分布式存储集群的存储位置。目前主流的处理方式是通过数据中心保存文件标识及其对应的存储位置的方式来管理索引，进而实现各文件存储位置的维护和响应文件的读写请求。

具体的，该索引将以文件标识为Key，将其与存储位置之间的映射关系存储于一定的区间，而为满足海量存储的需要，该区间涵盖了较大宽度的Key范围，进而存在着单个区间存储的索引数量过大，索引所对应的操作性能显著降低。

技术实现要素：

基于此，有必要提供一种文件存储中的索引实现方法，该方法能够满足海量存储的需要，并显著提高索引的操作性能。

此外，还有必要提供一种文件存储中的索引实现系统，该系统能够满足海量存储的需要，并显著提高索引的操作性能。

为解决上述技术问题，将采用如下技术方案：

一种文件存储中的索引实现方法，包括：

获取文件的索引操作请求；

查询增量区间是否存在所述文件对应的元数据，若为是，则通过位于所述增量区间的元数据响应所述索引操作请求，若为否，则

通过所述增量区间对应的全量区间处理所述索引操作请求；

其中，所述元数据包括所述文件对应的索引。

一种文件存储中的索引实现系统，包括：

请求获取模块，用于获取文件的索引操作请求；

增量查询模块，用于查询增量区间是否存在所述文件对应的元数据，若为是，则通知增量响应模块，若为否，则通知全量响应模块；

所述增量响应模块用于通过位于所述增量区间的元数据响应所述索引操作请求；

所述全量响应模块用于通过所述增量区间对应的全量区间处理所述索引操作请求；

其中，所述元数据包括所述文件对应的索引。

由上述技术方案可知，对于任一文件的索引操作请求，将在增量区间查询该文件对应的元数据，若查询得到，则，该元数据包括了文件对应的索引，通过位于增量区间的元数据响应该文件的索引操作请求，元数据包括了文件对应的索引，因此，可对该文件的索引操作请求进行相应的响应；如若未在增量区间查询得到该文件对应的元数据，则需要通过对应的全量区间进行索引操作请求的处理，在增量区间和对应全量区间的配合下实现海量规模下的文件存储，并且每一区间，特别是增量区间的读写性能明显提高，进而显著提高索引的操作性能。

附图说明

图1是本发明实施例提供的一种服务器的结构示意图；

图2是一个实施例中文件存储中的索引实现方法的流程图；

图3是图2中通过增量区间对应的全量区间处理索引操作请求的方法流程图；

图4是另一个实施例中文件存储中的索引实现方法的流程图；

图5是图4中根据索引创建请求触发进行存储位置的分配的方法流程图；

图6是另一个实施例中文件存储中的索引实现方法的流程图；

图7是图6中通过合并任务的发起触发进行增量区间和对应全量区间的区间合并的方法流程图；

图8是一个实施例中元数据存储服务的应用示意图；

图9是一个实施例中索引创建的时序图；

图10是一个实施例中索引获取的时序图；

图11是一个实施例中索引删除的时序图；

图12是一个实施例中文件存储中的索引实现系统的结构示意框图；

图13是图12中全量响应模块的结构示意框图；

图14是另一个实施例中文件存储中的索引实现系统的结构示意框图；

图15是图14中位置分配模块的结构示意框图；

图16是另一个实施例中文件存储中的索引实现系统的结构示意框图；

图17是图16中合并模块的结构示意框图。

具体实施方式

体现本发明特征与优点的典型实施方式将在以下的说明中详细叙述。应理解的是本发明能够在不同的实施方式上具有各种的变化，其皆不脱离本发明的范围，且其中的说明及图示在本质上是当作说明之用，而非用以限制本发明。

如前所述的，主流分布式存储主要分布两种索引的管理方式，一种是避免使用数据中心，而采用一致性哈希的方式管理索引；另一种是使用数据中心保存文件标识及其对应的存储位置的方式来管理索引。

无论采用何种方式，对于海量的文件存储规模而言，均大规模不断维护着不断膨胀的海量索引。

而对于现有的海量索引，其操作性能将是由索引查询的延迟高低决定的，现有的索引管理方式由于需要查询的数据量过大而无法提高操作性能。

因此，需要对文件存储中索引的实现进行优化，提供一种文件存储中的索引实现方法，以提高其处理各种索引操作的性能。

该文件存储中的索引实现方法将由计算机程序实现，与之相对应的，所构建的文件存储中的索引实现系统则被存储在服务器或者服务器集群中，以运行实现各种索引操作的处理，进而完成索引的增删查改操作。

图1示出了本发明实施例提供的一种服务器结构示意图。该服务器100可因配置或性能不同而产生较大差异，可以包括一个或一个以上中央处理器（central processing units，CPU）110（例如，一个或一个以上处理器）和存储器120，一个或一个以上存储应用程序131或数据133的存储介质130（例如一个或一个以上海量存储设备）。其中，存储器120和存储介质130可以是短暂存储或持久存储。存储在存储介质130的程序可以包括一个或一个以上模块（图示未示出），每个模块可以包括对服务器中的一系列指令操作。更进一步地，中央处理器110可以设置为与存储介质130通信，在服务器100上执行存储介质130中的一系列指令操作。服务器100还可以包括一个或一个以上的电源150，一个或一个以上有线或无线网络接口170，一个或一个以上输入输出接口180，和/或，一个或一个以上操作系统135，例如Windows ServerTM，Mac OS XTM，UnixTM, LinuxTM，FreeBSDTM等等。下述实施例中所述的由服务器执行的步骤可以基于该图1所示的服务器结构。

如上面所详细描述的，适用本发明的服务器100将对通过程序指令的形式对文件的索引操作请求进行响应，以实现文件存储中的索引。

此外，通过硬件电路或者硬件电路结合软件指令也能同样实现本发明，因此，实现本发明并不限于任何特定硬件电路、软件以及两者的组合。

在一个实施例中，具体的，该文件存储中的索引实现方法如图2所示，包括：

步骤210，获取文件的索引操作请求。

该文件可以是即将进行存储的文件，即，将要存入分布式存储系统中的文件；也可以是已经存储在分布式存储系统中的任一文件。文件的索引操作将是与文件在分布式存储系统中涉及的操作相对应的，将根据所需进行的文件操作触发相应的索引操作。

例如，文件在分布式存储系统中涉及的文件操作包括写入操作、读取操作、删除操作等，以实现文件的写入、读取和删除；与之相对应的，文件的索引操作则包括索引的创建、获取和删除操作。

由于存储的文件是海量的，并且也不断有新的文件需要写入，而需针对某一文件执行一定文件操作的客户端也是海量的，因此，将不断接收客户端发起的文件索引操作请求。

步骤230，查询增量区间是否存在该文件对应的元数据，若为是，则进入步骤250，若为否则，进入步骤270。

在实际运营中，元数据以及用于实现元数据存储的增量区间的存储可在元数据集群中进行，也可在其它装置中实现。元数据集群用于存储元数据并提供元数据存储服务，其中任一元数据包括了文件对应的索引以及相关的属性，元数据之间将首先通过文件标识区分；元数据存储服务则是构建在元数据之上的提供服务的程序，进而提供数据增删查改的接口以使响应索引操作请求时调用。

元数据集群中，对于任一Key区间，都划分成增量区间和全量区间两种区间类型，其中，增量区间和全量区间均存储了多条元数据，但增量区间中存储的数据量将远小于全量区间中存储的数据量。

针对存储的文件，无论是获取存储的文件还是删除存储的文件，客户端都将相应发起文件的索引操作请求，其中，该索引操作请求是索引获取请求或者索引删除请求。

获取得到该索引操作请求之后，将首先在元数据停发的增量区间进行元数据的查询，如果增量区间存储了相应的元数据，则使该元数据对索引操作请求进行响应即可。

由于增量区间存储的数据量较少，其查询性能非常高，从而避免了由于查询所造成的延迟。

步骤250，通过位于增量区间的元数据响应索引操作请求。

在由增量区间查询得到索引操作请求对应的元数据之后，将在该元数据中执行相应的索引操作，并向客户端返回相应的处理结果，以完成索引操作请求的响应。

步骤270，通过增量区间对应的全量区间处理索引操作请求。

未在增量区间查找得到索引操作请求对应的元数据，则说明该元数据存储于全量区间的可能性极大，因此，通过全量区间进行该索引操作请求的处理即可。

也就是说，元数据集群作为分布式存储系统的数据中心，虽然也如现有的数据中心的功能相类似，也进行索引的存储和管理，然而，其实现存储服务的架构并不相同。

在此元数据集群中，任一Key区间均划分为增量区间和全量区间，在获取得到文件的索引操作请求之后，将根据文件标识确定Key区间，在此确定的Key区间中，首先在增量区间进行查询，如若查询不到相应的元数据才会在对应的全量区间中查询，如果在增量区间中查询得到相应的元数据，则极大地节省了计算资源，并且保证了海量数据存储的高可靠性。

在一个实施例中，如上所述的索引操作请求包括索引获取请求，该步骤250包括：

增量区间查询得到的文件对应的元数据中，按照写入时间戳提取元数据，并下发提取的元数据。

如前所述的，元数据包括了文件对应的索引以及相关的属性，该属性包括了针对该索引执行操作所对应的时间戳，例如，在增量区间写入元数据时标记的写入时间戳等。

在写入时间戳的作用下，元数据之间除了通过文件标识相互区分之外，还将在时间戳的辅助下进行相互之间的区分。因此，对于同一文件，可对应了多条元数据，并同处于增量区间中、全量区间中或者分布于增量区间和全量区间中，这些元数据拥有同一文件标识，但写入时间戳各不相同。

因此，实际运营中，增量区间查询得到的文件对应的多条元数据中，比对每一元数据中的写入时间戳，以提取时间戳最新的元数据，并下发。

进一步的，在本实施例中，如图3所示，该步骤270包括：

步骤271，进一步查询增量区间对应的全量区间是否存在文件对应的元数据，若为是，则进入步骤273，若为否，则进入步骤275。

如未在增量区间查询得到对应的元数据，则在对应全量区间进行元数据的查询。

具体的，根据索引操作请求中记录的文件标识，在全量区间查询包括了该文件标识的元数据，所查询得到的元数据即为文件所对应的元数据。

步骤273，由全量区间查询得到的文件对应的元数据中按照写入时间戳提取元数据，并下发。

如前所述的，每一元数据均有对应的写入时间戳，因此，将按照写入时间戳提取这一文件对应的时间戳最新的元数据。

步骤275，返回没有该文件对应的索引记录的结果信息。

如果未在全量区间查询得到对应的元数据，则需向发起索引操作请求的客户端反馈相应的结果信息。

在一个实施例中，如上所述的索引操作请求包括了索引删除请求，该步骤250包括：

根据文件的索引删除请求在位于增量区间的元数据中标记索引删除操作，并添加索引删除操作对应的删除时间戳。

对存储的文件执行删除操作之前，将首先执行索引的删除操作，因此，客户端将首先向元数据集群发起索引删除请求。

对于元数据集群而言，将获取得到索引删除请求，并由增量区间查询得到对应的元数据，在此基础上，根据文件的索引删除请求将该元数据标记为删除，即标记索引删除操作，而非直接删除该元数据，并在该元数据所包含的属性中添加对应的删除时间戳。

通过此过程，将避免了当前版本的元数据被丢弃，而将其保存为历史版本，从而在遇到用户希望回退的问题时得以提供支持。

在一个实施例中，如上所述的索引操作请求包括索引创建请求，该步骤210之后，如图4所示，如上所述的方法还包括：

步骤310，根据索引创建请求触发进行存储位置的分配。

索引创建请求中记录了文件标识，该文件标识与当前需要写入的文件相对应。任一客户端如需要向分布式存储系统写入文件，则首先需要为该文件创建索引。

具体的，客户端向元数据集群发起索引创建请求，相对应的，在接收的客户端发起的索引创建请求之后，触发为即将写入的文件分配存储位置，即进行该文件存储的物理位置。

随着存储位置的分配，当前需要写入的文件将被按照该存储位置进行存储。进一步的，在本实施例中，如图5所示，该步骤310包括：

步骤311，提取索引创建请求中的文件标识。

步骤313，触发进行文件的存储位置分配，以使文件按照存储位置写入。

步骤330，根据分配得到的存储位置建立文件的索引，通过该索引形成文件的元数据。

元数据中索引是文件标识和存储位置之间的映射关系。如前所述的，任一条元数据均包括了文件对应的索引以及相关的属性。因此，为一文件的写入创建索引的过程中，将根据文件标识和存储位置形成元数据中的索引部分，通过添加写入时间戳形成元数据中的属性部分。

具体的，由分配得到的存储位置形成文件的元数据的具体过程包括：建立文件标识和分配的存储位置之间的映射关系，以由该映射关系作为索引形成文件的元数据。

其中，该分配的存储位置可为一个或者多个，以通过多个存储位置进行文件存储的多个备份。

步骤350，在元数据中添加写入时间戳。

步骤370，定位增量区间，通过新增数据的方式将形成的元数据写入定位的增量区间。

对于增量区间的定位，其具体过程为：根据索引创建请求中的文件标识，得到元数据集群中对应的Key区间，该Key区间中的增量区间即为当前进行索引创建的增量区间。

新增数据的写入方式即为Append（追加）方式，而非覆盖写入的方式，以保证历史版本的保留，从而使得后续对于同一文件可跟踪其不同版本。

在另一个实施例中，如图6所示，如上所述的方法还包括如下步骤：

步骤410，发起合并任务。

该合并任务指的是对增量区间和对应全量区间中的元数据进行合并处理。该合并任务的发起是随着Merge操作的触发进行的，通过Merge操作的饮用执行合并已有增量区间和对应全量区间的动作，以完成合并任务。其中，该Merge操作可以是离线操作。

步骤430，通过合并任务的发起触发进行增量区间和对应全量区间的区间合并。

如前所述的，新的元数据写入将是以新增数据的方式在增量区间进行的，而对于数据集群中元数据的删除，也是在增量区间添加相应的标记，由此可知，全量区间中的元数据是不会发生修改的，仅有增量区间发生了元数据的修改。

全量区间将用于进行元数据的历史数据记录，而增量区间则用于进行元数据的写入、删除，元数据的查询则在全量区间和增量区间进行，从而既可查询历史数据，也可对新增的元数据进行查询。

随着新文件的不断写入，增量区间中包含的元数据在不断增加膨胀，因此，需要对分区进行动态调整，以保证增量区间的数据量远小于全量区间的数据量，保障增量区间中索引的读写性能。

该分区的动态调整过程即为已有增量区间和全量区间的合并以及新的增量区间的创建过程。

步骤450，划分合并的区间得到若干个全量区间。

由已有的增量区间和对应的全量区间合所得到的区间大都包含了大量的元数据，其数据量非常大，因此需要对该区间进行划分，以得到若干个全量区间，进而使得划分得到的全量区间在元数据条数和发生的平均索引操作数都尽可能均衡。

步骤470，分别创建若干个全量区间对应的增量区间，以用于为文件的索引操作请求提供写入服务。

每一全量区间均有与之相对应的增量区间，因此，随着全量区间的分区划分，将对应创建增量区间。

在后续所进行的文件写入中，索引的创建和写入在新创建的增量区间中实现，即生成并在新创建的增量区间中写入对应的元数据。

通过如上所述的过程，通过合并任务的发起实现了区间的动态调整，进而元数据集群中增量区间和全量区间的设置是与其存储的元数据数据量相适应的，为元数据的存储和索引的增、删、查改等相关存储服务的实现提供了较强的可靠性。

进一步的，在本实施例中，如图7所示，该步骤430包括：

步骤431，通过合并任务的发起触发导出增量区间和对应全量区间的元数据。

合并任务发起时，将合并在此时间点之前写入的元数据，并使用新的增量区间存储这一时间点后写入的元数据。因此，通过合并任务的发起触发导出当前增量区间和全量区间中的元数据。其中，该导出过程和合并过程可以是分布式进行的。

步骤433，将增量区间和对应的全量区间合并为一个区间。

步骤435，根据预置的合并策略合并导出的元数据。

预置的合并策略包括：（1）是否剔除标识删除的元数据；（2）是否合并文件标识相同，写入时间戳不同的元数据；（3）合并得到的区间进行分区时每一区间的大小；用于进行元数据合并的合并策略可以为其中的任意一种，或者几种策略的组合，可根据实际运营的需要确定，灵活性较强。

进一步的，该步骤435的过程包括：在导出的元数据中剔除标记了索引删除操作的元数据，以实现剔除标识删除的元数据的合并策略。

步骤437，将合并后的元数据纳入该区间。

下面结合一个具体的实施例来详细阐述上述文件存储中的索引实现方法。该实施例中，如图8所示，在实际运营中，元数据存储服务是通过Delta和Snapshot实现的，其中，Delta即上述所说的增量区间，Snapshot则为上述所说的全量区间，二者相对应。

对于元数据的访问也就分为两部分，即访问Delta和访问Snapshot，也就说，该元数据的访问即为图8所示的数据读取过程。

如图8所示的方块将清楚的显示了Delta中包含的数据量远小于Snapshot中包含的数据量。而新数据的写入，即索引的创建将针对Delta进行。

请结合参阅图9，即客户端向数据节点选择器发起索引创建请求时，数据节点选择器将触发分配存储位置，即执行步骤620，并向客户端返回分配结果，即步骤630。

在客户端和数据节点的作用下，客户端将文件上传至存储位置对应的数据节点，以执行步骤650，在该数据节点中，文件落入磁盘。

客户端将接收数据节点返回的上传结果，以获知文件是否上传成功，若上传文件成功，则根据文件标识和分配的存储位置生成元数据，并执行步骤680进行元数据的上传，以将元数据写入Delta，创建该文件所对应的索引。

需要说明的是，本实施例所说的数据节点选择器即为元数据集群中提供服务的程序，而数据节点则为分布式存储系统中用于提供存储介质的计算机。

在完成了索引的创建之后，请参阅图10，客户端在与数据节点选择器的交互下获取索引。

具体的，客户端将执行步骤710，向数据节点选择器发起索引获取请求，以请求下发索引。数据节点选择器根据索引获取请求中的文件标识即可确定该索引所在的Key区间。

客户端首先向Key区间中的Delta下载索引，以在Delta中查询是否存在包含该索引的元数据，并返回相应的查询结果。

根据查询结果，如若在Delta查询得到包含该索引的元数据，则客户端直接由Delta下载即可。

如若在Delta未查询得到包含该索引的元数据，则需要由对应的Snapshot索引的下载，即执行步骤770至步骤790。

另一方面的，对于创建并存储的索引，如若删除对应的文件，则该索引也将随之删除。

基于此，如图11所示，在文件的删除过程中，客户端向数据节点选择器发起索引删除请求，数据节点选择器执行步骤820以确定包含该索引的元数据存储于Delta上，因此将对该元数据标记索引删除，即执行步骤850，并向客户端反馈索引删除成功。

随着Delta中元数据的写入和标记删除，如图8所示的Merge过程，将Delta和Snapshot合并为NewSnapshot，进而由并创建NewDelta，以实现分区的动态调整。

在一个实施例中，还相应地提供了一种文件存储中的索引实现系统，如图12所示，包括请求获取模块910、增量查询模块930、增量响应模块950和全量响应模块970，其中：

请求获取模块910，用于获取文件的索引操作请求。

增量查询模块930，用于查询增量区间是否存在文件对应的元数据，若为是，则通知增量响应模块950，若为否，则通知全量响应模块970。

增量响应模块950，用于通过位于增量区间的元数据响应索引操作请求。

全量响应模块970，用于通过增量区间对应的全量区间处理索引操作请求。

其中，该元数据包括文件对应的索引。

在一个实施例中，索引操作请求包括索引获取请求，该增量响应模块进一步用于在增量区间查询得到的文件对应的元数据中，按照写入时间戳提取元数据，并下发提取的元数据。

进一步的，如图13所示，在本实施例中，该全量响应模块970包括查询单元971、提取单元973和结果返回单元975，其中：

查询单元971，用于进一步查询增量区间对应的全量区间是否存在文件对应的元数据，若为是，则通知提取单元973，若为否，则通知结果返回单元975。

提取单元973，用于由全量区间查询得到的文件对应的元数据中按照写入时间戳提取元数据，并下发。

结果返回单元975，用于返回没有该文件对应的索引记录的结果信息。

在一个实施例中，索引操作请求包括索引删除请求，增量响应模块进一步用于根据文件的索引删除请求在位于增量区间的元数据中标记索引删除操作，并添加索引删除操作对应的删除时间戳。

在一个实施例中，索引操作请求包括索引创建请求，如图14所示，该系统包括位置分配模块1010、元数据生成模块1030、时间戳添加模块1050和写入模块1070，其中：

位置分配模块1010，用于根据索引创建请求触发进行存储位置的分配。

元数据生成模块1030，用于根据分配得到的存储位置建立文件的索引，通过该索引形成文件的元数据。

时间戳添加模块1050，用于在元数据中添加写入时间戳。

写入模块1070，用于定位增量区间，通过新增数据的试将形成的元数据写入定位的增量区间。

进一步的，在本实施例中，如图15所示，位置分配模块1010包括：

标识提取单元1011，用于提取索引创建请求中的文件标识。

写入单元1013，用于触发进行文件的存储位置分配，以使文件按照存储位置写入。

进一步的，元数据生成模块1030进一步用于建立文件标识和分配的存储位置之间的映射关系，以由映射关系作为索引形成文件的元数据。

在一个实施例中，如图16所示，如上所述的系统还包括任务发起模块1110、合并模块1130、划分模块1150和增量区间创建模块1170，其中：

任务发起模块1110，用于发起合并任务。

合并模块1130，用于通过合并任务的发起触发进行增量区间和对应全量区间的区间合并。

划分模块1150，用于划分合并的区间得到若干个全量区间。

增量区间创建模块1170，用于分别创建若干个全量区间对应的增量区间，以用于为文件的索引操作请求提供写入服务。

进一步的，在本实施例中，如图17所示，合并模块1130包括数据导出单元1131、区间合并单元1133、数据合并单元1135和数据纳入单元1137，其中：

数据导出单元1131，用于通过合并任务的发起触发导出增量区间和对应全量区间中的元数据。

区间合并单元1133，用于将增量区间和对应全量区间合并为一个区间。

数据合并单元1135，用于根据预置的合并策略合并导出的元数据。

进一步的，数据合并单元1135进一步用于在导出的元数据中剔除标记了索引删除操作的元数据。

数据纳入单元1137，用于将合并后的元数据该区间。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

虽然已参照几个典型实施方式描述了本发明，但应当理解，所用的术语是说明和示例性、而非限制性的术语。由于本发明能够以多种形式具体实施而不脱离发明的精神或实质，所以应当理解，上述实施方式不限于任何前述的细节，而应在随附权利要求所限定的精神和范围内广泛地解释，因此落入权利要求或其等效范围内的全部变化和改型都应为随附权利要求所涵盖。