CN111984598A - 一种高性能元数据日志文件管理方法、系统、介质及终端 - Google Patents
一种高性能元数据日志文件管理方法、系统、介质及终端 Download PDFInfo
- Publication number
- CN111984598A CN111984598A CN202010843131.1A CN202010843131A CN111984598A CN 111984598 A CN111984598 A CN 111984598A CN 202010843131 A CN202010843131 A CN 202010843131A CN 111984598 A CN111984598 A CN 111984598A
- Authority
- CN
- China
- Prior art keywords
- file
- metadata
- metadata log
- log file
- level
- 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
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/16—File or folder operations, e.g. details of user interfaces specifically adapted to file systems
- G06F16/164—File meta data generation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/17—Details of further file system functions
- G06F16/172—Caching, prefetching or hoarding of files
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/18—File system types
- G06F16/1805—Append-only file systems, e.g. using logs or journals to store data
- G06F16/1815—Journaling file systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/18—File system types
- G06F16/182—Distributed file systems
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Human Computer Interaction (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明提供一种高性能元数据日志文件管理方法、系统、介质及终端,方法包括将数据与元数据设置于不同的文件系统;记录数据写入时所有修改过程中的操作,并将其作为第一级过程元数据日志文件;对所述第一级过程元数据日志文件中记录的过程进行合并,获取合并结果;将所述合并结果进行记录,将其作为第二级结果元数据日志文件;根据所述第一级过程元数据日志文件和第二级结果元数据日志文件进行组合写入,完成元数据日志文件的加载合并操作;本发明一方面,增加数据写入的性能,满足在大压力场景下的业务需求,确保元数据信息不会丢失,简化了元数据的管理流程;另一方面,加快了元数据信息的读写性能,克服了由元数据信息记录带来的性能消耗问题。
Description
技术领域
本发明涉及计算机领域,尤其涉及一种高性能元数据日志文件管理方法、系统、介质及终端。
背景技术
在分布式存储中,数据与元数据信息除了有元数据管理节点的管理之外还需要将元数据信息记录在各数据节点中,元数据信息即是包含了数据文件在存储节点中的位置,大小,时间等信息,通过元数据信息可以准确寻址到数据文件信息。因此,元数据的管理对于存储尤为重要。
目前,元数据与数据通常采用一个文件系统的方式,这样的方式对于文件系统存在很高的IO压力,文件系统一方面管理大量的数据文件,一方面管理着元数据文件,这两种文件在业务层面来说是不同管理方式,数据文件访问频率低,修改频率低,而元数据日志文件则相反,访问频率高,修改频率高,因此,需要一种新的元数据管理方式,在保证整个存储系统的读写性能的基础上,增加对元数据文件的处理效率。
发明内容
鉴于以上所述现有技术的缺点,本发明提供一种高性能元数据日志文件管理方法、系统、介质及终端,以解决上述技术问题。
本发明提供的高性能元数据日志文件管理方法,包括:
将数据与元数据设置于不同的文件系统;
记录数据写入时所有修改过程中的操作,并将其作为第一级过程元数据日志文件;
对所述第一级过程元数据日志文件中记录的过程进行合并,获取合并结果;
将所述合并结果进行记录,将其作为第二级结果元数据日志文件;
根据所述第一级过程元数据日志文件和第二级结果元数据日志文件进行组合写入,完成元数据日志文件的加载合并操作。
可选的,通过第一文件系统对元数据日志文件进行管理,通过第二文件系统对数据文件进行管理,所述第一文件系统包括XFS文件系统。
可选的,对所述第一级元数据日志文件中记录的过程进行合并后,还包括:
检查是否存在第二级结果元数据日志中间文件,如果存在,则判定合并过程未完成;如果存在,在判定合并过程完成。
可选的,当判定合并过程未完成时,将原第二级结果元数据日志文件删除,并将所述第二级结果元数据日志中间文件重命名为第二级结果元数据日志文件;
加载重命名后的第二级结果元数据日志文件,并对其进行解析,加至内存哈希表中;
加载第一级元数据日志中间文件,并对其进行解析,获取第二级结果元数据日志文件所在哈希表中的节点,
对节点信息进行基本操作,所述基本操作包括数据节点信息的创建、修改和删除;
将哈希表中的记录转换为基本数据写入第二级结果元数据日志中间文件中,完成第一级元数据日志中间文件的合并。
可选的,删除合并后的第一级元数据日志中间文件,以及原第二级结果元数据日志文件,并将第二级结果元数据日志中间文件重命名为第二级结果元数据日志文件。
可选的,当所述第一级过程元数据日志文件的大小达到预设的阈值时,将其重命名为一第一级元数据日志中间文件并重新打开一新的第一级过程元数据日志文件。
可选的,将磁盘划分为至少两个分区,其中一分区为用于存储元数据文件的元数据分区,其他分区为用于存储数据的数据分区,并将所述元数据分区格式化为XFS文件系统。
本发明还提供一种高性能元数据日志文件管理系统,包括:
磁盘管理单元,用于对磁盘的分区管理,将数据与元数据设置于不同的文件系统;
日志流程单元,用于记录数据写入时所有修改过程中的操作,并将其作为第一级过程元数据日志文件;对所述第一级过程元数据日志文件中记录的过程进行合并,获取合并结果;将所述合并结果进行记录,将其作为第二级结果元数据日志文件;
日志控制单元,用于根据所述第一级过程元数据日志文件和第二级结果元数据日志文件进行组合写入,完成元数据日志文件的加载合并操作。
本发明还提供一种计算机可读存储介质,其上存储有计算机程序,该程序被处理器执行时实现上述中任一项所述方法。
本发明还提供一种电子终端,包括:处理器及存储器;
所述存储器用于存储计算机程序,所述处理器用于执行所述存储器存储的计算机程序,以使所述终端执行如上述中任一项所述方法。
本发明的有益效果:本发明中的高性能元数据日志文件管理方法、系统、介质及终端,一方面,通过第一级过程元数据日志文件作为缓冲,增加数据写入的性能,满足在大压力场景下的业务需求,通过第二级的结果元数据日志文件保证了数据的完整性,确保元数据信息不会丢失,并且从第一级到第二级的合并过程具有简单易操作的有点,简化了元数据的管理流程;另一方面,通过将元数据信息与数据信息分离,采用不同文件系统的方式进一步加快了元数据信息的读写性能,本发明保证了元数据信息的完整性,同时克服了由元数据信息记录所带来的性能消耗问题。
附图说明
图1是本发明实施例中高性能元数据日志文件管理方法中的分布式存储的结构示意图。
图2是本发明实施例中高性能元数据日志文件管理系统的结构示意图。
图3是本发明实施例中高性能元数据日志文件管理方法中的第一级元数据文件结构示意图。
图4是本发明实施例中高性能元数据日志文件管理方法中的第而级元数据文件结构示意图。
图5是本发明实施例中高性能元数据日志文件管理方法中的前置检查流程示意图。
图6是本发明实施例中高性能元数据日志文件管理方法中的元数据文件合并流程示意图。
图7是本发明实施例中高性能元数据日志文件管理方法中的元数据合并流程示意图。
图8是本发明实施例中高性能元数据日志文件管理方法中的元数据文件后台巡检流程示意图。
图9是本发明实施例中高性能元数据日志文件管理方法中的元数据文件后台巡检合并控制流程示意图。
图10是本发明实施例中高性能元数据日志文件管理方法中的Linux文件IO缓存示意图。
附图标记说明:
10-存储管理节点,11-存储数据节点。
具体实施方式
以下通过特定的具体实例说明本发明的实施方式,本领域技术人员可由本说明书所揭露的内容轻易地了解本发明的其他优点与功效。本发明还可以通过另外不同的具体实施方式加以实施或应用,本说明书中的各项细节也可以基于不同观点与应用,在没有背离本发明的精神下进行各种修饰或改变。需说明的是,在不冲突的情况下,以下实施例及实施例中的特征可以相互组合。
需要说明的是,以下实施例中所提供的图示仅以示意方式说明本发明的基本构想,遂图式中仅显示与本发明中有关的组件而非按照实际实施时的组件数目、形状及尺寸绘制,其实际实施时各组件的型态、数量及比例可为一种随意的改变,且其组件布局型态也可能更为复杂。
在下文描述中,探讨了大量细节,以提供对本发明实施例的更透彻的解释,然而,对本领域技术人员来说,可以在没有这些具体细节的情况下实施本发明的实施例是显而易见的,在其他实施例中,以方框图的形式而不是以细节的形式来示出公知的结构和设备,以避免使本发明的实施例难以理解。
本实施例中的高性能元数据日志文件管理方法,包括:
S1.将数据与元数据设置于不同的文件系统;
S2.记录数据写入时所有修改过程中的操作,并将其作为第一级过程元数据日志文件;
S3.对第一级过程元数据日志文件中记录的过程进行合并,获取合并结果;
S4.将合并结果进行记录,将其作为第二级结果元数据日志文件;
S5.根据第一级过程元数据日志文件和第二级结果元数据日志文件进行组合写入,完成元数据日志文件的加载合并操作。
在本实施例中,数据文件访问频率低,修改频率低,而元数据日志文件则相反,通过将数据与元数据设置于不同的文件系统,在业务层面对两种文件采用不同的管理方式,可以有效的避免元数据与数据采用一个文件系统导致的IO压力过高的问题。可选的,本实施例采用XFS文件系统来管理元数据日志文件,与数据文件隔离的方式来增加对元数据文件的处理效率。
在本实施例中,通过第一文件系统对元数据日志文件进行管理,通过第二文件系统对数据文件进行管理,第一文件系统包括XFS文件系统,一方面通过多级日志文件组合方式,提高了日志文件层面写入效率,另一方面通过采用XFS文件系统,利用XFS文件系统的优秀特性从文件系统层面提高文件IO的效率。
在本实施例中,在分布式存储纠删场景下,读写业务按条带进行,数据节点在每次写入的一组条带数据都会记录到当前文件的写入大小中,这些数据需要更新到元数据日志文件中。本实施例通过两级日志文件的方式优化写入效率,提供两级日志文件基本操作,创建、打开、删除、重名命、读写,提供两级日志文件加载合并操作。其中,第一级过程元数据日志文件用于记录对文件每次写入修改过程中的操作。例如对一个文件进行了3次写操作,第一次文件大小被修改为1024,第二次文件大小被修改为2048,第三次文件大小被修改为3072,这三次的修改都会被记录在第一级过程元数据日志文件中,而该文件的记录则是日志记录的方式,即是往文件尾部追加写的方式,对于文件的追加写是一个很快的过程;第二级结果元数据日志文件用于记录结果,即是将第一级元数据日志文件中记录的过程做一个合并得到的结果记录在该文件中。例如,元数据日志文件中对同一个文件的三个操作最终结果即是将文件大小修改为3072,第二级结果元数据日志文件中仅记录该文件的大小为3072。
在本实施例中,对第一级元数据日志文件中记录的过程进行合并后,检查是否存在第二级结果元数据日志中间文件,如果存在,则判定合并过程未完成;如果存在,在判定合并过程完成。如果否存在第二级结果元数据日志中间文件,则说明上次的合并过程未完成,此时删除老的第二级结果元数据日志文件,将第二级结果元数据日志中间文件重命名为第二级结果元数据日志文件。
加载重命名后的第二级结果元数据日志文件,并对其进行解析,加至内存哈希表中。可选的,加载第二级结果元数据日志文件至程序内存,按文件格式将其中的记录解析出来加至内存哈希表(Hash-meta)中,其中以文件ID做为哈希的key值。
加载第一级元数据日志中间文件,并对其进行解析,获取第二级结果元数据日志文件所在哈希表中的节点。可选的,加载第一级元数据日志中间文件至程序内存,按文件格式进行解析出所记录的信息并转成(Hash-meta)中节点的数据结构,根据文件ID查找到哈希表(Hash-meta)中的节点,进行基本的创建、删除和修改操作。
创建操作,表明哈希表中(Hash-meta)不存在当前文件的节点信息,则创建数据节点信息,往哈希表中插入一个节点。
修改操作,表明文件已被创建,查找哈希节点,对节点数据做修改。
删除操作,文件需要删除,查找哈希节点,将节点从哈希表(Hash-meta)中删除。
之后,修改完成将(Hash-meta)中的记录转换为基本数据写入第二级结果元数据日志中间文件中。
最后,将合并完成的第一级元数据日志中间文件删除以及老的第二级结果元数据日志文件删除,将第二级结果元数据日志中间文件重命名为第二级结果元数据日志文件。
在本实施例中,通过检查一级文件是否需要进行重命名,检查是否有需要合并的一级文件,并开启合并流程。具体的:
S31.存储节点可以通过磁盘管理单元的分区结果为管理的每个磁盘单独记录元数据信息,如果存储节点有60块数据盘,则会有60份元数据信息。所述单元提供基本文件创建、打开、删除、重命名等基本文件操作。所述存储节节点第一次启动就会为每个磁盘创建出第一级元数据日志文件。
S32.数据写入时对文件所有的修改记录写入在第一级元数据日志文件中;
S33.可以通过日志控制单元控制,当第一级过程元数据日志文件大小达到预设的阈值(按一小时产生的数据量计算,B/N*L*3600*2,其中B表示存储性能规格写入带宽,N表示块大小,L表示每条元数据记录长度,取其两倍值),将其重命名为一个第一级元数据日志中间文件并重新打开一个新的第一级过程元数据日志文件;
S34.将第一级过程元数据日志文件中的记录合并到第二级结果元数据日志文件中;
S35.可以由日志控制单元控制存储节点后台定时巡检第一级过程元数据日志文件,存在则进行S33-S34;
S36.存储节点重启进行S34;
S37.存储节点管理磁盘上线进行S34。
在本实施例中,将数据与元数据设置于不同的文件系统,在业务层面对两种文件采用不同的管理方式,可以有效的避免元数据与数据采用一个文件系统导致的IO压力过高的问题。具体的:
S11,磁盘分区,将磁盘进行分区,例如:使用parted把磁盘分为两个区,P1和P2。P1分区用于专门存放元数据文件,是元数据分区,也即是第一级过程日志文件和第二级结果日志文件以及合并过程中产生的中间文件。
分区大小计算:L*N*3
其中,L表示每条元数据记录的长度,N表示当前这块磁盘所能存储的块个数(通常块大小为64MB,一个块有一条记录)。
剩余空间全部分给P2分区,P2分区则是存放真正数据的数据分区。
S12,分区格式化,将P1分区格式化为XFS,P2分区由应用程序格式化为需要使用的文件系统。
S13,挂载,在/mnt目录下分别为两个分区建一个目录,将P1分区以及P2分区均挂载在/mnt目录下的对应子目录下。
S14,直写模式,linux内核的缓存机制在磁盘出现异常下线时会导致数据丢失问题,采用直写模式,跳过内核缓存,保证数据的完整性。
在本实施例中,如图1所示的分布式存储结构包含了一个管理节点10和M个数据节点11,每个数据节点下包含n块数据磁盘。由管理节点根据业务选择数据节点进行数据写入,数据节点上一方面保存写入的数据同时也保存着数据的元数据信息。以一个文件写入数据节点11为例,说明文件元数据信息中记录的内容,首先在数据节点11上选择一块磁盘1,其次在磁盘1上创建目录A并在目录A下创建文件A-b,最后写入文件大小为64MB,最终元数据记录的信息即是该文件A-b存在磁盘1上的目录A下,文件大小为64MB,通过这些信息可以准确读取该文件。
在本实施例中,如图3所示的第一级元数据过程日志文件结构,其中301记录为对元数据信息的操作,包括创建、修改、删除,其中302记录元数据记录的条数,在文件中保持递增。其余信息为文件的元数据信息,包括文件ID,文件大小、文件目录、所在磁盘信息、创建时间、修改时间。如图4所示的第二级元数据结果日志文件结构,头部401为元数据版本信息,402为文件记录的元数据的md5sun,403为从第一级文件合并到第二级文件时,一级文件中最后一条记录的CmdXid,用于表明合并到哪一条记录,同时用于判断第一级日志文件是否需要合并。其余信息为文件的元数据信息与第一级文件中记录保持一致。
在本实施例中,可选的,可以通过使用工具parted为数据节点11中包含的所有磁盘做分区处理,分为两个区,第一个分区大小,以一张8TB的磁盘计算,可存储大小为64MB文件131072个,以当前示例中每条元数据记录大小232Byte,计算得出分区下大小为121MB可取为128MB,其余大小划分为给第二个分区。第一个分区格式化为XFS文件系统,第二个分区由应用程序格式化为EVFS文件系统。元数据文件记录存在第一分区meta目录下。应用程序为每个磁盘创建一个第一级元数据日志文件用于数据写入过程中文件修改记录。
在本实施例中,如图5所示,应用启动加载元数据时,需要加载流程的前置检查:
S501.检查第二级元数据结果日志中间文件;
S502.判断文件存在?;
S503.使用该中间文件替换为第二级结果元数据日志文件。
步骤501为检验过程,当上一次合并出现异常,未完成最后一步将第二级中间文件重名命成功则会产生这种情况。而处理则是对应的503步骤,存在则使用该文件替换。
在本实施例中,当前置完成后,进行加载合并流程,一级文件到二级文件的合并流程如图6所示,
S601.加载一级元数据过程日志文件或者该文件的中间文件;
S602.元数据记录分割,对每条命令进行长度检验;
S603.加载二级元数据结果日志文件;
S604.元数据记录分割;
S605.判断文件是否不为空?
S606.判断一级文件是否需要合并?
当判定一级文件需要合并时:
S6071.将二级文件解析出的元数据信息,再解析后加入在内存哈希表中
S6072.通过一级文件中记录的不同命令,依次修改哈希表中的数据
S6073.完成后将内存中哈希表数据整合回写在二级临时文件中
S6074.删除一级文件文件,删除旧的二级文件,将二级中间文件重命名为二级文件
步骤S601-604是对文件的加载和数据的解析过程,增加了对元数据记录长度的判断,可以解决文件异常导致服务崩溃问题。在步骤S605中,判断一级元数据过程日志文件是否需要合并的即是根据一级文件中记录的CmdXid判断,例如:如果第一级元数据日志文件A文件中记录的CmdXid是从1-1000,而第二级元数据结果日志文件B中记录的CmdXid是500,则第一级文件1-500条记录已经被合并过,只需要从501条记录合并至1000条记录即可。可选的,本实施例中的两个文件中CmdXid的查找采用二分法,如果B文件中记录的CmdXid为1001,则A文件不需要合并,如果B文件中记录的CmdXid为0则A文件需要全部合并。606中为元数据在内存中的操作,第一级和第二级文件均采用哈希的方式,以便于修改。创建指令即是添加一个哈希节点,修改指令即是修改哈希节点的参数值,删除指令即是删除哈希节点。数据修改完成后,将哈希表中的数据组装为一条一条记录最终写入第二级元数据结果中间文件中,最后将其重命名为第二级元数据结果日志文件,完成一次合并流程。在本实施例中,合并的整体流程如图7所示。
在本实施例中,后台巡检流程如图8所示:
S801.巡检存储节点上各磁盘元数据分区/meta目录下的元数据文件
S802.判断第一级元数据过程日志文件大小是否超过设定大小或者时间超过预设时间;
S803.将第一级元数据过程日志文件重命名为第一级元数据过程日志中间文件,重新创建打开出一个新的过程日志文件。
在本实施例中,通过后台巡检过程负责重命名,预设大小计算,例如集群带宽按300MB/s,块大小为64MB,每条元数据大小为232Byte,计算后取10MB,即是当第一级元数据过程日志文件达到10MB时进行重命名。预设时间为1小时,当到达一小时同样进行重命名。本实施例可以通过后台合并控制过程,检查到存在第一级元数据日志中间文件,则启动合并流程,如图9所示:
S901.巡检存储节点上各磁盘元数据分区/meta目录下的元数据文件;
S902.判断存在第一级元数据过程日志中间文件?
S903.将第一级元数据过程日志中间文件合并到第二级中元数据结果日志文件中。
在本实施例中,由于Linux内核的缓存机制,在写入过程出现磁盘离线时,这部分数据会出现丢失,本实施例通过采用直写模式,跳过内核缓存,直接进行刷盘操作,文件IO缓存如图10所示。
相应的,本实施例还提供一种高性能元数据日志文件管理系统,如图2所示,包括:
磁盘管理单元,用于对磁盘的分区管理,将数据与元数据设置于不同的文件系统;
日志流程单元,用于记录数据写入时所有修改过程中的操作,并将其作为第一级过程元数据日志文件;对所述第一级过程元数据日志文件中记录的过程进行合并,获取合并结果;将所述合并结果进行记录,将其作为第二级结果元数据日志文件;
日志控制单元,用于根据所述第一级过程元数据日志文件和第二级结果元数据日志文件进行组合写入,完成元数据日志文件的加载合并操作。
在本实施例中,高性能元数据日志文件管理系统可以通过采用上述方法进行工作,通过上述方法中的元数据优化方式,可以使操作流程简单易于实现,另外,本实施例中的分区格式化的文件系统也可以采用其他文件系统,不局限于本例,示例中采用的是适合当前业务场景下优选。不同的文件系统组合下可以得到不同的效果,再此不再赘述。
本实施例还提供一种计算机可读存储介质,其上存储有计算机程序,该程序被处理器执行时实现本实施例中的任一项方法。
本实施例还提供一种电子终端,包括:处理器及存储器;
所述存储器用于存储计算机程序,所述处理器用于执行所述存储器存储的计算机程序,以使所述终端执行本实施例中任一项方法。
本实施例中的计算机可读存储介质,本领域普通技术人员可以理解:实现上述各方法实施例的全部或部分步骤可以通过计算机程序相关的硬件来完成。前述的计算机程序可以存储于一计算机可读存储介质中。该程序在执行时,执行包括上述各方法实施例的步骤;而前述的存储介质包括:ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。
本实施例提供的电子终端,包括处理器、存储器、收发器和通信接口,存储器和通信接口与处理器和收发器连接并完成相互间的通信,存储器用于存储计算机程序,通信接口用于进行通信,处理器和收发器用于运行计算机程序,使电子终端执行如上方法的各个步骤。
在本实施例中,存储器可能包含随机存取存储器(Random Access Memory,简称RAM),也可能还包括非易失性存储器(non-volatile memory),例如至少一个磁盘存储器。
上述的处理器可以是通用处理器,包括中央处理器(Central Processing Unit,简称CPU)、网络处理器(Network Processor,简称NP)等;还可以是数字信号处理器(Digital Signal Processing,简称DSP)、专用集成电路(Application SpecificIntegrated Circuit,简称ASIC)、现场可编程门阵列(Field-Programmable Gate Array,简称FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。
在上述实施例中,除非另外规定,否则通过使用“第一”、“第二”等序号对共同的对象进行描述,只表示其指代相同对象的不同实例,而非是采用表示被描述的对象必须采用给定的顺序,无论是时间地、空间地、排序地或任何其他方式。
本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于系统实施例而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
本发明可用于众多通用或专用的计算系统环境或配置中。例如:个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器系统、基于微处理器的系统、置顶盒、可编程的消费电子设备、网络PC、小型计算机、大型计算机、包括以上任何系统或设备的分布式计算环境等等。
本发明可以在由计算机执行的计算机可执行指令的一般上下文中描述,例如程序模块。一般地,程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本发明,在这些分布式计算环境中,由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中,程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
上述实施例仅示例性说明本发明的原理及其功效,而非用于限制本发明。任何熟悉此技术的人士皆可在不违背本发明的精神及范畴下,对上述实施例进行修饰或改变。因此,但凡所属技术领域中具有通常知识者在未脱离本发明所揭示的精神与技术思想下所完成的一切等效修饰或改变,仍应由本发明的权利要求所涵盖。
Claims (10)
1.一种高性能元数据日志文件管理方法,其特征在于,包括:
将数据与元数据设置于不同的文件系统;
记录数据写入时所有修改过程中的操作,并将其作为第一级过程元数据日志文件;
对所述第一级过程元数据日志文件中记录的过程进行合并,获取合并结果;
将所述合并结果进行记录,将其作为第二级结果元数据日志文件;
根据所述第一级过程元数据日志文件和第二级结果元数据日志文件进行组合写入,完成元数据日志文件的加载合并操作。
2.根据权利要求1所述的高性能元数据日志文件管理方法,其特征在于,通过第一文件系统对元数据日志文件进行管理,通过第二文件系统对数据文件进行管理,所述第一文件系统包括XFS文件系统。
3.根据权利要求1所述的高性能元数据日志文件管理方法,其特征在于,对所述第一级元数据日志文件中记录的过程进行合并后,还包括:
检查是否存在第二级结果元数据日志中间文件,如果存在,则判定合并过程未完成;如果存在,在判定合并过程完成。
4.根据权利要求3所述的高性能元数据日志文件管理方法,其特征在于,
当判定合并过程未完成时,将原第二级结果元数据日志文件删除,并将所述第二级结果元数据日志中间文件重命名为第二级结果元数据日志文件;
加载重命名后的第二级结果元数据日志文件,并对其进行解析,加至内存哈希表中;
加载第一级元数据日志中间文件,并对其进行解析,获取第二级结果元数据日志文件所在哈希表中的节点,
对节点信息进行基本操作,所述基本操作包括数据节点信息的创建、修改和删除;
将哈希表中的记录转换为基本数据写入第二级结果元数据日志中间文件中,完成第一级元数据日志中间文件的合并。
5.根据权利要求4所述的高性能元数据日志文件管理方法,其特征在于,删除合并后的第一级元数据日志中间文件,以及原第二级结果元数据日志文件,并将第二级结果元数据日志中间文件重命名为第二级结果元数据日志文件。
6.根据权利要求4所述的高性能元数据日志文件管理方法,其特征在于,当所述第一级过程元数据日志文件的大小达到预设的阈值时,将其重命名为一第一级元数据日志中间文件并重新打开一新的第一级过程元数据日志文件。
7.根据权利要求1所述的高性能元数据日志文件管理方法,其特征在于,将磁盘划分为至少两个分区,其中一分区为用于存储元数据文件的元数据分区,其他分区为用于存储数据的数据分区,并将所述元数据分区格式化为XFS文件系统。
8.一种高性能元数据日志文件管理系统,其特征在于,包括:
磁盘管理单元,用于对磁盘的分区管理,将数据与元数据设置于不同的文件系统;
日志流程单元,用于记录数据写入时所有修改过程中的操作,并将其作为第一级过程元数据日志文件;对所述第一级过程元数据日志文件中记录的过程进行合并,获取合并结果;将所述合并结果进行记录,将其作为第二级结果元数据日志文件;
日志控制单元,用于根据所述第一级过程元数据日志文件和第二级结果元数据日志文件进行组合写入,完成元数据日志文件的加载合并操作。
9.一种计算机可读存储介质,其上存储有计算机程序,其特征在于:该程序被处理器执行时实现权利要求1至8中任一项所述方法。
10.一种电子终端,其特征在于,包括:处理器及存储器;
所述存储器用于存储计算机程序,所述处理器用于执行所述存储器存储的计算机程序,以使所述终端执行如权利要求1至8中任一项所述方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010843131.1A CN111984598A (zh) | 2020-08-20 | 2020-08-20 | 一种高性能元数据日志文件管理方法、系统、介质及终端 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010843131.1A CN111984598A (zh) | 2020-08-20 | 2020-08-20 | 一种高性能元数据日志文件管理方法、系统、介质及终端 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN111984598A true CN111984598A (zh) | 2020-11-24 |
Family
ID=73443388
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202010843131.1A Pending CN111984598A (zh) | 2020-08-20 | 2020-08-20 | 一种高性能元数据日志文件管理方法、系统、介质及终端 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN111984598A (zh) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114564460A (zh) * | 2022-02-25 | 2022-05-31 | 苏州浪潮智能科技有限公司 | 基于分布式存储系统的参数调优方法、装置、设备及介质 |
CN117873965A (zh) * | 2024-02-01 | 2024-04-12 | 重庆大道云行科技有限公司 | 用于存储系统的元数据管理系统及方法 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102117297A (zh) * | 2009-12-31 | 2011-07-06 | 华为技术有限公司 | 流媒体文件处理方法、装置和系统 |
CN103514258A (zh) * | 2013-08-09 | 2014-01-15 | 北京龙存科技有限责任公司 | 一种基于离线缓存文件操作集中记录预处理并重放的方法 |
CN106611024A (zh) * | 2015-10-27 | 2017-05-03 | 北京国双科技有限公司 | 文件合并方法和装置 |
CN108984686A (zh) * | 2018-07-02 | 2018-12-11 | 中国电子科技集团公司第五十二研究所 | 一种基于日志合并的分布式文件系统索引方法和装置 |
-
2020
- 2020-08-20 CN CN202010843131.1A patent/CN111984598A/zh active Pending
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102117297A (zh) * | 2009-12-31 | 2011-07-06 | 华为技术有限公司 | 流媒体文件处理方法、装置和系统 |
CN103514258A (zh) * | 2013-08-09 | 2014-01-15 | 北京龙存科技有限责任公司 | 一种基于离线缓存文件操作集中记录预处理并重放的方法 |
CN106611024A (zh) * | 2015-10-27 | 2017-05-03 | 北京国双科技有限公司 | 文件合并方法和装置 |
CN108984686A (zh) * | 2018-07-02 | 2018-12-11 | 中国电子科技集团公司第五十二研究所 | 一种基于日志合并的分布式文件系统索引方法和装置 |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114564460A (zh) * | 2022-02-25 | 2022-05-31 | 苏州浪潮智能科技有限公司 | 基于分布式存储系统的参数调优方法、装置、设备及介质 |
CN114564460B (zh) * | 2022-02-25 | 2024-01-19 | 苏州浪潮智能科技有限公司 | 基于分布式存储系统的参数调优方法、装置、设备及介质 |
CN117873965A (zh) * | 2024-02-01 | 2024-04-12 | 重庆大道云行科技有限公司 | 用于存储系统的元数据管理系统及方法 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN110531940B (zh) | 视频文件处理方法及装置 | |
KR102564170B1 (ko) | 데이터 객체 저장 방법, 장치, 및 이를 이용한 컴퓨터 프로그램이 저장되는 컴퓨터 판독가능한 저장 매체 | |
US11314719B2 (en) | Method for implementing change data capture in database management system | |
CN104657500A (zh) | 一种基于key-value键值对的分布式存储方法 | |
CN110673800B (zh) | 文件系统的数据操作方法、装置、设备及可读存储介质 | |
US20120136842A1 (en) | Partitioning method of data blocks | |
KR20060085899A (ko) | 데이터베이스 시스템 및 그 데이터베이스 시스템의데이터베이스 컴포넌트를 메인 메모리에 저장하는 시스템및 방법 | |
CN111177143B (zh) | 键值数据存储方法、装置、存储介质与电子设备 | |
CN113568582B (zh) | 数据管理方法、装置和存储设备 | |
CN109977078B (zh) | 一种数据的处理方法、装置、计算机设备和存储介质 | |
KR20160100211A (ko) | 대용량 오디오 핑거프린트 데이터베이스의 온라인 실시간 업데이팅을 구성하기 위한 방법 및 장치 | |
CN111984598A (zh) | 一种高性能元数据日志文件管理方法、系统、介质及终端 | |
CN111796767A (zh) | 一种分布式文件系统及数据管理方法 | |
CN114625696B (zh) | 文件恢复方法、装置、电子设备及存储介质 | |
CN111444114B (zh) | 一种非易失性内存中数据的处理方法、装置及系统 | |
CN114297196B (zh) | 元数据存储方法、装置、电子设备及存储介质 | |
CN108021562B (zh) | 应用于分布式文件系统的存盘方法、装置及分布式文件系统 | |
CN107943412B (zh) | 一种分区分裂、删除分区中数据文件的方法、装置及系统 | |
CN113253932B (zh) | 一种分布式存储系统的读写控制方法和系统 | |
CN111400273A (zh) | 数据库扩容方法、装置、电子设备及机器可读存储介质 | |
CN113568868A (zh) | 文件系统管理方法、系统、电子设备及介质 | |
US7949632B2 (en) | Database-rearranging program, database-rearranging method, and database-rearranging apparatus | |
CN112328433B (zh) | 归档数据恢复的处理方法、装置、电子装置和存储介质 | |
CN111190549A (zh) | 一种共享卷可用容量获取方法、装置、设备及介质 | |
CN111435342A (zh) | 海报的更新方法、更新系统以及管理系统 |
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: 20201124 |