Metadata storage method and device, metadata query method and device

Abstract

Embodiments of the present specification provide a metadata storage method and apparatus, and a metadata query method and apparatus. The metadata storage method, applied to a metadata server, includes: receiving a data storage request for metadata to be stored that carries an object identifier; determining, upon determining that a version control function is enabled and that the metadata to be stored does not carry a deletion mark, an updated version metadata table corresponding to the metadata to be stored; and, upon determining, based on the object identifier, that historically stored metadata carrying the object identifier exists in the updated version metadata table, and that the historically stored metadata carries an empty version mark, moving the historically stored metadata from the updated version metadata table to a historical empty version metadata table, and storing the metadata to be stored that carries the object identifier in the updated version metadata table, so that corresponding metadata can be directly indexed from metadata tables of different versions in the future.

Description

Technical Field

[0001] The embodiments of this specification relate to the field of computer technology, and in particular to a metadata storage method and a metadata query method. Background Art

[0002] With the development of informatization, the scale of metadata in metadata management systems is getting larger and larger. The metadata server (MDS) can enable the version control function to help users prevent accidental overwriting and deletion. After the version control function is enabled, each object can retain multiple versions, including the latest version and several historical versions of metadata. Since metadata introduces multiple versions, that is, the primary key extends the object version number, then, in the scenario where the user queries the latest version of metadata for a certain object identifier, it is necessary to compare the version numbers in the primary keys of each object to finally determine the metadata corresponding to the latest version. In this way, in the scenario with a large number of versions, the server not only consumes a lot of computing resources to index the latest version of metadata, but also makes the indexing speed slow and the resource overhead high. Summary of the Invention

[0003] In light of this, embodiments of this specification provide a metadata storage method. One or more embodiments of this specification also include a metadata query method, a metadata storage device, a metadata query device, a computing device, a computer-readable storage medium, and a computer program to address technical deficiencies in the prior art.

[0004] According to a first aspect of an embodiment of this specification, a metadata storage method is provided, which is applied to a metadata server, including:

[0005] receiving a data storage request for metadata to be stored that carries an object identifier;

[0006] If it is determined that the version control function is enabled and the metadata to be stored does not carry a deletion mark, determining an updated version metadata table corresponding to the metadata to be stored;

[0007] Based on the object identifier in the updated version metadata table, it is determined that there is historical storage metadata carrying the object identifier, and

[0008] When the historical stored metadata contains an empty version mark, the historical stored metadata is moved from the updated version metadata table to the historical empty version metadata table, and the metadata to be stored carrying the object identifier is stored in the updated version metadata table.

[0009] According to a second aspect of an embodiment of this specification, a metadata query method is provided, which is applied to a metadata server, including:

[0010] receiving a metadata query request, wherein the metadata query request carries version information;

[0011] Based on the version information, determining a target metadata storage table from at least two version tables storing metadata, and determining metadata that satisfies the metadata query request from the target metadata storage table;

[0012] The at least two version tables include an updated version metadata table and a historical empty version metadata table.

[0013] According to a third aspect of an embodiment of this specification, a metadata storage device is provided, which is applied to a metadata server, including:

[0014] a request receiving module configured to receive a data storage request for metadata to be stored that carries an object identifier;

[0015] a metadata table determination module configured to, when it is determined that the version control function is enabled and the metadata to be stored does not carry a deletion mark, determine an updated version metadata table corresponding to the metadata to be stored;

[0016] The metadata mobile storage module is configured to determine whether there is historical storage metadata carrying the object identifier in the updated version metadata table based on the object identifier, and

[0017] When the historical stored metadata contains an empty version mark, the historical stored metadata is moved from the updated version metadata table to the historical empty version metadata table, and the metadata to be stored carrying the object identifier is stored in the updated version metadata table.

[0018] According to a fourth aspect of the embodiments of this specification, a metadata query device is provided, which is applied to a metadata server, including:

[0019] a request receiving module, configured to receive a metadata query request, wherein the metadata query request carries version information;

[0020] a data query module configured to determine, based on the version information, a target metadata storage table from at least two version tables storing metadata, and determine metadata that satisfies the metadata query request from the target metadata storage table;

[0021] The at least two version tables include an updated version metadata table and a historical empty version metadata table.

[0022] According to a fifth aspect of the embodiments of this specification, there is provided a computing device, including:

[0023] memory and processor;

[0024] The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions. When the computer-executable instructions are executed by the processor, the steps of the above method are implemented.

[0025] According to a sixth aspect of the embodiments of this specification, a computer-readable storage medium is provided, which stores computer-executable instructions, and when the instructions are executed by a processor, the steps of the above method are implemented.

[0026] According to a seventh aspect of the embodiments of this specification, a computer program is provided, wherein when the computer program is executed in a computer, the computer is caused to execute the steps of the above method.

[0027] One embodiment of the present specification provides a metadata storage method, which is applied to a metadata server, including: receiving a data storage request for metadata to be stored that carries an object identifier; determining an updated version metadata table corresponding to the metadata to be stored when it is determined that a version control function is enabled and the metadata to be stored does not carry a deletion mark; and if it is determined in the updated version metadata table based on the object identifier that historical stored metadata carrying the object identifier exists and the historical stored metadata carries an empty version mark, moving the historical stored metadata from the updated version metadata table to a historical empty version metadata table, and storing the metadata to be stored that carries the object identifier in the updated version metadata table.

[0028] Specifically, when the version control function is turned on, it is determined whether the metadata to be stored carries a deletion mark, and then the updated version metadata table corresponding to the metadata to be stored is determined, and the historical storage metadata originally stored in the updated version metadata table is moved to other metadata tables, so that the metadata to be stored can be directly stored in the updated version metadata table; this method does not directly extend the primary key of the metadata table with the version number in the same key-value table to manage the metadata, but uses a metadata storage table constructed by multiple key-value tables to store different types of metadata in different metadata tables for management. In this way, in the metadata indexing scenario, the corresponding metadata can be directly indexed from different versions of the metadata tables, which not only improves the indexing speed, but also avoids the server's comparison process of each version number and saves resource overhead. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] Figure 1 This is a system architecture diagram of a metadata storage method provided by an embodiment of this specification;

[0030] Figure 2This is a flowchart of a metadata storage method provided by one embodiment of this specification;

[0031] Figure 3 This is a schematic diagram of a metadata storage method provided by an embodiment of this specification for storing metadata in multiple different metadata storage tables;

[0032] Figure 4 This is a schematic diagram of the structure of a metadata storage device provided by one embodiment of this specification;

[0033] Figure 5 This is a flowchart of a metadata query method provided by one embodiment of this specification;

[0034] Figure 6 This is a schematic diagram of the structure of a metadata query device provided by an embodiment of this specification;

[0035] Figure 7 This is a structural block diagram of a computing device provided by one embodiment of this specification. DETAILED DESCRIPTION

[0036] The following description sets forth many specific details to facilitate a thorough understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar generalizations without violating the scope of this specification. Therefore, this specification is not limited to the specific implementations disclosed below.

[0037] The terms used in one or more embodiments of this specification are for the purpose of describing specific embodiments only and are not intended to limit one or more embodiments of this specification. The singular forms "a," "the," and "the" used in one or more embodiments of this specification and the appended claims are also intended to include plural forms unless the context clearly indicates otherwise. It should also be understood that the term "and / or" used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

[0038] It should be understood that although the terms first, second, etc. may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of one or more embodiments of this specification, the first may also be referred to as the second, and similarly, the second may also be referred to as the first. Depending on the context, the word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining".

[0039] First, the terms involved in one or more embodiments of this specification are explained.

[0040] Cloud Object Storage (COS): is a distributed storage service for storing massive files, with the advantages of high scalability, low cost, reliability and security.

[0041] Version control: A data protection feature of object storage that retains multiple versions of each object to prevent users from accidentally overwriting or deleting it.

[0042] Delete marker: A placeholder created when versioning is enabled. When the latest version of an object is a delete marker, the object is considered deleted, and any access to the latest version of the object will be treated as if the object does not exist.

[0043] Empty version: The version written before version control is enabled or when it is paused. Each object has at most one empty version. Empty versions of the same object will overwrite each other.

[0044] Metadata Server (MDS): The MDS provides metadata to clients, primarily a logical view of files, including the organizational relationships between files and directories, and the OSD corresponding to each file. The MDS also supports client caches. When cached files change, it notifies the client to refresh the cache, thus avoiding issues caused by cache inconsistencies.

[0045] Object storage client (Client): The object storage client includes some special tools and interfaces on the computing node, which are used to access the object storage system in turn, such as the command line.

[0046] Object Storage Service (OSS): OSS is an intermediary service for interaction between clients and OSDs. The object storage service is responsible for collecting information fed back by OSDs, authenticating clients through file locks, AccessKeys, and other methods, and controlling their read and write capabilities.

[0047] Versioning is a key feature in object storage, helping users prevent accidental overwrites and deletions. With versioning enabled, each object can retain multiple versions, including the latest version and several historical versions. Object storage metadata is stored in a distributed key-value table on the backend. With versioning enabled, the primary key is extended with the object version number. Accessing the latest version or empty versions can lead to performance issues due to incomplete primary key mappings. For buckets without versioning, the primary key is the object ID; for buckets with versioning, the primary key must include both the object ID and the object version number. Furthermore, when users can access metadata for the latest version or empty versions, they no longer directly access the primary key. For example, reading the latest version of an object becomes a list operation, which increases request latency and machine resource overhead compared to a point-based query based on the primary key. Furthermore, due to the introduction of delete markers in versioning, listing the latest version requires skipping delete markers. This can also cause latency and overhead proportional to the number of delete markers, potentially preventing convergence, due to the presence of a large number of delete markers.

[0048] Based on this, the metadata storage method provided in the embodiments of this specification utilizes multiple key-value index tables to construct a logical index table for object metadata storage. This logical index table provides fast indexing of the latest version and any specified version, achieving nearly identical enumeration and reading performance to that achieved without version control. This addresses the efficiency issues associated with indexing the latest version and empty versions in scenarios using version control. Furthermore, the provided metadata query method provides an efficient way to quickly index the latest version and specified versions.

[0049] This specification provides a metadata storage method. This specification also relates to a metadata query method, a metadata storage device, a metadata query device, a computing device, a computer-readable storage medium, and a computer program, each of which is described in detail in the following embodiments.

[0050] See also Figure 1 , Figure 1 A system architecture diagram of a metadata storage method provided according to an embodiment of this specification is shown.

[0051] Figure 1 The system includes a client 102, a metadata server 104, and an object storage device 106. Specifically, the client 102 sends a metadata access request to the metadata server 104. When the metadata server 104 receives the metadata access request, it queries the corresponding metadata and updates it to the object storage device 106. At the same time, the client 102 can also send a data read and write request to the object storage device 106 to realize the storage and query of object data.

[0052] The metadata storage method provided in the embodiments of this specification can be applied to the above Figure 1 In the metadata server 104, in actual applications, when the metadata server receives a data storage request for metadata to be stored, it first determines whether the version control function is enabled. If it is enabled, it can determine whether the metadata to be stored carries a deletion mark. If it does not carry a deletion mark, it can be determined that the metadata to be stored should be stored in the updated version metadata table; at the same time, the metadata server also needs to determine in the updated version metadata table whether there is historical storage metadata with the same object identifier as the metadata to be stored, and further determine whether the historical storage metadata carries an empty version mark. If it carries an empty version mark, the historical storage metadata can be moved and stored in the historical empty version metadata table, and the metadata to be stored can be directly stored in the updated version metadata table.

[0053] Based on this, the metadata storage method provided in the embodiments of this specification can store the metadata to be stored in different metadata storage tables when the version control function in the metadata server is enabled to complete the management of the metadata, so as to facilitate the subsequent use of these different metadata storage tables to provide an efficient indexing method for quickly indexing the metadata in the metadata storage tables of each version.

[0054] See also Figure 2 , Figure 2 A flowchart of a metadata storage method provided according to an embodiment of this specification is shown, which specifically includes the following steps.

[0055] It should be noted that the metadata storage method provided in the embodiments of this specification is applied to a metadata server to manage metadata of different objects, support metadata storage of object storage, and access requirements related to version control.

[0056] Step 202: Receive a data storage request for metadata to be stored that carries an object identifier.

[0057] The metadata to be stored may be understood as metadata of a certain object that the user needs to store in the metadata server, for example, the object identifier ID=1 corresponds to metadata A.

[0058] In actual applications, a metadata server receives a data storage request, which includes metadata to be stored and an object identifier. In this application scenario, a user may perform multiple operations on the metadata of an object, including adding, deleting, and other operations. Therefore, the metadata of the same object may face multiple storage requests from the user. The metadata storage method provided in the embodiments of this specification is a metadata storage method that is faced with multiple storage request operations for metadata corresponding to the same object identifier.

[0059] Step 204: When it is determined that the version control function is enabled and the metadata to be stored does not carry a deletion mark, an updated version metadata table corresponding to the metadata to be stored is determined.

[0060] Version control can be understood as a data protection function for object storage. Each object can retain multiple versions to prevent users from accidentally overwriting or deleting them.

[0061] A delete marker can be thought of as a placeholder created when a user performs a delete operation after version control is enabled or disabled. Specifically, when the latest version of an object's metadata is marked with a delete marker, it indicates that the metadata corresponding to the object has been deleted, and access to the latest version of the object will be treated as if it does not exist.

[0062] The updated version metadata table can be understood as a storage table that stores the metadata of the latest version corresponding to each object identifier. The storage table is a key-value storage table, including object IDs and metadata.

[0063] In actual applications, when the metadata server determines that the version control function is turned on, it can be understood that the metadata under the same object identifier in the metadata server can store multiple versions to achieve data protection; at the same time, the metadata server can also determine whether there is a deletion mark in the metadata to be stored, that is, determine whether the metadata to be stored is a version that the user has confirmed to be deleted. If it is determined that the metadata to be stored does not have a deletion mark, then the metadata to be stored can be understood as the metadata of the current latest version in the object identifier, and the metadata to be stored should be stored in the latest version metadata table, that is, only the key-value table of the latest version of metadata under each object identifier is stored.

[0064] Step 206: Based on the object identifier in the updated version metadata table, if it is determined that there is historical storage metadata carrying the object identifier, and the historical storage metadata has an empty version mark, the historical storage metadata is moved from the updated version metadata table to the historical empty version metadata table, and the metadata to be stored carrying the object identifier is stored in the updated version metadata table.

[0065] Among them, historical storage metadata can be understood as metadata stored in the update version metadata table. When the metadata to be stored is written by the user, the metadata currently stored in the update version metadata table can be called historical storage metadata; for example, the metadata stored in the update version metadata table has a version number of 101. After the metadata with a version number of 102 is written by the user, the metadata of version 101 can be the historical storage metadata.

[0066] Among them, the empty version marker can be understood as the version written before the version control function is enabled or paused; it should be noted that each object has at most one empty version, and empty versions of the same object will overwrite each other.

[0067] Among them, the historical empty version metadata table can be understood as the metadata table written before the storage version function is enabled after the metadata storage is completed, or the metadata table of the version generated by the write operation when the version control function is suspended (it should be noted that the metadata generated by the above two writing methods can also be stored in the update version storage table or the update version deletion mark table during the storage process); it should be noted that since the metadata of the empty version has the overwriting function, in the historical empty version metadata table, there is only one metadata with the empty version mark corresponding to each object identifier.

[0068] In actual applications, the metadata server can also determine whether there is metadata corresponding to the object identifier in the updated version metadata table based on the object identifier corresponding to the metadata to be stored, that is, determine whether there is other versions of the metadata of the object identifier stored in the updated version metadata table; if so, the metadata of the object identifier already stored in the updated version metadata table can be regarded as historical storage metadata. Further, the attributes of the historical storage metadata can be judged. If the historical storage metadata contains an empty version mark, the historical storage metadata can be moved from the updated version metadata table to the historical empty version metadata table. Finally, the metadata to be stored is stored in the updated version metadata table, completing the storage process of the metadata to be stored.

[0069] For example, if the version number of the metadata to be stored is version 101, and the version number of the historically stored metadata stored in the updated version metadata table is version 100, then when the user writes the metadata of version 101, it is necessary to determine in the updated version metadata table whether there is an empty version mark in the metadata of version 100. If so, the metadata of version 100 can be moved to the historical empty version metadata table, and then the metadata of version 101 can be directly stored in the updated version metadata table. It should be noted that the reason why there is an empty version mark in version 100 may be that the version control function has not been enabled or is in the process of suspending the version control function. When version 101 is written, it does not carry an empty version mark, so when version 101 is written, the version control function has been enabled.

[0070] Furthermore, when storing the historically stored metadata in the historical empty version metadata table, it is necessary to determine whether metadata with the same object identifier as the historically stored metadata exists in the historical empty version metadata table. If so, an overwrite operation is performed to ensure that only one piece of metadata with an empty version mark exists for the same object identifier in the historical empty version metadata table. Specifically, moving the historically stored metadata from the updated version metadata table to the historical empty version metadata table includes:

[0071] In the historical empty version metadata table, if it is determined that there is historical empty version metadata with an empty version mark, deleting the historical empty version metadata;

[0072] The historical storage metadata is moved from the updated version metadata table to the historical empty version metadata table.

[0073] In actual applications, the metadata server can also first determine whether there is metadata with the same object identifier in the historical empty version metadata table, that is, whether there is historical empty version metadata with an empty version mark. If there is metadata with the same object identifier as the metadata to be stored, a deletion operation can be performed to delete the historical empty version metadata corresponding to the object identifier. Finally, the historical storage metadata is moved from the updated version metadata table to the historical empty version metadata table, completing the overwriting operation of the metadata with the empty version mark.

[0074] For example, the metadata stored in the historical empty version metadata table is the metadata of the object ID = 1, 100 version; when the version control function is suspended, the metadata of the object ID = 1, 105 version is written, then the metadata of the object ID = 1, 105 version is stored in the updated version metadata table, and the metadata of the object ID = 1, 100 version stored in the historical empty version metadata table is deleted. This process completes the overwriting operation of the metadata marked with the empty version of object ID = 1.

[0075] If the metadata of object ID=1, 106 version is subsequently written, since the metadata of version 106 is the latest version of metadata, the metadata of object ID=1, 106 version can be stored in the updated version metadata table. At the same time, the metadata of object ID=1, 105 version is deleted. This process also completes the overwriting operation of the empty version metadata of object ID=1, 105 version. It should be noted that the order of the deletion steps and the overwriting storage steps involved in the overwriting operation is not specifically limited.

[0076] The metadata storage method provided in the embodiments of this specification determines whether metadata of a version to be overwritten is stored in a historical empty version metadata table, and implements an overwriting operation on metadata with an empty version mark corresponding to the same object identifier through a deletion operation.

[0077] In addition, in the process of storing the metadata to be stored in the updated version metadata table, the metadata server may also determine the specific storage location of the metadata to be stored and store the metadata to be stored according to the storage location; specifically, storing the metadata to be stored carrying the object identifier in the updated version metadata table includes:

[0078] The storage location of the historically stored metadata in the updated version metadata table is determined, and the metadata to be stored carrying the object identifier is stored in the storage location in the updated version metadata table.

[0079] In actual applications, since the updated version metadata table stores the latest version of metadata under each object identifier and deletes the old version of metadata (historically stored metadata) from the updated version metadata table, the metadata server can also determine the storage location of the historically stored metadata in the updated version metadata table and store the latest version of the metadata to be stored directly in the storage location in the updated version metadata table.

[0080] The metadata storage method provided in the embodiments of this specification can directly store the metadata to be stored in the specific storage location by determining the specific storage location of the metadata to be stored, and also facilitates the management of metadata corresponding to all objects.

[0081] In another embodiment, when determining that the historically stored metadata is stored, the metadata server may also determine that the historically stored metadata does not have an empty version tag, that is, the system has enabled the version control function when writing the historically stored metadata. In this case, the metadata server may also move the metadata without the empty version tag to the historical non-empty version metadata table for storage. Specifically, after determining that the historically stored metadata carrying the object identifier exists in the updated version metadata table based on the object identifier, the method further includes:

[0082] If it is determined that the historical stored metadata does not carry an empty version mark, the historical stored metadata is moved from the updated version metadata table to the historical non-empty version metadata table, and the metadata to be stored carrying the object identifier is stored in the updated version metadata table.

[0083] The historical non-empty version metadata table can be understood as metadata that stores various historical versions under the same object identifier, and the metadata does not carry a deletion mark or an empty version mark.

[0084] In actual applications, when the metadata server determines that the historically stored metadata does not have an empty version mark, it can move the historically stored metadata from the updated version metadata table to the historical non-empty version metadata table, and then directly store the metadata to be stored in the updated version metadata table; it should be noted that the non-empty version metadata table may include multiple different versions of metadata with the same object identifier, and the number of versions of the metadata is related to the user's historical write times, which is not limited in this embodiment.

[0085] The metadata storage method provided in the embodiments of this specification can directly store metadata that does not contain an empty version mark and is not the latest version in the historical non-empty version metadata table, so as to classify and store different versions of metadata under the same object identifier in different metadata storage tables, which is convenient for subsequent rapid indexing.

[0086] Furthermore, in another embodiment, when the metadata server determines that the metadata to be stored has a deletion mark, it may further determine an updated version deletion mark table and store the metadata with the deletion mark. Specifically, after receiving the data storage request for the metadata to be stored carrying the object identifier, the method further includes:

[0087] If it is determined that the version control function is enabled and the metadata to be stored has a deletion mark, determining an updated version deletion mark table corresponding to the metadata to be stored;

[0088] If it is determined that there is historical deletion mark metadata carrying the object identifier in the updated version deletion mark table based on the object identifier, the historical deletion mark metadata is moved to the historical non-empty version metadata table;

[0089] The metadata to be stored that carries the object identifier is stored in the update version deletion mark table.

[0090] Among them, the updated version deletion mark table can be understood as the metadata storage table of the latest version corresponding to the storage object identifier, and the metadata of the latest version is marked with a deletion mark, that is, the metadata corresponding to the deletion operation performed by the user; it should be noted that since the version control function is enabled, after the user performs the deletion operation, a placeholder will be generated in the metadata, indicating that the metadata has been deleted.

[0091] In actual applications, after the metadata server determines that the version control function is turned on, if it determines that the metadata to be stored has a deletion mark, it can directly determine the updated version deletion mark table corresponding to the metadata to be stored, and store the metadata to be stored in the updated version deletion mark table; at the same time, the metadata server can also determine in the updated version deletion mark table whether there is metadata with the same object identifier as the metadata to be stored. If so, the historical deletion mark metadata can be moved to the historical non-empty version metadata table for continued storage.

[0092] It should be noted that after the metadata to be stored with a deletion mark is stored in the updated version deletion mark table, the metadata to be stored with a deletion mark is the latest version of the metadata. Therefore, in the updated version metadata table, the latest version of the metadata that has been stored needs to be moved to the historical empty version table or the historical non-empty version table; in addition, after the metadata to be stored without a deletion mark is stored in the updated version metadata table, the latest version of the metadata to be stored with a deletion mark that has been stored needs to be moved to the historical non-empty version table.

[0093] The metadata storage method provided in the embodiments of this specification can also move metadata with historical deletion marks from the updated version deletion mark table to the historical non-empty version metadata table, so that the metadata of the historical version can be directly indexed from the historical non-empty metadata table later.

[0094] It should be emphasized that the historical non-empty version metadata table includes an object identifier, a version number, and metadata corresponding to the object identifier.

[0095] Since metadata of various versions corresponding to a certain object identifier may be stored in the historical non-empty version metadata table, the primary key part in the historical non-empty version metadata table may extend the version number to identify that metadata of various different versions are stored in the historical non-empty version metadata table.

[0096] In addition, in the metadata storage method provided in the embodiments of this specification, if metadata with the same object identifier as the metadata to be stored does not exist in the updated version metadata table, it means that the metadata to be stored is metadata written by the user for the first time and has no historical version. In this case, the metadata to be stored can be directly stored in the updated version metadata table. Specifically, after determining the updated version metadata table corresponding to the metadata to be stored, the method further includes:

[0097] If it is determined in the updated version metadata table based on the object identifier that no historically stored metadata carrying the object identifier exists, the metadata to be stored carrying the object identifier is stored in the updated version metadata table.

[0098] In actual applications, the metadata server can directly store the metadata to be stored in the updated version metadata table as the latest version of metadata under the current object identifier, based on the object identifier of the metadata to be stored. If it determines that there is no historical stored metadata carrying the object identifier in the updated version metadata table, the metadata to be stored can be directly stored in the updated version metadata table as the latest version of metadata under the current object identifier.

[0099] The metadata storage method provided in the embodiments of this specification can directly store the metadata to be stored in the updated version metadata table when it is determined that no other version of metadata with the same object identifier as the metadata to be stored exists in the updated version metadata table, so that the latest version of the metadata can be directly queried directly from the updated version metadata.

[0100] See also Figure 3 , Figure 3 A schematic diagram showing a metadata storage method provided in an embodiment of this specification that stores metadata in multiple different metadata storage tables.

[0101] Figure 3 Part A is a schematic diagram of managing metadata using a key-value table; Part B is a schematic diagram of managing metadata using multiple key-value tables.

[0102] It should be noted that multiple key-value tables are used to abstract a logical table to the outside world to support the storage of metadata for objects with version control enabled; the multiple tables are described as follows: Table 1: Latest version metadata table. The primary key is the object identifier (ID). If the latest version of the object exists and is not a deletion mark, its metadata is stored in this table. Table 2: Latest version deletion mark table. The primary key is the object identifier (ID). If the latest version of the object exists and is a deletion mark, its metadata is stored in this table. Table 3: Historical empty version table. The primary key is the object identifier (ID). If an empty version of the object exists and is not the latest version, its metadata is stored in this table. Table 4: Historical non-empty version table. The primary key is the object identifier (ID) and the object version number. If a historical version of the object exists that is not an empty version, its metadata is stored in this table.

[0103] In addition, it should be emphasized that the multiple key-value tables proposed in this solution include but are not limited to the above four key-value tables. More types of key-value tables can be set according to the needs of different application scenarios to achieve the purpose of metadata classification storage and management.

[0104] Therefore, in the metadata write transaction, it is necessary to ensure that the written data is placed in the appropriate table. For example: if the metadata written is the latest version of the object, move the current latest version to Table 3 or Table 4 and store the written version in Table 1. If the metadata written is the deletion mark of the latest version, move the current latest version to Table 3 or Table 4 and store the written version in Table 2. If the metadata written is not the latest version of the object, write it directly to Table 4. If the metadata written is not the latest version and is an empty version, write it to Table 3.

[0105] In practical applications, Figure 3 Part A in the figure shows the process of writing metadata for object ID = 1. When writing version 100 of the metadata, the current system has not yet enabled the version control function. When writing version 101 of the metadata, the current system has already started the version control function. When writing version 105 of the metadata, the system has already suspended the version control function. Based on this, when there is only one key-value table to maintain metadata management, you can follow Figure 3 Store in part A.

[0106] The metadata storage method provided in the embodiment of this specification can be Figure 3 Part B manages and stores metadata in multiple key-value tables. The specific process can be referred to as follows (this embodiment takes the metadata of object ID=1 as an example for explanation, and is not limited to the key-value table storing only the metadata of object ID=1): Step 1: When version 100 is written, it is directly stored in Table 1; Step 2: When version 101 is written, version 101 is stored in Table 1, and at the same time, version 100 is moved to Table 3; Step 3: When version 102 is written, version 102 is stored in Table 1, and at the same time, version 101 is moved to Table 3. Move the data to Table 4; Step 4: When version 103 is written, store version 103 in Table 2, and move version 102 from Table 1 to Table 4; Step 5: When version 104 is written, store version 104 in Table 2, and move version 103 to Table 4; Step 6: When version 105 is written, store version 105 in Table 1, and move version 104 to Table 4, and delete version 100 in Table 3; Step 7: When version 106 is written, store version 106 in Table 1, overwriting version 105. Finally, the data can be realized. Figure 3 Part B shows the metadata storage status of each version.

[0107] In summary, this solution does not directly expand the primary key of the metadata table. Instead, it uses a logical table constructed from multiple key-value tables to manage and index object metadata. Multiple tables are used to virtualize a logical table that supports version control, supporting metadata storage for object storage and access requirements related to version control.

[0108] Corresponding to the above method embodiment, this specification also provides a metadata storage device embodiment, Figure 4 FIG. 1 shows a schematic diagram of a metadata storage device provided by an embodiment of this specification. Figure 4 As shown, the device is applied to a metadata server and includes:

[0109] The request receiving module 402 is configured to receive a data storage request for metadata to be stored that carries an object identifier;

[0110] The metadata table determination module 404 is configured to determine an updated version metadata table corresponding to the metadata to be stored when it is determined that the version control function is enabled and the metadata to be stored does not have a deletion mark;

[0111] The metadata mobile storage module 406 is configured to determine whether there is historical storage metadata carrying the object identifier in the updated version metadata table based on the object identifier, and

[0112] When the historical stored metadata contains an empty version mark, the historical stored metadata is moved from the updated version metadata table to the historical empty version metadata table, and the metadata to be stored carrying the object identifier is stored in the updated version metadata table.

[0113] Optionally, the device further includes:

[0114] The metadata storage module is configured to store the metadata to be stored carrying the object identifier in the updated version metadata table if it is determined that there is no historical stored metadata carrying the object identifier in the updated version metadata table based on the object identifier.

[0115] Optionally, the metadata mobile storage module 406 is further configured to:

[0116] If it is determined that the historical stored metadata does not carry an empty version mark, the historical stored metadata is moved from the updated version metadata table to the historical non-empty version metadata table, and the metadata to be stored carrying the object identifier is stored in the updated version metadata table.

[0117] Optionally, the metadata table determination module 404 is further configured to:

[0118] If it is determined that the version control function is enabled and the metadata to be stored has a deletion mark, determining an updated version deletion mark table corresponding to the metadata to be stored;

[0119] Optionally, the metadata mobile storage module 406 is further configured to:

[0120] If it is determined that there is historical deletion mark metadata carrying the object identifier in the updated version deletion mark table based on the object identifier, the historical deletion mark metadata is moved to the historical non-empty version metadata table;

[0121] The metadata to be stored that carries the object identifier is stored in the update version deletion mark table.

[0122] Optionally, the historical non-empty version metadata table includes an object identifier, a version number, and metadata corresponding to the object identifier.

[0123] Optionally, the metadata mobile storage module 406 is further configured to:

[0124] In the historical empty version metadata table, if it is determined that there is historical empty version metadata with an empty version mark, deleting the historical empty version metadata;

[0125] The historical storage metadata is moved from the updated version metadata table to the historical empty version metadata table.

[0126] Optionally, the metadata mobile storage module 406 is further configured to:

[0127] The storage location of the historically stored metadata in the updated version metadata table is determined, and the metadata to be stored carrying the object identifier is stored in the storage location in the updated version metadata table.

[0128] The metadata storage device provided in the embodiments of this specification uses multiple key-value tables to classify and store metadata of various versions, so that when the version function is enabled, metadata of each version can be stored in different versions of metadata storage tables, which is convenient for supporting subsequent access requirements related to version control.

[0129] The above is a schematic diagram of a metadata storage device according to this embodiment. It should be noted that the technical solution of this metadata storage device and the technical solution of the metadata storage method described above share the same concept. For details not described in detail in the technical solution of the metadata storage device, please refer to the description of the technical solution of the metadata storage method described above.

[0130] Currently, when versioning is enabled, the primary key of the table storing metadata is expanded to the object ID and version number. If a user accesses the latest version, the version number is unknown before reading, and the complete primary key cannot be provided for point-in query. This access degenerates into a request to list the first version, resulting in increased overhead. If a user enumerates the latest version, objects with deletion marks in the latest version should be considered deleted and skipped without being returned to the user. If a large number of objects have deletion marks in the latest version, skipping deletion marks will significantly increase enumeration request latency and prevent convergence. Resource consumption associated with enumeration will also increase proportionally to the number of deletion marks.

[0131] Based on this, see Figure 5 , Figure 5 A flowchart of a metadata query method provided by an embodiment of this specification is shown, which specifically includes the following steps.

[0132] It should be noted that the metadata query method provided in this embodiment may rely on the above-mentioned metadata storage method, and provides a fast metadata indexing method based on the above-mentioned metadata storage method.

[0133] Step 502: Receive a metadata query request, wherein the metadata query request carries version information.

[0134] The version information may be understood as the version information of the metadata that the user needs to query, including but not limited to the latest version, historical version, latest version with a deletion mark, historical version with an empty mark, and the like.

[0135] In actual applications, the metadata server receives a metadata query request, determines the version information in the metadata query request, and determines the version of the metadata to be indexed and queried, so as to subsequently determine the corresponding metadata storage table based on the determined version.

[0136] Step 504: Based on the version information, determine a target metadata storage table from at least two version tables storing metadata, and determine metadata that meets the metadata query request from the target metadata storage table.

[0137] The at least two version tables include an updated version metadata table and a historical empty version metadata table. The meanings of the two metadata tables are the same as those in the previous embodiment, and reference may be made to the description in the above embodiment, so they will not be described in detail here.

[0138] It should be noted that at least two version tables can be understood as version tables with multiple metadata storage. The above description only uses the updated version metadata table and the historical empty version metadata table as examples, but is not limited to these two metadata storage tables.

[0139] In actual applications, the metadata server determines a target metadata storage table from at least two version tables based on the version information indexed by the user, and determines metadata that meets the metadata query request from the target metadata storage table.

[0140] During metadata query, this embodiment provides two indexing methods: one is point query, which queries only the metadata of a certain object identifier; the other is enumeration, which lists the metadata of all object identifiers contained in a metadata table of a version; whether it is point query or enumeration, after storing the metadata of each version using the metadata storage method provided in the embodiment of this specification, and then using the metadata query method provided in this embodiment, efficient indexing of the latest version and specified version can be quickly achieved.

[0141] Among them, the first point query method is to first determine the version information corresponding to the target object identifier that the user needs to index, and then determine the target metadata storage table corresponding to the version information, so as to complete the metadata indexing of the point query; specifically, the metadata query request carries the target object identifier;

[0142] Accordingly, the step of determining a target metadata storage table from at least two version tables storing metadata based on the version information, and determining metadata that satisfies the metadata query request from the target metadata storage table includes:

[0143] Based on the version information, determining a target metadata storage table from at least two version tables storing metadata;

[0144] The metadata that satisfies the target object identifier is determined from the target metadata storage table.

[0145] In actual applications, the metadata server can determine the target metadata storage table from at least two version tables storing metadata based on version information, and directly search the target metadata storage table for the metadata corresponding to the target object identifier. For example, if a user needs to query the latest version of metadata for object ID = 1, after receiving the metadata query request sent by the user, the metadata server will determine that the target metadata storage table is an updated version storage table based on the version information carried in the request, namely the "latest version" information. The metadata server can then directly search the updated version storage table for metadata for object ID = 1, eliminating the need to compare version numbers to determine the latest version. This avoids consuming a large amount of computing resources and improves the efficiency of point-to-point indexing.

[0146] In addition, the second enumeration query method can determine the metadata storage table that the user needs to enumerate, and then return all metadata in the metadata storage table as enumerated metadata for display to the user. Specifically, based on the version information, determining the target metadata storage table from at least two version tables storing metadata, and determining metadata that meets the metadata query request from the target metadata storage table includes:

[0147] Based on the version information, determining a target metadata storage table from at least two version tables storing metadata;

[0148] Determining, from the target metadata storage table, initial metadata that satisfies the metadata query request;

[0149] The initial metadata is sorted based on a preset enumeration rule to determine target metadata.

[0150] The preset enumeration rules may be understood as sorting rules for metadata enumeration in different application scenarios, including but not limited to sorting from largest to smallest or from smallest to largest according to the serial number identifier of the version number.

[0151] In actual applications, the metadata server determines the target metadata storage table from multiple version tables based on the version information listed by the user, and determines the initial metadata that meets the metadata query request in the target metadata storage table. The initial metadata is then sorted according to the preset enumeration rules to determine the target metadata, which is the enumerated metadata.

[0152] It should be noted that in the transaction of querying the original data, reading the latest version of the object, for example, point query of the latest version, corresponds to the point query of Table 1; listing of the latest version corresponds to the listing of Table 1.

[0153] Reading a specified version object, that is, accessing the primary key of the logical table, corresponds to the merge result of each key-value table. For example, a point query of an empty version corresponds to a point query and merge of tables 1, 2, and 3; a point query of a non-empty version corresponds to a point query and merge of tables 1, 2, and 4.

[0154] In addition, the at least two version tables also include an updated version deletion mark table and a historical non-empty version metadata table.

[0155] Among them, the updated version deletion mark table and the historical non-empty version metadata table have the same meaning as the updated version deletion mark table and the historical non-empty version metadata table mentioned in the above embodiments. Please refer to the description in the above embodiments. At the same time, in the metadata query scheme, at least two version tables are not limited to the above four key-value tables, and may also include key-value tables of other version types.

[0156] At the same time, for any of the above metadata storage tables, point query or list query operations can be implemented, which will not be described one by one here.

[0157] In summary, in the metadata query method provided in the embodiments of this specification, multiple key-value tables construct indexes for objects of different version types respectively, so that the reading of the latest version, specified version and empty version can achieve point-check performance, and there is no need to skip objects whose latest version is marked as deleted when listing, avoiding additional delays and overhead.

[0158] Corresponding to the above method embodiment, this specification also provides a metadata query device embodiment, Figure 6 FIG. 1 shows a schematic diagram of a metadata query device provided by an embodiment of this specification. Figure 6 As shown, the device is applied to a metadata server and includes:

[0159] The request receiving module 602 is configured to receive a metadata query request, wherein the metadata query request carries version information;

[0160] The data query module 604 is configured to determine a target metadata storage table from at least two version tables storing metadata based on the version information, and determine metadata that satisfies the metadata query request from the target metadata storage table;

[0161] The at least two version tables include an updated version metadata table and a historical empty version metadata table.

[0162] Optionally, the metadata query request carries a target object identifier;

[0163] Optionally, the data query module 604 is further configured to:

[0164] Based on the version information, determining a target metadata storage table from at least two version tables storing metadata;

[0165] The metadata that satisfies the target object identifier is determined from the target metadata storage table.

[0166] Optionally, the data query module 604 is further configured to:

[0167] Based on the version information, determining a target metadata storage table from at least two version tables storing metadata;

[0168] Determining, from the target metadata storage table, initial metadata that satisfies the metadata query request;

[0169] The initial metadata is sorted based on a preset enumeration rule to determine target metadata.

[0170] Optionally, the at least two version tables further include an updated version deletion mark table and a historical non-empty version metadata table.

[0171] The metadata query device provided in the embodiments of this specification constructs indexes for objects of different version types through multiple key-value tables, so that the reading of the latest version, specified version and empty version can achieve point-check performance. There is no need to skip objects whose latest version is marked as deleted when listing, avoiding additional delays and overhead.

[0172] The above is a schematic diagram of a metadata query device according to this embodiment. It should be noted that the technical solution of this metadata query device and the technical solution of the metadata query method described above are based on the same concept. For details not described in detail in the technical solution of the metadata query device, please refer to the description of the technical solution of the metadata query method described above.

[0173] Figure 7 7 shows a block diagram of a computing device 700 according to one embodiment of the present disclosure. Components of the computing device 700 include, but are not limited to, a memory 710 and a processor 720. The processor 720 is connected to the memory 710 via a bus 730, and a database 750 is used to store data.

[0174] The computing device 700 also includes an access device 740 that enables the computing device 700 to communicate via one or more networks 760. Examples of such networks include a public switched telephone network (PSTN), a local area network (LAN), a wide area network (WAN), a personal area network (PAN), or a combination of communication networks such as the Internet. The access device 740 may include one or more of any type of network interface (e.g., a network interface card (NIC)), whether wired or wireless, such as an IEEE 802.11 wireless local area network (WLAN) wireless interface, a Worldwide Interoperability for Microwave Access (Wi-MAX) interface, an Ethernet interface, a universal serial bus (USB) interface, a cellular network interface, a Bluetooth interface, a near field communication (NFC) interface, and the like.

[0175] In one embodiment of the present specification, the above components of the computing device 700 and Figure 7 Other components not shown in the figure may also be connected to each other, for example, via a bus. Figure 7 The computing device structure block diagram shown is for illustrative purposes only and is not intended to limit the scope of this specification. Those skilled in the art may add or replace other components as needed.

[0176] Computing device 700 can be any type of stationary or mobile computing device, including a mobile computer or mobile computing device (e.g., a tablet computer, a personal digital assistant, a laptop computer, a notebook computer, a netbook computer, etc.), a mobile phone (e.g., a smartphone), a wearable computing device (e.g., a smartwatch, smart glasses, etc.), or other types of mobile devices, or a stationary computing device such as a desktop computer or PC. Computing device 700 can also be a mobile or stationary server.

[0177] The processor 720 is configured to execute the following computer-executable instructions, which, when executed by the processor, implement the steps of the above-mentioned metadata storage method or metadata query method.

[0178] The above is a schematic diagram of a computing device according to this embodiment. It should be noted that the technical solution of this computing device is based on the same concept as the technical solution of the metadata storage method or metadata query method described above. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the metadata storage method or metadata query method described above.

[0179] An embodiment of the present specification further provides a computer-readable storage medium storing computer-executable instructions. When the computer-executable instructions are executed by a processor, the steps of the above-mentioned metadata storage method or metadata query method are implemented.

[0180] The above is an illustrative embodiment of a computer-readable storage medium. It should be noted that the technical solution of this storage medium is based on the same concept as the technical solution of the metadata storage method or metadata query method described above. For details not described in detail in the technical solution of the storage medium, please refer to the description of the technical solution of the metadata storage method or metadata query method described above.

[0181] An embodiment of the present specification further provides a computer program, wherein when the computer program is executed in a computer, the computer is caused to execute the steps of the above-mentioned metadata storage method or metadata query method.

[0182] The above is an illustrative embodiment of a computer program. It should be noted that the technical solution of this computer program is based on the same concept as the technical solution of the metadata storage method or metadata query method described above. For details not described in detail in the technical solution of the computer program, please refer to the description of the technical solution of the metadata storage method or metadata query method described above.

[0183] The foregoing description of this specification describes specific embodiments. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that described in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the specific order shown or the sequential order to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0184] The computer instructions include computer program code, which may be in source code form, object code form, executable file, or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, USB flash drive, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal, and software distribution medium, etc. It should be noted that the content contained in the computer-readable medium may be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electric carrier signals and telecommunication signals.

[0185] It should be noted that for the aforementioned method embodiments, for the sake of simplicity of description, they are all expressed as a series of action combinations, but those skilled in the art should be aware that the embodiments of this specification are not limited by the order of the actions described, because according to the embodiments of this specification, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in this specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the embodiments of this specification.

[0186] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0187] The preferred embodiments disclosed above are intended only to help illustrate this specification. The optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific embodiments described. Obviously, many modifications and variations can be made based on the content of the embodiments of this specification. This specification selects and specifically describes these embodiments in order to better explain the principles and practical applications of the embodiments of this specification, so that those skilled in the art can better understand and utilize this specification. This specification is limited only by the claims and their full scope and equivalents.

Claims

1. A metadata storage method, applied to a metadata server, comprising: receiving a data storage request for metadata to be stored that carries an object identifier; If it is determined that the version control function is enabled and the metadata to be stored does not carry a deletion mark, determining an updated version metadata table corresponding to the metadata to be stored; Based on the object identifier in the updated version metadata table, it is determined that there is historical storage metadata carrying the object identifier, and If the historically stored metadata contains an empty version mark, the historically stored metadata is moved from the updated version metadata table to the historical empty version metadata table, and the metadata to be stored that carries the object identifier is stored in the updated version metadata table, wherein the empty version is the version written before version control is enabled or when it is paused; When it is determined that the version control function is enabled and the metadata to be stored has a deletion mark, an updated version deletion mark table corresponding to the metadata to be stored is determined and stored to avoid skipping objects whose latest version is a deletion mark when reading the latest version.

2. The metadata storage method according to claim 1, further comprising: after determining the updated version metadata table corresponding to the metadata to be stored; If it is determined in the updated version metadata table based on the object identifier that no historically stored metadata carrying the object identifier exists, the metadata to be stored carrying the object identifier is stored in the updated version metadata table.

3. The metadata storage method according to claim 1, after determining that historically stored metadata carrying the object identifier exists in the updated version metadata table based on the object identifier, further comprising: If it is determined that the historical stored metadata does not carry an empty version mark, the historical stored metadata is moved from the updated version metadata table to the historical non-empty version metadata table, and the metadata to be stored carrying the object identifier is stored in the updated version metadata table.

4. The metadata storage method according to claim 1, wherein determining and storing an updated version deletion mark table corresponding to the metadata to be stored comprises: If it is determined that there is historical deletion mark metadata carrying the object identifier in the updated version deletion mark table based on the object identifier, the historical deletion mark metadata is moved to the historical non-empty version metadata table; The metadata to be stored that carries the object identifier is stored in the update version deletion mark table.

5. The metadata storage method according to claim 3 or 4, wherein the historical non-empty version metadata table includes an object identifier, a version number, and metadata corresponding to the object identifier.

6. The metadata storage method according to claim 1, wherein the step of moving the historically stored metadata from the updated version metadata table to the historical empty version metadata table comprises: In the historical empty version metadata table, if it is determined that there is historical empty version metadata with an empty version mark, deleting the historical empty version metadata; The historical storage metadata is moved from the updated version metadata table to the historical empty version metadata table.

7. The metadata storage method according to claim 1, wherein storing the metadata to be stored carrying the object identifier into the updated version metadata table comprises: The storage location of the historically stored metadata in the updated version metadata table is determined, and the metadata to be stored carrying the object identifier is stored in the storage location in the updated version metadata table.

8. A metadata query method, applied to a metadata server, comprising: receiving a metadata query request, wherein the metadata query request carries version information; Based on the version information, a target metadata storage table is determined from at least two version tables storing metadata, and metadata that satisfies the metadata query request is determined from the target metadata storage table, wherein the metadata storage process is to receive a data storage request for metadata to be stored that carries an object identifier, and when it is determined that the version control function is enabled and the metadata to be stored does not carry a deletion mark, determine an updated version metadata table corresponding to the metadata to be stored, and based on the object identifier, when it is determined that historical stored metadata carrying the object identifier exists in the updated version metadata table, and when the historical stored metadata carries an empty version mark, move the historical stored metadata from the updated version metadata table to a historical empty version metadata table, and store the metadata to be stored that carries the object identifier in the updated version metadata table, wherein the empty version is a version written before version control is enabled or when it is paused, and when it is determined that the version control function is enabled and the metadata to be stored carries a deletion mark, determine and store an updated version deletion mark table corresponding to the metadata to be stored, so as to avoid skipping objects whose latest versions are deleted when reading the latest version; The at least two version tables include an updated version metadata table and a historical empty version metadata table.

9. The metadata query method according to claim 8, wherein the metadata query request carries a target object identifier; Accordingly, the step of determining a target metadata storage table from at least two version tables storing metadata based on the version information, and determining metadata that satisfies the metadata query request from the target metadata storage table includes: Based on the version information, determining a target metadata storage table from at least two version tables storing metadata; Determine metadata that satisfies the target object identifier from the target metadata storage table.

10. The metadata query method according to claim 8, wherein the step of determining a target metadata storage table from at least two version tables storing metadata based on the version information, and determining metadata that satisfies the metadata query request from the target metadata storage table comprises: Based on the version information, determining a target metadata storage table from at least two version tables storing metadata; Determining, from the target metadata storage table, initial metadata that satisfies the metadata query request; The initial metadata is sorted based on a preset enumeration rule to determine target metadata.

11. The metadata query method according to claim 8, wherein the at least two version tables further include a historical non-empty version metadata table.

12. A metadata storage device, applied to a metadata server, comprising: a request receiving module configured to receive a data storage request for metadata to be stored that carries an object identifier; a metadata table determination module configured to, when it is determined that the version control function is enabled and the metadata to be stored does not carry a deletion mark, determine an updated version metadata table corresponding to the metadata to be stored; The metadata mobile storage module is configured to determine whether there is historical storage metadata carrying the object identifier in the updated version metadata table based on the object identifier, and If the historically stored metadata contains an empty version mark, the historically stored metadata is moved from the updated version metadata table to the historical empty version metadata table, and the metadata to be stored that carries the object identifier is stored in the updated version metadata table, wherein the empty version is the version written before version control is enabled or when it is paused; When it is determined that the version control function is enabled and the metadata to be stored has a deletion mark, an updated version deletion mark table corresponding to the metadata to be stored is determined and stored to avoid skipping objects whose latest version is a deletion mark when reading the latest version.

13. A metadata query device, applied to a metadata server, comprising: a request receiving module, configured to receive a metadata query request, wherein the metadata query request carries version information; A data query module is configured to determine, based on the version information, a target metadata storage table from at least two version tables storing metadata, and determine metadata that satisfies the metadata query request from the target metadata storage table, wherein the metadata storage process is to receive a data storage request for metadata to be stored that carries an object identifier, and upon determining that a version control function is enabled and the metadata to be stored does not carry a deletion mark, determine an updated version metadata table corresponding to the metadata to be stored, and upon determining, based on the object identifier, that historical stored metadata carrying the object identifier exists in the updated version metadata table, and upon determining that the historical stored metadata carries an empty version mark, move the historical stored metadata from the updated version metadata table to a historical empty version metadata table, and store the metadata to be stored that carries the object identifier in the updated version metadata table, wherein the empty version is a version written before version control is enabled or when it is paused, and upon determining that the version control function is enabled and the metadata to be stored carries a deletion mark, determine and store an updated version deletion mark table corresponding to the metadata to be stored, so as to avoid skipping objects whose latest versions are deleted when reading the latest version; The at least two version tables include an updated version metadata table and a historical empty version metadata table.

14. A computing device comprising: memory and processor; The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions. When the computer-executable instructions are executed by the processor, the steps of the method according to any one of claims 1 to 11 are implemented.

Images