Metadata index storage method and device for distributed object storage system

Abstract

The application discloses a metadata index storage method and device for a distributed object storage system. The method comprises the following steps: a master node storage step, receiving metadata index information sent by a metadata server, converting the metadata index information into a key-value pair structure, performing deduplication and mapping storage, and delivering the metadata index information to a leader in a consistency protocol Raft; calling an interface of a database to store the metadata index information converted into the key-value pair structure; based on the consistency protocol Raft, the leader synchronizes the metadata index information converted into the key-value pair structure to a slave node in a storage system cluster; and a slave node storage step, receiving synchronization information sent by the master node, and writing the metadata index information converted into the key-value pair structure into a database for storage. The consistency protocol Raft introduced in the application reduces space occupation, solves the read-write amplification problem through a range tree structure of a composite key, and finally improves the index efficiency of metadata.

Description

Technical Field

[0001] This invention relates to the field of non-object storage technology, and specifically to a method and apparatus for storing metadata indexes in a distributed object storage system. Background Technology

[0002] Object storage technology is widely used in cloud computing environments, where applications store data as a large number of objects. These objects contain not only the actual data but also metadata describing that data, primarily including indexes and attributes. To achieve efficient storage and flexible management, modern object storage systems (such as Ceph and Oasis) typically maintain data and metadata separately. However, in typical read / write workloads, over 70% of read operations and 80% of write operations involve only metadata access, making efficient metadata access crucial for performance.

[0003] Traditional object storage systems leverage the relatively small size of object metadata by storing data on low-cost hard disk drives (HDDs) and metadata on high-performance solid-state drives (SSDs). However, with the increasing volume of object data, despite continuous improvements in SSD performance, metadata servers often struggle to meet users' performance requirements under high-load real-world environments. To further improve the performance of metadata services in object storage systems, researchers have proposed various optimization techniques, including metadata indexing, compression, caching, and partitioning. These techniques alleviate performance requirements in specific scenarios to some extent. For example, indexing allows for fast metadata retrieval but increases storage and maintenance overhead; compression saves storage space but may increase read overhead; caching improves access speed but requires additional memory and introduces complexity in maintaining consistency; and partitioning improves parallelism and scalability but may increase management overhead.

[0004] Therefore, when selecting technologies to optimize metadata services, storage costs, performance requirements, and system scalability must be considered. Mainstream object storage systems such as Ceph, Amazon S3, and Google Cloud Storage generally use indexes to improve metadata storage performance and query speed, thereby alleviating the pressure on metadata servers. However, this approach often has several significant drawbacks, such as storage overhead. Creating indexes requires additional storage space. Especially for large datasets, indexes can consume a considerable amount of storage space, increasing overall storage costs. Increased storage costs mean that enterprises need to invest in more solid-state drives, ultimately leading to reduced economic benefits. Secondly, there is maintenance overhead. As data is updated and deleted, indexes also need to be updated and maintained accordingly. This can introduce additional write overhead and system load, especially in environments with frequent changes. Simultaneously, given the complexity of queries, for complex query operations, indexes may involve multiple fields or multiple data tables, making index maintenance and querying complex. This can increase development and maintenance costs and reduce system maintainability. Most importantly, there are issues with index consistency and availability. During index updates, if a failure or network latency occurs, the index may become inconsistent with the actual data, thus affecting the normal operation of the system. This presents significant challenges to optimizing metadata services using indexing. Therefore, to address the issue of effectively managing the massive increase in metadata, it is necessary to redesign the metadata service architecture of a modern object storage system to meet the goals of efficient storage and read / write consistency.

[0005] The current mainstream metadata management solution uses key-value databases, which often employ log tree structures to provide good write and query performance. However, in ultra-large-scale object storage scenarios, this structure also has certain drawbacks that can significantly impact the system. For example, LSM trees can cause write amplification during write operations, leading to data being repeatedly written to disk and increasing the total number of writes. For read operations, since multiple levels of data need to be searched, the total number of reads may increase, reducing read performance. To maintain the order of the LSM tree, periodic merge operations are required. This merge process can consume significant system resources, such as CPU and disk bandwidth, leading to performance degradation. Furthermore, due to the merge operation and background tasks, LSM tree write operations may introduce latency. In certain scenarios, especially for applications with high real-time requirements, this latency can affect user experience. Additionally, during metadata index storage, object storage systems typically replicate and redundantly store metadata indexes and implement version control to ensure data reliability and consistency. By storing identical copies of the metadata index across multiple nodes, the system can tolerate node failures or data corruption and ensure data persistence. These methods help object storage systems meet consistency requirements, but they also have some drawbacks. For example, storage overhead increases; replication and redundant storage increase storage costs and consume significant network bandwidth because identical copies of the metadata index need to be stored on multiple nodes. Version control may introduce additional latency and performance penalties because it needs to wait for the order of all application updates and handle various concurrency and failure scenarios in a distributed environment. Summary of the Invention

[0006] To address the aforementioned technical issues, this application aims to propose a metadata index storage method and apparatus for distributed object storage systems. It proposes to manage the metadata index in a distributed key-value pair manner, relying on an efficient consistency protocol to ensure the consistency and availability of metadata while saving space, and improving the read and write performance of the metadata index through a range tree structure based on composite keys.

[0007] The technical solution of the present invention is as follows.

[0008] On one hand, a method for storing metadata indexes in a distributed object storage system, the distributed object storage system including master nodes and slave nodes, the method comprising:

[0009] The master node storage process involves receiving metadata index information from the metadata server and converting it into a key-value pair structure. After deduplication and mapping, the stored metadata index information is delivered to the leader in the Raft consensus protocol. The leader then calls the database interface to store the converted key-value pair metadata index information. Based on the Raft consensus protocol, the leader synchronizes the converted key-value pair metadata index information to the slave nodes in the storage system cluster. The keys in the key-value pair structure are stored as composite keys. The key in the composite key identifies the starting address and offset of the index information, and the value in the composite key corresponds to the log address, i.e., the address within the database. There is no overlap between two composite keys, and the composite keys are in a completely ordered relationship.

[0010] The slave node storage step receives synchronization information sent by the master node and writes the metadata index information, which is converted into a key-value pair structure, into the database for storage; the slave node and the master node are configured with a matching Raft consistency protocol.

[0011] Preferably, the step of receiving metadata index information sent from the metadata server and converting it into a key-value pair structure specifically includes:

[0012] Receive metadata index information sent from the metadata server, deliver it to the task management interface for processing, set a threshold, and when the received metadata index information reaches the threshold, batch process this metadata index information into a key-value pair structure.

[0013] Preferably, after receiving the metadata index information sent from the metadata server and converting it into a key-value pair structure, the process further includes:

[0014] Batch data is stored in a cache so that it can be recovered in time if a failure occurs during the synchronization process.

[0015] Preferably, after the leader synchronizes the metadata index information, converted into a key-value pair structure, to the slave nodes in the storage system cluster, the method further includes:

[0016] The leader will synchronize the metadata index information, which is converted into a key-value pair structure, to the slave nodes in the storage system cluster.

[0017] Preferably, the step of delivering the deduplication and mapping storage to the leader in the Raft consensus protocol specifically includes:

[0018] The metadata index information, converted into a key-value pair structure, is stored in the deduplication table and the mapping table and then delivered to the leader in the Raft consensus protocol; the process of storing it in the deduplication table involves sorting.

[0019] Preferably, within the database, the composite key is stored using a two-level structure of red-black trees and arrays.

[0020] Preferably, for a range query q within the offset space of the database, the read / write request processing procedure is as follows:

[0021] The steps to find the smallest composite key that is not less than the range query are as follows: Find the smallest composite key m that is not less than the range query q; the "not less than" is defined according to the LESS relation, that is, the offset plus length of m is at least as large as the starting offset of q; where the LESS relation is defined as follows: if the sum of the offset and length of the first composite key is not greater than the offset of the second composite key, then the first composite key is less than the second composite key.

[0022] Check the intersection region: After finding the composite bond m, start from m and check whether a series of composite bonds intersect with q, and determine all intersecting regions;

[0023] Read request processing: If the query is to read data, locate the mapping regions corresponding to all intersecting regions. These mapping regions are the regions that actually need to be read from the log.

[0024] Write request processing: If the query is for writing data, all intersecting regions are removed from the index before inserting the new composite key q to maintain the total order relationship between composite keys; after removing all intersecting regions, the new composite key q is inserted into the correct position without violating the order of the data.

[0025] Preferably, the time complexity of finding the composite key m is O(log n), where n is the number of keys in each block index, and the search is implemented using a red-black tree.

[0026] Preferably, the database is the RocksDB database.

[0027] On the other hand, a metadata index storage device for a distributed object storage system includes:

[0028] The master node storage module receives metadata index information from the metadata server, converts it into a key-value pair structure, performs deduplication and mapping storage, and delivers it to the leader in the Raft consensus protocol. It then calls the database interface to store the converted key-value pair metadata index information. Based on the Raft consensus protocol, the leader synchronizes the converted key-value pair metadata index information to the slave nodes in the storage system cluster. The keys in the key-value pair structure are stored as composite keys. The key in the composite key identifies the starting address and offset of the index information, and the value in the composite key corresponds to the log address, i.e., the address within the database. There is no overlap between two composite keys, and the composite keys are in a completely ordered relationship.

[0029] The slave node storage module is used to receive synchronization information sent by the master node, convert it into metadata index information in a key-value pair structure, and write it into the database for storage; the slave node and the master node are configured with a matching Raft consistency protocol.

[0030] Compared with the prior art, the present invention has the following beneficial effects:

[0031] (1) This invention uses a distributed key-value storage architecture based on the Raft consistency protocol to store metadata indexes, allowing users to customize the logic to store the indexes on the server side, thus saving space while ensuring the consistency and availability of metadata.

[0032] (2) This invention optimizes the key-value storage structure of the underlying index storage. Based on the traditional log structure tree, it proposes the concept of range tree and changes the key-value storage to a strictly ordered composite key method to improve writing and query efficiency. Attached Figure Description

[0033] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0034] Figure 1 This is a flowchart of a metadata indexing and storage method for a distributed object storage system according to an embodiment of the present invention;

[0035] Figure 2 This is the architecture of the metadata indexing service I-Meta according to an embodiment of the present invention;

[0036] Figure 3 This is a schematic diagram of the range tree structure according to an embodiment of the present invention;

[0037] Figure 4 This is a schematic diagram of a range tree query according to an embodiment of the present invention;

[0038] Figure 5 This is a comparison chart of the average throughput of the method in this embodiment of the invention and Ceph under 100% PUT load;

[0039] Figure 6 This is a comparison chart of the average write latency of the method in this embodiment of the invention and Ceph under 100% PUT load;

[0040] Figure 7 This is a comparison chart of read / write latency between the method of this invention and Ceph under 50% PUT and 50% GET loads;

[0041] Figure 8 This is a structural block diagram of a metadata index storage system for a distributed object storage system, according to an embodiment of the present invention. Detailed Implementation

[0042] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this invention, and not all of them. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0043] like Figure 1 As shown in the figure, this embodiment provides a metadata index storage method for a distributed object storage system, including:

[0044] In step 101 of the master node storage process, the master node receives metadata index information from the metadata server and converts it into a key-value pair structure. After deduplication and mapping, the stored information is delivered to the leader in the Raft consensus protocol. The master node then calls the database interface to store the metadata index information converted into a key-value pair structure. Based on the Raft consensus protocol, the leader synchronizes the metadata index information converted into a key-value pair structure to the slave nodes in the storage system cluster. The keys in the key-value pair structure are stored as composite keys. The key in the composite key identifies the starting address and offset of the index information, and the value in the composite key corresponds to the log address, i.e., the address in the database. There is no overlap between two composite keys, and the composite keys are in a completely ordered relationship.

[0045] In step 102 of the slave node storage, the slave node receives the synchronization information sent by the master node and writes the metadata index information, which is converted into a key-value pair structure, into the database for storage; the slave node and the master node are configured with a matching Raft consistency protocol.

[0046] Specifically, this embodiment proposes an optimization method I-Meta for metadata index storage in distributed object storage systems. It proposes to manage metadata indexes in a distributed key-value pair (KV) manner, while relying on an efficient consistency protocol to ensure the consistency and availability of metadata while saving space. It also proposes the concept of a range tree to improve the read and write performance of metadata indexes.

[0047] As can be seen from the above, the core idea of ​​I-Meta in this embodiment is to improve the distributed framework based on the traditional replication and redundancy method of storing metadata indexes, add the Raft consistency protocol to reduce space occupation, and improve the log structure tree to solve the problem of read-write amplification and improve the indexing efficiency of metadata.

[0048] like Figure 2The diagram shows the architecture of I-Meta. The distributed object storage system in I-Meta mainly consists of master nodes and slave nodes. The diagram primarily illustrates the task processing flow within the master node. The RocksDB database component is responsible for storing index information; the underlying implementation of RocksDB relies on a log structure tree.

[0049] The master node processing flow is as follows.

[0050] The master node receives metadata index information from the metadata server and delivers it to the task management interface for processing①. A threshold THR is set to limit the maximum number of indexes processed in a single batch. Once the threshold is reached, the data is converted to batch processing②, meaning the received metadata index information is converted into key-value data. To ensure the order and uniqueness of the indexes, they are stored in a deduplication table and a mapping table ③ before being delivered to the leader in the Raft consistency protocol ④ for subsequent distribution to slave nodes. Simultaneously, the batch data is stored in a cache ⑤ to facilitate data recovery in case of power outages, synchronization interruptions, or other failures during the synchronization process. After this process, the master node first stores the index information (key-value structure) using the RocksDB database interface ⑥. RocksDB then reports to the Raft leader that the index data has been successfully written ⑧. The Raft leader then synchronizes the index information to the slave nodes on other metadata servers in the storage system cluster via the network ⑦. Synchronization relies on the Raft consistency protocol; if more than half of the slave nodes receive the information, the data synchronization is considered successful. Finally, the cache information is cleared ⑨ to release excess space.

[0051] Specifically, the metadata index information can include the unique identifier and storage location of the data, as well as other key management information such as data size, creation time, access permissions, and owner.

[0052] To improve efficiency, the task management interface sets a threshold THR (Threshold for Hierarchical Relationships), such as 1000 indexes. When the received metadata index information reaches this threshold, the index data is converted into batch data for processing. This means that if metadata index information for 1000 files is received at once, this information will be packaged into a batch processing task, and then the index information for all 1000 files will be processed at once, instead of processing each file individually.

[0053] In this batch processing process, the metadata index information is converted into key-value pair format, which makes it easier to perform batch processing, such as batch updating file location information and batch modifying access permissions.

[0054] The received metadata index information is converted into key-value (KV) data, as explained below. When the master node receives metadata index information from the metadata server, it needs to transform this information into a format suitable for the task management interface. In this process, the received metadata index information is converted into a more general key-value (KV) format structure. This simplifies data management and processing, making it more flexible and universal. For example, the metadata index information "File ID: File12345" is converted into the key-value pair format "Key:FileID, Value:File12345".

[0055] In addition, the deduplication table stores unique identifiers for the metadata indexes (such as file IDs or other information that uniquely identifies data) to detect duplicates, and sorting is performed automatically during the deduplication process. The mapping table stores the mapping relationship between the metadata indexes and their corresponding actual storage locations or other relevant information. The data delivered to the Raft leader node is the deduplicated and mapped metadata index information converted into a key-value structure. This information needs to be synchronized across all relevant nodes in the storage system cluster to maintain data consistency.

[0056] The node processing flow is as follows.

[0057] Slave nodes are the machines on the other metadata servers in the storage system cluster. They are configured with the Raft consistency protocol along with the master node to ensure data distribution consistency. After receiving information, a slave node directly writes the index information into the RocksDB database to complete the storage task. Simultaneously, in metadata access tasks, upper-layer applications can directly call the RocksDB GET interface to obtain the metadata index information for query requests. Based on the index information, the upper-layer application then locates the metadata location information to complete the read task.

[0058] The storage structure of the RocksDB database will be explained below.

[0059] RocksDB database is implemented using a log structure tree, which stores key-value data. The range tree structure described in this article is an improvement upon this. Traditional key-value pairs are already sorted during the master node's deduplication process, so they are stored using a range tree. A composite key is a combination of consecutive keys into a single composite key, in the form {offset, length}, where the log offset mappings of the keys are also consecutive. The composite key represents a range mapping from a half-closed, half-open interval [offset, offset+length) in the block offset space to the log offset space, recorded by a key-value pair ({offset, length} → j_offset).

[0060] The LESS relationship between two composite bonds is defined as follows: if the sum of the offset and length of the first composite bond is not greater than the offset of the second composite bond, then the first composite bond is smaller than the second composite bond. There are no intersecting composite bonds; therefore, LESS is a completely ordered relationship between composite bonds.

[0061] Figure 3 It describes compound key operations performed within a key space, demonstrating how new keys are written and how they interact with existing keys.

[0062] After writing: Three intervals in the key space are displayed. Each interval is identified by a compound key in the form (offset, length). For example, (100, 50) represents an interval starting at position 100, with a length of 50, covering the position up to position 150.

[0063] Write key: Describes the operation of writing a new compound key (150, 200), which attempts to cover the range from 150 to 350.

[0064] Two old keys: These represent two existing composite keys (100,100) and (300,100) before the new composite key was written. The new composite key overlaps with these two old keys.

[0065] from Figure 3 In this context, a composite key can be understood as representing a range or interval in the key space. When a new key is introduced, it may partially or completely overlap with existing keys. Such operations typically require addressing these overlaps—perhaps by splitting, truncating, or otherwise reorganizing existing keys to maintain non-overlapping intervals that can be efficiently searched and retrieved.

[0066] Total order relations also allow for fast range queries and updates on composite keys. Suppose there exists a range query q (which can be considered a composite key) in the offset space of the database, such as... Figure 4 As shown. The parameters are defined as follows.

[0067] • Query q: This is a range query that finds all keys that intersect with the query range.

[0068] ·m: The median or a specific reference point in the key space, used for querying.

[0069] • Intervals a, b, c: represent existing keys in the key space that intersect with the query range q.

[0070] • Intervals a', b', c': These are the exact parts where intervals a, b, and c intersect with the query range q, and are also the results of the query.

[0071] The specific implementation is as follows.

[0072] Suppose we perform a range query in the block offset space, which can be viewed as a composite key q. The goal of the range query is to find all intervals that intersect with the query range q. The specific steps are as follows:

[0073] (1) Finding the smallest composite key that is not less than the query: In this query process, we first need to find the smallest composite key m that is not less than the range query q. Here, "not less than" is defined according to the LESS relation, meaning that the offset plus length of m is at least as large as the starting offset of q. The time complexity of finding m is O(log n), where n is the number of keys in each block index. This is an efficient search process, implemented using a red-black tree.

[0074] (2) Check the intersection area: After finding the composite key m, the system will check whether a series of composite keys intersect with the query q starting from m, and determine all intersecting areas, namely a, b and c.

[0075] (3) For read requests: If the query is to read data, then it is necessary to locate the corresponding mapping regions a', b' and c' of these intersection regions a, b and c. These are the regions that actually need to be read from the log.

[0076] (4) For write requests: If the query is for writing data, these overlapping regions need to be removed from the index before inserting the new composite key q to maintain the total order relationship between the composite keys. After removing these overlapping regions, the new composite key q can be inserted in the correct position without violating the order of the data.

[0077] This embodiment's range tree supports fast data access and updates. By maintaining total order relationships, it ensures an explicit ordering among all composite keys, which is crucial for achieving consistent and efficient data operations. In practice, this means that even large blocks of data can be handled efficiently for range queries and data write tasks, whether appending new data or updating existing data.

[0078] The use of range trees is particularly suitable for handling frequently accessed object metadata, as metadata queries and updates typically involve a set of related key-value pairs, not just operations on a single key-value pair. Therefore, this strategy often significantly improves data query and write performance. The key-value pairs ({offset, length} → j_offset) are packaged into an 8-byte structure, with the bit length of each field set. I-Meta uses a two-level structure to store key-value pairs. The first level is a red-black tree, which is highly efficient for insertion but less efficient for storage because each tree node incurs the overhead of three additional pointers and a bit flag. The second level is a sorted array, which is slower for insertion than a red-black tree but more efficient for storage and querying. When a new key-value pair is added, I-Meta first quickly inserts it into the red-black tree, and then asynchronously merges it into the array via a low-priority background worker thread. Since key-value pairs in the array may be outdated, queries are first resolved in the red-black tree, and then any missing ranges are resolved in the array. As a first-level small write cache, a red-black tree array can store one billion records in 8GB of space, corresponding to at least 16TB of log data, which far exceeds the requirements and effectively reduces the storage space problem of traditional indexes. Furthermore, since the memory space occupied when writing data to a range tree often has a long single release time and causes unnecessary waste of system resources, affecting system performance, the range tree can quickly release a large number of composite keys within the range when facing a large number of write requests, further reducing the index's memory usage.

[0079] The following will compare the I-Meta of this embodiment with the existing Ceph through experiments.

[0080] The I-Meta service was integrated into the mainstream storage system Ceph, replacing its original metadata service component. A comparative experiment was conducted using the COSBench stress testing tool to compare the I-Meta-integrated metadata service system with Ceph. The main metrics tested were read / write latency and throughput. The experiment was configured to simulate a workload of writing massive amounts of small objects by performing 100% PUT operations on individual 4KB objects. 100 client threads simultaneously sent requests, with the number of objects written ranging from 0 to 100 million. After this workload was completed, a mixture of 50% GET and 50% PUT operations was used to simulate a real business workload, still using 4KB objects and performing 100 million operations.

[0081] (1) Higher throughput stability

[0082] Thanks to the current Raft framework's optimizations for batch data, it can effectively merge multiple I / O operations under high-pressure scenarios, thereby improving system performance. The average throughput of the two systems was recorded during 100% PUT operations on 100 million 4KB small objects. Figure 5 The experimental results show that the method in this embodiment maintains high stability during the stress test, which is much higher than that of Ceph at the same time, and the average throughput is 2.7 times that of Ceph.

[0083] (2) Lower read / write latency

[0084] like Figure 6 and Figure 7 As shown, the metadata service system that integrates I-Meta performs better than Ceph in terms of read and write latency. Its read latency is slightly better than Ceph, but its write latency is 5.4 times lower than Ceph.

[0085] Further as Figure 8 As shown in the figures above, this application provides an embodiment of a metadata index storage system for a distributed object storage system, which is an implementation of the methods shown in the figures above. Figure 1 Corresponding to the method embodiments shown, this device can be specifically applied to various electronic devices.

[0086] This application provides a metadata indexing storage system for a distributed object storage system, including:

[0087] The master node storage module 801 receives metadata index information sent from the metadata server, converts it into a key-value pair structure, performs deduplication and mapping storage, and delivers it to the leader in the Raft consensus protocol. It calls the database interface to store the converted key-value pair metadata index information. Based on the Raft consensus protocol, the leader synchronizes the converted key-value pair metadata index information to the slave nodes in the storage system cluster. The keys in the key-value pair structure are stored as composite keys. The key in the composite key identifies the starting address and offset of the index information, and the value in the composite key corresponds to the log address, i.e., the address within the database. There is no overlap between two composite keys, and the composite keys are in a completely ordered relationship.

[0088] The slave node storage module 802 is used to receive synchronization information sent by the master node and write the metadata index information, which is converted into a key-value pair structure, into the database for storage; the slave node and the master node are configured with a matching Raft consistency protocol.

[0089] The specific implementation of each module of the metadata index storage system for a distributed object storage system is the same as the metadata index storage method for a distributed object storage system, and will not be described again in this embodiment.

[0090] The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in this application is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described inventive concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this application.

Claims

1. A method for storing metadata indexes in a distributed object storage system, characterized in that, The distributed object storage system includes master nodes and slave nodes, and the method includes: The master node storage process involves receiving metadata index information from the metadata server and converting it into a key-value pair structure. After deduplication and mapping, the stored metadata index information is delivered to the leader in the Raft consensus protocol. The leader then calls the database interface to store the converted key-value pair metadata index information. Based on the Raft consensus protocol, the leader synchronizes the converted key-value pair metadata index information to the slave nodes in the storage system cluster. The keys in the key-value pair structure are stored as composite keys. The key in the composite key identifies the starting address and offset of the index information, and the value in the composite key corresponds to the log address, i.e., the address within the database. There is no overlap between two composite keys, and the composite keys are in a completely ordered relationship. The slave node storage step receives synchronization information sent by the master node and writes the metadata index information, which is converted into a key-value pair structure, into the database for storage; the slave node and the master node are configured with a matching Raft consistency protocol. For a range query q within the offset space of the database, the read / write request processing procedure is as follows: The steps to find the smallest composite key that is not less than the range query are as follows: Find the smallest composite key m that is not less than the range query q; the "not less than" is defined according to the LESS relation, that is, the offset plus length of m is at least as large as the starting offset of q; where the LESS relation is defined as follows: if the sum of the offset and length of the first composite key is not greater than the offset of the second composite key, then the first composite key is less than the second composite key. Check the intersection region: After finding the composite bond m, start from m and check whether a series of composite bonds intersect with q, and determine all intersecting regions; Read request processing: If the query is to read data, locate the mapping regions corresponding to all intersecting regions. These mapping regions are the regions that actually need to be read from the log. Write request processing: If the query is for writing data, all intersecting regions are removed from the index before inserting the new composite key q to maintain the total order relationship between composite keys; after removing all intersecting regions, the new composite key q is inserted into the correct position without violating the order of the data.

2. The metadata indexing and storage method for a distributed object storage system according to claim 1, characterized in that, The process of receiving metadata index information from the metadata server and converting it into a key-value pair structure specifically includes: Receive metadata index information sent from the metadata server, deliver it to the task management interface for processing, set a threshold, and when the received metadata index information reaches the threshold, batch process this metadata index information into a key-value pair structure.

3. The metadata indexing and storage method for a distributed object storage system according to claim 1, characterized in that, After receiving the metadata index information sent from the metadata server and converting it into a key-value pair structure, the process further includes: Batch data is stored in a cache so that it can be recovered in time if a failure occurs during the synchronization process.

4. The metadata indexing and storage method for a distributed object storage system according to claim 3, characterized in that, After the leader synchronizes the metadata index information, converted into a key-value pair structure, to the slave nodes in the storage system cluster, it also includes: The leader will synchronize the metadata index information, which is converted into a key-value pair structure, to the slave nodes in the storage system cluster.

5. The metadata indexing and storage method for a distributed object storage system according to claim 1, characterized in that, The process of deduplication and mapping storage followed by delivery to the leader in the Raft consensus protocol specifically includes: The metadata index information, converted into a key-value pair structure, is stored in the deduplication table and the mapping table and then delivered to the leader in the Raft consensus protocol; the process of storing it in the deduplication table involves sorting.

6. The metadata indexing and storage method for a distributed object storage system according to claim 1, characterized in that, Within the database, the composite key is stored using a two-level structure of red-black trees and arrays.

7. The metadata indexing and storage method for a distributed object storage system according to claim 6, characterized in that, The time complexity of finding the composite key m is O(log n), where n is the number of keys in each block index, and the search is implemented using a red-black tree.

8. The metadata indexing and storage method for a distributed object storage system according to claim 1, characterized in that, The database in question is the RocksDB database.

9. A metadata index storage device for a distributed object storage system, characterized in that, For implementing the method of any one of claims 1 to 8, comprising: The master node storage module receives metadata index information from the metadata server, converts it into a key-value pair structure, performs deduplication and mapping storage, and delivers it to the leader in the Raft consensus protocol. It then calls the database interface to store the converted key-value pair metadata index information. Based on the Raft consensus protocol, the leader synchronizes the converted key-value pair metadata index information to the slave nodes in the storage system cluster. The keys in the key-value pair structure are stored as composite keys. The key in the composite key identifies the starting address and offset of the index information, and the value in the composite key corresponds to the log address, i.e., the address within the database. There is no overlap between two composite keys, and the composite keys are in a completely ordered relationship. The slave node storage module is used to receive synchronization information sent by the master node, convert it into metadata index information in a key-value pair structure, and write it into the database for storage; the slave node and the master node are configured with a matching Raft consistency protocol.

Images