CN120523810A - 数据管理方法、装置及可读存储介质 - Google Patents

Abstract

本申请提供了一种数据管理方法、装置及可读存储介质。应用于云平台，该方法包括：接收来自第一客户端上传的第一文件的操作请求，操作请求携带对第一文件的操作类型以及文件信息，操作类型包括写入、修改和/或读取，文件信息包括文件标识；根据文件标识，确定文件路径；根据文件路径，确定第一分区表中第一文件对应的节点映射表；节点映射表为文件树结构，节点映射表中的节点与第一文件的元数据一一对应；以节点映射表中的根节点为搜索起点，按照文件路径的层级关系，在节点映射表中逐层搜索，得到物理地址；根据物理地址访问第一文件，并对第一文件执行操作类型对应的操作。能够实现云环境下复杂逻辑结构数据的高效管理。

Description

数据管理方法、装置及可读存储介质

技术领域

本申请属于虚拟化技术领域，尤其涉及数据管理方法、装置及可读存储介质。

背景技术

当前，以亚马逊网络服务简单存储服务(Amazon Web Services Simple StorageService，AWS S3)、微软Azure Blob存储服务(Microsoft Azure Blob Storage)和谷歌云存储服务(Google Cloud Storage)为代表的主流云存储系统，普遍采用对象存储服务来应对海量数据的存储需求。这类系统通过键值对(Key-Value，KV)结构，以“对象”为基本单元存储数据，具备高效的存取速度和良好的扩展性。然而，当对象存储的无序键值对特性时，使其难以直接支持具有逻辑层次关系的数据组织方式。在面对需要管理复杂逻辑结构数据的场景时，传统的对象存储系统显得力不从心，无法提供充分的支持。

发明内容

本申请实施例提供了数据管理方法、装置及可读存储介质，能够实现云环境下复杂逻辑结构数据的高效管理。

第一方面，本申请实施例提供了一种数据管理方法，应用于云平台，该方法包括：接收来自第一客户端上传的第一文件的操作请求，操作请求携带对第一文件的操作类型以及文件信息，操作类型包括写入、修改和/或读取，文件信息包括文件标识；根据文件标识，确定文件路径；根据文件路径，确定第一分区表中第一文件对应的节点映射表；节点映射表为文件树结构，节点映射表中的节点与第一文件的元数据一一对应；以节点映射表中的根节点为搜索起点，按照文件路径的层级关系，在节点映射表中逐层搜索，得到物理地址；根据物理地址访问第一文件，并对第一文件执行操作类型对应的操作。

上述方案中，针对现有技术中的对象存储在云平台环境中因无序键值对特性导致的逻辑层次数据组织难题，本方案通过构建树状节点映射表与层级搜索机制，实现了云环境下复杂逻辑结构数据的高效管理与操作。具体而言，本方案将云存储中文件的元数据组织为树状结构，每个节点对应文件或目录的元数据，并通过父子节点关系体现层级逻辑，从而突破了传统对象存储在云平台中缺乏目录层级支持的局限。同时，通过文件路径快速解析节点映射表，实现物理地址的精准定位，避免了传统对象存储依赖全局扫描或外部元数据库的低效操作，有效降低了云平台中大规模数据访问的延迟。

通过本申请显著提升了云平台环境下数据访问与操作性能，并增强了系统的可扩展性与维护性，支持动态增删节点与模块化功能扩展，适配云平台弹性伸缩的特性。此外，还能够无缝对接现有云对象存储系统(如AWS S3、Azure Blob Storage、Google CloudStorage等)，通过细粒度权限控制和跨层级关联查询，满足云环境中文档管理、多媒体资源库、物联网数据流等复杂场景的需求，为需要管理逻辑层次数据的云业务提供了高效、灵活且可靠的解决方案。

在第一方面的一种可能的实现方式中，以节点映射表中的根节点为搜索起点，按照文件路径的层级关系，在节点映射表中逐层搜索，得到物理地址，包括：将根节点作为当前父节点，在节点映射表中匹配属于当前父节点的子节点中，匹配与文件路径下一层级对应的目标子节点；若文件路径下一层级表征文件路径中的目录，则将目标子节点更新为当前父节点，重新执行在节点映射表中属于当前父节点的子节点中，匹配与文件路径下一层级对应的目标子节点及之后的步骤；若文件路径下一层级表征文件，且目标子节点无指向的下一级节点，则根据目标子节点得到物理地址。

在第一方面的一种可能的实现方式中，根据文件路径，确定第一分区表中第一文件对应的节点映射表之前，还包括：获取空间映射表，空间映射表包括虚拟存储单元的标识与物理存储单元的标识之间的映射关系、物理存储单元的标识与分区表的分区标识之间的映射关系。

根据文件路径，确定第一分区表中第一文件对应的节点映射表，包括：根据文件路径和空间映射表，确定第一分区表中第一文件对应的节点映射表。

在第一方面的一种可能的实现方式中，根据文件路径，确定第一分区表中第一文件对应的节点映射表，包括：提取文件路径中的根目录；在空间映射表中，匹配得到根目录对应的分区标识；根目录为虚拟存储单元的标识，空间映射表包括虚拟存储单元的标识与物理存储单元的标识之间的映射关系、物理存储单元的标识与分区表的分区标识之间的映射关系；在分区标识所指示的第一分区表中，查询得到根目录对应的节点映射表。

在第一方面的一种可能的实现方式中，该方法还包括：若第一分区表中节点映射表的数量大于或等于第一阈值，则在至少一个分区表中查找是否存在第二分区表；第二分区表的内存占用量小于第一阈值；若存在，则将第一分区表中第一数量的节点映射表，迁移至第二分区表中；第一数量小于或等于第一阈值与第二分区表中节点映射表的数量之间的差值；迁移完成后，更新空间映射表；其中，更新后的空间映射表中，迁移的节点映射表对应的物理存储单元的标识指向第二分区表；空间映射表包括虚拟存储单元的标识与物理存储单元的标识之间的映射关系、物理存储单元的标识与分区表的分区标识之间的映射关系。

在第一方面的一种可能的实现方式中，该方法还包括：若不存在，则创建新的分区表，并将第一分区表中第二数量的节点映射表，迁移至新的分区表，第二数量小于或等于第一阈值；迁移完成后，更新空间映射表；其中，更新后的空间映射表中，迁移的节点映射表对应的物理存储单元的标识指向新的分区表。

在第一方面的一种可能的实现方式中，操作类型为修改，文件信息包括修改内容，对第一文件执行操作类型对应的操作，包括：根据修改内容，定位第一文件中待修改行；若待修改行未锁定，则在待修改行中添加行锁，并利用修改内容对待修改行中的内容进行修改；若待修改行已锁定，则等待待修改行解锁后，在待修改行中添加行锁，并基于修改内容对待修改行执行修改操作。

在第一方面的一种可能的实现方式中，该方法还包括：利用雪花算法对节点生成的时间戳、节点类型及自增序列号进行组合，生成节点映射表中各节点的标识。

第二方面，本申请实施例提供了一种数据管理装置，该装置包括：

接收模块，用于接收来自第一客户端上传的第一文件的操作请求，操作请求携带对第一文件的操作类型以及文件信息，操作类型包括写入、修改和/或读取，文件信息包括文件标识。

处理模块，用于根据文件标识，确定文件路径。

处理模块，还用于根据文件路径，确定第一分区表中第一文件对应的节点映射表；节点映射表为文件树结构，节点映射表中的节点与第一文件的元数据一一对应。

搜索模块，用于以节点映射表中的根节点为搜索起点，按照文件路径的层级关系，在节点映射表中逐层搜索，得到物理地址。

处理模块，还用于根据物理地址访问第一文件，并对第一文件执行操作类型对应的操作。

第三方面，本申请实施例提供了一种电子设备，包括：该电子设备包括处理器以及与处理器耦接的存储器和数据接口；其中，数据接口用于进行数据通信，存储器用于程序数据，程序数据在被处理器执行时，用于实现上述提供的应用于第一方面及其任一项可能的实现方式的方法。

第四方面，本申请实施例提供了一种计算机可读存储介质，该计算机可读存储介质中存储有计算机程序/指令，当计算机程序/指令在电子设备上运行时，使得电子设备执行上述第一方面及其任一项可能的实现方式的方法。

第五方面，本申请实施例提供了一种计算机程序产品，包括计算机程序/指令，当计算机程序/指令被处理器执行时，使得电子设备执行上述第一方面及其任一项可能的实现方式的方法。

可以理解的是，上述第二方面至第五方面的有益效果可以参见上述第一方面中的相关描述，在此不再赘述。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请一实施例提供的应用环境的架构示意图；

图2是本申请一实施例提供的数据管理方法的流程示意图；

图3是本申请一实施例提供的分区表的结构示意图；

图4是本申请一实施例提供的存储过程调用的流程示意图；

图5是本申请一实施例提供的数据迁移方法的流程示意图；

图6是本申请一实施例提供的数据库的结构示意图；

图7是本申请一实施例提供的数据管理装置的结构示意图；

图8是本申请实施例提供的电子设备的结构示意图。

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本申请。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本申请的描述。

应当理解，当在本申请说明书和所附权利要求书中使用时，术语“包括”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。

还应当理解，在本申请说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。

另外，在本申请说明书和所附权利要求书的描述中，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

在本申请说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本申请的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。

由于现有云平台通过键值对(Key-Value，KV)结构，以“对象”为基本单元存储数据，然而，对象存储的无序键值对特性，使其难以直接支持具有逻辑层次关系的数据组织方式。在面对需要管理复杂逻辑结构数据的场景时，传统的对象存储系统显得力不从心，无法提供充分的支持。

基于此，本申请实施例提供一种数据管理方法、装置及可读存储介质，该方法的技术原理为：基于MySQL分区表技术与逻辑卷(Volume)、驱动器(Drive)的分层架构，实现了云平台海量数据的层级化管理，尤其针对海量小文件元数据的存储与查询场景进行了深度优化。通过逻辑卷与分区表的一一映射，每个逻辑卷的数据可独立存储与管理，解决了传统单表架构随数据量增长导致的性能下降问题，显著提升了存储效率与查询响应速度。

在架构设计上，驱动器(Drive)层面对多租户场景进行了逻辑划分，将不同用户或业务空间映射到对应的物理卷，实现了跨租户的元数据隔离、安全访问与弹性扩展。该机制通过动态容量扩展和自动数据迁移能力，有效支撑了多租户环境下资源隔离与弹性扩展的需求。

在文件操作层面，通过封装数据库存储过程实现了文件创建、删除等核心操作，并引入行级锁机制构建空间锁定策略。结合数据库事务机制与预编译逻辑，确保了高并发场景下的线程安全、操作原子性及数据一致性，显著提升了系统整体性能与访问可靠性。通过分区表的动态扩展能力，配合灵活的文件树结构与唯一索引设计，实现了高效的文件层级管理。该架构特别优化了终端备份、同步、云盘等大规模分布式文件系统场景，在保障系统稳定性的同时，全面提升了存储性能、查询效率、系统扩展性及管理灵活性，满足复杂业务场景下的高性能需求。

本申请实施例提供的数据管理方法可以应用于如图1所示的应用环境中。其中，至少一个客户端101或者云平台102。云平台102可以包括业务系统和文件网关，其中，业务系统与业务逻辑和功能相关。文件网关作为可以客户端101或者云平台102之间的接口或中间件，处理与文件相关的请求。

作为一个示例，在支付场景中，业务系统中部署有认证(Authentication，AD)模块、管理(Management，MG)模块、文件系统(File System，FS)、MySQL分区表。

其中，FS的核心功能是管理文件元数据，其技术实现主要依赖关系型数据库(如MySQL)进行数据存储。主要功能包括以下3点：

1、元数据存储设计：基于MySQL提供底层存储服务，通过Schema(数据库表结构)设计实现元数据存储。通过分区表(Partition Table)建模，能够解决单节点存储海量数据的性能瓶颈。

2、高并发访问支持：通过存储过程(Stored Procedure)封装业务逻辑，实现高并发访问。从而利用数据库内部事务机制(Transaction)保障并发控制，确保数据一致性与业务逻辑正确性。

3、外部访问与安全控制：通过定义文件系统操作接口，允许客户端通过文件系统操作接口与文件系统交互(如RESTful接口)，支持客户端通过HTTPS加密协议进行安全通信。为保障数据访问的安全性，FS可以集成主流鉴权机制，包括OAuth2.0授权框架和JWT(JSON Web Token)身份认证方案，构建多层次安全防护体系。

在文件管理服务中，基于HTTPS协议的文件系统操作接口。以网盘应用场景为例，当客户端需要展示网盘文件数据时，可通过调用后端服务提供的ls接口实现元数据获取。该接口遵循RESTful规范，接收客户端的标准化请求后，返回包含文件名称、大小、修改时间等核心元数据信息的响应体。客户端接收到元数据后，可依据业务需求进行动态渲染展示，实现数据与界面的高效联动。通过标准化接口设计、加密通信协议、多维度鉴权机制及前后端分离架构，在确保数据安全性的同时，显著提升了系统的可扩展性与维护性。

另外，管理模块提供了业务开通和管理的API接口。

此外，MySQL分区表通过将表数据按规则(如范围、哈希、列表、业务租户、空间等)划分为独立逻辑分区，实现物理存储隔离(每个分区对应独立文件)，在逻辑上仍保持单一表结构。这种设计显著提升了海量数据场景下的查询效率(仅扫描相关分区)、管理便捷性(分区级备份、归档)及系统扩展性(突破单文件大小限制)。与之配合，MySQL存储过程作为预编译的SQL逻辑集合，封装于数据库服务器中，支持参数化输入与结果集输出，可被应用程序或其他存储过程灵活调用，其功能类似于数据库端的“函数”或“子程序”，通过减少客户端-服务器交互次数进一步优化系统性能。二者结合使用，可构建兼具高效查询与复杂业务逻辑处理能力的数据库架构。

在一些实施例中，客户端101可以但不限于是各种个人计算机、笔记本电脑和平板电脑，服务器可以用独立的服务器或者是多个服务器组成的服务器集群来实现。云平台102可以包括多个不同的独立云平台。

下面，结合图1，通过具体实施例对本申请所示的方法进行说明。可以理解的是，下面几个实施例可以单独存在，也可以互相结合，对于相同或相似的内容，在不同的实施例中不再重复说明。

图2为本申请实施例提供的一种数据管理方法的流程示意图，应用于云平台。请参见图2，该方法可以包括：

201、接收来自第一客户端上传的第一文件的操作请求。

其中，操作请求携带对第一文件的操作类型以及文件信息，操作类型包括写入、修改和/或读取，文件信息包括文件标识。

在一些实施例中，可基于用户在第一客户端上的操作行为确定第一文件的操作请求，例如，对第一文件的修改操作。

可选的，文件标识可以是但不限于以下任一项：用于指示文件路径的关键字、应用程序逻辑、文件系统元数据。其中，关键字可以是元数据(文件名称)、在命令行中cd和ls等命令等。

202、根据文件标识，确定文件路径。

可选的，文件标识即为文件路径。例如，在文件浏览器中选择文件或目录时，程序可以直接获取所选项目的完整路径。又如，在命令行中使用cd和ls等命令导航到特定目录，并通过pwd命令查看当前工作目录的路径。又如，当网页或应用程序在内部维护文件路径信息时，特别是在处理文件操作时。例如：当用户通过网页或应用程序上传或下载文件时，网页或应用程序、网页或应用程序对应的服务端可以记录文件存储的位置和路径。基于此，云平台接收到的文件标识，即为文件路径。

可选的，文件标识可以是文件名，云平台接收到文件名后，在其内存中搜索该文件名对应的文件路径。

203、根据文件路径，确定第一分区表中第一文件对应的节点映射表；节点映射表为文件树结构，节点映射表中的节点与第一文件的元数据一一对应。

一些实施例中，假设有文件路径为:/Drive1/User/Desktop/test.txt，则表示虚拟存储单元由4个对象组成(3个目录+1个文件；其中，目录为：Drive1、User、Desktop；文件为：test.txt)，相应的，第一文件对应的文件树中，包括三个目录节点和一个文件节点，其中，表示Drive1的目录节点为根节点。

可选的，对应关系通过节点中的元数据指针实现，该指针指向存储第一文件元数据的内存页表项。

可选的，第一分区表为一个或多个MySQL分区表其中的一个。

其中，如图3所示，第一分区表与物理存储单元一一对应，物理存储单元与虚拟存储单元为一对多。

需要说明的是，虚拟存储单元为驱动器Drive。其中，Drive是一个虚拟存储单元或云盘，类似于常见的云盘概念。每个Drive包含容量和使用量等属性，并用于管理文件(File)。文件需要声明其所属的Drive。Drive提供了一个逻辑上的存储空间，用户可以在不同的Drive中组织和管理文件。每个Drive可以有自己的独立文件树结构。

物理存储单元可以为Volume。其中，Volume是物理存储单元或逻辑卷，映射到数据库的分区表，采用一一映射的方式。即每个物理存储单元对应一个分区表。Volume提供了底层存储的实际物理实现。每个Volume可以包含多个Drive，但每个Drive的数据存储在一个特定的Volume上。

204、以节点映射表中的根节点为搜索起点，按照文件路径的层级关系，在节点映射表中逐层搜索，得到物理地址。

可选地，每个节点包括以下字段：主键(由Volume和节点ID(OID)构成)、逻辑索引(由Volume+父节点ID(FID)+Name组成)。通过逻辑索引能够快速定位文件的方法，避免节点映射表的全表扫描。

其中，Volume表示文件所在的逻辑卷；FID(父节点ID)指向当前节点的父节点ID，帮助定位文件在文件树中的位置；Name为文件或目录的名称。

在一些实施例中，生成节点映射表的部分代码如下：

CREATE TABLE`t_b_drive_file_metadata`(

`volume`char(8)NOT NULL COMMENT'空间存储卷',

`oid`bigint NOT NULL COMMENT'文件节点标识',

`drive`varchar(255)NOT NULL COMMENT'逻辑空间名称',

`fid`bigint NOT NULL COMMENT'父节点标识',

`file_name`varchar(255)NOT NULL COMMENT'文件名称',

`size`bigint NOT NULL DEFAULT 0COMMENT'文件大小(字节)',

......

`status`tinyint NOT NULL DEFAULT 0COMMENT'文件状态：0-正常、1-上传中',

`last_modified_at`datetime NOT NULL DEFAULT CURRENT_TIMESTAMPCOMMENT'更新时间',

`created_at`datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT'创建时间',

`delete_at`datetime NULL DEFAULT NULL COMMENT'删除时间',

PRIMARY KEY(`volume`,`oid`)USING BTREE,

UNIQUE INDEX`file_name_inx`(`volume`ASC,`fid`ASC,`file_name`ASC)USINGBTREE,

INDEX`drive_inx`(`volume`ASC,`drive`ASC)USING BTREE

)ENGINE＝InnoDB ROW_FORMAT＝Dynamic PARTITION BY LIST COLUMNS(`volume`)

(

PARTITION volume1 VALUES IN('V-01-001'),

PARTITION volume2 VALUES IN('V-01-002'),

PARTITION volume3 VALUES IN('V-01-003'),

PARTITION volume4 VALUES IN('V-01-004'),

PARTITION volume5 VALUES IN('V-01-005'),

PARTITION volume6 VALUES IN('V-01-006'),

PARTITION volume7 VALUES IN('V-01-007'),

PARTITION volume8 VALUES IN('V-01-008'),

PARTITION volume9 VALUES IN('V-01-009'),

PARTITION volume10 VALUES IN('V-01-010')

.......(创建分区表)

)

在一些实施例中，对映射表中的所有操作均封装为事务性存储过程。将针对节点映射表和空间映射表的操作(如节点的增删改查)通过存储过程实现，并结合事务管理(Transaction)来保证操作一致性和完整性。存储过程封装的部分节点操作如下表1。

表1

结合表1和图4，整个存储过程调用由存储工程p_css_file_XX、函数f_css_file_XX和函数f_css_inode_XX。需要说明的是，XX可以替换为相应的节点操作。

其中，存储工程p_css_file_XX负责节点创建的会话管理、事务管理以及遵循统一的标准和流程。作为整个节点创建流程的起点，它可能调用后续的函数来执行具体的任务。

函数f_css_file_XX在存储工程p_css_file_XX之后被调用。负责将节点路径解析到具体的节点，即确定节点在存储系统中的具体位置。

函数ff_css_inode_XX：在路径解析完成后被调用。负责执行具体的节点操作，即在这个例子中是添加代表节点的节点到存储系统中。

这种设计体现了模块化编程的思想，将不同的职责封装到不同的存储工程和函数中。存储工程p_css_file_XX作为整个流程的起点和协调者，负责会话和事务管理，确保操作的一致性和可靠性。函数f_css_file_XX和f_css_inode_XX则分别负责路径解析和节点操作的具体实现，使得每个部分都可以独立开发和维护，提高了代码的可读性和可维护性。

综上所述，存储工程p_css_file_XX及其相关的函数共同构成了节点创建流程的一个完整封装，每个部分都承担着特定的职责，共同协作以完成节点创建的任务。

在一些实施例中，从根节点开始，逐层访问，在搜索每一层的子节点过程中，确定文件路径中该层对应的名称，依次搜索该层子节点，直至搜索到与该名称对应的子节点停止。再以该子节点为起点，确定该子节点对应的下一层子节点，以此类推，直至搜索到文件节点，根据文件节点得到第一文件的物理地址。

在另一些实施例中，还可以基于索引辅助搜索方式，得到第一文件的物理地址。可选地，通过构建索引结构(如B树、B+树或哈希表等)，将节点映射表中的路径或节点标识(如文件路径、目录名、唯一ID等)与对应的物理存储地址关联起来。在搜索时，通过索引快速定位文件节点，避免逐层遍历整个节点映射表，从而显著提升查询效率。

作为一个示例，使用B+树优化：为每个目录创建一个B+树，键值是文件名，值是文件的元数据(比如路径)。例如，查找/Drive1/user1/file1.txt时，直接在/Drive/user1的B+树中查找file1.txt，从而快速定位到文件节点。

205、根据物理地址访问第一文件，并对第一文件执行操作类型对应的操作。

可选的，若操作类型为读取，则将第一文件传输至客户端。

可选的，若操作类型为写入，则文件信息中包括第一文件的写入内容，利用该写入内容更新第一文件，更新后的第一文件的内容为该写入内容。

可选地，操作类型为修改，文件信息包括修改内容，对第一文件执行操作类型对应的操作，包括：根据修改内容，定位第一文件中待修改行；若待修改行未锁定，则在待修改行中添加行锁，并利用修改内容对待修改行中的内容进行修改；若待修改行已锁定，则等待待修改行解锁后，在待修改行中添加行锁，并基于修改内容对待修改行执行修改操作。

在一些实施例中，基于修改内容对第一文件执行修改操作可以包括以下步骤：

步骤1、定位待修改行，系统通过查询数据库表(例如节点表)来定位待修改行。

其中，查询条件通常包括：文件路径或目录层级信息(如Volume,FID,Name)。其他唯一标识符(如OID)。查询结果返回待修改行的主键或其他相关信息，用于后续操作。

步骤2、检查行是否已锁定，如果行未被锁定，则继续下一步。如果行已被锁定(例如另一个进程正在修改该行)，当前进程进入等待状态。

需要说明的是，等待机制通常是阻塞式的，直到待修改行解锁后，当前进程才能继续。

步骤3、当前进程获取待修改行的排他锁(ExclusiveLock)，确保在修改过程中不会有其他进程干扰。

其中，排他锁能够禁止其他进程读取或修改。

步骤4、在获取行锁后，根据提供的修改内容更新待修改行。修改操作完成后，系统将更新后的数据写回数据库。

可选的，修改内容可以包括：更新文件元数据(如文件名、大小、权限等)、修改文件路径或目录层级关系。

步骤5、当前进程完成提交或回滚后，自动释放行锁。如果进程成功提交，修改生效。如果进程失败回滚，则修改被撤销，待修改行恢复到原始状态。释放行锁后，其他等待的进程可以继续尝试获取锁并执行操作。

本实施例中，针对现有技术中的对象存储在云平台环境中因无序键值对特性导致的逻辑层次数据组织难题，本方案通过构建树状节点映射表与层级搜索机制，实现了云环境下复杂逻辑结构数据的高效管理与操作。具体而言，本方案将云存储中文件的元数据组织为树状结构，每个节点对应文件或目录的元数据，并通过父子节点关系体现层级逻辑，从而突破了传统对象存储在云平台中缺乏目录层级支持的局限。同时，通过文件路径快速解析节点映射表，实现物理地址的精准定位，避免了传统对象存储依赖全局扫描或外部元数据库的低效操作，有效降低了云平台中大规模数据访问的延迟。

通过本申请显著提升了云平台环境下数据访问与操作性能，并增强了系统的可扩展性与维护性，支持动态增删节点与模块化功能扩展，适配云平台弹性伸缩的特性。此外，还能够无缝对接现有云对象存储系统(如AWS S3、Azure Blob Storage、Google CloudStorage等)，通过细粒度权限控制和跨层级关联查询，满足云环境中文档管理、多媒体资源库、物联网数据流等复杂场景的需求，为需要管理逻辑层次数据的云业务提供了高效、灵活且可靠的解决方案。

在本申请其中的一个实施例中，前述的步骤204包括：将根节点作为当前父节点，在节点映射表中匹配属于当前父节点的子节点中，匹配与文件路径下一层级对应的目标子节点；若文件路径下一层级表征文件路径中的目录，则将目标子节点更新为当前父节点，重新执行在节点映射表中属于当前父节点的子节点中，匹配与文件路径下一层级对应的目标子节点及之后的步骤；若文件路径下一层级表征文件，且目标子节点无指向的下一级节点，则根据目标子节点得到物理地址。

作为一个示例，假设我们需要找到Volume_1/home/user/documents/report.docx这个文件的位置，可以按照以下步骤进行：

查找Volume_1下的根节点/(OID＝10000001)。

根据FID＝10000001找到子节点home(OID＝10000002)。

根据FID＝10000002找到子节点user(OID＝10000003)。

根据FID＝10000003找到子节点documents(OID＝10000004)。

最后根据FID＝10000004和文件名report.docx找到文件节点report.docx(OID＝10000005)。

本实施例中，通过节点映射表与递归解析的深度融合，构建了一套抽象路径到物理地址的映射机制，节点映射表作为抽象逻辑层，独立于底层存储实现，屏蔽文件系统差异，支持云平台的动态路径解析；递归逻辑通过逐层匹配路径层级并自动切换父节点，将复杂路径解析分解为可复用的子问题，避免硬编码层级关系，简化遍历逻辑。提升了系统的扩展性和灵活性，能够处理大规模、多层次的文件元数据，适应复杂的存储需求。支持文件系统的动态变化和高效管理，确保系统可以在不同规模的环境下平稳运行。

在本申请其中的一个实施例中，根据文件路径，确定第一分区表中第一文件对应的节点映射表之前，还包括：获取空间映射表，空间映射表包括虚拟存储单元的标识与物理存储单元的标识之间的映射关系、物理存储单元的标识与分区表的分区标识之间的映射关系。

根据文件路径，确定第一分区表中第一文件对应的节点映射表，包括：根据文件路径和空间映射表，确定第一分区表中第一文件对应的节点映射表。

应理解地，空间映射表用于管理虚拟存储单元和物理存储单元之间映射关系的数据结构。能够实现虚拟存储与物理存储之间的解耦，同时支持灵活的分区管理和动态调整，从而提升存储系统的性能、可靠性和可管理性。

可选地，可以采用手动配置空间映射表。在文件系统初始化或创建Drive时，管理员可以明确指定每个Drive映射到哪个Volume。这种配置通常保存在系统的元数据存储中(如数据库或配置文件)。例如，创建Drive_A时，管理员指定它映射到Volume_1。创建Drive_B时，管理员指定它映射到Volume_2。

可选地，可以采用自动分配策略配置空间映射表。Drive和Volume的映射关系可以根据预定义的规则自动分配。例如：根据存储容量：将新创建的Drive分配到剩余空间最多的Volume。根据性能需求(如数据访问速度和延迟)：将需要高性能的Drive分配到固态硬盘(Solid State Drive，SSD)支持的Volume。根据负载均衡：将新Drive分配到当前负载较低的Volume。

可选地，可以采用动态调整策略配置空间映射表。例如，若某个Volume的存储空间不足，系统可以将部分Drive的数据迁移到其他Volume。迁移完成后，更新映射关系表示以指示新的存储位置。

需要说明的是，关于空间映射表的实施例可以参照前述步骤202中的相关说明，此处不再赘述。

在一些实施例中，空间映射表的配置代码如下：

CREATE TABLE`t_b_drive_metadata`(

`drive`varchar(64)COMMENT'空间名称',

`volume`char(8)COMMENT'空间存储卷',

`uuid`bigint NOT NULL COMMENT'唯一标识符',

`capacity`bigint NOT NULL DEFAULT'0'COMMENT'空间容量(字节)',

`usage_size`bigint NOT NULL DEFAULT'0'COMMENT'已使用总大小(字节)',

......

`lock_status`tinyint NOT NULL DEFAULT'0'COMMENT'锁状态:0-未加锁,1-被上锁(只读状态)',

`delete_at`datetime DEFAULT NULL COMMENT'删除时间',

`delete_status`tinyint DEFAULT'0'COMMENT'删除状态:0-未删除,1-已删除',

PRIMARY KEY(`drive`)USING BTREE,

KEY`account_inx`(`account_id`)USING BTREE,

KEY`refresh_status_inx`(`refresh_status`)

)ENGINE＝InnoDB COMMENT＝'云空间信息'；

在本申请其中的一个实施例中，根据文件路径，确定第一分区表中第一文件对应的节点映射表，包括：提取文件路径中的根目录；在空间映射表中，匹配得到根目录对应的分区标识；根目录为虚拟存储单元的标识，在分区标识所指示的第一分区表中，查询得到根目录对应的节点映射表。

本实施例中，首先，从文件路径中提取根目录。随后，借助空间映射表这一关键数据结构，匹配出根目录对应的分区标识。该映射表通过构建虚拟存储单元标识与物理存储单元标识、物理存储单元标识与分区表分区标识之间的关联，实现了多层级、复杂存储结构的统一管理与映射；最终，依据匹配得到的分区标识，在对应的第一分区表中迅速查询到根目录对应的节点映射表。不仅提高了数据查询的效率与准确性，还显著增强了存储管理的灵活性与可扩展性，为云平台这类大规模、复杂存储系统的有效管理提供了有力支撑。

在本申请其中一种可能的实现方式中，鉴于存储需求不断攀升，以及为达成存储资源的均衡利用这一实际目标，本申请通过节点映射表的自动迁移与动态扩展机制来解决上述问题，因此，参照图5，该方法还包括：若第一分区表中节点映射表的数量大于或等于第一阈值，则在至少一个分区表中查找是否存在第二分区表；第二分区表的内存占用量小于第一阈值。

若存在，则将第一分区表中第一数量的节点映射表，迁移至第二分区表中；第一数量小于或等于第一阈值与第二分区表中节点映射表的数量之间的差值。在迁移完成后，更新空间映射表；其中，更新后的空间映射表中，迁移的节点映射表对应的物理存储单元的标识指向第二分区表；空间映射表包括虚拟存储单元的标识与物理存储单元的标识之间的映射关系、物理存储单元的标识与分区表的分区标识之间的映射关系。

若不存在，则创建新的分区表，并将第一分区表中第二数量的节点映射表，迁移至新的分区表，第二数量小于或等于第一阈值。迁移完成后，更新空间映射表；其中，更新后的空间映射表中，迁移的节点映射表对应的物理存储单元的标识指向新的分区表。

在一些实施例中，第一分区表和上述的至少一个分区表可以属于同一MySQL数据库。云平台的FS可以管理多个MySQL数据库，一个MySQL数据库包括多个分区表。

可以理解的是，第一阈值为数量阈值，对应判断一个分区表中存储的节点映射表的数量。

可选的，物理存储单元可以是逻辑卷/物理卷/云存储桶。

可选地，监测各分区表的内存占用量，当第一分区表的内存占用量大于或等于第一阈值时，从所述至少一个分区表中筛选满足以下条件的第二分区表：小于第一阈值或/和与第一分区表具有数据关联关系。

在实际应用中，若筛选出的第二分区表为多个的情况下，优先选择内存占用量最小的第二分区表，将第一分区表中第一数量的节点映射表迁移至该第二分区表中。

在一些实施例中，若第一数量的节点映射表迁移至第二分区表后，第一分区表的内存占用量依然大于或等于第一阈值。则确定是否存在其他第二分区表，若存在，则将第一分区表中第一数量的节点映射表，迁移至第二分区表中。若不存在，则创建新的分区表，并将第一分区表中第二数量的节点映射表，迁移至新的分区表。

参照图6，在实际应用场景中，若存储需求出现增长，可通过在同一MySQL数据库(即集群cluster)中新增Volume分区表(也即MySQL分区表)的方式来扩充存储容量。在新增Drive时，文件系统FS会优先将其分配至新创建的Volume分区表，以此有效分散存储压力或者将节点映射表数量较多的MySQL分区表中的部分或全部采用上述图5中的方式迁移至新创建的Volume分区表。例如，图6中假设cluster1中的MySQL2为新创建的Volume分区表，将cluster1的MySQL1中的部分或全部节点映射表迁移至MySQL2中。需要明确的是，Volume在本质上与分区表一一对应关系，这些概念均存在于同一个MySQL数据库中。然而，MySQL数据库对其支持的分区表数量存在一定限制，并且单个数据库的运行能力也较为有限。为突破这些限制，采用横向扩展的设计思路，借助多个数据库来共同承载多个MySQL分区表，即当一个MySQL数据库中内存占用量已超出负荷，则可以通过重新建立一个新的MySQL数据库，来实现存储能力的进一步拓展。例如，图6中的cluster1～cluster m-1的内存均已占满，则可以通过创建cluster m来扩充数据存储容量。通过文件系统的动态调整分区表数量以及数据库数量的能力，无需对数据库结构进行重建，极大地提高了扩展的便捷性和灵活性。采用分布式存储架构，不同Volume分区表能够灵活地分布在不同的数据库实例或存储节点上，真正实现了横向扩展。同时，系统借助分布式查询技术对数据访问进行优化，有效避免了集中访问单一节点可能导致的性能瓶颈，确保了系统的高效稳定运行。

在一种可能的实现方式中，针对已创建的各数据库，若各数据库的内存占用量大于或等于各数据对应的第二阈值，则创建新的数据库，并在新的数据库中创建新的分区表。这样，可以将新的文件存储在新的数据库中，将该文件对应的节点映射表存储于该新的分区表，并根据文件对应节点映射表更新该分区表中的分区映射表。

其中，上述数据库均为MySQL数据库。

可以理解的是，第二阈值对应的是数据库的内存占用量的阈值，用于衡量数据库的内存占用量是否已超出负荷。需要说明的是，不同的数据库对应的第二阈值可以相同，也可以不同，具体根据数据库的数据内存确定，本申请实施例对此不作限定。

本实施例中，当第一分区表的内存占用量达到或超过第一阈值时，系统通过将内存占用较低的分区表作为迁移目标，合理分配内存资源，使得各个分区表的内存使用更加均衡。避免了部分分区表内存闲置而其他分区表内存紧张的情况，提高了整个存储系统的内存资源利用效率，降低了硬件成本。有效防止了单个分区表因内存过载而导致的性能下降甚至系统崩溃，确保了存储系统的稳定运行。

另外，当现有的分区表的内存占用量均达到或超过第一阈值时，导致无可迁移的分区表时，可以通过新增分区表的方式，实现资源均衡的目的。

在其中一种实现方式中，利用雪花算法对节点生成的时间戳、节点类型及自增序列号进行组合，生成节点映射表中各节点的标识。

其中，节点的标识可以包括元数据时间戳字段、节点类型字段欧空自增序列号字段。元数据时间戳字段用于记录节点创建的系统时间；节点类型字段用于区分文件节点与目录节点；自增序列号字段，用于区分同一时间戳下生成的多个节点。

需要说明的是，本申请实施例中与前述实施例中相同步骤和相同内容的说明，可以参照前述实施例中的描述，此处不再赘述。

应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

对应于上文实施例所述的数据访问方法，图7示出了本申请实施例提供的数据管理装置的结构框图，为了便于说明，仅示出了与本申请实施例相关的部分。

参照图7，数据管理装置包括：接收模块701、处理模块702、搜索模块703，其中，

接收模块701，用于接收来自第一客户端上传的第一文件的操作请求，操作请求携带对第一文件的操作类型以及文件信息，操作类型包括写入、修改和/或读取，文件信息包括文件标识。

处理模块702，用于根据文件标识，确定文件路径。

处理模块702，还用于根据文件路径，确定第一分区表中第一文件对应的节点映射表；节点映射表为文件树结构，节点映射表中的节点与第一文件的元数据一一对应。

搜索模块703，用于以节点映射表中的根节点为搜索起点，按照文件路径的层级关系，在节点映射表中逐层搜索，得到物理地址。

处理模块702，还用于根据物理地址访问第一文件，并对第一文件执行操作类型对应的操作。

在本申请其中的一个实施例中，搜索模块703，具体用于，

将根节点作为当前父节点，在节点映射表中匹配属于当前父节点的子节点中，匹配与文件路径下一层级对应的目标子节点。

若文件路径下一层级表征文件路径中的目录，则将目标子节点更新为当前父节点，重新执行在节点映射表中属于当前父节点的子节点中，匹配与文件路径下一层级对应的目标子节点及之后的步骤。

若文件路径下一层级表征文件，且目标子节点无指向的下一级节点，则根据目标子节点得到物理地址。

在本申请其中的一个实施例中，处理模块702，还用于，

获取空间映射表，空间映射表包括虚拟存储单元的标识与物理存储单元的标识之间的映射关系、物理存储单元的标识与分区表的分区标识之间的映射关系。

根据文件路径和空间映射表，确定第一分区表中第一文件对应的节点映射表。

在本申请其中的一个实施例中，操作类型为修改，处理模块702，具体用于，

根据修改内容，定位第一文件中待修改行。

若待修改行未锁定，则在待修改行中添加行锁，并利用修改内容对待修改行中的内容进行修改。

若待修改行已锁定，则等待待修改行解锁后，在待修改行中添加行锁，并基于修改内容对待修改行执行修改操作。

在本申请其中的一个实施例中，处理模块702，具体用于，

提取文件路径中的根目录。

在空间映射表中，匹配得到根目录对应的分区标识；根目录为虚拟存储单元的标识，空间映射表包括虚拟存储单元的标识与物理存储单元的标识之间的映射关系、物理存储单元的标识与分区表的分区标识之间的映射关系。

在分区标识所指示的第一分区表中，查询得到根目录对应的节点映射表。

在本申请其中的一个实施例中，处理模块702，还用于，

若第一分区表中节点映射表的数量大于或等于第一阈值，则在至少一个分区表中查找是否存在第二分区表；第二分区表的内存占用量小于第一阈值。

若存在，则将第一分区表中第一数量的节点映射表，迁移至第二分区表中；第一数量小于或等于第一阈值与第二分区表中节点映射表的数量之间的差值。

迁移完成后，更新空间映射表；其中，更新后的空间映射表中，迁移的节点映射表对应的物理存储单元的标识指向第二分区表；空间映射表包括虚拟存储单元的标识与物理存储单元的标识之间的映射关系、物理存储单元的标识与分区表的分区标识之间的映射关系。

在本申请其中的一个实施例中，处理模块702，还用于若不存在，则创建新的分区表，并将第一分区表中第二数量的节点映射表，迁移至新的分区表，第二数量小于或等于第一阈值；迁移完成后，更新空间映射表；其中，更新后的空间映射表中，迁移的节点映射表对应的物理存储单元的标识指向新的分区表。

在本申请其中的一个实施例中，处理模块702，还用于利用雪花算法对节点生成的时间戳、节点类型及自增序列号进行组合，生成节点映射表中各节点的标识。

应当理解，数据管理模块中记载的诸单元与参考图2描述的方法中的各个步骤相对应。由此，上文针对方法描述的操作和特征同样适用于数据管理模块及其中包含的单元，在此不再赘述。数据管理模块可以预先实现在电子设备的浏览器或其他安全应用中，也可以通过下载等方式而加载到电子设备的浏览器或其安全应用中。数据管理模块中的相应单元可以与电子设备中的单元相互配合以实现本申请实施例的方案。

在上文详细描述中提及的若干模块或者单元，这种划分并非强制性的。实际上，根据本申请的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

需要说明的是，本申请实施例的数据管理模块中未披露的细节，请参照本申请上述实施例中所披露的细节，这里不再赘述。

下面参考图8，图8示出了适于用来实现本申请实施例的电子设备的结构示意图，如图8所示，电子设备800包括中央处理单元(CPU)801，其可以根据存储在只读存储器(ROM)802中的程序或者从存储部分808加载到随机访问存储器(RAM)803中的程序而执行各种适当的动作和处理。在RAM803中，还存储有电子设备的操作指令所需的各种程序和数据。CPU801、ROM802以及RAM803通过总线804彼此相连。输入/输出(I/O)接口805也连接至总线804。

以下部件连接至I/O接口805；包括键盘、鼠标等的输入部分806；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分807；包括硬盘等的存储部分808；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分809。通信部分809经由诸如因特网的网络执行通信处理。驱动器810也根据需要连接至I/O接口805。可拆卸介质811，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器810上，以便于从其上读出的计算机程序根据需要被安装入存储部分808。

特别地，根据本申请的实施例，上文参考流程图图2描述的过程可以被实现为计算机软件程序。例如，本申请的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分809从网络上被下载和安装，和/或从可拆卸介质811被安装。在该计算机程序被中央处理单元(CPU)801执行时，执行本申请的电子设备中限定的上述功能。

需要说明的是，本申请所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行电子设备、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以为的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作指令。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，前述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以不同于附图中所标注的顺序发生。例如，两个连接表示的方框实际上可以基本并行地执行，他们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作指令的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本申请实施例中所涉及到的单元或模块可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的单元或模块也可以设置在处理器中，例如，可以描述为：一种处理器包括获取模块、合并模块以及传输模块。其中，这些单元或模块的名称在某种情况下并不构成对该单元或模块本身的限定。

作为另一方面，本申请还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中描述的电子设备中所包含的，也可以是单独存在，而未装配入该电子设备中的。上述计算机可读存储介质存储有一个或多个程序，当上述程序被一个或者一个以上的处理器用来执行本申请所述的数据管理方法。例如，可以执行图2所示的数据管理方法的各个步骤。

本申请实施例提供一种计算机程序产品，该计算机程序产品包括指令，当该指令被运行时，使得如本申请实施例描述的方法被执行。例如，可以执行图2所示的数据管理方法的各个步骤。

以上描述仅为本申请的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解，本申请中所涉及的公开范围，并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在不脱离前述公开构思的情况下，由上述技术特征或其等同特征进行任意组合而形成的其他技术方案。例如上述特征与本申请中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。

Claims (10)

1.一种数据管理方法，其特征在于，应用于云平台，所述方法包括：

接收来自第一客户端上传的第一文件的操作请求，所述操作请求携带对第一文件的操作类型以及文件信息，所述操作类型包括写入、修改和/或读取，所述文件信息包括文件标识；

根据所述文件标识，确定文件路径；

根据所述文件路径，确定第一分区表中所述第一文件对应的节点映射表；所述节点映射表为文件树结构，所述节点映射表中的节点与所述第一文件的元数据一一对应；

以所述节点映射表中的根节点为搜索起点，按照所述文件路径的层级关系，在所述节点映射表中逐层搜索，得到物理地址；

根据所述物理地址访问所述第一文件，并对所述第一文件执行所述操作类型对应的操作。

2.根据权利要求1所述的数据管理方法，其特征在于，所述以所述节点映射表中的根节点为搜索起点，按照所述文件路径的层级关系，在所述节点映射表中逐层搜索，得到物理地址，包括：

将所述根节点作为当前父节点，在所述节点映射表中匹配属于所述当前父节点的子节点中，匹配与所述文件路径下一层级对应的目标子节点；

若所述文件路径下一层级表征所述文件路径中的目录，则将所述目标子节点更新为当前父节点，重新执行在所述节点映射表中属于所述当前父节点的子节点中，匹配与所述文件路径下一层级对应的目标子节点及之后的步骤；

若所述文件路径下一层级表征文件，且所述目标子节点无指向的下一级节点，则根据所述目标子节点得到所述物理地址。

3.根据权利要求1或2所述的数据管理方法，其特征在于，所述根据所述文件路径，确定第一分区表中所述第一文件对应的节点映射表之前，还包括：

获取空间映射表，所述空间映射表包括虚拟存储单元的标识与物理存储单元的标识之间的映射关系、所述物理存储单元的标识与分区表的分区标识之间的映射关系；

所述根据所述文件路径，确定第一分区表中所述第一文件对应的节点映射表，包括：

根据所述文件路径和所述空间映射表，确定第一分区表中所述第一文件对应的节点映射表。

4.根据权利要求3所述的数据管理方法，其特征在于，所述根据所述文件路径，确定第一分区表中所述第一文件对应的节点映射表，包括：

提取所述文件路径中的根目录；

在所述空间映射表中，匹配得到所述根目录对应的分区标识；所述根目录为所述虚拟存储单元的标识；

在所述分区标识所指的第一分区表中，查询得到所述根目录对应的所述节点映射表。

5.根据权利要求3所述的数据管理方法，其特征在于，所述方法还包括：

若所述第一分区表中节点映射表的数量大于或等于第一阈值，则在至少一个分区表中查找是否存在第二分区表；所述第二分区表的内存占用量小于所述第一阈值；

若存在，则将所述第一分区表中第一数量的节点映射表，迁移至所述第二分区表中；所述第一数量小于或等于所述第一阈值与所述第二分区表中节点映射表的数量之间的差值；

迁移完成后，更新空间映射表；其中，更新后的空间映射表中，迁移的节点映射表对应的物理存储单元的标识指向所述第二分区表；所述空间映射表包括所述虚拟存储单元的标识与物理存储单元的标识之间的映射关系、所述物理存储单元的标识与分区表的分区标识之间的映射关系。

6.根据权利要求5所述的数据管理方法，其特征在于，所述方法还包括：

若不存在，则创建新的分区表，并将所述第一分区表中第二数量的节点映射表，迁移至所述新的分区表，所述第二数量小于或等于所述第一阈值；

迁移完成后，更新所述空间映射表；其中，更新后的空间映射表中，迁移的节点映射表对应的物理存储单元的标识指向所述新的分区表。

7.根据权利要求1或2所述的数据管理方法，其特征在于，所述操作类型为修改，所述文件信息包括修改内容，所述对所述第一文件执行所述操作类型对应的操作，包括：

根据所述修改内容，定位所述第一文件中待修改行；

若所述待修改行未锁定，则在所述待修改行中添加行锁，并利用所述修改内容对所述待修改行中的内容进行修改；

若所述待修改行已锁定，则等待所述待修改行解锁后，在所述待修改行中添加行锁，并基于所述修改内容对所述待修改行执行修改操作。

8.根据权利要求1或2任一项所述的数据管理方法，其特征在于，所述方法还包括：

利用雪花算法对节点生成的时间戳、节点类型及自增序列号进行组合，生成所述节点映射表中各节点的标识。

9.一种数据管理装置，其特征在于，包括：

接收模块，用于接收来自第一客户端上传的第一文件的操作请求，所述操作请求携带对第一文件的操作类型以及文件信息，所述操作类型包括写入、修改和/或读取，所述文件信息包括文件标识；

处理模块，用于根据所述文件标识，确定文件路径；

所述处理模块，还用于根据所述文件路径，确定第一分区表中所述第一文件对应的节点映射表；所述节点映射表为文件树结构，所述节点映射表中的节点与所述第一文件的元数据一一对应；

搜索模块，用于以所述节点映射表中的根节点为搜索起点，按照所述文件路径的层级关系，在所述节点映射表中逐层搜索，得到物理地址；

所述处理模块，还用于根据所述物理地址访问所述第一文件，并对所述第一文件执行所述操作类型对应的操作。

10.一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序/指令，当计算机程序/指令在电子设备上运行时，使得所述电子设备执行上述权利要求1-8任一项所述的方法。