CN102725755B - 文件访问方法及系统 - Google Patents
文件访问方法及系统 Download PDFInfo
- Publication number
- CN102725755B CN102725755B CN201180003437.5A CN201180003437A CN102725755B CN 102725755 B CN102725755 B CN 102725755B CN 201180003437 A CN201180003437 A CN 201180003437A CN 102725755 B CN102725755 B CN 102725755B
- Authority
- CN
- China
- Prior art keywords
- access
- file
- attribute
- directory entry
- content
- 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.)
- Active
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/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computational Linguistics (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Storage Device Security (AREA)
Abstract
本发明实施例提供一种文件访问方法及系统。其方法包括:文件系统驱动模块接收上层应用发送的第一访问请求;文件系统驱动模块根据上层应用对应的访问接口与键值数据库的访问接口的对应关系,将第一访问请求转换为适用于访问键值数据库的第二访问请求;文件系统驱动模块向键值数据库的客户端发送第二访问请求;键值数据库的客户端根据第二访问请求,从键值数据库的服务器端存储的键值数据库中查找对应的文件内容或者目录项内容或者文件属性或者目录项属性。本发明实施例的技术方案,相对于现有技术中POSIX的文件系统的逐层访问元数据的技术方案,访问开销较小,访问效率较高。
Description
技术领域
本发明实施例涉及计算机技术领域,尤其涉及一种文件访问方法及系统。
背景技术
现有技术中,类似于可移植Unix或者Linux操作系统接口(PortableOperating System Interface for Unix/Linux;POSIX)的文件系统中,包括元数据和数据两大部分;其中元数据部分中包括文件节点(inode)信息,组成特定的数据结构(如多路搜索树等)。其中数据部分包括文件内容。POSIX文件系统能够向上层应用程序提供POSIX接口。在POSIX文件系统中的每一个目录、文件都有一个对应的文件节点(inode),文件节点中包含有文件的大小、创建修改访问时间、权限归属等信息以及文件内容在数据部分的地址信息。对于较大的文件,其在文件系统上的数据部分的分布可能是不连续的,可能会是存储介质中的几个不同的片段组成。现有技术中访问POSIX文件系统中的某个文件时,通常需要先通过POSIX接口访问元数据部分,通过搜索获取到数据部分的地址信息后,再次根据数据部分的地址信息进行搜索找到要访问的文件内容。
对于上述POSIX的文件系统存储文件的时候,当文件系统中存储的文件较多,某一要访问的文件对应的目录深度较深,访问该文件时需要按照文件存储的路径逐层访问元数据,直到访问到该要访问的文件,造成访问开销较大,访问效率较低。
发明内容
本发明实施例提供一种文件访问方法及系统,用以提供一种对基于Key-Value数据库的文件系统的访问方案,用以提高文件访问效率。
本发明实施例提供一种文件访问方法,包括:
文件系统驱动模块接收上层应用发送的第一访问请求,所述第一访问请求中携带有路径信息和要访问的值信息的类型;所述要访问的值信息的类型为内容类型或者属性类型;
所述文件系统驱动模块根据所述上层应用对应的访问接口与键值数据库的访问接口的对应关系,将所述第一访问请求转换为适用于访问所述键值数据库的第二访问请求;所述第二访问请求中携带所述路径信息和要访问的值信息的类型;
所述文件系统驱动模块向所述键值数据库的客户端发送所述第二访问请求;
所述键值数据库的客户端根据所述第二访问请求,从所述键值数据库的服务器端存储的键值数据库中查找对应的文件内容或者目录项内容或者文件属性或者目录项属性;所述键值数据库中包括键信息和所述键信息对应的两个值信息;所述键信息中包括所述路径信息对应的路径哈希值;所述两个值信息对应的类型分别为所述内容类型和所述属性类型,所述内容类型对应的所述值信息中包括所述路径信息对应的路径下的文件内容或者目录项内容;所述属性类型对应的所述值信息中包括所述路径信息对应的路径下的文件属性或者目录项属性。
本发明实施例提供一种文件访问系统,包括:
文件系统驱动模块,用于接收上层应用发送的第一访问请求,所述第一访问请求中携带有路径信息和要访问的值信息的类型;所述要访问的值信息的类型为内容类型或者属性类型;并根据所述上层应用对应的访问接口与键值数据库的访问接口的对应关系,再将所述第一访问请求转换为适用于访问所述键值数据库的第二访问请求;所述第二访问请求中携带所述路径信息和所述要访问的值信息的类型;向所述键值数据库的客户端发送所述第二访问请求;
所述键值数据库的客户端,用于根据所述第二访问请求,从所述键值数据库的服务器端存储的键值数据库中查找对应的文件内容、目录项内容、文件属性或者目录项属性;所述键值数据库中包括键信息和所述键信息对应的两个值信息;所述键信息中包括所述路径信息对应的路径哈希值;所述两个值信息对应的类型分别包括所述内容类型和所述属性类型,所述内容类型对应的所述值信息中包括所述路径信息对应的路径下的文件内容或者目录项内容;所述属性类型对应的所述值信息中包括所述路径信息对应的路径下的文件属性或者目录项属性。
本发明实施例的文件访问方法及系统,通过采用Key-Value数据库存储文件,其中Key信息中包括路径信息对应的路径哈希值,内容类型对应的Value信息中包括路径信息对应的路径下的文件内容或者目录项内容;属性类型对应的Value信息中包括路径信息对应的路径下的文件属性或者目录项属性,当对该Key-Value数据库中的文件进行访问的时候,直接根据路径信息直接获取该路径信息对应的哈希值,以及要访问的Value信息的类型,便可以直接获取对应的文件内容或者目录项内容或者文件属性或者目录项属性。相对于现有技术中POSIX的文件系统的逐层访问元数据的技术方案,访问开销较小,访问效率较高。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍,显而易见地,下面描述中的附图是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动性的前提下,还可以根据这些附图获得其他的附图。
图1为本发明实施例提供的文件访问方法的流程图。
图2为本发明另一实施例提供的文件访问系统的结构示意图。
图3为本发明另一实施例的文件访问系统的结构示意图。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
键值(Key-Value)数据库相比于关系数据库,主要的区别就是数据格式没有严格的定义。在关系数据库中,数据定义就是对数据的约束,包括数据之间的关系和数据的完整性。Key-Value数据库中是没有严格的数据定义的,对于某一个Key及其对应的Value可以是任意的数据类型。Key作为信息的唯一标识,Value作为信息的内容。键值(Key-Value)存储相对于传统的文件系统存储方式,有更大的灵活性、可扩展性,由于没有了目录/路径的约束,结构更加扁平化,没有了传统的POSIX文件系统复杂的元数据信息,能够提高访问效率。
由于Key-Value数据库具有上述优点,可以采用Key-Value数据库代替传统的POSIX文件系统存储文件,本发明实施例中,将文件或者目录项的路径信息对应的哈希值存储在Key-Value数据库对应的Key信息中,对应的文件的属性信息以及文件的内容和目录项的属性信息以及目录项的内容存储在Key-Value数据库对应的Value信息中。这样可以直接根据要访问的文件的路径信息计算器对应的哈希值,然后直接根据该哈希值获取要访问的文件的属性信息或者文件的内容、或者要访问的目录项的属性信息或者目录项的内容。与现有技术中采用POSIX文件系统存储文件而言,不用按照文件存储的路径逐层访问,从而能有效地提高文件的访问效率。而且采用Key-Value数据库存储文件可扩展性较强。使用非常灵活、方便。
下面本发明实施例中详细介绍对基于Key-Value数据库的文件系统进行访问的技术方案。
图1为本发明实施例提供的文件访问方法的流程图。如图1所示,本实施例的文件访问方法,具体可以包括如下步骤:
100、文件系统驱动模块接收上层应用发送的第一访问请求;
本实施例中该第一访问请求中携带有路径信息和要访问的Value信息的类型;该要访问的Value信息的类型为内容类型或者属性类型。
101、文件系统驱动模块根据上层应用对应的访问接口与Key-Value数据库的访问接口的对应关系,将第一访问请求转换为适用于访问Key-Value数据库的第二访问请求;
同理,本实施例的第二访问请求中也携带路径信息和要访问的Value信息的类型。
102、文件系统驱动模块向Key-Value数据库的客户端发送第二访问请求;
103、Key-Value数据库的客户端根据第二访问请求,从Key-Value数据库的服务器端存储的Key-Value数据库中查找对应的文件内容、目录项内容、文件属性或者目录项属性。
本实施例中Key-Value数据库中包括Key信息和Key信息对应的两个Value信息;Key信息中包括路径哈希值;两个Value信息对应的类型分别为内容类型和属性类型,内容类型对应的Value信息中包括路径信息对应的路径下的文件内容或者目录项内容;属性类型对应的Value信息中包括路径信息对应的路径下的文件属性或者目录项属性。
本实施例的文件访问方法,通过采用Key-Value数据库存储文件,其中Key信息中包括路径信息对应的路径哈希值,内容类型对应的Value信息中包括路径信息对应的路径下的文件内容或者目录项内容;属性类型对应的Value信息中包括路径信息对应的路径下的文件属性或者目录项属性,当对该Key-Value数据库中的文件进行访问的时候,直接根据路径信息直接获取该路径信息对应的哈希值,以及要访问的Value信息的类型,便可以直接获取对应的文件内容或者目录项内容或者文件属性或者目录项属性。相对于现有技术中POSIX的文件系统的逐层访问元数据的技术方案,访问开销较小,访问效率较高。
可选地,本实施例的Key-Value数据库的客户端可以对应于多个Key-Value数据库的服务器端。
可选地,在上述图1所示实施例的基础上,其中上述实施例中的步骤103中的“Key-Value数据库的客户端根据第二访问请求,从Key-Value数据库的服务器端存储的Key-Value数据库中查找对应的文件内容或者目录项内容或者文件属性或者目录项属性”,具体可以包括如下步骤:
(1)Key-Value数据库的客户端计算第二访问请求中的路径信息的路径哈希值;
(2)Key-Value数据库的客户端根据路径哈希值和要访问的Value信息的类型,从Key-Value数据库的服务器端存储的Key-Value数据库中查找对应的文件内容或者所述目录项内容或者所述文件属性或者所述目录项属性。具体地,当该路径信息下进对应一个文件时,那么查找的结果即为文件内容信息或者文件属性。当该路径信息下还包括有多个子路径,在每个子路径中还包括有文件名称时,此时查找到的是包括该路径下的多个子路径以及各个子路径中的文件名称的目录项信息或者目录项属性。且由于Key-Value数据库中Key信息和两个Value信息存储在一起,只要查找到Key信息,便可以根据Value的类型直接获取到对应的Value信息,查找非常方便。
进一步可选地,当Key-Value数据库的客户端根据路径哈希值和要访问的Value信息的类型,从Key-Value数据库的服务器端存储的Key-Value数据库中能够查找到对应的文件内容或者所述目录项内容或者所述文件属性或者所述目录项属性时,此时在上述步骤(2)之后,还可以包括:
(3)Key-Value数据库的客户端通过文件系统驱动模块向上层应用发送文件内容或者所述目录项内容或者所述文件属性或者所述目录项属性。这样上层应用便可以访问到Key-Value数据库中要访问的内容。
可选地,在上述图1所示实施例的基础上,Key信息中还可以包括文件名称。文件属性和目录项属性分别包括:大小、类型、最后访问时间、最后修改时间、创建时间、拥有者名、拥有组名和权限信息中的至少一个。目录项内容包括:目录项的子目录和/或子文件的路径哈希值、目录项的子目录和/或子文件的名称。
例如Key信息对应两个Value信息,可以取Value1表示文件或目录项内容,可以取Value2表示文件属性或者目录项属性。例如对应的Key信息可以为如下表1所示,当Value1为目录项内容时,可以如以下表2所示,Value1为文件内容时,可以如以下表3所示。Value2表示文件属性或者目录项属性时,可以如以下表4所示。
其中表2中包括目录下的子文件或子目录的路径哈希值、文件或目录名,其中包括“.”、“..”两个特殊的文件,“.”对应的哈希值为当前目录的路径哈希值,“..”则对应该目录的上层目录哈希值。其中表4中以文件属性或者目录项属性包括大小、类型、最后访问时间、最后修改时间、创建时间、拥有者名、拥有组名、权限信息为例。实际应用中,文件属性或者目录项属性可以包括大小、类型、最后访问时间、最后修改时间、创建时间、拥有者名、拥有组名和权限信息中的至少一个。
表1
路径哈希值:文件名称 |
表2
表3
文件内容 |
表4
需要说明的是,在上述实施例的步骤100之前,还可以包括:文件系统驱动模块确定上层应用对应的访问接口与Key-Value数据库的访问接口的对应关系,以实现上层应用与Key-Value数据库接口的匹配,便于后续实现将上层应用的第一访问请求转换为适用于访问Key-Value数据库的第二访问请求,实现上层应用对Key-Value数据库的访问。
其中本实施例中上层应用的访问接口可以为标准POSIX接口。
本实施例的文件访问方法,通过采用Key-Value数据库存储文件,其中Key信息中包括路径信息对应的路径哈希值,内容类型对应的Value信息中包括路径信息对应的路径下的文件内容或者目录项内容;属性类型对应的Value信息中包括路径信息对应的路径下的文件属性或者目录项属性,当对该Key-Value数据库中的文件进行访问的时候,直接根据路径信息直接获取该路径信息对应的哈希值,以及要访问的Value信息的类型,便可以直接获取对应的文件内容或者目录项内容或者文件属性或者目录项属性。相对于现有技术中POSIX的文件系统的逐层访问元数据的技术方案,访问开销较小,访问效率较高。
可选地,在上述图1所示实施例的基础上,其中Key信息可以对应两个Value信息,实际应用中,也可以扩展一个Key信息对应多个Value信息,例如采用不同的Value信息分别表示文件的不同属性或者类型。
本领域普通技术人员可以理解:实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成,前述的程序可以存储于一计算机可读取存储介质中,该程序在执行时,执行包括上述方法实施例的步骤;而前述的存储介质包括:ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。
图2为本发明另一实施例提供的文件访问系统的结构示意图。如图2所示,本实施例的文件访问系统,包括:文件系统驱动模块10和Key-Value数据库的客户端20。
其中文件系统驱动模块10用于接收上层应用发送的第一访问请求,该第一访问请求中携带有路径信息和要访问的Value信息的类型;要访问的Value信息的类型为内容类型或者属性类型。文件系统驱动模块10还用于根据上层应用对应的访问接口与Key-Value数据库的访问接口的对应关系,将第一访问请求转换为适用于访问Key-Value数据库的第二访问请求;该第二访问请求中携带路径信息和要访问的Value信息的类型。文件系统驱动模块10还用于向Key-Value数据库的客户端发送第二访问请求。Key-Value数据库的客户端20与文件系统驱动模块10连接,Key-Value数据库的客户端20用于根据接收到的文件系统驱动模块10发送的第二访问请求,从Key-Value数据库的服务器端存储的Key-Value数据库中查找第二访问请求(亦即第一访问请求)对应的文件内容、目录项内容、文件属性或者目录项属性;其中Key-Value数据库中包括Key信息和Key信息对应的两个Value信息;Key信息中包括路径信息对应的路径哈希值;两个Value信息对应的类型分别为内容类型和属性类型,内容类型对应的Value信息中包括路径信息对应的路径下的文件内容或者目录项内容;属性类型对应的Value信息中包括路径信息对应的路径下的文件属性或者目录项属性。
本实施例的文件访问系统,通过采用上述文件系统驱动模块和Key-Value数据库的客户端实现文件访问的机制与上述相关方法实施例的实现机制相同,详细可以参考上述相关方法实施例的记载,在此不再赘述。
本实施例的文件访问系统,通过采用上述技术方案,通过采用Key-Value数据库存储文件,其中Key信息中包括路径信息对应的路径哈希值,内容类型对应的Value信息中包括路径信息对应的路径下的文件内容或者目录项内容;属性类型对应的Value信息中包括路径信息对应的路径下的文件属性或者目录项属性,当对该Key-Value数据库中的文件进行访问的时候,直接根据路径信息直接获取该路径信息对应的哈希值,以及要访问的Value信息的类型,便可以直接获取对应的文件内容或者目录项内容或者文件属性或者目录项属性。相对于现有技术中POSIX的文件系统的逐层访问元数据的技术方案,访问开销较小,访问效率较高。
图3为本发明另一实施例的文件访问系统的结构示意图。本实施例的文件访问系统对上述图2所示实施例的文件访问系统作了进一步地详细介绍。如图3所示,本实施例的文件访问系统具体可以包括如下技术方案:
本实施例的文件访问系统中的文件系统驱动模块10具体可以包括:接收单元101、处理单元102和发送单元103。
其中接收单元101用于接收上层应用发送的第一访问请求,该第一访问请求中携带有路径信息和要访问的Value信息的类型;该要访问的Value信息的类型为内容类型或者属性类型。处理单元102与接收单元101连接,处理单元102还用于根据上层应用对应的访问接口与Key-Value数据库的访问接口的对应关系,将接收单元101接收的第一访问请求转换为适用于访问Key-Value数据库的第二访问请求;该第二访问请求中携带路径信息和要访问的Value信息的类型。发送单元103与处理单元102连接,发送单元103还用于向Key-Value数据库的客户端发送处理单元102处理得到的第二访问请求。
可选地,本实施例的文件访问系统中的Key-Value数据库的客户端20中包括接收模块201、计算模块202和查找模块203。其中接收模块201用于接收文件系统驱动模块发送的第二访问请求,第二访问请求中携带路径信息和要访问的Value信息的类型。例如本实施例中该接收模块201具体可以与文件系统驱动模块10中的发送单元103连接,接收模块201接收发送单元103发送的第二访问请求。计算模块202与接收模块201连接,计算模块202用于计算接收模块201接收的第二访问请求中的路径信息的路径哈希值。查找模块203分别与接收模块201和计算模块202连接,查找模块203用于根据计算模块202计算的路径哈希值和接收模块201接收的第二访问请求中携带的要访问的Value信息的类型,从Key-Value数据库的服务器端存储的Key-Value数据库中查找对应的文件内容或者目录项内容或者文件属性或者目录项属性。
进一步可选地,本实施例的文件访问系统中的Key-Value数据库的客户端20中还包括发送模块204。其中该发送模块204与查找模块203连接,发送模块204用于当查找模块203根据路径哈希值和要访问的Value信息的类型,从Key-Value数据库的服务器端存储的Key-Value数据库中查找到第二访问请求(亦即第一访问请求)对应的文件内容或者目录项内容或者文件属性或者目录项属性时,通过文件系统驱动模块10向上层应用发送文件内容、目录项内容、文件属性或者目录项属性。例如发送模块204可以通过文件系统驱动模块10的接收单元101向上层应用发送第一访问请求对应的文件内容、目录项内容、文件属性或者目录项属性。
可选地,本实施例的文件访问系统,其中Key信息中还包括文件名称或者目录名称。
可选地,本实施例的文件访问系统,其中文件属性和目录项属性分别包括:大小、类型、最后访问时间、最后修改时间、创建时、拥有者名、拥有组名和权限信息中的至少一个;目录项内容包括:目录项的子目录和/或子文件的路径哈希值、目录项的子目录和/或子文件的名称。
进一步可选地,本实施例的文件访问系统中的文件系统驱动模块10还包括确定单元104。该确定单元104用于确定上层应用对应的访问接口与Key-Value数据库的访问接口的对应关系。该确定单元104与处理单元102连接,处理单元102用于根据确定单元104确定的上层应用对应的访问接口与键值数据库的访问接口的对应关系,将第一访问请求转换为适用于访问所述键值数据库的第二访问请求。
需要说明的是,图3所示实施例以包括上述所有可选技术方案为例详细介绍本发明的技术方案,实际应用中上述可选技术方案可以以任意可结合的方式结合形成本发明的一可选实施例,在此不再赘述。
本实施例的文件访问系统,通过采用上述文件系统驱动模块和Key-Value数据库的客户端实现文件访问的机制与上述相关方法实施例的实现机制相同,详细可以参考上述相关方法实施例的记载,在此不再赘述。
本实施例的文件访问系统,通过采用上述技术方案,通过采用Key-Value数据库存储文件,其中Key信息中包括路径信息对应的路径哈希值,内容类型对应的Value信息中包括路径信息对应的路径下的文件内容或者目录项内容;属性类型对应的Value信息中包括路径信息对应的路径下的文件属性或者目录项属性,当对该Key-Value数据库中的文件进行访问的时候,直接根据路径信息直接获取该路径信息对应的哈希值,以及要访问的Value信息的类型,便可以直接获取对应的文件内容或者目录项内容或者文件属性或者目录项属性。相对于现有技术中POSIX的文件系统的逐层访问元数据的技术方案,访问开销较小,访问效率较高。
以上所描述的装置实施例仅仅是示意性的,其中作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到至少两个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下,即可以理解并实施。
最后应说明的是:以上实施例仅用以说明本发明的技术方案,而非对其限制;尽管参照前述实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。
Claims (11)
1.一种文件访问方法,其特征在于,包括:
文件系统驱动模块接收上层应用发送的第一访问请求,所述第一访问请求中携带有路径信息和要访问的值信息的类型;所述要访问的值信息的类型为内容类型或者属性类型;
所述文件系统驱动模块根据所述上层应用对应的访问接口与键值数据库的访问接口的对应关系,将所述第一访问请求转换为适用于访问所述键值数据库的第二访问请求;所述第二访问请求中携带所述路径信息和所述要访问的值信息的类型;
所述文件系统驱动模块向所述键值数据库的客户端发送所述第二访问请求;
所述键值数据库的客户端根据所述第二访问请求,从所述键值数据库的服务器端存储的键值数据库中查找对应的文件内容或者目录项内容或者文件属性或者目录项属性;所述键值数据库中包括键信息和所述键信息对应的两个值信息;所述键信息中包括所述路径信息对应的路径哈希值;所述两个值信息对应的类型分别为所述内容类型和所述属性类型,所述内容类型对应的所述值信息中包括所述路径信息对应的路径下的文件内容或者目录项内容;所述属性类型对应的所述值信息中包括所述路径信息对应的路径下的文件属性或者目录项属性;
所述键值数据库的客户端根据所述第二访问请求,从所述键值数据库的服务器端存储的键值数据库中查找对应的文件内容或者目录项内容或者文件属性或者目录项属性,包括:
所述键值数据库的客户端计算所述第二访问请求中的所述路径信息的所述路径哈希值;
所述键值数据库的客户端根据所述路径哈希值和所述要访问的值信息的类型,从所述键值数据库的服务器端存储的键值数据库中查找对应的所述文件内容或者所述目录项内容或者所述文件属性或者所述目录项属性。
2.根据权利要求1所述的方法,其特征在于,当所述键值数据库的客户端根据所述路径哈希值和所述访问类型,从所述键值数据库的服务器端存储的键值数据库中查找到对应的所述文件内容或者所述目录项内容或者所述文 件属性或者所述目录项属性时,所述方法还包括:
所述键值数据库的客户端通过所述文件系统驱动模块向所述上层应用发送所述文件内容或者所述目录项内容或者所述文件属性或者所述目录项属性。
3.根据权利要求1至2任一所述的方法,其特征在于,所述文件系统驱动模块接收上层应用发送的第一访问请求之前,还包括:
所述文件系统驱动模块确定所述上层应用对应的访问接口与所述键值数据库的访问接口的对应关系。
4.根据权利要求3所述的方法,其特征在于,所述键信息中还包括文件名称或者目录名称。
5.根据权利要求4所述的方法,其特征在于,所述文件属性和所述目录项属性包括:大小、类型、最后访问时间、最后修改时间、创建时间、拥有者名、拥有组名和权限信息中的至少一个;
所述目录项内容包括:所述目录项的子目录和/或子文件的路径哈希值、所述目录项的子目录和/或子文件的名称。
6.一种文件访问系统,其特征在于,包括:
文件系统驱动模块,用于接收上层应用发送的第一访问请求,所述第一访问请求中携带有路径信息和要访问的值信息的类型;所述要访问的值信息的类型为内容类型或者属性类型;并根据所述上层应用对应的访问接口与键值数据库的访问接口的对应关系,再将所述第一访问请求转换为适用于访问所述键值数据库的第二访问请求;所述第二访问请求中携带所述路径信息和所述要访问的值信息的类型;向所述键值数据库的客户端发送所述第二访问请求;
所述键值数据库的客户端,用于根据所述第二访问请求,从所述键值数据库的服务器端存储的键值数据库中查找对应的文件内容、目录项内容、文件属性或者目录项属性;所述键值数据库中包括键信息和所述键信息对应的两个值信息;所述键信息中包括所述路径信息对应的路径哈希值;所述两个值信息对应的类型分别包括所述内容类型和所述属性类型,所述内容类型对应的所述值信息中包括所述路径信息对应的路径下的文件内容或者目录项内容;所述属性类型对应的所述值信息中包括所述路径信息对应的路径下的文 件属性或者目录项属性;
所述键值数据库的客户端,包括:
接收模块,用于接收所述文件系统驱动模块发送的所述第二访问请求;
计算模块,用于计算所述第二访问请求中的所述路径信息的所述路径哈希值;
查找模块,用于根据所述路径哈希值和所述要访问的值信息的类型,从所述键值数据库的服务器端存储的键值数据库中查找对应的所述文件内容、所述目录项内容、所述文件属性或者所述目录项属性。
7.根据权利要求6所述的系统,其特征在于,所述文件系统驱动模块,包括:
接收单元,用于接收上层应用发送的第一访问请求,所述第一访问请求中携带有路径信息和要访问的值信息的类型;所述要访问的值信息的类型为内容类型或者属性类型;
处理单元,用于根据所述上层应用对应的访问接口与键值数据库的访问接口的对应关系,将所述第一访问请求转换为适用于访问所述键值数据库的第二访问请求;所述第二访问请求中携带所述路径信息和要访问的值信息的类型;
发送单元,用于向所述键值数据库的客户端发送所述第二访问请求。
8.根据权利要求7所述的系统,其特征在于,所述文件系统驱动模块还包括:
确定单元,用于确定所述上层应用对应的访问接口与所述键值数据库的访问接口的对应关系。
9.根据权利要求6所述的系统,其特征在于,所述键值数据库的客户端,还包括:
发送模块,用于当所述查找模块根据所述路径哈希值和所述要访问的值信息的类型,从所述键值数据库的服务器端存储的键值数据库中查找到对应的所述文件内容或者所述目录项内容或者所述文件属性或者所述目录项属性时,通过所述文件系统驱动模块向所述上层应用发送所述文件内容或者所述目录项内容或者所述文件属性或者所述目录项属性。
10.根据权利要求6所述的系统,其特征在于,所述键信息中还包括文 件名称或者目录名称。
11.根据权利要求6至10任一所述的系统,其特征在于,所述文件属性和所述目录项属性分别包括:大小、类型、最后访问时间、最后修改时间、创建时间、拥有者名、拥有组名和权限信息中的至少一个;
所述目录项内容包括:所述目录项的子目录和/或子文件的路径哈希值、所述目录项的子目录和/或子文件的名称。
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/CN2011/085169 WO2013097231A1 (zh) | 2011-12-31 | 2011-12-31 | 文件访问方法及系统 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN102725755A CN102725755A (zh) | 2012-10-10 |
CN102725755B true CN102725755B (zh) | 2014-07-09 |
Family
ID=46950466
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201180003437.5A Active CN102725755B (zh) | 2011-12-31 | 2011-12-31 | 文件访问方法及系统 |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN102725755B (zh) |
WO (1) | WO2013097231A1 (zh) |
Families Citing this family (16)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103077199B (zh) * | 2012-12-26 | 2016-07-13 | 北京思特奇信息技术股份有限公司 | 一种文件资源查找定位方法及装置 |
CN103226592A (zh) * | 2013-04-15 | 2013-07-31 | 浪潮(北京)电子信息产业有限公司 | 一种基于数据库的文件系统及文件存储方法 |
CN104077374B (zh) * | 2014-06-24 | 2018-09-11 | 华为技术有限公司 | 一种实现ip盘文件存储的方法及装置 |
CN104268280B (zh) * | 2014-10-17 | 2017-07-07 | 中国人民解放军国防科学技术大学 | 一种基于键值数据库的层次化存储与查询方法 |
CN105404821B (zh) * | 2015-10-23 | 2018-05-04 | 上海帝联信息科技股份有限公司 | 操作系统的文件访问控制方法及装置 |
CN105741031A (zh) * | 2016-01-28 | 2016-07-06 | 北京恒华伟业科技股份有限公司 | 一种工程设计方案的处理方法和装置 |
CN107818113B (zh) * | 2016-09-13 | 2023-08-11 | 中兴通讯股份有限公司 | 文件访问位置的确定方法及装置 |
CN106484820B (zh) * | 2016-09-26 | 2020-01-17 | 华为技术有限公司 | 一种重命名方法、访问方法及装置 |
CN106844579A (zh) * | 2017-01-09 | 2017-06-13 | 山东中创软件商用中间件股份有限公司 | 一种网站废旧文件的处理方法及系统 |
CN107247722B (zh) * | 2017-04-25 | 2020-11-06 | 北京金山安全软件有限公司 | 一种文件扫描方法、装置及智能终端 |
US11030155B2 (en) * | 2017-04-26 | 2021-06-08 | Samsung Electronics Co., Ltd. | Key value file system |
CN107741968B (zh) * | 2017-10-09 | 2021-06-29 | 郑州云海信息技术有限公司 | 一种文件检索的方法、系统、装置及计算机可读存储介质 |
CN110109866B (zh) * | 2017-12-28 | 2021-11-09 | 中移(杭州)信息技术有限公司 | 一种文件系统目录的管理方法及设备 |
US20210248107A1 (en) * | 2017-12-29 | 2021-08-12 | Beijing Memblaze Technology Co., Ltd | Kv storage device and method of using kv storage device to provide file system |
CN109726202B (zh) * | 2018-12-18 | 2020-11-17 | 北京新唐思创教育科技有限公司 | 一种区块链数据存储方法及计算机存储介质 |
CN117472915B (zh) * | 2023-12-27 | 2024-03-15 | 中国西安卫星测控中心 | 一种面向多Key值的时序数据的层级存储方法 |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6725223B2 (en) * | 2000-12-22 | 2004-04-20 | International Business Machines Corporation | Storage format for encoded vector indexes |
CN100451976C (zh) * | 2007-07-23 | 2009-01-14 | 清华大学 | 基于海量数据分级存储系统的迁移管理方法 |
CN101510209B (zh) * | 2009-03-30 | 2012-05-30 | 北京金山软件有限公司 | 实现实时检索的方法、系统和服务器 |
US20100332516A1 (en) * | 2009-06-30 | 2010-12-30 | Alcatel-Lucent Usa Inc. | Linking inner and outer mpls labels |
CN102147711B (zh) * | 2010-12-31 | 2014-04-02 | 华为数字技术(成都)有限公司 | 一种基于数据内容识别的存储方法及装置 |
-
2011
- 2011-12-31 CN CN201180003437.5A patent/CN102725755B/zh active Active
- 2011-12-31 WO PCT/CN2011/085169 patent/WO2013097231A1/zh active Application Filing
Also Published As
Publication number | Publication date |
---|---|
WO2013097231A1 (zh) | 2013-07-04 |
CN102725755A (zh) | 2012-10-10 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN102725755B (zh) | 文件访问方法及系统 | |
CN104794123B (zh) | 一种为半结构化数据构建NoSQL数据库索引的方法及装置 | |
CN105224546B (zh) | 数据存储和查询方法及设备 | |
US8555018B1 (en) | Techniques for storing data | |
CN102708165B (zh) | 分布式文件系统中的文件处理方法及装置 | |
CN107704202B (zh) | 一种数据快速读写的方法和装置 | |
CN109726044A (zh) | 基于数据块名称从重复数据删除存储中高效还原多个文件 | |
CN102495894A (zh) | 重复数据查找方法、装置及系统 | |
US9934247B2 (en) | Built-in search indexing for NAS systems | |
CN105303456A (zh) | 电力传输设备监控数据处理方法 | |
CN106471501B (zh) | 数据查询的方法、数据对象的存储方法和数据系统 | |
CN103812939A (zh) | 一种大数据存储系统 | |
CN103488687A (zh) | 用于大数据的搜索系统和搜索方法 | |
CN105808622A (zh) | 一种文件存储的方法和装置 | |
CN103597474A (zh) | 对列入访问控制表的文档进行的高效索引和搜索 | |
CN103440301A (zh) | 一种数据多副本混合存储方法及系统 | |
US20130124503A1 (en) | Delta indexing method for hierarchy file storage | |
US20140019454A1 (en) | Systems and Methods for Caching Data Object Identifiers | |
US20220188340A1 (en) | Tracking granularity levels for accessing a spatial index | |
US9069681B1 (en) | Real-time log joining on a continuous stream of events that are approximately ordered | |
EP3042316B1 (en) | Music identification | |
CN109062500B (zh) | 一种元数据管理服务器、数据存储系统及数据存储方法 | |
CN104462349A (zh) | 一种文件处理方法及装置 | |
US9092338B1 (en) | Multi-level caching event lookup | |
CN115168499B (zh) | 数据库表的分片方法、装置、计算机设备和存储介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
TR01 | Transfer of patent right | ||
TR01 | Transfer of patent right |
Effective date of registration: 20220207 Address after: 550025 Huawei cloud data center, jiaoxinggong Road, Qianzhong Avenue, Gui'an New District, Guiyang City, Guizhou Province Patentee after: Huawei Cloud Computing Technology Co.,Ltd. Address before: 518129 Bantian HUAWEI headquarters office building, Longgang District, Guangdong, Shenzhen Patentee before: HUAWEI TECHNOLOGIES Co.,Ltd. |