CN114528260A - 文件访问请求的处理方法、电子设备及计算机程序产品 - Google Patents
文件访问请求的处理方法、电子设备及计算机程序产品 Download PDFInfo
- Publication number
- CN114528260A CN114528260A CN202210039207.4A CN202210039207A CN114528260A CN 114528260 A CN114528260 A CN 114528260A CN 202210039207 A CN202210039207 A CN 202210039207A CN 114528260 A CN114528260 A CN 114528260A
- Authority
- CN
- China
- Prior art keywords
- metadata
- target
- file
- access request
- memory
- 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/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/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/178—Techniques for file synchronisation in 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/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
- G06F16/2453—Query optimisation
-
- 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
- G06F16/245—Query processing
- G06F16/2457—Query processing with adaptation to user needs
- G06F16/24573—Query processing with adaptation to user needs using data annotations, e.g. user-defined metadata
-
- 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/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Databases & Information Systems (AREA)
- Data Mining & Analysis (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computational Linguistics (AREA)
- Computing Systems (AREA)
- Human Computer Interaction (AREA)
- Library & Information Science (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本申请公开了一种文件访问请求的处理方法、电子设备及计算机程序产品,S3FS服务接收到文件访问请求后,处理文件访问请求的过程中需要获取目标文件的目标元数据时,先到内存中查找目标元数据。若内存中没有目标元数据,则在本地的持久化数据库中查找目标元数据。采用该种方案,S3FS服务基于本地持久化数据库存储的元数据对文件访问请求进行处理,并不需要从S3云端获取元数据,因此降低了S3FS服务和S3云端的交互次数,提高对文件访问请求的处理速度的同时,降低资源消耗,并提高网络可靠性。
Description
技术领域
本申请涉及云存储技术领域,特别涉及一种文件访问请求的处理方法、电子设备及计算机程序产品。
背景技术
目前,主流的存储类型主要有三种:块存储、文件存储和对象存储。其中,对象存储有着块存储的高速直接访问磁盘的优点,同时兼具文件存储的分布式共享特点。因此,对象存储正逐渐在云计算存储服务领域占据越来越重要的地位。
对象存储本质上是网络存储***,一般通过应用程序接口(ApplicationProgramming Interface,API)的形式进行访问。但是,普通用户很难通过写代码调用API的形式访问对象存储***。S3FS服务是***开发的一款支持将对象存储中的存储桶(bucket)以文件形式导出的文件***接口,兼容可移植操作***接口(PortableOperating System Interface,POSIX)语义。S3FS是基于用户空间文件***(File systemin Userspace,FUSE)开发的文件***,允许Linux和Mac Os X挂载S3的存储桶在本地文件***,S3FS能够保持对象原来的格式。因此,可借助S3FS服务来实现将对象存储转换为文件存储。这样一来,普通用户就可以像访问文件存储***一样访问对象存储***。
当用户操作文件时产生文件访问请求,部署了S3FS服务的设备接收到文件访问请求后,获取相关元数据,进而根据获取结果处理文件访问请求。获取元数据的过程中,S3FS服务判断内存中是否存在相关元数据。若内存中没有,则通过网络从S3云端请求元数据。
然而,文件存储***的日常使用中,用户对文件的大量操作使得元数据的访问和更新十分频繁。由于部署了S3FS服务的设备的内存空间有限,导致S3FS服务从云端获取元数据,响应速度慢,且耗费大量资源。
发明内容
本申请提供一种文件访问请求的处理方法、电子设备及计算机程序产品,通过将元数据存储在本地持久化数据库中,减少S3FS服务和S3云端的交互,提高文件访问请求的处理速度的同时,降低资源消耗。
第一方面,本申请实施例提供一种文件访问请求的处理方法,应用于S3FS服务,所述方法包括:
接收文件访问请求,所述文件访问请求是所述S3FS服务根据用户对目标文件的操作生成的,所述目标文件存储在目标目录下;
当处理所述文件访问请求过程中需要获取所述目标文件的目标元数据时,确定所述S3FS服务本地设备的内存中是否存在所述目标元数据;
当所述内存中不存在所述目标元数据时,从持久化数据库中获取所述目标元数据,所述持久化数据库是创建在所述本地设备的本地磁盘上、且专为所述S3FS服务提供元数据存储服务的持久化数据库;
基于所述目标元数据的获取结果,确定所述文件访问请求的处理方式。
第二方面,本申请实施例提供一种电子设备,包括:处理器、存储器及存储在所述存储器上并可在处理器上运行的计算机程序,所述处理器执行所述计算机程序时使得所述电子设备实现如上第一方面或第一方面各种可能的实现方式所述的方法。
第三方面,本申请实施例提供一种包含计算程序的计算机程序产品,所述计算机程序被处理器执行时实现如上第一方面或第一方面各种可能的实现方式所述的方法。
本申请实施例提供的文件访问请求的处理方法、电子设备及计算机程序产品,S3FS服务接收到文件访问请求后,处理文件访问请求的过程中需要获取目标文件的目标元数据时,先到内存中查找目标元数据。若内存中没有目标元数据,则在本地的持久化数据库中查找目标元数据。采用该种方案,S3FS服务基于本地持久化数据库存储的元数据对文件访问请求进行处理,并不需要从S3云端获取元数据,因此降低了S3FS服务和S3云端的交互次数,提高对文件访问请求的处理速度的同时,降低资源消耗,并提高网络可靠性。
附图说明
为了更清楚地说明本申请实施例中的技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1是本申请实施例提供的文件访问请求的处理方法的网络架构示意图;
图2是本申请实施例提供的文件访问请求的处理方法的流程图;
图3是本申请实施例提供的文件访问请求的处理方法另一个流程图;
图4为本申请实施例提供的一种电子设备的结构示意图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚,下面将结合附图对本申请实施方式作进一步地详细描述。
为了方便普通用户使用对象存储***,运维人员利用S3FS等开源软件将对象存储转换为文件存储。这样一来,普通用户就可以像访问文件存储***一样访问对象存储***。文件存储***含有大量的元数据(metadata),元数据是用于描述数据的数据,主要是描述文件的属性,如文件的属主、权限、修改时间、创建时间等。
现有的S3FS等开源软件部署在网关上,网关将元数据临时保存在内存中。用户在终端设备操作文件时,终端设备基于用户的操作生成文件访问请求并发送给网关,该文件访问请求触发请求元数据。其中,操作文件包括如新增文件、修改文件、删除文件、查询文件等。网关接收到文件访问请求后,先查询内存中是否存在用户操作的文件对应的元数据。若内存中没有文件对应的元数据,则从S3云端获取元数据。
然而,对象存储转换为文件存储后,用户像访问文件存储***一样访问对象存储***的过程中,会产生大量的文件访问请求,使得元数据的访问和更新十分频繁。由于网关的内存空间有限,导致大量的文件访问请求所需的元数据都要从S3云端设备获取。S3云端和网关的交互频繁,响应速度慢,且耗费大量资源。而且,当网关与S3云端之间的网络异常时,则无法获取到元数据,导致对象存储转换为文件存储的服务不可用,进而导致用户操作失败。
基于此,本申请实施例提供一种文件访问请求的处理方法、电子设备及计算机程序产品,通过将元数据存储在持久化数据库中,减少S3FS服务和S3云端的交互,提高文件访问请求的处理速度的同时,降低资源消耗,并提高网络可靠性。
本申请实施例相关名词解释如下:
存储桶(bucket):用户用来管理存储对象的存储空间,类似于文件存储***里面根目录或磁盘分区,对象存储***通过存储桶来管理对象。
文件存储***:也称之为文件***,一种存储和组织计算机数据的方法,它使得对文件的存取和查找变得容易。文件存储***使用文件和树形目录的抽象逻辑概念代替了硬盘和光盘等物理设备使用数据块的概念,用户使用文件存储***来保存数据只需要记住这个文件的所属目录和文件名。
元数据:用于描述数据的数据,主要是描述文件的属性,如文件的属主、权限、修改时间、创建时间等。
文件:可以称之为数据,每个文件有自己的元数据。本申请实施例中,文件存储***存储的数据称之为文件,对象存储***存储的数据称之为对象。可以理解的是,同一份数据即可基于文件进行管理,也可基于对象进行管理,用户对文件的操作,可以转换为用户对对象的操作。例如,用户新增一个文件,相当于新增一个对象;用户删除一个文件,相当于删除一个对象。
持久化数据库:指为S3FS服务创建的持久化数据库,该数据库是一个能够持久化保存的数据库,可以基于rocksdb、Redis或其他类型的数据库技术实现,用于保存用户像访问文件存储***时访问对象存储***的过程中涉及的元数据,它区别于内存,需创建在磁盘上。一般而言,在使用本申请的技术方案时,需要预先为S3FS服务划分磁盘空间,如在部署S3FS服务的设备上添加新的磁盘,以用于为S3FS服务的持久化数据库存储数据。
云计算里,存储类型相关的术语通常为文件存储、对象存储等,一般不称作文件存储***、对象存储***。可以理解的是,将对象存储转换为文件存储,是指将基于对象存储***进行管理的对象数据转换为基于文件存储***进行管理的文件数据。下文中若未做特殊说明,对象存储等同于对象存储***,文件存储等同于文件存储***。
图1是本申请实施例提供的文件访问请求的处理方法所适用的网络架构示意图。请参照图1,该网络架构包括S3FS服务11和S3云端12。S3FS服务11部署在终端设备或网关等电子设备上,用户可通过S3FS服务以文件的形式访问数据。当一个S3FS服务11挂载了对象存储中的存储桶后,用户就可以像访问文件一样访问存储桶中的对象。
S3云端12是提供简易存储服务(Simple Storage Service,S3)的平台,可以部署在云端的服务器或服务器集群,以存储桶的形式管理对象数据,换言之,S3云端以对象存储的方式对数据进行存储。
下面,基于图1所示实施环境,对本申请实施例提供的文件访问请求的处理方法进行详细说明。示例性的,请参照图2。
图2是本申请实施例提供的文件访问请求的处理方法的流程图。本实施例是从S3FS服务的角度进行说明。本实施例包括:
201、接收文件访问请求。
其中,所述文件访问请求是所述S3FS服务根据用户对目标文件的操作生成的,所述目标文件存储在目标目录下。
基于S3FS服务,用户像访问文件存储***一样访问对象存储***时,对目标目录下的目标文件进行各种操作。例如,当目标目录为空或存在至少一个文件时,用户可以在该目标目录下增加文件。再如,当目标目录不为空时,用户可以对目标目录下的文件进行修改、删除或查询等操作。用户同时可以对一个目标目录下的所有文件进行操作,比如list操作,此时,目标文件为目标目录下的所有文件。另外,用户也可以仅对目标目录下的一个文件进行操作,则这个文件为目标文件。终端设备根据用户对目标文件的操作生成文件访问请求。
202、当处理所述文件访问请求过程中需要获取所述目标文件的目标元数据时,确定所述S3FS服务本地设备的内存中是否存在所述目标元数据,若S3FS服务本地设备的内存中不存在目标文件对应的目标元数据,则执行步骤203;若S3FS服务本地设备的内存中存在目标文件对应的目标元数据,则执行步骤204。
S3FS服务处理文件访问请求的过程中,通常会获取元数据,以基于元数据对访问请求进行处理。例如,文件访问请求指示用户删除目标文件,则S3FS服务获取目标文件的目标元数据,根据目标元数据确定用户是否具有删除权限。再如,文件访问请求指示用户下载目标文件,则S3FS服务获取目标文件的目标元数据,根据目标元数据确定用户是否具有下载权限。
本申请实施例中,S3FS服务部署在网关、终端设备等电子设备上,部署了S3FS服务的电子设备称之为本地设备。一般而言,本地设备内存是设备上的各应用程序共用的,存储空间较小,且基于***自身对内存的管理机制,内存中的缓存数据可能会被覆盖,S3FS服务可在本地设备内存中临时保存一些文件的元数据,并定期对元数据进行清理。例如,利用先进先出原则对元数据进行清理。再如,定期删除使用频率最小的元数据等。由于内存的响应速度较快,S3FS服务接收到访问请求后,可先查询本地设备的内存中是否存在目标元数据。
203、从持久化数据库中获取所述目标元数据。
其中,所述持久化数据库是创建在所述本地设备的本地磁盘上、且专为所述S3FS服务提供元数据存储服务的持久化数据库。
示例性的,持久化数据库创建在本地磁盘上,可用于数据的持久化存储,是区别于内存的缓存方式,S3FS将从S3云端获取的元数据写入持久化数据库中,进行持久化存储。当内存中不存在目标元数据时,S3FS服务查询本地的持久化数据库,以从持久化数据库中获取目标元数据。
204、从本地设备的内存中获取目标元数据。
当内存中存在目标文件的目标元数据时,S3FS服务从内存中获取目标元数据。
205、基于目标元数据的获取结果,确定文件访问请求的处理方式。
其中,目标元数据的获取结果可包含:从内存中获取到目标元数据;内存中没有目标元数据的情况下,从持久化数据库中获取到了目标元数据;内存和持久化数据库中均未获取到目标元数据。不同的获取结果对应的处理方式不同。
具体而言,S3FS服务从本地设备的内存或本地的持久化数据库中获取到目标元数据后,基于目标元数据继续对文件访问请求进行处理。例如,用户操作为删除操作,若目标元数据指示用户具有删除权限,则S3FS服务删除目标文件;若目标元数据指示用户不具有删除权限,则S3FS服务拒绝删除目标文件。
当从内存和持久化数据库中均未获取到目标元数据时,向用户发送提示信息,以提示用户所述目标文件不存在,并终止所述文件访问请求的处理,也就是说,当无法从本地获取目标元数据时,S3FS服务直接拒绝处理该文件访问请求。
值得注意的是,当处理所述文件访问请求的过程中需要新增目标元数据时,可先基于上述方法获取目标元数据,若无法获取到目标元数据时,则将所述目标元数据写入所述持久化数据库中,若获取到目标元数据,则终止处理该文件访问请求,并向用户发送错误信息。
在一个较佳实施中,当处理所述文件访问请求的过程中需要新增目标元数据时,可以覆盖的形式直接将所述目标元数据写入所述持久化数据库中,无需先从本地获取目标元数据,处理流程更加高效。相应地,为保证S3云端数据的一致性,在成功完成目标数据的新增后,S3FS服务可生成新增所述目标元数据的操作记录,并将所述操作记录同步至S3云端,使得所述S3云端基于所述操作记录进行对应新增操作。可以理解的是,当处理文件访问请求的过程中涉及目标元数据的删除和修改时,也可以生成对应的操作记录,并同步至S3云端。
其中,同步的方式可以是周期性的同步、也可以是在S3FS服务需要向S3云端发送文件数据时,一并进行同步,以节省网络资源。
可以理解的是,在实际应用中,文件访问请求的处理过程中可包含多次获取、新增目标元数据的情形,都可基于本申请实施例所提供的方法进行处理,不再赘述。
由此可见,本申请实施例所提供的文件访问请求处理方法完全基于S3FS服务本地设备上存储的元数据对文件访问请求进行处理,并不需要从S3云端获取元数据,因此降低了S3FS服务和S3云端的交互次数,提高对文件访问请求的处理速度的同时,降低资源消耗,并提高网络可靠性。同时,通过对目标元数据更新的操作记录同步至S3云端,可保证S3FS服务与S3云端的数据一致。
在上述实施例中,当在处理文件访问请求的过程中涉及目标元数据的更新操作时,如新增、删除和修改,S3FS服务可以对本地内存进行相应的更新,从而保证本地内存的元数据与持久化数据库的元数据保持一致,避免因数据不一致而导致的处理异常的问题。
较佳地,上述实施例中,S3FS服务可通过设置持久化数据库中元数据的存储格式来优化查询效率,即提高目标元数据的获取速度。
在实施中,S3FS服务在启动过程中可预先从S3云端获取挂载的存储桶相关的元数据,即在接收文件访问请求前,预先完成元数据的全量同步。其中全量同步是指S3FS服务在为用户提供服务前,先与S3云端进行元数据的同步。具体地,S3FS服务在启动过程中需进行存储桶的挂载,以实现将该存储桶内的对象数据用文件的方式提供给用户操作。一般而言,需要全量同步情形包含两种:初始挂载存量存储桶和重新部署用于同一个存储桶的S3FS服务,其中,初始挂载是指S3FS服务首次挂载存储桶;重新部署用于同一个存储桶的S3FS服务是指:先前已部署过S3FS服务,并完成了存储桶的挂载,当因设备异常等原因需要重新部署且该服务挂载的存储桶不变。换言之,在启动过程中,当S3FS服务所挂载的存储桶内有存量数据时,则需要预先从云端获取该存储桶中的全部元数据并写入持久化数据库,使得用户访问请求达到时,可直接基于持久化数据库中的元数据进行响应。可以理解的是,全量同步的过程就是S3FS服务构建持久化数据库的过程。
示例性的,S3FS服务可直接根据技术人员配置信息来确定是否需要全量同步,技术人员可根据S3FS挂载的存储桶内是否有存量数据来设置配置信息,并启动S3FS服务。
在挂载的过程中,S3FS服务会在本地磁盘创建持久化数据库,用于元数据的缓存。在实施中,创建持久化数据库就是open一个数据库,数据库的名称是可以重复的,如果创建的目录下已创建过相同名称的数据库,那么就相当于打开了旧的数据库,旧的数据库中会有残留的数据,为了防止数据库残留的旧数据对后续的操作产生影响,可在创建持久化数据库后,全量同步前,将持久化数据库清空。
采用该种方案,全量同步前清空持久化数据库,确保全量同步后持久化数据库内的元数据都是同一个存储桶内各对象的元数据,而不存在其他对象的元数据或存有先前的旧数据,保证同步过程中不会出错,提升数据可靠性高。
当完成数据清空后,可从S3云端拉取挂载的存储桶内的元数据,将各对象的元数据写入持久化数据库,从而完成持久化数据库的构建及全量同步。值得注意的是,若在全量同步过程中发生异常,S3FS服务将停止启动,并反馈错误信息。只有当全量同步顺利完成后,S3FS服务才会继续完成后的启动步骤,如此一来,S3FS服务正常启动后,可直接基于本地的元数据对文件访问请求进行处理,而无需再向S3云端获取元数据。
为了优化持久化数据的查询效率,可基于下文所述的方式进行元数据的存储。
S3FS服务接收文件访问请求之前,为所述S3FS服务挂载的存储桶对应的每个目录生成唯一标识,以得到映射表,所述映射表用于记录目录与唯一标识的对应关系。之后,为所述每个目录下的每个文件的元数据生成键值对,所述键值对的键为所述文件的上级目录的唯一标识和所述文件的文件名的组合,所述键值对的值为所述文件的元数据。最后,将所述每个目录下的每个文件的元数据的键值对写入所述持久化数据库。
示例性的,一个S3FS服务挂载一个存储桶,当需要对多个存储桶中的对象进行操作时,可在设备上部署多个S3FS服务,S3FS服务将挂载的存储桶中的对象以文件的形式展示给用户,以供用户进行操作。
为了快速地对用户访问请求进行响应,本申请的实施例中,S3FS服务预先将挂载的存储桶中各对象的元数据写入持久化数据库。写入过程中,S3FS服务为存储桶中的每个目录生成一个唯一标识,该唯一标识也称之为(Universally Unique Identifier,UUID),S3FS服务将各目录与对应的唯一标识记录在一张映射表中。例如,存储桶包含3个目录,则生成3个唯一标识,具体可参见表1。
表1
目录 | 唯一标识 |
dir1 | uuid-1 |
dir2 | uuid-2 |
dir2/dira | uuid-3 |
请参照表1,目录dir1的唯一标识为uuid-1,目录dir2的唯一标识为uuid-2,目录dir2/dira的唯一标识是uuid3。目录dir2/dira是目录dir2的子目录。
S3FS服务为每个目录生成唯一标识之后,为每个目录下的每个文件的元数据生成键值对,最后将各文件的元数据以键值对(key-value,kv)的形式写入本地的持久化数据库。其中,key=uuid<parent>_name<file>,value=stat,即key=上级目录唯一标识_文件名,Value=元数据。
例如,一个文件的文件名为file.txt,该文件位于目录dir1下,即该文件的上级目录为dir1,则该文件的键值对的key=uuid-1_file.txt,value=stat。stat代表文件file.txt的元数据。
再如,一个文件的文件名为dira,该文件位于目录dir2下,即该文件的上级目录为dir2,则该文件的键值对的key=uuid-2_dira,value=stat。stat代表文件dira的元数据。文件dira可以是一个文件、一个文件夹等,当文件dira为文件夹时,其可以包含一个或多个文件,也可以为空。
又如,一个文件的文件名为file2.exe,该文件位于目录dir2/dira下,即该文件的上级目录为dir2/dira,则该文件的键值对的key=uuid-3_file2.exe,value=stat。stat代表文件file2.exe的元数据。
采用该种方案,通过以键值对的形式来存储各个文件(即对象)的元数据,并以文件所在目录对应的唯一标识与文件名的拼接值作为key值,可同时便于某个文件的元数据、某个目录下所有文件的元数据的获取,提高了文件访问请求的处理过程中元数据的获取效率。
基于上述的元数据的存储格式,当S3FS服务的内存中不存在目标元数据时,S3FS服务从本地的持久化数据库中获取目标元数据时,首先,确定目标目录的唯一标识。之后,根据所述唯一标识查询所述持久化数据库,以获取所述目标元数据,其中,所述持久化数据库中以键值对的形式存储元数据,键值对中的键包含元数据所属文件的所在目录对应的唯一标识。
示例性的,目标目录即为目标文件的上级目录。用户通过终端设备操作目标目录时,比如,修改目标目录下的某个文件、删除某个文件、新增文件时,终端设备产生文件访问请求,该文件访问请求携带目标目录。S3FS服务接收到文件访问请求后,能够从文件访问请求中提取出目标目录。之后,S3FS服务根据目标目录查询映射表,从而确定出目标目录的唯一标识,进而根据唯一标识查询持久化数据库以获取目标元数据。
采用该种方案,S3FS服务每次接收到文件访问请求后,处理该文件访问请求的过程中如果需要获取目标元数据,则根据目标目录确定出唯一标识,根据唯一标识查询持久化数据库以获取元数据,速度快且无需去S3云端获取,提高文件访问请求的处理速度。
上述实施例中,用户对目标目录的操作包括两种场景,一种是对目标目录下的一个具体文件的操作,比如删除目标目录下的一个文件或修改目标目录下的一个文件。这个时候,目标文件即为一个具体的文件,S3FS服务需要获取目标文件的元数据。另一种是列表(list)操作,即获取目标目录下所有文件的元数据,这时候,目标文件包括目标目录下的所有文件。下面,对这两种情况分别进行详细说明。
List操作的场景中,若采用现有从S3云端获取元数据的方式,则会带来大量的头(head)请求,效率低下。其中,head请求是用于获取指定对象元数据的请求。而本申请实施例中,list操作场景中,目标文件是目标目录下的所有文件,S3FS服务处理文件访问请求的过程中,需要获取目标目录下所有目标文件的元数据。获取过程中,S3FS服务从持久化数据库存储的多个键值对中确定出键中包含唯一标识的全部键值对,将全部键值对中的值确定为目标元数据。
示例性的,S3FS服务确定出目标目录对应的唯一标识后,由于是获取整个目标目录下所有文件的元数据,因此,S3FS服务利用目标目录对应的唯一标识查询持久化数据库,从多个键值对中确定出键中包含唯一标识的键值对,将这些键值对的值作确定为目标元数据。
例如,用户操作为ls dir1/,即用户请求查询dir1下面所有的文件,目标元数据是目录dir1下所有文件的元数据。S3FS服务接收到文件访问请求后,确定出dir1的唯一标识为uuid-1,则以此为key的前缀,在持久化数据库中查找所有key的前缀为uuid-1的键值对,将这些键值对的值确定为目标元数据。
再如,用户操作为ls dir1/dira/,即用户请求查询dir1/dira/下面所有的文件,目标元数据是目录dir1/dira下所有文件的元数据。S3FS服务接收到访问请求后,确定出dir1/dir的唯一标识为uuid-3,则以此为key的前缀,在持久化数据库中查找所有key的前缀为uuid-3的键值对,将这些键值对的值确定为目标元数据。
采用该种方案,通过将目标目录对应的唯一标识作为key前缀的方式查询持久化数据库,减少了S3FS服务与云端设备的交互次数,提高查询效率,同时也减少了本地数据库的访问压力与请求次数。
对具体文件操作的场景中,目标文件是目标目录下一个文件,S3FS服务处理文件访问请求的过程中需要获取这一个目标文件的目标元数据。获取过程中,S3FS服务根据所述唯一标识和所述目标文件的文件名拼接出所述目标文件的元数据的目标键。之后,从所述持久化数据库存储的多个键值对中确定出包含所述目标键的目标键值对,将所述目标键值对的值确定为所述目标元数据。
例如,文件访问请求携带的信息如下:stat dir1/file.txt,S3FS服务处理该文件访问请求的过程中,需要获取的目标元数据是:目标目录dir1下文件名为file.txt的文件的元数据。S3FS服务根据目标目录dir1确定出唯一标识为uuid-1,进一步的根据唯一标识和文件名拼装出key=uuid-1_file.txt。之后,S3FS服务从持久化数据库中确定出键为uuid-1_file.txt的键值对,将该键值对的值确定为请求的元数据。
再如,文件访问请求携带的信息如下:stat dir2/dira,S3FS服务处理该文件访问请求的过程中,需要获取的目标元数据是:目标目录dir2下文件名为dira的文件的元数据。S3FS服务根据目标目录dir2确定出唯一标识为uuid-2,进一步的根据唯一标识和文件名拼装出key=uuid-2_dira。之后,S3FS服务从持久化数据库中确定出键为uuid-2_dira的键值对,将该键值对的值确定为目标元数据。
采用该种方案,通过根据目标目录和文件名得到键值对的键,通过该键查询持久化数据库以获取元数据,速度快,提高查询效率。
图3是本申请实施例提供的文件访问请求的处理方法的另一个流程图。本实施例包括:
301、接收文件访问请求。
其中,所述文件访问请求是S3FS服务根据用户对目标文件的操作生成的,所述目标文件存储在目标目录下;
302、确定S3FS服务本地设备的内存中是否存在目标文件的目标元数据,若内存中不存在目标元数据,则执行步骤303;若内存中存在目标元数据,则执行步骤308。
303、确定S3FS服务的持久化数据库中是否存在目标元数据,若持久化数据库中存在目标元数据,则执行步骤304的同时执行步骤308;若持久化数据库中不存在目标文件,则执行步骤309。
其中,持久化数据库是创建在所述终端设备的本地磁盘上、且专为所述S3FS服务提供元数据存储服务的持久化数据库。
上述的步骤301-303,具体可参见图2中步骤201-203的描述,此处不再赘述。
304、确定所述内存中元数据的数据量是否超过预设阈值,若内存中元数据的数据量未超过预设阈值,则执行步骤305;若内存中元数据的数据量超过预设阈值,则执行步骤306。
示例性的,部署S3FS服务的本地设备的内存空间是有限的,S3FS服务会根据预设的策略删除一些元数据。预设阈值例如为50、100等,本申请实施例并不限制。当本地设备的内存中不存在目标元数据、但是持久化数据库中存在目标元数据时,S3FS服务继续判断内存中元数据的数据流是否超过预设阈值,若内存中元数据的数据量未超过预设阈值,则执行步骤305;若内存中元数据的数据量超过预设阈值,则执行步骤306。
305、将目标元数据写入本地设备的内存。
S3FS服务将从持久化数据库中查找到的目标元数据写入内存。这样一来,后续用户再次操作目录文件时,S3FS服务就能够从内存中查找到目标元数据,提高响应速度。
306、从所述内存中确定出淘汰元数据。
307、从所述内存中删除所述淘汰元数据,将目标元数据写入内存。
示例性的,S3FS服务根据先进先出原则等确定出淘汰元数据,删除该些淘汰元数据后,将目标元数据写入部署了S3FS服务的本地设备的内存。
采用该种方案,通过及时清理内存、以及将内存中原本不存在的元数据写入内存,便于后续用户再次操作目录文件时,S3FSS服务能够从内存中查找到元数据,提高响应速度。
可选的,上述实施例中,淘汰元数据是所述内存中近期最少使用或使用频率最小的元数据。
示例性的,S3FS服务根据近期最少使用(Least Recently Used,LRU)算法,从缓存在本地设备的内存中的多个元数据中,确定出近期最少使用的元数据,将这些元数据作为必须删除的淘汰元数据。或者,S3FS服务根据使用频率最少(Least Frequently Used,LFU)算法,从缓存在本地设备的内存中的多个元数据中,确定出使用频率最少的元数据,将这些元数据作为必须删除的淘汰元数据。另外,S3FSS服务还可以通过其他算法确定出淘汰元数据,本申请实施例并不限制。
采用该种方案,实现快速、准确确定出淘汰元数据的目的。
308、基于所述目标元数据的获取结果继续对所述文件访问请求的处理。
309、S3FS服务确定出用户操作的文件不存在。
当S3FS服务确定出用户操作的文件不存在时,根据操作类型确定后续动作。例如,当用户操作为新增文件的操作时,新建文件并生成元数据,将元数据写入内存以及数据库。
当用户操作为查询文件时,向所述终端设备发送提示信息,以提示所述文件对应的元数据不存,进而使得终端设备根据提示信息生成用于提示用户的告警信息,使得用户知道查询操作失败。
需要说明的是,上述图3实施例中,是以步骤304和步骤308同时执行为例对本申请实施例进行说明。然而,本申请实施例并不限制,其他可行的实现方式中,其他可行的实现方式中,也可以是在步骤305和步骤307之后执行步骤308。
图4为本申请实施例提供的一种电子设备的结构示意图。如图4所示,该电子设备400例如为部署了S3FS服务的设备,该电子设备400包括:
处理器41和存储器42;
所述存储器42存储计算机指令;
所述处理器41执行所述存储器42存储的计算机指令,使得所述处理器41执行如上S3FS服务实施的文件访问请求的处理方法。
处理器41的具体实现过程可参见上述方法实施例,其实现原理和技术效果类似,本实施例此处不再赘述。
可选地,该电子设备400还包括通信部件43。其中,处理器41、存储器42以及通信部件43可以通过总线44连接。
本申请实施例还提供一种计算机可读存储介质,所述计算机可读存储介质中存储有计算机指令,所述计算机指令被处理器执行时用于实现如上S3FS服务实施的文件访问请求的处理方法。
本申请实施例还提供一种计算机程序产品,该计算机程序产品包含计算机程序,计算机程序被处理器执行时实现如上S3FS服务实施的文件访问请求的处理方法。
本领域技术人员在考虑说明书及实践这里公开的发明后,将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化,这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的,本申请的真正范围和精神由下面的权利要求书指出。
应当理解的是,本申请并不局限于上面已经描述并在附图中示出的精确结构,并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求书来限制。
Claims (12)
1.一种文件访问请求的处理方法,其特征在于,应用于S3FS服务,所述方法包括:
接收文件访问请求,所述文件访问请求是所述S3FS服务根据用户对目标文件的操作生成的,所述目标文件存储在目标目录下;
当处理所述文件访问请求过程中需要获取所述目标文件的目标元数据时,确定所述S3FS服务本地设备的内存中是否存在所述目标元数据;
当所述内存中不存在所述目标元数据时,从持久化数据库中获取所述目标元数据,所述持久化数据库是创建在所述本地设备的本地磁盘上、且专为所述S3FS服务提供元数据存储服务的持久化数据库;
基于所述目标元数据的获取结果,确定所述文件访问请求的处理方式。
2.根据权利要求1所述的方法,其特征在于,所述当所述内存中不存在所述目标元数据时,从持久化数据库中获取所述目标元数据,包括:
当所述内存中不存在所述目标元数据时,确定所述目标目录的唯一标识;
根据所述唯一标识查询所述持久化数据库,以获取所述目标元数据,其中,所述持久化数据库中以键值对的形式存储元数据,所述键值对中的键包含元数据所属文件的所在目录对应的唯一标识。
3.根据权利要求2所述的方法,其特征在于,所述根据所述唯一标识查询所述持久化数据库,以获取所述目标元数据,包括:
当处理所述文件访问请求的过程中需要获取所述目标目录下的全部元数据时,从所述持久化数据库存储的多个键值对中确定出键中包含所述唯一标识的全部键值对,将所述全部键值对中的值确定为所述目标元数据。
4.根据权利要求2所述的方法,其特征在于,所述根据所述唯一标识查询所述持久化数据库,以获取所述目标元数据,包括:
当处理所述文件访问请求的过程中需要获取所述目标目录下的目标文件对应的元数据时,根据所述唯一标识和所述目标文件的文件名拼接出所述目标文件的元数据的目标键;
从所述持久化数据库存储的多个键值对中确定出包含所述目标键的目标键值对,将所述目标键值对的值确定为所述目标元数据。
5.根据权利要求2所述的方法,其特征在于,所述接收文件访问请求之前,还包括:
为所述S3FS服务挂载的存储桶对应的每个目录生成唯一标识,以得到映射表,所述映射表用于记录目录与唯一标识的对应关系;
为所述每个目录下的每个文件的元数据生成键值对,所述键值对的键为所述文件的上级目录的唯一标识和所述文件的文件名的组合,所述键值对的值为所述文件的元数据;
将所述每个目录下的每个文件的元数据的键值对写入所述持久化数据库。
6.根据权利要求1-5任一项所述的方法,其特征在于,所述当所述内存中不存在所述目标元数据时,从持久化数据库中获取到所述目标元数据之后,还包括:
确定所述内存中元数据的数据量是否超过预设阈值;
当所述数据量未超过所述预设阈值时,将所述目标元数据写入所述内存。
7.根据权利要求6所述的方法,其特征在于,还包括:
当所述数据量超过所述预设阈值时,从所述内存中确定出淘汰元数据;
从所述内存中删除所述淘汰元数据;
将所述目标元数据写入所述内存。
8.根据权利要求7所述的方法,其特征在于,所述淘汰元数据是所述内存中近期最少使用或使用频率最小的元数据。
9.根据权利要求1-5任一项所述的方法,其特征在于,所述方法还包括:
当处理所述文件访问请求的过程中需要新增目标元数据时,直接将所述目标元数据写入所述持久化数据库中,生成新增所述目标元数据的操作记录,并将所述操作记录同步至S3云端,使得所述S3云端基于所述操作记录进行对应新增操作。
10.根据权利要求1-5任一项所述的方法,其特征在于,所述基于所述目标元数据的获取结果,确定所述文件访问请求的处理方式包括:
当从所述内存和所述持久化数据库中均未获取到所述目标元数据时,向用户发送提示信息,以提示所述目标文件不存在,并终止所述文件访问请求的处理;
当从所述内存或所述持久化数据库中获取到所述目标元数据时,基于所述目标元数据继续对所述文件访问请求的处理。
11.一种电子设备,包括处理器、存储器及存储在所述存储器上并可在所述处理器上运行的计算机程序,其特征在于,所述处理器执行所述计算机程序时使得所述电子设备实现如权利要求1至10任一所述的方法。
12.一种计算机程序产品,其包含计算程序,其特征在于,所述计算机程序被处理器执行时实现如权利要求1至10任一所述的方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210039207.4A CN114528260A (zh) | 2022-01-13 | 2022-01-13 | 文件访问请求的处理方法、电子设备及计算机程序产品 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210039207.4A CN114528260A (zh) | 2022-01-13 | 2022-01-13 | 文件访问请求的处理方法、电子设备及计算机程序产品 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN114528260A true CN114528260A (zh) | 2022-05-24 |
Family
ID=81620278
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202210039207.4A Pending CN114528260A (zh) | 2022-01-13 | 2022-01-13 | 文件访问请求的处理方法、电子设备及计算机程序产品 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN114528260A (zh) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2024041188A1 (zh) * | 2022-08-26 | 2024-02-29 | 华为技术有限公司 | 一种数据管理的方法及相应设备 |
-
2022
- 2022-01-13 CN CN202210039207.4A patent/CN114528260A/zh active Pending
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2024041188A1 (zh) * | 2022-08-26 | 2024-02-29 | 华为技术有限公司 | 一种数据管理的方法及相应设备 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20200348852A1 (en) | Distributed object replication architecture | |
US20200125410A1 (en) | Dynamic allocation of worker nodes for distributed replication | |
KR101137299B1 (ko) | 스냅샷을 제공하는 파일 시스템에 대한 계층적 저장 관리 | |
US6748504B2 (en) | Deferred copy-on-write of a snapshot | |
US7216135B2 (en) | File system for providing access to a snapshot dataset where disk address in the inode is equal to a ditto address for indicating that the disk address is invalid disk address | |
US7111014B2 (en) | Providing a snapshot of a subject of a file system | |
US7043503B2 (en) | Ditto address indicating true disk address for actual data blocks stored in one of an inode of the file system and subsequent snapshot | |
US6959310B2 (en) | Generating data set of the first file system by determining a set of changes between data stored in first snapshot of the first file system, and data stored in second snapshot of the first file system | |
US7085785B2 (en) | Writable file system snapshot with ditto address feature | |
US7818287B2 (en) | Storage management system and method and program | |
US10536522B2 (en) | Data storage system with LUN archiving to cloud using volume-to-object translation | |
EP4006737A1 (en) | Concurrent multiprotocol access to an object storage system | |
US11669405B2 (en) | Leveraging metadata to manage the expiration of objects storing incremental backup data | |
CN114528255A (zh) | 元数据管理方法、电子设备及计算机程序产品 | |
US11822370B2 (en) | Concurrent multiprotocol access to an object storage system | |
CN109407975B (zh) | 写数据方法与计算节点以及分布式存储*** | |
CN115774703A (zh) | 信息处理方法及装置 | |
CN116467275A (zh) | 共享远程存储方法、装置、***、电子设备及存储介质 | |
CN109165078B (zh) | 一种虚拟分布式服务器及其访问方法 | |
US11809280B2 (en) | Synchronizing expirations for incremental backup data stored on a cloud-based object storage | |
CN114528260A (zh) | 文件访问请求的处理方法、电子设备及计算机程序产品 | |
CN113853778B (zh) | 一种文件***的克隆方法及装置 | |
CN115061630A (zh) | 一种数据迁移方法、装置、设备及介质 | |
CN114584551A (zh) | 文件上传方法、电子设备及计算机程序产品 | |
US10713121B1 (en) | Dynamic migration of a cloud based distributed file system metadata server |
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 |