CN108920613A - 一种元数据管理方法、系统及设备和存储介质 - Google Patents
一种元数据管理方法、系统及设备和存储介质 Download PDFInfo
- Publication number
- CN108920613A CN108920613A CN201810688052.0A CN201810688052A CN108920613A CN 108920613 A CN108920613 A CN 108920613A CN 201810688052 A CN201810688052 A CN 201810688052A CN 108920613 A CN108920613 A CN 108920613A
- Authority
- CN
- China
- Prior art keywords
- mds
- metadata
- logical partition
- mapping
- mapping relations
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本申请公开了一种元数据管理方法、系统及设备和计算机可读存储介质,该方法包括:获取元数据的文件名和父目录的唯一标识,并计算所述文件名和所述唯一标识的散列结果,将所述散列结果作为所述元数据的全局标识;根据所述全局标识和第一映射函数得到所述元数据的逻辑分区标识;其中,所述第一映射函数表示散列结果与逻辑分区的映射关系;根据所述逻辑分区标识和所述第二映射函数得到所述元数据的MDS标识;其中,所述第二映射函数表示逻辑分区与MDS的映射关系,且为根据所有MDS的处理能力和当前负载能力建立的函数。本申请公开的元数据管理方法,在元数据管理中,减少移动数据造成的开销。
Description
技术领域
本申请涉及存储技术领域,更具体地说,涉及一种元数据管理方法、系统及设备和一种计算机可读存储介质。
背景技术
日益增长的海量数据的存储与管理都面临着巨大的挑战。传统的存储体系结构,如DAS(中文全称:直接附加存储,英文全称:Directly Attached Storage)和NAS(中文全称:网络附加存储,英文全称:Network Attached Storage),由于其容量以及I/O性能的限制,已经不能满足海量数据存储的需求。SAN(中文全称:存储区域网络,英文全称:StorageArea Network)使用专用存储网络连接主机和设备,可以提供几乎不受设备数量限制的存储容量,适合存储大量数据。但是底层磁盘设备无法验证用户的身份,而且它的共享能力有限,安全性差强人意。
在面向对象的存储系统中,文件的元数据和数据分开存储,元数据的存储和管理由元数据服务器(MDS)负责,而数据存储在对象存储设备(OSD)上。用户从MDS获取文件的元数据后,直接与OSD通信,数据的传输不需要经过MDS转发。尽管元数据的数据量相对于整个存储系统的数据容量而言比较小,但是在访问数据之前必须先访问元数据。MDS机群管理元数据的操作和文件到对象的映射,并执行安全策略。
由此可见,为保证整个存储系统的性能,防止出现瓶颈,元数据的处理负载在整个MDS机群中的分布必须对称均匀,并可以动态调整和扩展。现有技术中的元数据管理方法如目录子树分割法、纯散列分割法、LH(中文全称:延迟混合,英文全称:Lazy Hybrid)元数据管理方法等,在发生访问冲突时移动数据会造成大量的开销。
因此,如何在元数据管理中,减少移动数据造成的开销是本领域技术人员需要解决的问题。
发明内容
本申请的目的在于提供一种元数据管理方法、系统及设备和一种计算机可读存储介质,在元数据管理中,减少了移动数据造成的开销。
为实现上述目的,本申请提供了一种元数据管理方法,包括:
获取元数据的文件名和父目录的唯一标识,并计算所述文件名和所述唯一标识的散列结果,将所述散列结果作为所述元数据的全局标识;
根据所述全局标识和第一映射函数得到所述元数据的逻辑分区标识;其中,所述第一映射函数表示散列结果与逻辑分区的映射关系;
根据所述逻辑分区标识和所述第二映射函数得到所述元数据的MDS标识;其中,所述第二映射函数表示逻辑分区与MDS的映射关系,且为根据所有MDS的处理能力和当前负载能力建立的函数。
其中,还包括:
获取所有所述MDS的处理能力和当前负载能力,并根据所述处理能力和所述当前负载能力建立所述第二映射函数;
其中,所述获取所有所述MDS的处理能力和当前负载能力,包括:
获取所有所述MDS的CPU信息、内存信息和带宽;
根据所述CPU信息中的CPU主频、所述内存信息中的内存大小和所述带宽确定所述MDS的处理能力;
根据所述CPU信息和所述内存信息中的内存使用率确定所述MDS的当前负载能力。
其中,还包括:
监测所有所述MDS对应的逻辑分区数量,判断是否存在逻辑分区数量大于第一预设值的第一目标MDS和逻辑分区数量小于第二预设值的第二目标MDS;
若是,则将所述第一目标MDS中超过所述第一预设值的逻辑分区迁移到所述第二目标MDS中,以便更新逻辑分区与MDS的映射关系;
根据更新后的映射关系修改所述第二映射函数。
其中,还包括:
监测所有所述MDS对应的逻辑分区数量,判断是否存在逻辑分区数量大于第三预设值的第三目标MDS;
若是,则将所述第三目标MDS对应的逻辑分区分裂为N个子部分,并建立每个所述子部分与子MDS的映射关系,以便更新逻辑分区与MDS的映射关系;其中,N为正整数;
根据更新后的映射关系修改所述第二映射函数。
其中,还包括:
监测所有所述MDS对应的逻辑分区数量,判断是否存在逻辑分区数量小于第四预设值的第四目标MDS和第五目标MDS;
若是,则合并所述第四目标MDS和所述第五目标MDS对应的逻辑分区,并建立合并后的逻辑分区与合并MDS的映射关系,以便更新逻辑分区与MDS的映射关系;其中,N为正整数;
根据更新后的映射关系修改所述第二映射函数。
其中,还包括:
获取待查找元数据父目录的唯一标识和全局标识,并根据所述全局标识确定所述待查找数据所在的哈希表;
根据所述唯一标识和所述全局标识在所述哈希表中确定所述带查找元数据的候选地址;
将所述候选地址的记录中与所述唯一标识和所述待查找元数据的文件名均相符的数据确定为所述待查找元数据。
其中,根据所述唯一标识和所述全局标识在所述哈希表中确定所述带查找元数据的候选地址,包括:
判断所述待查找数据在所述哈希表中是否存在哈希冲突;
若是,则将与所述唯一标识和所述全局标识均匹配的地址确定为所述候选地址;
若否,则将与所述唯一标识相匹配的地址确定为所述候选地址。
为实现上述目的,本申请提供了一种元数据管理系统,包括:
获取模块,用于获取元数据的文件名和父目录的唯一标识,并计算所述文件名和所述唯一标识的散列结果,将所述散列结果作为所述元数据的全局标识;
第一确定模块,用于根据所述全局标识和第一映射函数得到所述元数据的逻辑分区标识;其中,所述第一映射函数表示散列结果与逻辑分区的映射关系;
第二确定模块,用于根据所述逻辑分区标识和所述第二映射函数得到所述元数据的MDS标识;其中,所述第二映射函数表示逻辑分区与MDS的映射关系,且为根据所有MDS的处理能力和当前负载能力建立的函数。
为实现上述目的,本申请提供了一种元数据管理设备,包括:
存储器,用于存储计算机程序;
处理器,用于执行所述计算机程序时实现如上述元数据管理方法的步骤。
为实现上述目的,本申请提供了一种计算机可读存储介质,所述计算机可读存储介质上存储有计算机程序,所述计算机程序被处理器执行时实现如上述元数据管理方法的步骤。
通过以上方案可知,本申请提供的一种元数据管理方法,包括:获取元数据的文件名和父目录的唯一标识,并计算所述文件名和所述唯一标识的散列结果,将所述散列结果作为所述元数据的全局标识;根据所述全局标识和第一映射函数得到所述元数据的逻辑分区标识;其中,所述第一映射函数表示散列结果与逻辑分区的映射关系;根据所述逻辑分区标识和所述第二映射函数得到所述元数据的MDS标识;其中,所述第二映射函数表示逻辑分区与MDS的映射关系,且为根据所有MDS的处理能力和当前负载能力建立的函数。
本申请提供的元数据管理方法,元数据到MDS的映射采用两级映射的方法,先把元数据映射到一个逻辑分区,然后逻辑分区再根据策略映射到MDS上。元数据到逻辑分区的映射使用静态散列映射的方法,而逻辑分区到MDS的映射则根据当前MDS的负载和处理能力使用动态映射的方法。动态散列分区是首先根据文件的文件名和路径信息使用静态散列的方法对元数据实现静态分区,然后把分区动态的映射到MDS上。但与HAP(散列分区方法)不同的是分区时使用的信息会保留文件的目录树的位置信息,不会出现不同目录下的同名文件映射到相同的分区,引起潜在的瓶颈问题。而且由于该方法选择的是表示位置信息具有特殊性,在需要移动数据时不会像LH那样在目录重命名时带来巨大的开销。本申请还公开了一种元数据管理系统及设备和一种计算机可读存储介质,同样能实现上述技术效果。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为本申请实施例公开的一种元数据管理方法的流程图;
图2为本申请实施例公开的另一种元数据管理方法的流程图;
图3为本申请实施例公开的一种分布式对象存储系统架构;
图4为本申请实施例公开的一种元数据管理系统的结构图;
图5为本申请实施例公开的一种元数据管理设备的结构图;
图6为本申请实施例公开的另一种元数据管理设备的结构图。
具体实施方式
下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
本申请实施例公开了一种元数据管理方法,在元数据管理中,减少了移动数据造成的开销。
参见图1,本申请实施例公开的一种元数据管理方法的流程图,如图1所示,包括:
S101:获取元数据的文件名和父目录的唯一标识,并计算所述文件名和所述唯一标识的散列结果,将所述散列结果作为所述元数据的全局标识;
在具体实施中,元数据到逻辑分区的映射由文件名和父目录唯一标示的散列结果决定。该散列结果是个全局标识(GlobalID),父目录的唯一标识(ExclusiveID)类似于本地文件系统的索引节点号,在文件系统中唯一标识一个文件或目录。计算所述文件名和所述唯一标识的散列结果的方式如下:
GlobalID=H(filename,ExclusiveID_parent);其中,H()为散列函数。
S102:根据所述全局标识和第一映射函数得到所述元数据的逻辑分区标识;其中,所述第一映射函数表示散列结果与逻辑分区的映射关系;
在具体实施中,元数据到逻辑分区的映射使用静态散列映射的方法,用户可以根据实际情况设置第一映射函数,在此不进行具体限定。若逻辑分区号用LogPid表示,则元数据到逻辑分区的映射关系如下:
LogPid=f(GlobalID);其中,f()为第一映射函数。
S103:根据所述逻辑分区标识和所述第二映射函数得到所述元数据的MDS标识;其中,所述第二映射函数表示逻辑分区与MDS的映射关系,且为根据所有MDS的处理能力和当前负载能力建立的函数。
在具体实施中,逻辑分区到MDS的映射则根据当前MDS的负载和处理能力使用动态映射的方法。可以理解的是,本步骤需要用户预先根据所有MDS的处理能力和当前负载能力建立第二映射函数,此处不对MDS的处理能力和当前负载能力的获取方式进行具体限定,用户可以根据实际情况灵活选择。例如,可以根据CPU信息中的CPU主频、内存信息中的内存大小和带宽确定MDS的处理能力,根据CPU信息和内存信息中的内存使用率确定MDS的当前负载能力。
逻辑分区到MDS的映射是一个动态映射,假设用MDSId标示MDS号,MPWi表示MDSId=i的MDS测处理能力,用MLWi表示MDSId=i的MDS的当前负载能力。则逻辑分区到MDS的映射关系如下:
MDSId=ML(LogPid,MPWi,MLWi);
其中,i∈{0,Mn},Mn为当前总的MDS个数,ML()为该第二映射函数,如果各个MDS的处理能力相同,则整个映射可以简化表示为:
MDSId=ML(LogPid,MLWi);
一个具体的逻辑分区到MDS的映射关系如表1所示,当用户需要访问在逻辑分区33上的元数据,客户端应该发送请求给MDS2。
表1
本申请实施例提供的元数据管理方法,元数据到MDS的映射采用两级映射的方法,先把元数据映射到一个逻辑分区,然后逻辑分区再根据策略映射到MDS上。元数据到逻辑分区的映射使用静态散列映射的方法,而逻辑分区到MDS的映射则根据当前MDS的负载和处理能力使用动态映射的方法。动态散列分区是首先根据文件的文件名和路径信息使用静态散列的方法对元数据实现静态分区,然后把分区动态的映射到MDS上。但与HAP(散列分区方法)不同的是分区时使用的信息会保留文件的目录树的位置信息,不会出现不同目录下的同名文件映射到相同的分区,引起潜在的瓶颈问题。而且由于该方法选择的是表示位置信息具有特殊性,在需要移动数据时不会像LH那样在目录重命名时带来巨大的开销。
在上述实施例的基础上,作为一种优选实施方式,还包括:
S11:监测所有所述MDS对应的逻辑分区数量,判断是否存在逻辑分区数量大于第一预设值的第一目标MDS和逻辑分区数量小于第二预设值的第二目标MDS;若是,则进入S12;
在具体实施中,当文件的访问频率不断变化时,使得某个MDS的负载过重,该MDS的一部分逻辑分区被转移到负载相对较轻的MDS上管理。也就是说,当系统中存在逻辑分区数量大于第一预设值的第一目标MDS和逻辑分区数量小于第二预设值的第二目标MDS时,进行逻辑分区的迁移。此处不对第一预设值和第二预设值进行具体限定,用户可以根据MDS的实际负载能力进行灵活设置。
可以理解的是,在需要进行数据迁移时,不需要一个备用的服务器来接管失败的MDS的工作,只需要改变逻辑分区到MDS的映射关系,即改变第二映射函数,与现有技术相比对于失败转移处理实现更加简单和有效,
S12:将所述第一目标MDS中超过所述第一预设值的逻辑分区迁移到所述第二目标MDS中,以便更新逻辑分区与MDS的映射关系;
在具体实施中,将第一目标MDS中超过第一预设值的逻辑分区迁移到第二目标MDS中。需要说明的是,若迁移后第二目标MDS的逻辑分区数量大于第一预设值,可以进行再次迁移,也可以进行逻辑分区的分裂操作,将在后续进行详细介绍。当然,作为一种优选实施方式,用户也可以在迁移前设定第二目标MDS中逻辑分区的上限值,达到该上限值时停止迁移操作,并将剩余的需要迁移的逻辑分区迁移到其他负载较轻的MDS上。
S13:根据更新后的映射关系修改所述第二映射函数。
可以理解的是,需要根据更新后的映射关系修改第二映射函数,当然,迁移后元数据到逻辑分区的映射关系也可能发生改变,但是这种改变并不会经常发生,因此可以认为元数据到逻辑分区的映射是相对固定的。
在上述实施例的基础上,作为一种优选实施方式,还包括:
S21:监测所有所述MDS对应的逻辑分区数量,判断是否存在逻辑分区数量大于第三预设值的第三目标MDS;若是,则进入S22;
在具体实施中,为了避免预置的逻辑分区个数限制机群的扩展,也为了在一个逻辑分区内能有效的查找元数据,当逻辑分区的元数据到达一定规模后,逻辑分区会随着它管理的元数据的增多动态分裂。也就是说,当系统中存在逻辑分区数量大于第三预设值的第三目标MDS时,进行逻辑分区的分裂。此处同样不对第三预设值进行具体限定,用户可以根据MDS的实际负载能力进行灵活设置。
S22:将所述第三目标MDS对应的逻辑分区分裂为N个子部分,并建立每个所述子部分与子MDS的映射关系,以便更新逻辑分区与MDS的映射关系;其中,N为正整数;
在具体实施中,将第三目标MDS对应的逻辑分区分裂为N个子部分,优选为分为两部分。建立每个所述子部分与子MDS的映射关系,即在系统中增加N-1个MDS,使得N个MDS对应N个逻辑分区的子部分,并根据该对应关系更新逻辑分区与MDS的映射关系。
S23:根据更新后的映射关系修改所述第二映射函数。
在上述实施例的基础上,作为一种优选实施方式,还包括:
S31:监测所有所述MDS对应的逻辑分区数量,判断是否存在逻辑分区数量小于第四预设值的第四目标MDS和第五目标MDS;若是,则进入S32;
在具体实施中,当逻辑分区由于删除操作导致元数据对象减少到一定程度时,可以把两个分区合并成一个分区。也就是说,当系统中存在逻辑分区数量小于第四预设值的第四目标MDS和第五目标MDS时,进行逻辑分区的合并。此处同样不对第四预设值进行具体限定,用户可以根据MDS的实际负载能力进行灵活设置。
S32:合并所述第四目标MDS和所述第五目标MDS对应的逻辑分区,并建立合并后的逻辑分区与合并MDS的映射关系,以便更新逻辑分区与MDS的映射关系;其中,N为正整数;
在具体实施中,并第四目标MDS和第五目标MDS对应的逻辑分区,即在系统中减少1个MDS,使得原第四目标MDS和第五目标MDS对应的逻辑分区对应到新的合并MDS,并根据该对应关系更新逻辑分区与MDS的映射关系。
S33:根据更新后的映射关系修改所述第二映射函数。
下面介绍本申请实施例公开了一种元数据查找方法,具体的:
参见图2,本申请实施例提供的另一种元数据管理方法的流程图,如图2所示,包括:
S201:获取待查找元数据父目录的唯一标识和全局标识,并根据所述全局标识确定所述待查找数据所在的哈希表;
在具体实施中,当接收到用户对待查找元数据的查询请求时,根据该查询请求获取待查找元数据父目录的唯一标识和全局标识,并根据该全局标识确定哈希表号,表示如下:
BucketId=BH(GlobalId);其中,BH()表示全局标识到哈希表的映射函数。
S202:根据所述唯一标识和所述全局标识在所述哈希表中确定所述带查找元数据的候选地址;
在具体实施中,首先判断待查找数据在上述的哈希表中是否存在哈希冲突,若是,则在哈希表中顺序查找,将与所述唯一标识和所述全局标识均匹配的地址确定为候选地址,若否,则在哈希表中顺序查找,将与所述唯一标识相匹配的地址确定为所述候选地址。
S203:将所述候选地址的记录中与所述唯一标识和所述待查找元数据的文件名均相符的数据确定为所述待查找元数据。
在具体实施中,利用候选地址读取内容文件中的元数据对象记录,即确定候选地址的记录中包含的父目录唯一标识和文件名信息与查询请求中的相符的元数据对象记录,并返回该元数据对象记录。
由上述查找过程可知,通过对比B+树索引具有O(logn)的查找复杂度和50%的空间使用率,散列表具有O(1)查找时间复杂度和比B+树更高的空间使用率,更适合组织元数据对象。
在本实施例中,对于元数据的存储如图3所示,可以分为两部分:用于索引的索引表和存放真正元数据的内容文件。把这个两部分分开存放在MDS机群共享存储上。在逻辑分区建立时,在共享存储上申请足够的空间来存放索引表,然后各个分区以独占的方式访问该空间。而对于内容文件在写入时才进行块分配,内容文件所在的空间可以被所有的分区访问。
下面对本申请实施例提供的一种元数据管理系统进行介绍,下文描述的一种元数据管理系统与上文描述的一种元数据管理方法可以相互参照。
参见图4,本申请实施例提供的一种元数据管理系统的结构图,如图4所示,包括:
获取模块401,用于获取元数据的文件名和父目录的唯一标识,并计算所述文件名和所述唯一标识的散列结果,将所述散列结果作为所述元数据的全局标识;
第一确定模块402,用于根据所述全局标识和第一映射函数得到所述元数据的逻辑分区标识;其中,所述第一映射函数表示散列结果与逻辑分区的映射关系;
第二确定模块403,用于根据所述逻辑分区标识和所述第二映射函数得到所述元数据的MDS标识;其中,所述第二映射函数表示逻辑分区与MDS的映射关系,且为根据所有MDS的处理能力和当前负载能力建立的函数。
本申请实施例提供的元数据管理系统,元数据到MDS的映射采用两级映射的方法,先把元数据映射到一个逻辑分区,然后逻辑分区再根据策略映射到MDS上。元数据到逻辑分区的映射使用静态散列映射的方法,而逻辑分区到MDS的映射则根据当前MDS的负载和处理能力使用动态映射的方法。动态散列分区是首先根据文件的文件名和路径信息使用静态散列的方法对元数据实现静态分区,然后把分区动态的映射到MDS上。但与HAP(散列分区方法)不同的是分区时使用的信息会保留文件的目录树的位置信息,不会出现不同目录下的同名文件映射到相同的分区,引起潜在的瓶颈问题。而且由于该方法选择的是表示位置信息具有特殊性,在需要移动数据时不会像LH那样在目录重命名时带来巨大的开销。
在上述实施例的基础上,作为一种优选实施方式,还包括:
建立模块,用于获取所有所述MDS的处理能力和当前负载能力,并根据所述处理能力和所述当前负载能力建立所述第二映射函数;
其中,所述建立模块包括:
获取单元,用于获取所有所述MDS的CPU信息、内存信息和带宽;
确定处理能力单元,用于根据所述CPU信息中的CPU主频、所述内存信息中的内存大小和所述带宽确定所述MDS的处理能力;
确定当前负载能力单元,用于根据所述CPU信息和所述内存信息中的内存使用率确定所述MDS的当前负载能力;
建立单元,用于根据所述处理能力和所述当前负载能力建立所述第二映射函数。
在上述实施例的基础上,作为一种优选实施方式,还包括:
第一监测模块,用于监测所有所述MDS对应的逻辑分区数量,判断是否存在逻辑分区数量大于第一预设值的第一目标MDS和逻辑分区数量小于第二预设值的第二目标MDS;若是,则启动第一更新模块的工作流程;
所述第一更新模块,用于将所述第一目标MDS中超过所述第一预设值的逻辑分区迁移到所述第二目标MDS中,以便更新逻辑分区与MDS的映射关系;
第一修改模块,用于根据更新后的映射关系修改所述第二映射函数。
在上述实施例的基础上,作为一种优选实施方式,还包括:
第二监测模块,用于监测所有所述MDS对应的逻辑分区数量,判断是否存在逻辑分区数量大于第三预设值的第三目标MDS;若是,则启动第二更新模块的工作流程;
所述第二更新模块,用于将所述第三目标MDS对应的逻辑分区分裂为N个子部分,并建立每个所述子部分与子MDS的映射关系,以便更新逻辑分区与MDS的映射关系;其中,N为正整数;
第二修改模块,用于根据更新后的映射关系修改所述第二映射函数。
在上述实施例的基础上,作为一种优选实施方式,还包括:
第三监测模块,用于监测所有所述MDS对应的逻辑分区数量,判断是否存在逻辑分区数量小于第四预设值的第四目标MDS和第五目标MDS;若是,则启动第三更新模块的工作流程;
所述第三更新模块,用于合并所述第四目标MDS和所述第五目标MDS对应的逻辑分区,并建立合并后的逻辑分区与合并MDS的映射关系,以便更新逻辑分区与MDS的映射关系;其中,N为正整数;
第三修改模块,用于根据更新后的映射关系修改所述第二映射函数。
在上述实施例的基础上,作为一种优选实施方式,还包括:
确定哈希表模块,用于获取待查找元数据父目录的唯一标识和全局标识,并根据所述全局标识确定所述待查找数据所在的哈希表;
确定候选地址模块,用于根据所述唯一标识和所述全局标识在所述哈希表中确定所述带查找元数据的候选地址;
查找模块,用于将所述候选地址的记录中与所述唯一标识和所述待查找元数据的文件名均相符的数据确定为所述待查找元数据。
在上述实施例的基础上,作为一种优选实施方式,所述确定候选地址模块包括:
判断单元,用于判断所述待查找数据在所述哈希表中是否存在哈希冲突;若是,则启动第一确定单元的工作流程;若否,则启动第二确定单元的工作流程;
所述第一确定单元,用于将与所述唯一标识和所述全局标识均匹配的地址确定为所述候选地址;
所述第二确定单元,用于将与所述唯一标识相匹配的地址确定为所述候选地址。
本申请还提供了一种元数据管理设备,参见图5,本申请实施例提供的一种元数据管理设备的结构图,如图5所示,包括:
存储器100,用于存储计算机程序;
处理器200,用于执行所述计算机程序时可以实现上述任一实施例所提供元数据管理方法的步骤。
具体的,存储器100包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统和计算机可读指令,该内存储器为非易失性存储介质中的操作系统和计算机可读指令的运行提供环境。处理器200为元数据管理设备提供计算和控制能力,执行所述存储器100中保存的计算机程序时,可以实现上述任一实施例所提供元数据管理方法的步骤。
本申请提供的元数据管理设备,元数据到MDS的映射采用两级映射的方法,先把元数据映射到一个逻辑分区,然后逻辑分区再根据策略映射到MDS上。元数据到逻辑分区的映射使用静态散列映射的方法,而逻辑分区到MDS的映射则根据当前MDS的负载和处理能力使用动态映射的方法。动态散列分区是首先根据文件的文件名和路径信息使用静态散列的方法对元数据实现静态分区,然后把分区动态的映射到MDS上。但与HAP(散列分区方法)不同的是分区时使用的信息会保留文件的目录树的位置信息,不会出现不同目录下的同名文件映射到相同的分区,引起潜在的瓶颈问题。而且由于该方法选择的是表示位置信息具有特殊性,在需要移动数据时不会像LH那样在目录重命名时带来巨大的开销。
在上述实施例的基础上,作为优选实施方式,参见图6,所述元数据管理设备还包括:
输入接口300,与处理器200相连,用于获取外部导入的计算机程序、参数和指令,经处理器200控制保存至存储器100中。该输入接口300可以与输入装置相连,接收用户手动输入的参数或指令。该输入装置可以是显示屏上覆盖的触摸层,也可以是终端外壳上设置的按键、轨迹球或触控板,也可以是键盘、触控板或鼠标等。
显示单元400,与处理器200相连,用于显示处理器200发送的数据。该显示单元400可以为PC机上的显示屏、液晶显示屏或者电子墨水显示屏等。具体的,在本实施例中,可以通过显示单元400显示元数据的查询结果等。
网络端口500,与处理器200相连,用于与外部各终端设备进行通信连接。该通信连接所采用的通信技术可以为有线通信技术或无线通信技术,如移动高清链接技术(MHL)、通用串行总线(USB)、高清多媒体接口(HDMI)、无线保真技术(WiFi)、蓝牙通信技术、低功耗蓝牙通信技术、基于IEEE802.11s的通信技术等。具体的,在本实施例中,可以通过网络端口500向处理器200导入第一映射函数和第二映射函数等。
本申请还提供了一种计算机可读存储介质,该存储介质可以包括:U盘、移动硬盘、只读存储器(Read-Only Memory,ROM)、随机存取存储器(Random Access Memory,RAM)、磁碟或者光盘等各种可以存储程序代码的介质。该存储介质上存储有计算机程序,所述计算机程序被处理器执行时实现上述任一实施例所提供元数据管理方法的步骤。
本说明书中各个实施例采用递进的方式描述,每个实施例重点说明的都是与其他实施例的不同之处,各个实施例之间相同相似部分互相参见即可。
对所公开的实施例的上述说明,使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的,本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下,在其它实施例中实现。因此,本申请将不会被限制于本文所示的这些实施例,而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。
说明书中各个实施例采用递进的方式描述,每个实施例重点说明的都是与其他实施例的不同之处,各个实施例之间相同相似部分互相参见即可。对于实施例公开的系统而言,由于其与实施例公开的方法相对应,所以描述的比较简单,相关之处参见方法部分说明即可。应当指出,对于本技术领域的普通技术人员来说,在不脱离本申请原理的前提下,还可以对本申请进行若干改进和修饰,这些改进和修饰也落入本申请权利要求的保护范围内。
还需要说明的是,在本说明书中,诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
Claims (10)
1.一种元数据管理方法,其特征在于,包括:
获取元数据的文件名和父目录的唯一标识,并计算所述文件名和所述唯一标识的散列结果,将所述散列结果作为所述元数据的全局标识;
根据所述全局标识和第一映射函数得到所述元数据的逻辑分区标识;其中,所述第一映射函数表示散列结果与逻辑分区的映射关系;
根据所述逻辑分区标识和所述第二映射函数得到所述元数据的MDS标识;其中,所述第二映射函数表示逻辑分区与MDS的映射关系,且为根据所有MDS的处理能力和当前负载能力建立的函数。
2.根据权利要求1所述元数据管理方法,其特征在于,还包括:
获取所有所述MDS的处理能力和当前负载能力,并根据所述处理能力和所述当前负载能力建立所述第二映射函数;
其中,所述获取所有所述MDS的处理能力和当前负载能力,包括:
获取所有所述MDS的CPU信息、内存信息和带宽;
根据所述CPU信息中的CPU主频、所述内存信息中的内存大小和所述带宽确定所述MDS的处理能力;
根据所述CPU信息和所述内存信息中的内存使用率确定所述MDS的当前负载能力。
3.根据权利要求1所述元数据管理方法,其特征在于,还包括:
监测所有所述MDS对应的逻辑分区数量,判断是否存在逻辑分区数量大于第一预设值的第一目标MDS和逻辑分区数量小于第二预设值的第二目标MDS;
若是,则将所述第一目标MDS中超过所述第一预设值的逻辑分区迁移到所述第二目标MDS中,以便更新逻辑分区与MDS的映射关系;
根据更新后的映射关系修改所述第二映射函数。
4.根据权利要求1所述元数据管理方法,其特征在于,还包括:
监测所有所述MDS对应的逻辑分区数量,判断是否存在逻辑分区数量大于第三预设值的第三目标MDS;
若是,则将所述第三目标MDS对应的逻辑分区分裂为N个子部分,并建立每个所述子部分与子MDS的映射关系,以便更新逻辑分区与MDS的映射关系;其中,N为正整数;
根据更新后的映射关系修改所述第二映射函数。
5.根据权利要求1所述元数据管理方法,其特征在于,还包括:
监测所有所述MDS对应的逻辑分区数量,判断是否存在逻辑分区数量小于第四预设值的第四目标MDS和第五目标MDS;
若是,则合并所述第四目标MDS和所述第五目标MDS对应的逻辑分区,并建立合并后的逻辑分区与合并MDS的映射关系,以便更新逻辑分区与MDS的映射关系;其中,N为正整数;
根据更新后的映射关系修改所述第二映射函数。
6.根据权利要求1-5任一项所述元数据管理方法,其特征在于,还包括:
获取待查找元数据父目录的唯一标识和全局标识,并根据所述全局标识确定所述待查找数据所在的哈希表;
根据所述唯一标识和所述全局标识在所述哈希表中确定所述带查找元数据的候选地址;
将所述候选地址的记录中与所述唯一标识和所述待查找元数据的文件名均相符的数据确定为所述待查找元数据。
7.根据权利要求6所述元数据管理方法,其特征在于,根据所述唯一标识和所述全局标识在所述哈希表中确定所述带查找元数据的候选地址,包括:
判断所述待查找数据在所述哈希表中是否存在哈希冲突;
若是,则将与所述唯一标识和所述全局标识均匹配的地址确定为所述候选地址;
若否,则将与所述唯一标识相匹配的地址确定为所述候选地址。
8.一种元数据管理系统,其特征在于,包括:
获取模块,用于获取元数据的文件名和父目录的唯一标识,并计算所述文件名和所述唯一标识的散列结果,将所述散列结果作为所述元数据的全局标识;
第一确定模块,用于根据所述全局标识和第一映射函数得到所述元数据的逻辑分区标识;其中,所述第一映射函数表示散列结果与逻辑分区的映射关系;
第二确定模块,用于根据所述逻辑分区标识和所述第二映射函数得到所述元数据的MDS标识;其中,所述第二映射函数表示逻辑分区与MDS的映射关系,且为根据所有MDS的处理能力和当前负载能力建立的函数。
9.一种元数据管理设备,其特征在于,包括:
存储器,用于存储计算机程序;
处理器,用于执行所述计算机程序时实现如权利要求1至7任一项所述元数据管理方法的步骤。
10.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质上存储有计算机程序,所述计算机程序被处理器执行时实现如权利要求1至7任一项所述元数据管理方法的步骤。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810688052.0A CN108920613A (zh) | 2018-06-28 | 2018-06-28 | 一种元数据管理方法、系统及设备和存储介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810688052.0A CN108920613A (zh) | 2018-06-28 | 2018-06-28 | 一种元数据管理方法、系统及设备和存储介质 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN108920613A true CN108920613A (zh) | 2018-11-30 |
Family
ID=64421968
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201810688052.0A Pending CN108920613A (zh) | 2018-06-28 | 2018-06-28 | 一种元数据管理方法、系统及设备和存储介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN108920613A (zh) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111597148A (zh) * | 2020-05-14 | 2020-08-28 | 杭州果汁数据科技有限公司 | 用于分布式文件系统的分布式元数据管理方法 |
CN113609071A (zh) * | 2021-07-28 | 2021-11-05 | 北京金山云网络技术有限公司 | 一种用于消息队列的自动扩容方法及装置 |
WO2022068596A1 (zh) * | 2020-09-30 | 2022-04-07 | 华为技术有限公司 | 元数据管理方法和电子设备 |
WO2023208404A1 (en) * | 2022-04-29 | 2023-11-02 | Petagene Ltd | Improvements in and relating to object-based storage |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101997918A (zh) * | 2010-11-11 | 2011-03-30 | 清华大学 | 异构san环境中的海量存储资源按需分配的实现方法 |
US20140095827A1 (en) * | 2011-05-24 | 2014-04-03 | Agency For Science, Technology And Research | Memory storage device, and a related zone-based block management and mapping method |
CN103763365A (zh) * | 2014-01-16 | 2014-04-30 | 浪潮(北京)电子信息产业有限公司 | 一种云存储下元数据服务的负载均衡方法及系统 |
CN103905540A (zh) * | 2014-03-25 | 2014-07-02 | 浪潮电子信息产业股份有限公司 | 基于两级哈希的对象存储数据分布机制 |
CN106599308A (zh) * | 2016-12-29 | 2017-04-26 | 郭晓凤 | 一种分布式元数据管理方法及系统 |
CN107329909A (zh) * | 2017-06-27 | 2017-11-07 | 郑州云海信息技术有限公司 | 一种数据管理方法及装置 |
-
2018
- 2018-06-28 CN CN201810688052.0A patent/CN108920613A/zh active Pending
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101997918A (zh) * | 2010-11-11 | 2011-03-30 | 清华大学 | 异构san环境中的海量存储资源按需分配的实现方法 |
US20140095827A1 (en) * | 2011-05-24 | 2014-04-03 | Agency For Science, Technology And Research | Memory storage device, and a related zone-based block management and mapping method |
CN103763365A (zh) * | 2014-01-16 | 2014-04-30 | 浪潮(北京)电子信息产业有限公司 | 一种云存储下元数据服务的负载均衡方法及系统 |
CN103905540A (zh) * | 2014-03-25 | 2014-07-02 | 浪潮电子信息产业股份有限公司 | 基于两级哈希的对象存储数据分布机制 |
CN106599308A (zh) * | 2016-12-29 | 2017-04-26 | 郭晓凤 | 一种分布式元数据管理方法及系统 |
CN107329909A (zh) * | 2017-06-27 | 2017-11-07 | 郑州云海信息技术有限公司 | 一种数据管理方法及装置 |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111597148A (zh) * | 2020-05-14 | 2020-08-28 | 杭州果汁数据科技有限公司 | 用于分布式文件系统的分布式元数据管理方法 |
CN111597148B (zh) * | 2020-05-14 | 2023-09-19 | 杭州果汁数据科技有限公司 | 用于分布式文件系统的分布式元数据管理方法 |
WO2022068596A1 (zh) * | 2020-09-30 | 2022-04-07 | 华为技术有限公司 | 元数据管理方法和电子设备 |
CN113609071A (zh) * | 2021-07-28 | 2021-11-05 | 北京金山云网络技术有限公司 | 一种用于消息队列的自动扩容方法及装置 |
WO2023208404A1 (en) * | 2022-04-29 | 2023-11-02 | Petagene Ltd | Improvements in and relating to object-based storage |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11068441B2 (en) | Caseless file lookup in a distributed file system | |
CN108920613A (zh) | 一种元数据管理方法、系统及设备和存储介质 | |
KR102127116B1 (ko) | 분산 데이터 저장 장치 및 분산 데이터 저장 방법 | |
US10037340B2 (en) | Tiered distributed storage policies | |
US20160117115A1 (en) | Disk partition stitching and rebalancing using a partition table | |
US10102210B2 (en) | Systems and methods for multi-threaded shadow migration | |
US20150039849A1 (en) | Multi-Layer Data Storage Virtualization Using a Consistent Data Reference Model | |
US10108644B1 (en) | Method for minimizing storage requirements on fast/expensive arrays for data mobility and migration | |
US20140195761A1 (en) | Logical volume space sharing | |
CN105683898A (zh) | 对储存系统中数据高效存储与检索的组相关哈希表组织 | |
US9355121B1 (en) | Segregating data and metadata in a file system | |
CN103034684A (zh) | 一种基于内容寻址存储的虚拟机镜像存储优化方法 | |
CN106682110B (zh) | 一种基于哈希格网索引的影像文件存储和管理系统及方法 | |
US20060253484A1 (en) | Flash memory directory virtualization | |
CN104182508A (zh) | 一种数据处理方法和数据处理装置 | |
US11947826B2 (en) | Method for accelerating image storing and retrieving differential latency storage devices based on access rates | |
CN113806300B (zh) | 数据存储方法、系统、装置、设备及存储介质 | |
US10417192B2 (en) | File classification in a distributed file system | |
CN115438016A (zh) | 分布式对象存储中动态分片方法、系统、介质及设备 | |
US9971789B2 (en) | Selective disk volume cloning for virtual disk creation | |
CN114138558A (zh) | 一种对象存储方法、装置、电子设备和存储介质 | |
US8818970B2 (en) | Partitioning a directory while accessing the directory | |
CN106934066A (zh) | 一种元数据处理方法、装置和存储设备 | |
US10146791B2 (en) | Open file rebalance | |
US10509578B2 (en) | Logical address space for storage resource pools |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
RJ01 | Rejection of invention patent application after publication | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20181130 |