Separated shared memory system and method based on multi-version memory pages

Abstract

The invention provides a separated shared memory system and method based on multi-version memory pages, which is applied to a distributed multi-master database and comprises a memory node and a plurality of computing nodes, the memory node stores a multi-version linked list of all version data pages; the computing node accesses a data page through a multi-version linked list and accesses data through a DRLU protocol; the DRLU protocol comprises a read operation protocol, a write operation protocol and a write submission protocol. Through multi-version management and a DRLU protocol, the lock contention is reduced, and the system performance in a high-concurrency scene is improved.

Description

Technical Field

[0001] This invention belongs to the field of distributed systems and database technology, specifically relating to a separate shared memory system and method based on multi-version memory pages. More specifically, it is a consistency maintenance method for a distributed multi-master database based on separate shared memory. Background Technology

[0002] Databases are one of the most crucial components of cloud computing systems. The throughput and latency of online transaction processing within cloud databases are critical to upper-layer applications. As applications grow in scale, they increasingly require cloud databases with high throughput and low latency. Furthermore, in addition to performance, operational costs are also a significant consideration for cloud databases.

[0003] To handle peak traffic demands, traditional cloud databases deploy servers based on the highest traffic volume, resulting in wasted server resources during off-peak hours. To improve resource utilization and hardware scalability in cloud computing scenarios, a significant research trend in recent years has been the adoption of compute-storage separation architectures for new cloud databases. Amazon Aurora, for example, employs this architecture. In this architecture, the database is divided into a compute layer and a storage layer, composed of compute nodes and storage nodes, respectively. Compute nodes typically run the database logic, such as handling SQL queries and transaction management, while storage nodes store the database data, ensuring data persistence. Compute nodes access data from storage nodes on demand via the network. This design not only improves system scalability and flexibility but also ensures high availability and data security.

[0004] Current mainstream cloud databases based on compute-storage separation often adopt a single-master, multi-slave architecture. This means that the compute nodes typically consist of a master node (RW node) that handles read or write requests, and multiple slave nodes (RO nodes) that can only handle read requests. This design implies that all write operations occur only on the master node, thus eliminating the possibility of multiple nodes modifying data, avoiding complex consistency issues, and improving system performance. Furthermore, in a single-master, multi-slave architecture, slave nodes can be freely scaled to handle varying read loads, enhancing system scalability.

[0005] Single-master databases based on compute-storage separation often perform well under read-heavy, write-light loads. However, when faced with heavy write loads, this architecture with only one master node becomes a bottleneck. In this architecture, the number of master nodes cannot be increased, and the resources available for adding master nodes are often limited. This is because cloud providers often provide resources across multiple instances on the same machine, so the scope for scaling a specific instance on the same machine is usually very small—for example, adding CPU / memory resources. Migrating the master node to a more resource-rich machine can lead to excessive downtime and still faces the limitations of a single machine's capacity. Therefore, multi-master databases are becoming increasingly necessary to achieve high scalability and availability.

[0006] PolarDB-MP is a multi-master cloud database solution proposed by Alibaba and has been deployed in production. PolarDB-MP introduces a distributed shared memory (PMFS) layer on top of its storage-compute separation architecture, acting as a new memory node. Compute nodes prioritize accessing the memory node to obtain data pages. On the memory node, PolarDB-MP employs the Polar Multi-Primary Fusion Server (PMFS). Transaction fusion includes a global timestamp for ordering transactions, resolving transaction visibility issues in distributed scenarios. Buffer Fusion manages global memory on the memory node, optimizing data storage and transmission using distributed shared memory. LockFusion addresses data consistency issues in multi-master databases by using read-write locks on each data page to ensure consistency, and integrates row locks into data rows to accelerate lock acquisition and release. Furthermore, PolarDB-MP implements local log sorting to ensure that modifications to the same data on different nodes are not out of order, thus facilitating better data recovery.

[0007] Its technical drawbacks are as follows: In PolarDB-MP, a read-write lock mechanism is used to handle cache consistency issues in this split shared memory environment. While this locking mechanism can solve the cache inconsistency problem, the probability of lock contention increases sharply when the system encounters high conflict loads, further impacting system performance and incurring significant consistency maintenance overhead. Furthermore, data transfer between compute nodes and memory nodes is done in units of data pages. Regardless of how much a data page has been modified, the entire data page is transferred, leading to network amplification issues, increasing network overhead, and affecting overall system performance.

[0008] Taurus-MM is a multi-master database solution proposed by Huawei. Taurus-MM introduces a Vector-Scalar clock algorithm (VS) for transaction ordering. The VS clock can generate both vector and scalar timestamps, thus achieving both low network consumption and ensuring database snapshot capabilities. In addition, Taurus-MM employs a hybrid page row locking mechanism, integrating row lock information into page locks to optimize the locking protocol and reduce network consumption. When the master node writes data to the storage node, Taurus-MM transmits logs instead of complete pages; the storage node replays the logs to generate the data, saving network bandwidth.

[0009] Its technical drawback is the high overhead of handling buffer consistency issues. When a node requests a page modified by another node, if the storage node has not yet generated the latest data for that page based on log replay, it must simultaneously transmit the data page and the log. Then, the compute node applies these logs to obtain the latest version of the page. This process typically involves more storage I / O, thus impacting performance, and the log application also consumes additional CPU cycles. Furthermore, Taurus-MM's lock-based pessimistic concurrency control suffers from a similar performance problem. The locking overhead becomes severe when readers and writers share a large amount of data.

[0010] This problem urgently needs to be solved. Summary of the Invention

[0011] In view of the deficiencies in the prior art, the purpose of this invention is to provide a separate shared memory system and method based on multi-version memory pages.

[0012] According to the present invention, a split shared memory system based on multi-version memory pages is applied to a distributed multi-master database, comprising: a memory node and multiple computing nodes; The memory node stores a multi-version linked list of all version data pages; The computing nodes access data pages through a multi-version linked list and access data through the DRLU protocol; the DRLU protocol includes a read operation protocol, a write operation protocol, and a write commit protocol.

[0013] Preferably, the multi-version linked lists of adjacent versions are stored in an incremental manner; the version information items of the multi-version linked lists are sorted in descending order according to the version number of the version information item.

[0014] Preferably, the read operation is performed via the read operation protocol of the DRLU protocol, including: Module A1: Enables the compute node to collect the current timestamp from the memory node via RDMA as the read ID for this read operation; Module A2: Based on the read ID and the multi-version linked list cached locally, search for the target data page; determine whether the target data page is cached; if the result is not cached, request the data page and all its incremental information from the memory node; if the result is cached, determine whether the version chain of the target data page is invalid; if the result is yes, obtain all locally lost incremental information from the memory node; if the result is no, trigger module A3 to work. Module A3: Copy the original data page and apply the incremental data of this version to form the data page for this read operation.

[0015] Preferably, the write operation is performed via the write operation protocol of the DRLU protocol, including: Module B1: Locks the target data page on the compute node to prevent other compute nodes from writing to it simultaneously; writes to the target data page; Module B2: Determine whether the target data page is cached; if not cached, request the data page and all its incremental information from the memory node; if cached, determine whether the version chain of the target data page is invalid; if yes, retrieve all locally lost incremental information from the memory node; if no, trigger module B3 to work. Module B3: Copy the original data page and apply the incremental data of this version to form the data page for this read operation.

[0016] Preferably, the write commit operation is performed via the write commit protocol of the DRLU protocol, including: Module C1: Initiates a commit to a memory node, causing the memory node to mark the commit and record all data pages committed; Module C2: Writes the new version's data page to the memory node incrementally, checks if the writing is complete, and if yes, increments the global timestamp and assigns a new version ID to this commit; if no, it does nothing. Module C3: Releases the locks on all data pages.

[0017] The present invention provides a method for a split shared memory based on multi-version memory pages, applied to a distributed multi-master database. This method is implemented through a split shared memory system based on multi-version memory pages, and includes: allowing computing nodes to access data pages via a multi-version linked list and accessing data via a DRLU protocol; the DRLU protocol includes a read operation protocol, a write operation protocol, and a write commit protocol.

[0018] Preferably, the multi-version linked lists of adjacent versions are stored in an incremental manner; the version information items of the version linked lists are sorted in descending order according to the version number of the version information item.

[0019] Preferably, the read operation is performed via the read operation protocol of the DRLU protocol, including: Step A1: Instruct the compute node to collect the current timestamp from the memory node via RDMA as the read ID for this read operation; Step A2: Based on the read ID and the multi-version linked list cached locally, find the target data page; determine whether the target data page is cached; if the result is not cached, request the data page and all its incremental information from the memory node; if the result is cached, determine whether the version chain of the target data page is invalid; if the result is yes, obtain all lost incremental information locally from the memory node; if the result is no, proceed to step A3. Step A3: Copy the original data page and apply the incremental data of this version to form the data page for this read operation.

[0020] Preferably, the write operation is performed via the write operation protocol of the DRLU protocol, including: Step B1: Lock the target data page on the compute node to prevent other compute nodes from writing to it simultaneously; write the target data page; Step B2: Determine whether the target data page is cached; if not, request the data page and all its incremental information from the memory node; if cached, determine whether the version chain of the target data page is invalid; if yes, retrieve all locally lost incremental information from the memory node; if no, proceed to step B3. Step B3: Copy the original data page and apply the incremental data of this version to form the data page for this read operation.

[0021] Preferably, the write commit operation is performed via the write commit protocol of the DRLU protocol, including: Step C1: Initiate a commit to the memory node, instruct the memory node to mark this commit, and record all data pages committed; Step C2: Write the new version's data page to the memory node incrementally, and determine whether the writing is complete. If yes, increment the global timestamp and assign a new version ID to this commit; if no, do nothing. Step C3: Release the locks on all data pages.

[0022] Compared with the prior art, the present invention has the following beneficial effects: 1. This invention reduces lock contention and improves system performance in high-concurrency scenarios through multi-version management and DRLU protocol.

[0023] 2. This invention employs an incremental compression mechanism, which significantly reduces network transmission overhead.

[0024] 3. This invention supports hardware and software co-design and can further optimize performance through hardware offloading. Attached Figure Description

[0025] Other features, objects, and advantages of the present invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 This is a schematic diagram of the D-RLU read operation process provided by the present invention; Figure 2 This is a schematic diagram of the D-RLU write operation process provided by the present invention; Figure 3 This is a schematic diagram of the D-RLU write commit process provided by the present invention. Detailed Implementation

[0026] The present invention will now be described in detail with reference to specific embodiments. These embodiments will help those skilled in the art to further understand the present invention, but do not limit the invention in any way. It should be noted that those skilled in the art can make several changes and improvements without departing from the concept of the present invention. These all fall within the protection scope of the present invention.

[0027] This invention provides a separate shared memory system and method based on multi-version memory pages, applicable to distributed multi-master databases. By introducing a multi-version memory page management mechanism, maintaining multi-version information of data pages based on a version linked list, and designing a DRLU (Distributed Read-Lock-Update Protocol) protocol to ensure data consistency in a multi-version environment, this invention includes three parts: read operation, write operation, and write commit, supporting incremental compression to reduce storage and network overhead. This invention effectively solves the data consistency problem between multiple master nodes and the network overhead caused by data transmission between nodes, improving the throughput and response speed of distributed databases in high-concurrency scenarios.

[0028] In summary, considering the shortcomings of existing technologies, the technical problems to be solved by this invention include: the data consistency problem among multiple master nodes and the network overhead problem caused by data transmission between nodes.

[0029] In multi-master databases, each node can read and write all data, requiring complex designs to maintain data consistency. In high-concurrency and frequently updated data scenarios, existing lock-based consistency maintenance schemes face significant lock overhead. In distributed environments, data transmission requires network communication, increasing lock holding time and becoming a bottleneck hindering further system performance improvements. Furthermore, the overhead caused by inter-node data transmission in multi-master databases, where data is modified on different nodes, necessitates substantial network transmissions to read the latest data, easily saturating network bandwidth and impacting system performance. Existing solutions, whether transmitting the latest data page or a combination of data pages and the latest logs, fail to effectively reduce network transmission size; each data read or write operation involves transmitting at least one data page.

[0030] This invention addresses the technical bottlenecks of existing distributed multi-master databases by proposing a separate shared memory based on multi-version memory pages to accelerate multi-master databases. This invention introduces multi-version memory pages, managing data page version information through a version linked list. Based on multi-version memory pages, this invention provides a DRLU protocol to ensure correct data consistency across multiple versions. Building upon the DRLU protocol, this invention designs an incremental compression function, recording incremental information between adjacent versions of the same data page. By storing and transmitting incremental information, storage and network overhead are reduced.

[0031] This invention introduces a multi-version management system on compute nodes and memory nodes, managing multi-version information of data pages through a linked list of versions. Memory nodes maintain a linked list of multiple versions for all data pages, while each compute node maintains its own locally cached linked list. Each linked list consists of multiple version information items, sorted in descending order of version number to ensure the linked list descends sequentially from head to tail. Each version information item has the following fields: version number, data pointer, and predecessor / successor pointers. The version number records the version number of the information item, the data pointer points to the incremental data corresponding to that version, and the predecessor / successor pointers point to the previous and successor information items of the information item, thus maintaining the linked list structure.

[0032] On the compute node, each version information item will also have an additional field to record whether the incremental data exists locally. For the compute node, there will also be an invalidation flag at the head of the version list to record whether the version list has become invalid. That is, check whether the invalidation flag is 0. If the result is yes, it means that the local version list has the latest version data. If the result is no, it means that the version information has been updated by other nodes.

[0033] The DRLU protocol is the core method of this invention, ensuring that the system can correctly maintain data consistency across multiple versions. The DRLU protocol consists of three parts: the read operation protocol, the write operation protocol, and the write commit protocol.

[0034] D-RLU Read Operation: Step 1: Before the entire read operation begins, the compute node first obtains the latest timestamp from the memory node via RDMA as the read version ID for this operation. A series of read operations on this compute node are performed based on this version ID. When a reader needs to access a specific data page, it uses this version ID to search for the appropriate version of the data page.

[0035] Step 2: Locate the data page you need to access in the locally cached version list.

[0036] Step 3: For data pages that need to be accessed, if they are not cached, the data page and all incremental information will be requested from the memory node. For data pages that are already cached, the expiration flag of the version chain will be checked. If it is found to be expired, all locally lost incremental information will be retrieved from the memory node.

[0037] Step 4: After the above operations are completed, the original data page will be copied and the incremental information required for this version will be applied to it to form the final data page for this read operation.

[0038] Specifically, the incremental information consists of multiple incremental units, each of which is responsible for recording changes in data of a certain length, with a default length of 8 bytes. Users can also configure different lengths according to different usage scenarios.

[0039] Specifically, each increment unit consists of three fields: the original data field, the current data field, and the offset field. The original data field records the data before modification, the current data field records the data after modification, and the offset field records the specific location of the increment within the entire data page. When applying specific increment data, the reader iterates through all increment units, locates the specific position of the record in the unit based on the offset field, and then modifies the data page using the current data field of the increment unit.

[0040] D-RLU write operation: Step 1: When the write operation begins, the compute node first locks the data page to prevent other nodes from writing at the same time.

[0041] Step 2: For the data page that needs to be accessed, if it is not cached, the data page and all incremental information will be requested from the memory node. For the data page that is already cached, the expiration flag of the version chain will be checked. If it is found to be expired, all locally lost incremental information will be retrieved from the memory node.

[0042] Step 3: Copy the original data page and apply all the incremental data to it to form the final data page for this write operation.

[0043] Step 4: The writer performs modification operations on the data page. Specifically, when the writer writes to the data page, corresponding incremental information is generated for each write operation.

[0044] The D-RLU write commit operation includes: Step 1: The writer initiates a commit operation to the memory node. The memory node marks this commit and records all data pages subsequently committed.

[0045] Step Two: The writer initiates multiple write operations to the memory node for this commit, incrementally writing the new version's data pages into the memory node's memory. At this point, the version ID written is UNREADABLE_VERSION. For other nodes, reading the UNREADABLE_VERSION version means they need to confirm the current actual version with the memory node.

[0046] Step 3: After the write operation on the last data page is completed, the compute node sends a commit completion request to the memory node. The memory node will increment the global timestamp and assign a new version ID for this commit.

[0047] Step 4: Release the locks on all data pages and complete the commit operation.

[0048] A multi-version split shared memory method provided by the present invention includes: The system manages multiple versions of data pages using a version linked list; maintains data consistency using the DRLU protocol based on multiple version memory pages; and implements an incremental compression mechanism to store and transmit incremental information between data page versions.

[0049] Specifically, the DRLU protocol includes: a read operation protocol: the compute node accesses the appropriate version of the data page based on the read version ID, and requests and applies incremental information when necessary; a write operation protocol: the compute node locks the data page, obtains and applies incremental information, and makes modifications; and a write commit protocol: the writer commits the new version incrementally, and the memory node releases the lock after allocating the new version ID.

[0050] Specifically, the incremental compression mechanism includes: recording incremental information between adjacent versions of data pages; and reducing network overhead by transmitting incremental data instead of complete data pages.

[0051] According to the present invention, a multi-version separated shared memory system includes: a memory node for maintaining a multi-version linked list of global data pages; a compute node for maintaining a multi-version linked list of local caches and interacting with the memory node via the DRLU protocol; and a network module for supporting efficient data transmission.

[0052] Specifically, the DRLU protocol can be implemented through hardware acceleration.

[0053] The consistency of the system is guaranteed in the following specific way.

[0054] For readers, the DRLU read operation protocol ensures that the data page version they read is a consistent version at any given time. Specifically, if a reader uses timestamp T0 as the version for this operation at the beginning, the DRLU read operation protocol will ensure that all data pages read are the latest version less than T0. This means that readers can access a consistent view at time T0, guaranteeing reader consistency.

[0055] For writers, the DRLU write operation protocol, which uses locking before the write operation, ensures mutual exclusion among writers and maintains writer consistency. Furthermore, the DRLU write commit protocol ensures that newly written data is not visible to other readers until it is committed and has a version number, preventing readers from reading inconsistent data.

[0056] In summary, the consistency of the entire system is guaranteed through the three protocols of DRLU.

[0057] Example 1: According to the multi-version split shared memory method provided by the present invention, take the example of a computing node attempting to read a data page that already exists locally and has been modified and committed by other computing nodes before the read operation begins.

[0058] Step 1: The compute node first obtains the latest timestamp t1 from the memory node via RDMA, which serves as the read version ID for this operation.

[0059] Step 2: The compute node finds the version list of the data page in its local cache.

[0060] Step 3: Since this version of the linked list has been cached, the compute node discovers that the data page has been modified by other nodes by checking the invalidation flag. Therefore, it retrieves all locally lost incremental information from the memory node and reads all incremental data less than version t1 into its local machine.

[0061] Step 4: Copy the original data page and apply the incremental data required for this version to it. That is, apply all incremental data less than t1 to the copied data page to form the final data page for this read operation.

[0062] Example 2: According to the multi-version split shared memory method provided by the present invention, take the example of a computing node attempting to write a data page that does not exist locally.

[0063] Step 1: The compute node first requests the memory node to lock the data page.

[0064] Step 2: The compute node attempts to find the data page in its local cache, but finds that the data page is not cached. Therefore, it requests the data page and all incremental information from the memory node to ensure that it can access the latest version of the data page.

[0065] Step 3: The compute node replicates the original data page and applies all incremental data to it to form the final data page for this write operation, which is the latest version of the data page.

[0066] Step 4: The writer performs local modifications on the data page.

[0067] Example 3: According to the multi-version split shared memory method provided by the present invention, take the example of a computing node attempting to submit data page p1 and data page p2 that have been modified.

[0068] Step 1: The compute node initiates a commit operation to the memory node. The memory node records the subsequent multiple data page write operations and treats them as a single commit.

[0069] Step 2: The compute node initiates write operations to the memory node for data pages p1 and p2 respectively, writing the modifications incrementally into the memory of the memory node. It then marks their versions as UNREADABLE_VERSION to prevent other compute nodes from reading this data during this process.

[0070] Step 3: After completing the write operation on data page p2, the compute node sends a commit completion request to the memory node. At this time, the memory node atomically increments the global timestamp by one and uses the original timestamp value as the new version ID for this commit. This version ID will overwrite the UNREADABLE_VERSION marked in Step 2. The data of this version is now visible to other nodes.

[0071] Step 4: The compute node requests the memory node to release the locks on data pages p1 and p2, and then commits the operation.

[0072] Those skilled in the art will understand that, besides implementing the system and its various devices, modules, and units provided by this invention in the form of purely computer-readable program code, the same functions can be achieved entirely through logical programming of the method steps, making the system and its various devices, modules, and units of this invention function in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, the system and its various devices, modules, and units provided by this invention can be considered as a hardware component, and the devices, modules, and units included therein for implementing various functions can also be considered as structures within the hardware component; alternatively, the devices, modules, and units for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0073] Specific embodiments of the present invention have been described above. It should be understood that the present invention is not limited to the specific embodiments described above, and those skilled in the art can make various changes or modifications within the scope of the claims, which do not affect the essence of the present invention. Unless otherwise specified, the embodiments and features described in this application can be arbitrarily combined with each other.

Claims

1. A split shared memory system based on multi-version memory pages, applied to a distributed multi-master database, characterized in that, include: One memory node and multiple compute nodes; The memory node stores a multi-version linked list of all version data pages; The computing nodes access data pages through a multi-version linked list and access data through the DRLU protocol; the DRLU protocol includes a read operation protocol, a write operation protocol, and a write commit protocol.

2. The split shared memory system based on multi-version memory pages according to claim 1, characterized in that, The multi-version linked lists of adjacent versions are stored in an incremental manner; the version information items of the multi-version linked lists are sorted in descending order according to the version number of the version information item.

3. The split shared memory system based on multi-version memory pages according to claim 1, characterized in that, The read operation is performed using the DRLU protocol, including: Module A1: Enables the compute node to collect the current timestamp from the memory node via RDMA as the read ID for this read operation; Module A2: Based on the read ID and the multi-version linked list cached locally, search for the target data page; determine whether the target data page is cached; if the result is not cached, request the data page and all its incremental information from the memory node; if the result is cached, determine whether the version chain of the target data page is invalid; if the result is yes, obtain all locally lost incremental information from the memory node; if the result is no, trigger module A3 to work. Module A3: Copy the original data page and apply the incremental data of this version to form the data page for this read operation.

4. The split shared memory system based on multi-version memory pages according to claim 1, characterized in that, Write operations are performed using the write operation protocol of the DRLU protocol, including: Module B1: Locks the target data page on the compute node to prevent other compute nodes from writing to it simultaneously; writes to the target data page; Module B2: Determine whether the target data page is cached; if not cached, request the data page and all its incremental information from the memory node; if cached, determine whether the version chain of the target data page is invalid; if yes, retrieve all locally lost incremental information from the memory node; if no, trigger module B3 to work. Module B3: Copy the original data page and apply the incremental data of this version to form the data page for this read operation.

5. The split shared memory system based on multi-version memory pages according to claim 1, characterized in that, The write commit operation is performed using the write commit protocol of the DRLU protocol, including: Module C1: Initiates a commit to a memory node, causing the memory node to mark the commit and record all data pages committed; Module C2: Writes the new version's data page to the memory node incrementally, checks if the writing is complete, and if yes, increments the global timestamp and assigns a new version ID to this commit; if no, it does nothing. Module C3: Releases the locks on all data pages.

6. A method for separate shared memory based on multi-version memory pages, applied to a distributed multi-master database, implemented based on the separate shared memory system based on multi-version memory pages as described in any one of claims 1 to 5, characterized in that, include: This allows compute nodes to access data pages via a multi-version linked list and to access data via the DRLU protocol. The DRLU protocol includes a read operation protocol, a write operation protocol, and a write commit protocol.

7. The method for separate shared memory based on multi-version memory pages according to claim 6, characterized in that, The multi-version linked lists of adjacent versions are stored in an incremental manner; the version information items of the multi-version linked lists are sorted in descending order according to the version number of the version information item.

8. The method for separate shared memory based on multi-version memory pages according to claim 6, characterized in that, The read operation is performed using the DRLU protocol, including: Step A1: Instruct the compute node to collect the current timestamp from the memory node via RDMA as the read ID for this read operation; Step A2: Based on the read ID and the multi-version linked list cached locally, find the target data page; determine whether the target data page is cached; if the result is not cached, request the data page and all its incremental information from the memory node; if the result is cached, determine whether the version chain of the target data page is invalid; if the result is yes, obtain all lost incremental information locally from the memory node; if the result is no, proceed to step A3. Step A3: Copy the original data page and apply the incremental data of this version to form the data page for this read operation.

9. The method for separate shared memory based on multi-version memory pages according to claim 6, characterized in that, Write operations are performed using the write operation protocol of the DRLU protocol, including: Step B1: Lock the target data page on the compute node to prevent other compute nodes from writing to it simultaneously; write the target data page; Step B2: Determine whether the target data page is cached; if not, request the data page and all its incremental information from the memory node; if cached, determine whether the version chain of the target data page is invalid; if yes, retrieve all locally lost incremental information from the memory node; if no, proceed to step B3. Step B3: Copy the original data page and apply the incremental data of this version to form the data page for this read operation.

10. The method for separate shared memory based on multi-version memory pages according to claim 6, characterized in that, The write commit operation is performed using the write commit protocol of the DRLU protocol, including: Step C1: Initiate a commit to the memory node, instruct the memory node to mark this commit, and record all data pages committed; Step C2: Write the new version's data page to the memory node incrementally, and determine whether the writing is complete. If yes, increment the global timestamp and assign a new version ID to this commit; if no, do nothing. Step C3: Release the locks on all data pages.

Images