File read-write method of distributed database and computer program product and equipment thereof

Abstract

The invention relates to a file reading and writing method of a distributed database and a computer program product and equipment thereof. The file read-write method of the distributed database comprises the following steps: a write-in process of a write-in node of the distributed database applies for a write lock permission of a target file from a distributed lock; and the distributed lock feeds back the version number of the target file to the write-in process according to the write lock permission. And the write-in process applies for a data write-in space from the shared storage space, and writes the target file into the data write-in space. And writing the metadata of the target file into the log. And in response to an update trigger event of the log, judging whether the version number is the latest version number of the target file in the current distributed database. And if yes, updating the metadata. According to the file reading and writing method of the distributed database, performance loss caused by serial writing of the target file in a distributed lock protection mode is reduced, and the performance of accessing the same file scene by multiple processes is greatly improved.

Description

Technical Field

[0001] This invention relates to the field of file reading and writing technology, and in particular to a file reading and writing method for a distributed database, as well as its computer program product and equipment. Background Technology

[0002] When writing files to the database, once a file is locked, it can only be handled by one process. Other processes can only acquire the lock and process it after the current process releases it. In a cluster scenario, switching locks also involves actions such as flushing the cache to disk. Since the use of file locks can only be done serially, it greatly reduces the performance of file access.

[0003] The industry's main solution to lock conflicts is through file partitioning at the application layer. For example, node A accesses file a, and node B accesses file b. At the application layer, partitioning and isolation should be done as much as possible. Node A should avoid accessing file b as much as possible, and node B should also avoid accessing file a as much as possible. This reduces the problem of lock conflicts caused by different nodes accessing the same file.

[0004] However, existing file read / write methods in distributed databases place high demands on the application layer, requiring it to have partitioning capabilities. Moreover, file partitioning schemes can only solve the problem of preventing conflicts when writing files between nodes, but they cannot solve the problem of multiple processes writing to the same file. Within the same node, multiple processes writing to the same file are still serial, and their file write performance is still greatly limited. Summary of the Invention

[0005] One object of the present invention is to overcome at least one deficiency in the prior art and to provide a file reading and writing method for a distributed database, as well as a computer program product and device thereof.

[0006] A further objective of this invention is to optimize the method for writing target files, thereby improving the file writing performance of distributed databases.

[0007] Specifically, this invention provides a file read / write method for a distributed database, comprising: The write process of the write node in the distributed database requests write lock permission for the target file from the distributed lock; The distributed lock returns the version number of the target file to the writing process based on the write lock permission. The writing process requests data write space from the shared storage space and writes the target file to the data write space. Write the target file's metadata to the log; In response to log update trigger events, determine whether the version number is the latest version number of the target file in the current distributed database; If so, update the metadata.

[0008] Optionally, the steps for the distributed lock to report the version number of the target file to the writing process based on write lock permissions include: Distributed locks determine the existing version number of the target file; Update the version number based on the existing version number; The updated version number is fed back to the writing process as the version number of the target file.

[0009] Optionally, during the version number update process based on the existing version number, a synchronization lock can be added to the distributed lock to prevent other processes from requesting write lock permissions for the target file from the distributed lock.

[0010] Optionally, the synchronization lock can be released after the step of updating the version number based on the existing version number.

[0011] Optionally, if the version number is not the latest version number in the current distributed database, it also includes: Release the space where data is written.

[0012] Optionally, after determining whether the version number is the latest version number in the current distributed database, the following steps may also be included: The read process of the read node in the distributed database requests read lock permission for the target file from the distributed lock; The distributed lock sends the latest version number back to the reading process based on the read lock permission; Determine if the latest version number is greater than the version number of the target file being read; If so, the read process of the read node in the distributed database reads the metadata corresponding to the latest version number; obtains the physical address of the target file, and reads the target file.

[0013] Optionally, if the latest version number is greater than the version number of the read node, the following is also included: Update the metadata of nodes other than the read node.

[0014] Optionally, if the latest version number is less than or equal to the version number of the read node, the following is also included: The read process of a distributed database's read node reads the metadata corresponding to the read node's version number; Obtain the physical address of the target file from the metadata; The target file is read based on its physical address.

[0015] According to another aspect of the present invention, a computer program product is also provided, which, when executed by a processor, implements the steps of the file read / write method for a distributed database according to any of the preceding claims.

[0016] According to another aspect of the present invention, a computer device is also provided, including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the steps of the file read / write method for a distributed database according to any of the above claims.

[0017] This invention provides a file read / write method for a distributed database. The write process of a write node in the distributed database requests write lock permission for a target file from a distributed lock. The distributed lock then returns the version number of the target file to the write process based on the write lock permission. The write process then requests data write space from shared storage and writes the target file into the data write space. The metadata of the target file is written to a log. In response to a log update trigger event, it is determined whether the version number is the latest version number of the target file in the current distributed database. If so, the metadata is updated. After requesting write lock permission, the version number of the target file is returned to the write process, and the decision to update the metadata in the log is based on whether the version number is the latest. This method reduces the limitation of only being able to perform serial writes due to the protection mode of the distributed lock during file write operations, significantly improving the file write performance of the distributed database.

[0018] Furthermore, the distributed lock updates the version number based on the existing version number, and adds a synchronization lock during the version number update process to prevent other processes from requesting write lock permissions for the target file. Adding a synchronization lock during version number updates avoids concurrent conflicts between write lock requests and version number updates, ensuring that the version number is unique and accurate, which can further improve the file write performance of the distributed database.

[0019] The above and other objects, advantages and features of the present invention will become more apparent to those skilled in the art from the following detailed description of specific embodiments of the invention in conjunction with the accompanying drawings. Attached Figure Description

[0020] The following sections will describe some specific embodiments of the invention in detail by way of example and not limitation, with reference to the accompanying drawings. The same reference numerals in the drawings denote the same or similar parts or portions. Those skilled in the art should understand that these drawings are not necessarily drawn to scale. In the drawings: Figure 1 This is a flowchart illustrating a file read / write method for a distributed database according to an embodiment of the present invention. Figure 2 This is a flowchart illustrating the process of a distributed lock feeding back the version number of the target file to the writing process based on the write lock permission in a file read / write method for a distributed database according to an embodiment of the present invention. Figure 3 This is a flowchart illustrating the process after the step of determining whether the version number is the latest version number in the current distributed database in a file read / write method for a distributed database according to an embodiment of the present invention. Figure 4 This is a flowchart illustrating a file read / write method for a distributed database according to an embodiment of the present invention, where the latest version number is less than or equal to the version number of the reading node. Figure 5 This is a schematic diagram of the data flow in a file read / write method for a distributed database according to an embodiment of the present invention; Figure 6 This is a schematic diagram of a computer program product according to an embodiment of the present invention; Figure 7 This is a schematic diagram of a computer-readable storage medium according to an embodiment of the present invention; and Figure 8 This is a schematic diagram of a computer device according to an embodiment of the present invention. Detailed Implementation

[0021] Those skilled in the art should understand that the embodiments described below are merely a part of the embodiments of the present invention, and not all of the embodiments of the present invention. These partial embodiments are intended to explain the technical principles of the present invention and are not intended to limit the scope of protection of the present invention. Based on the embodiments provided by the present invention, all other embodiments obtained by those skilled in the art without creative effort should still fall within the scope of protection of the present invention.

[0022] It should be noted that the logic and / or steps represented in the flowchart or otherwise described herein can be considered as a ordered list of executable instructions for implementing logical functions, which can be specifically implemented in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus or device (such as a computer-based system, a processor-based system or other system that can fetch and execute instructions from, an instruction execution system, apparatus or device).

[0023] This invention provides a file read / write method for a distributed database, such as... Figure 1 As shown, the file read / write method of this distributed database includes at least the following steps S101 to S106.

[0024] In step S101, the write process of the write node in the distributed database requests write lock permission for the target file from the distributed lock. The distributed lock is a lightweight locking mechanism. The process of requesting write lock permission for the target file only applies to the target file and does not affect the read and write operations of other files. Moreover, the purpose of requesting the write lock is to obtain the version number rather than to hold the lock for a long time. This lays the foundation for multiple nodes and multiple processes to access the same file concurrently, breaking the limitations of traditional serial locks on concurrency performance.

[0025] In step S102, the distributed lock sends the version number of the target file back to the writing process based on the write lock permissions. The version number sent back by the distributed lock provides the basis for subsequent determination of whether the version number is the latest. After the writing process obtains the version number, it is released from the restriction of the distributed lock, and other processes can immediately request a new version number from the distributed lock, completely solving the serial blocking problem of traditional locks and greatly improving the concurrent writing capability of the same file.

[0026] In step S103, the writing process requests dedicated space from the shared storage space and writes the target file to the dedicated space. Requesting dedicated space from the shared storage space avoids overwriting existing data at the same address and supports the coexistence of multiple versions of the same file.

[0027] Step S104: Write the target file's metadata to the log. The metadata is written to the log first, awaiting subsequent verification to determine if the version number is the latest version number, before deciding whether to update the metadata. The log fully records the corresponding written metadata. When verifying the version number later, there's no need to reread the original data or rely on the local cache of the dependent nodes; the necessary information for verification can be obtained directly from the log. If the version number is not the latest, there's no need to perform a metadata update operation; simply mark the corresponding data space as reclaimable to avoid invalid updates consuming storage resources.

[0028] Step S105: In response to the log update trigger event, determine whether the version number is the latest version number of the target file in the current distributed database. Verification based on the version number fed back by the distributed lock can prevent older version data from overwriting newer version data, resolving consistency conflicts caused by concurrent writes from multiple processes.

[0029] Step S106: If the version number is the latest version number of the target file in the current distributed database, update the metadata. Only writes to the latest version are allowed to trigger metadata updates, ensuring that subsequent read processes can obtain the most valid data address and achieving read-write consistency. When updating metadata, the storage space corresponding to the old version data is marked as reclaimable, which can avoid multiple versions of data occupying redundant storage resources. At the same time, metadata updates do not affect the concurrent read and write of other processes, maintaining overall high concurrency performance and thus solving the global blocking problem caused by metadata updates under traditional distributed locks.

[0030] In some alternative embodiments, such as Figure 2 As shown, the step of the distributed lock feeding back the version number of the target file to the writing process based on the write lock permission includes at least the following steps S201 to S203.

[0031] Step S201: The distributed lock determines the existing version number of the target file. The distributed lock accurately locates the existing version number of the target file, ensuring that subsequent version updates have a clear basis and avoiding confusion such as version number jumps or duplications. Simultaneously, this step ensures that version number generation is based on the distributed lock, guaranteeing global consistency of version numbers acquired by all processes from the source, providing a reliable premise for subsequent version number determination.

[0032] Step S202 involves updating the version number based on the existing version number. This step ensures the uniqueness and order of the version number, while also aligning with the high-performance design of distributed locks. Taking the version number update operation as an example of incremental update: when the distributed lock receives a write lock request from the write process of the write node in the distributed database, it increments the existing version number by 1 and sends the result back to the write process. In this application, the version number update allows for a time-sequential mapping between version numbers, and the order of write operations can be directly determined by the version number.

[0033] Step S203 involves sending the updated version number as the version number of the target file back to the writing process. This can be achieved by checking whether the updated version number is the latest version number in subsequent checks to determine if the metadata has been updated.

[0034] In some optional embodiments, a synchronization lock is added to the distributed lock during the version number update process based on the existing version number to prevent other processes from requesting write lock permissions for the target file. The synchronization lock only takes effect during the extremely short operation of version number increment, forcing multiple nodes and processes to queue for updates. This ensures that multiple processes do not generate the same new version number based on the same existing version, keeping the version numbers unique and ordered, providing reliable support for subsequent determination of the latest version number. Furthermore, the synchronization lock is held for a very short time, released immediately after the version number update operation is completed, unlike traditional locks that control the entire write process for an extended period. This allows other processes to quickly request new version numbers, thus improving the file write performance of the distributed database.

[0035] In some optional embodiments, if the version number is not the latest version number in the current distributed database, the method further includes: releasing the data write space. Timely releasing the allocated dedicated data write space when the version number is not the latest version number in the current distributed database can quickly reclaim redundant storage resources and prevent invalid old version data from occupying shared storage capacity for a long time.

[0036] In some alternative embodiments, such as Figure 3 As shown, the step of determining whether the version number is the latest version number in the current distributed database includes at least the following steps S301 to S304.

[0037] In step S301, the read process of the read node in the distributed database requests read lock permission for the target file from the distributed lock. Requesting read lock permission does not affect read / write operations on other files, and the request process does not require waiting for the write lock to be released for a long time, avoiding serial blocking under traditional locking mechanisms and ensuring the smooth concurrency of read / write operations across multiple nodes and processes.

[0038] Step S302: The distributed lock sends the latest version number back to the reading process based on the read lock permissions. This step ensures that the version number obtained by the reading process is globally unique and real-time, avoiding consistency issues when reading old data from the source. The latest version number sent back by the distributed lock is the global sorting result of all write operations, not the version number cached locally by the reading node. The version number feedback corresponding to the read lock is only a query and return, without involving version number increment or long-term lock occupation, resulting in extremely high processing efficiency, no increase in read latency, and a reliable basis for subsequent version verification.

[0039] Step S303: Determine if the latest version number is greater than the version number of the target file being read. By comparing version numbers, two scenarios can be quickly filtered: if the local version is already the latest, read the local data directly to avoid invalid metadata updates; if the local version is outdated, trigger the latest data reading process to ensure accurate results. This judgment step requires no complex calculations and can be completed simply through numerical comparison. It avoids consistency issues caused by blindly reading old local data and eliminates the resource waste caused by forcibly refreshing regardless of version consistency, making read operations more targeted and improving overall read / write efficiency.

[0040] In step S304, if the latest version number is greater than the version number of the target file on the reading node, the reading process of the distributed database's reading node reads the metadata corresponding to the latest version number; obtains the physical address of the target file, and then reads the target file. Locating the metadata corresponding to the latest version number allows direct access to the physical address of that version of data, significantly reducing data location and reading latency. Furthermore, it reads the latest globally valid data, solving the problem of writing completed but not being able to read the latest data in a distributed environment. Simultaneously, this reading process, based on direct IO (DIO) mode and shared storage direct read characteristics, bypasses invalid caching, ensuring data consistency without blocking other write or read processes, achieving both data accuracy and concurrency performance in multi-node read / write mixed scenarios.

[0041] In some optional embodiments, when the latest version number is greater than the version number of the reading node, the method further includes updating the metadata of nodes other than the reading node. If the metadata of each node is not synchronized, other nodes will still perform read and write operations based on the old metadata, leading to data inconsistency or invalid operations. Updating the metadata of nodes other than the reading node allows the metadata of the entire cluster to be quickly updated to the latest version, ensuring that all subsequent read and write requests from all nodes are based on the unified, latest metadata. This eliminates consistency problems caused by differences in metadata between nodes from the source, improving the file read performance of the distributed database.

[0042] Furthermore, after the metadata is synchronized and updated, all nodes can identify the storage space corresponding to the old version of the metadata and mark the storage space corresponding to the old version of the metadata as recyclable. The recycling process is used to reclaim these redundant spaces, avoiding the problem that the old version space cannot be reclaimed in time due to the fact that the metadata of some nodes has not been updated. This improves the resource utilization of shared storage and further enhances the file reading performance of the distributed database.

[0043] In some alternative embodiments, such as Figure 4 As shown, when the latest version number is less than or equal to the version number of the read node, at least the following steps S401 to S403 are included.

[0044] Step S401: The reading process of the reading node of the distributed database reads the metadata corresponding to the version number of the reading node.

[0045] Step S402: Obtain the physical address of the target file from the metadata.

[0046] Step S403: Read the target file according to the physical address.

[0047] When the latest version number is less than or equal to the read node's version number, steps S401 to S403 offer the advantage of balancing read efficiency and data consistency, maximizing the use of local resources. Having confirmed through a distributed lock that the local version is not behind the latest global version, the read node directly reads the metadata corresponding to its own version, eliminating the need for cross-node requests or external collaboration, thus avoiding network transmission latency and increased distributed lock load. The physical address of the target file is accurately extracted from the local metadata, quickly locating the valid storage location without traversing and filtering multiple versions of data. Based on this physical address, the file is read directly, and combined with DIO mode to bypass caching, ensuring data authenticity and consistency across nodes, while eliminating invalid addressing and cross-node transmission, preventing the blocking of other read / write processes, significantly shortening read response time, and improving the overall cluster read speed, thus meeting the needs of efficient concurrent read / write in a distributed environment.

[0048] In some alternative embodiments, such as Figure 5As shown, the data flow of file read / write methods in a distributed database can be understood as follows: In step S511, process 1 of node 1 performs a write operation on file A, which first requires obtaining write lock permission from the distributed lock.

[0049] In step S512, after the distributed lock provides only a version number 1, it no longer prevents other processes from obtaining the version number.

[0050] In step S513, after obtaining the version number, process 1 requests data write space and performs data writing.

[0051] Step S514: After writing the data, the metadata is written to the log, which can be updated later.

[0052] Step S515: When updating, obtain the latest version number of file A from the distributed lock. If the current update version number is less than the latest version, no update is needed, and the written address space a will be released later.

[0053] In step S521, process 2 of node 2 also needs to modify file A, so it first needs to obtain write lock permission of the distributed lock.

[0054] In step S522, the distributed lock immediately assigns version number 2 to process 2 and then no longer prevents other processes from obtaining the version number.

[0055] In step S523, after obtaining the version number, process 2 requests data write space.

[0056] Step S524: Write the data.

[0057] Step S525: After writing the data, the metadata is written to the log. The update can be delayed. When updating, the latest version number of file A needs to be obtained from the distributed lock. If the currently held version number is found to be the latest, the metadata is updated.

[0058] In step S531, process 3 of node 1 wants to obtain data from file A, so it first obtains read lock permission from the distributed lock.

[0059] Step S532: Obtain the latest version number of the distributed lock feedback.

[0060] In step S533, the obtained version number is 2, while the version number of local node 1 is 1, so other nodes are required to refresh the logs.

[0061] In step S534, process 3 rereads the metadata of file A, obtains the physical address b, and reads the disk to get the latest data.

[0062] The aforementioned file read / write method for distributed databases reduces the performance overhead caused by serial file writes under distributed lock protection, significantly improving performance in scenarios where multiple processes access the same file. Furthermore, this method eliminates conflicts caused by file write locks, allowing multiple nodes, multiple processes, and mixed read / write scenarios to operate on the same file simultaneously, further enhancing performance in multi-node access to the same file. Distributed locks change from lock control to version number control. When writing, only the version number needs to be updated; when reading, only the latest version number is returned. Processes holding different version numbers can perform write operations, but all write operations require allocating new address space for writing, without modifying the original data. Therefore, multiple copies of the same data in a file can exist.

[0063] Data for the target file is written to the cache and logs, and may not be immediately committed to disk. However, when writing to disk, the latest version number must be obtained from the distributed lock. Then, the version numbers are compared. If the version number of the current write operation is less than the version number of the metadata on disk, the write operation is not performed, and the corresponding address space is marked as reclaimable, allowing the background garbage collection process to reclaim it. If the version number of the metadata written to disk is the latest, the address space corresponding to that data segment must be marked as reclaimable, allowing the background garbage collection process to reclaim it, and the latest address and version number information must be updated.

[0064] Each time data is written to the target file, including append and modify writes, new physical space needs to be allocated, and the original address space is marked as reclaimable. This operation is more suitable for all-flash hard drives, so this invention is more suitable for all-flash shared storage systems.

[0065] This embodiment also provides a computer program product 10, a computer-readable storage medium 20, and a computer device 30. Figure 6 This is a schematic diagram of a computer program product 10 according to an embodiment of the present invention. Figure 7 This is a schematic diagram of a computer-readable storage medium 20 according to an embodiment of the present invention. Figure 8 This is a schematic diagram of a computer device 30 according to an embodiment of the present invention. The computer program product 10 includes a computer program 11, which, when executed by the processor 32, implements the steps of the file read / write method for any of the above-described distributed database methods. A computer-readable storage medium 20 stores the computer program 11 thereon, which, when executed by the processor 32, implements the steps of the file read / write method for any of the above-described distributed database methods. The computer device 30 may include a memory 31, a processor 32, and the computer program 11 stored on the memory 31 and running on the processor 32.

[0066] The computer program 11 used to perform the operations of this invention may be assembly instructions, Instruction Set Architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, integrated circuit configuration data, or source code or object code written in any combination of one or more programming languages ​​and procedural programming languages. The computer program 11 may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network, including a Local Area Network (LAN) or Wide Area Network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, to perform aspects of this invention, electronic circuits, including, for example, programmable logic circuits, Field-Programmable Gate Arrays (FPGAs), or Programmable Logic Arrays (PLAs), may execute computer-readable program instructions to personalize the electronic circuits by utilizing state information from computer-readable program instructions.

[0067] For the purposes of this embodiment, computer program product 10 is a related product containing computer program 11. For the purposes of this embodiment, computer-readable storage medium 20 is a tangible device capable of holding and storing computer program 11, and can be any device capable of containing, storing, communicating, propagating, or transmitting program 11 for use by or in conjunction with an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable storage medium 20 include: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable optical disc read-only memory (CD-ROM), digital versatile disc (DVD), memory stick, floppy disk, mechanical encoding device, and any suitable combination thereof.

[0068] Computer device 30 can be, for example, a server, desktop computer, laptop computer, tablet computer, or smartphone. In some examples, computer device 30 can be a cloud computing node. Computer device 30 can be described in the general context of computer system executable instructions (such as program modules) executed by a computer system. Typically, program modules can include routines, programs, object programs, components, logic, data structures, etc., that perform specific tasks or implement specific abstract data types. Computer device 30 can be implemented in a distributed cloud computing environment where tasks are performed by remote processing devices linked through a communication network. In a distributed cloud computing environment, program modules can reside on local or remote computing system storage media, including storage devices.

[0069] Computer device 30 may include a processor 32 adapted to execute stored instructions and a memory 31 that provides temporary storage space for the operation of instructions during operation. The processor 32 may be a single-core processor, a multi-core processor, a computing cluster, or any other configuration. The memory 31 may include random access memory (RAM), read-only memory, flash memory, or any other suitable storage system.

[0070] Computer device 30 may also include a network adapter / interface and an input / output (I / O) interface. The I / O interface allows external devices that can be connected to the computer device to input and output data. The network adapter / interface provides communication between the computer device and a network, typically represented as a communication network.

[0071] Therefore, those skilled in the art should recognize that although numerous exemplary embodiments of the present invention have been shown and described in detail herein, many other variations or modifications conforming to the principles of the present invention can be directly determined or derived from the disclosure of the present invention without departing from the spirit and scope of the invention. Thus, the scope of the present invention should be understood and construed as covering all such other variations or modifications.

Claims

1. A file read / write method for a distributed database, comprising: The write process of the write node of the distributed database requests write lock permission for the target file from the distributed lock; The distributed lock sends the version number of the target file back to the writing process based on the write lock permission; The writing process requests data writing space from the shared storage space and writes the target file into the data writing space; Write the metadata of the target file into the log; In response to the log update trigger event, determine whether the version number is the latest version number of the target file in the current distributed database; If so, update the metadata.

2. The file read / write method for a distributed database according to claim 1, characterized in that, The step of the distributed lock feeding back the version number of the target file to the writing process based on the write lock permission includes: The distributed lock determines the existing version number of the target file; Update the version number based on the existing version number; The updated version number is fed back to the writing process as the version number of the target file.

3. The file read / write method for a distributed database according to claim 2, characterized in that, During the version number update process based on the existing version number, a synchronization lock is added to the distributed lock to prevent other processes from requesting write lock permissions for the target file from the distributed lock.

4. The file read / write method for a distributed database according to claim 3, characterized in that, The synchronization lock is released after the step of updating the version number based on the existing version number.

5. The file read / write method for a distributed database according to claim 1, characterized in that, If the version number is not the latest version number in the current distributed database, the following is also included: Release the space where the data was written.

6. The file read / write method for a distributed database according to claim 1, characterized in that, The step of determining whether the version number is the latest version number in the current distributed database further includes: The read process of the read node of the distributed database requests read lock permission for the target file from the distributed lock; The distributed lock sends the latest version number back to the reading process according to the read lock permission; Determine whether the latest version number is greater than the version number of the target file of the read node; If so, the reading process of the reading node of the distributed database reads the metadata corresponding to the latest version number; obtains the physical address of the target file, and reads the target file.

7. The file read / write method for a distributed database according to claim 6, characterized in that, If the latest version number is greater than the version number of the read node, the method further includes: Update the metadata of nodes other than the read node.

8. The file read / write method for a distributed database according to claim 6, characterized in that, If the latest version number is less than or equal to the version number of the read node, the method further includes: The read process of the read node of the distributed database reads the metadata corresponding to the version number of the read node; Obtain the physical address of the target file from the metadata; The target file is read based on the physical address.

9. A computer program product, comprising a computer program, characterized in that, When executed by a processor, the computer program implements the steps of the file read / write method for a distributed database as described in any one of claims 1 to 8.

10. A computer device, comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the steps of the file read / write method for a distributed database as described in any one of claims 1 to 8.

Images