A data page access method, a cache management method, a construction method, a device, a storage medium and a program product

Abstract

The application provides a data page access method, a cache management method, a construction method, equipment, a storage medium, and a program product. The method comprises at least: obtaining a read request of a target data page, wherein the read request carries a target version identifier of the target data page; obtaining a synchronization version identifier of a current synchronization control point; comparing the target version identifier with the synchronization version identifier; when the target version identifier is later than the synchronization version identifier, reading the target data page from a local cache of the computing node; and when the target version identifier is not later than the synchronization version identifier, reading the target data page from the shared storage.

Description

Technical Field

[0001] This application relates to database system and cloud computing architecture technologies, and in particular to a data page access method, cache management method, construction method, device, storage medium, and program product. Background Technology

[0002] With the rapid development of cloud infrastructure, traditional relational database hosting models (such as RDS) face problems such as poor scalability and weak fault tolerance in large-scale cluster environments. To enhance system maintainability and horizontal scalability, the industry is gradually shifting to a "storage-compute separation" architecture, dividing the database system into master nodes (responsible for generating write-ahead logs, WAL) and compute nodes (building locally readable views through log replay). However, distributed log replay causes problems of "inconsistent data versions" and "recovery delays" in real-world scenarios—due to the different WAL progression paces of different nodes, in the absence of an effective coordination mechanism, the data page content of multiple nodes may be in an inconsistent version state.

[0003] There are two main technological approaches to address this challenge: Existing Solution 1: Log-driven data page replay mechanism. When the primary instance performs an update, it only writes the change log to remote storage, and the PageServer replays it to generate the data page. In this solution, when a data page on the primary instance is frequently modified and memory space is tight, the page may be frequently evicted and reloaded. If the PageServer log replay progress is lagging at this time, the primary instance must wait for the page to be replayed to the corresponding version when reading it, causing read latency and limiting system throughput.

[0004] Existing Solution 2: High-performance page flushing mechanism based on RDMA. This solution leverages high-end network hardware (such as RDMA) and assumes the network is not a bottleneck. The primary instance simultaneously flushes logs and data pages directly to remote storage and allocates dual memory spaces to manage page modification history. To ensure version consistency, this solution requires verification during disk flushing to ensure the flushed page version does not exceed the replay point of the slowest standby instance. When the standby instance malfunctions or replay is delayed, memory space cannot be released in a timely manner, hindering new page loading and affecting the stable operation of the primary instance.

[0005] The two solutions described above each have the following problems: In Option 1, when a compute node reads a data page again after it has been evicted from its local cache, it needs to wait for the shared storage service to replay the log chain and reconstruct the data page, resulting in high access latency and a high dependence on the log replay progress.

[0006] In Option 2, the page-flipping operation is limited by the playback progress of the slowest standby machine. When the standby machine malfunctions or playback is delayed, the memory space cannot be released in time, affecting system stability and memory reclamation efficiency.

[0007] Therefore, how to achieve low-latency multi-version data page access under a storage-compute separation architecture, while reducing the strong dependence on log replay progress and avoiding page flushing operations, has become an urgent technical problem to be solved. Summary of the Invention

[0008] This application provides a data page access method, a cache management method, a batch construction method, an electronic device, a computer storage medium, and a computer program product.

[0009] The data page access method provided in this application is applied to a compute node, wherein the compute node is equipped with a local cache and connected to shared storage, and the method includes: Obtain a read request for the target data page, wherein the read request carries the target version identifier of the target data page; Get the synchronization version identifier of the current synchronization control point; Compare the target version identifier with the synchronization version identifier; When the target version identifier is later than the synchronization version identifier, the target data page is read from the local cache of the computing node; When the target version identifier is not later than the synchronization version identifier, the target data page is read from the shared storage.

[0010] In some implementations, the local cache is used to store copies of data pages with version identifiers later than the current synchronization control point; the shared storage is used to store versions of data pages with version identifiers no later than the current synchronization control point.

[0011] In some implementations, reading the target data page from the local cache of the computing node includes: Check whether the local cache stores a copy of the data page corresponding to the target version identifier of the target data page; If the local cache does not store a copy of the data page corresponding to the target version identifier, then the base version is obtained from the shared storage, and the incremental log between the target version identifier and the synchronization version identifier is applied to the base version to reconstruct the target data page, and the reconstructed target data page is stored in the local cache.

[0012] The data page cache management method provided in this application is applied to a compute node, wherein the compute node is equipped with a local cache and connected to shared storage, and the method includes: Obtain the synchronization version identifier of the current synchronization control point, and determine the synchronization version identifier of the current synchronization control point as the cache security threshold; Compare the version identifier of the data page to be managed with the cache security threshold; When the version identifier of the data page to be managed is later than the cache security threshold, a copy of the data page to be managed is retained in the local cache; When the version identifier of the data page to be managed is not later than the cache security threshold, the copy of the data page to be managed is evicted from the local cache.

[0013] In some implementations, the version identifier of the data page obtained by the computing node from the shared storage is no later than the current synchronization control point.

[0014] In some implementations, the current synchronization control point is a synchronization checkpoint currently visible to the shared storage service client, and the synchronization version identifier of the current synchronization control point is determined based on the processing progress of the slowest processing node among all computing nodes.

[0015] The data page batch construction method provided in this application is applied to a shared storage service client, which is connected to multiple computing nodes. The method includes: Detect synchronization control points appearing in the log stream; In response to the emergence of the synchronization control point, the version identifier of the synchronization control point is used as the reconstruction boundary to obtain the log records within the reconstruction boundary; Data pages are constructed in batches based on the log records, wherein multiple modifications to the same data page within the reconstruction boundary are merged into a single data page write operation.

[0016] This application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method described in any of the above-mentioned embodiments.

[0017] This application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described in any of the above claims.

[0018] This application also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the method described in any of the above-described embodiments.

[0019] The above technical solution has the following beneficial effects: First, addressing the technical issues of "long log replay paths and high read latency," this application provides a version-matching read mechanism in its data page access method: by obtaining the target version identifier and the synchronization version identifier and comparing them, data pages are read from either the local cache or shared storage based on the comparison result. Since the local cache stores copies of data pages later than the synchronization control point, and the shared storage stores versions of data pages no later than the synchronization control point, compute nodes can directly determine the read source based on the version boundary, avoiding the process of waiting for the log replay chain to be reconstructed and significantly reducing read latency.

[0020] Second, regarding the issue of "reading a cached page again after it has been evicted requires waiting for reconstruction", in the optional implementation of the above data page access method, the compute node reads directly from the local cache when the cache hits and refills the cache after reconstruction when the cache misses, so that reading again after being evicted can directly hit the local cache, further shortening the access path.

[0021] Third, addressing the issue of memory blocking caused by page flushing operations being limited by the slowest standby machine, this application provides a page-level conflict isolation mechanism in its data page cache management method: by obtaining the synchronization version identifier of the synchronization control point as a cache safety threshold, data pages with version identifiers later than the threshold are retained, while data pages with version identifiers no later than the threshold are evicted. Each compute node can independently manage its local cache based on this threshold, without needing to coordinate page flushing progress, avoiding memory release blocking during page flushing operations, reducing inter-node collaboration dependencies, and improving system stability and scalability.

[0022] Fourth, addressing the issue of "write amplification caused by replaying logs one by one in shared storage," this application provides a log aggregation and reconstruction mechanism based on synchronization control points in the batch construction method for data pages: the shared storage service side detects logs using the synchronization control point as the reconstruction boundary and constructs data pages in batches, merging multiple modifications to the same data page within the boundary into a single write operation. This aggregation approach significantly reduces the number of repeated flushes of data pages, lowers the write amplification effect on the shared storage side, and improves write efficiency. Attached Figure Description

[0023] Figure 1 A schematic diagram of the architecture of a multi-version data page collaborative sharing system with separate computing and storage logic provided in an embodiment of this application; Figure 2 A schematic diagram of the local cache state of each computing node after the synchronization control point, provided for embodiments of this application; Figure 3 A flowchart illustrating the data page access method provided in this application embodiment; Figure 4 A flowchart illustrating the data page cache management method provided in this application embodiment; Figure 5 A flowchart illustrating the batch construction method for data pages provided in this application embodiment; Figure 6 This is a schematic diagram of the structure of a data page access device provided in an embodiment of this application; Figure 7 A schematic diagram of the structure of the data page cache management device provided in the embodiments of this application; Figure 8 A schematic diagram of the structure of the data page batch construction apparatus provided in the embodiments of this application; Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0024] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0025] In the description of this application, it should be noted that, unless otherwise expressly specified and limited, the terms "connected" and "linked" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection, an electrical connection, or a communication connection; they can refer to a direct connection or an indirect connection through an intermediate medium; they can refer to the internal connection of two components or the interaction between two components. Those skilled in the art can understand the specific meaning of the above terms in this application according to the specific circumstances.

[0026] It should be noted that, in this application, the terms "later than" and "no later than" are used to describe the sequential relationship between version identifiers. Since version identifiers (such as log sequence numbers, LSNs) monotonically increase over time, "later than" means that one version identifier is generated after another, and "no later than" means that one version identifier is the same as or precedes another. Unless otherwise specified, "later than" is equivalent to "greater than," and "no later than" is equivalent to "less than or equal to."

[0027] System Architecture Please see Figure 1 , Figure 1 This is a schematic diagram of the architecture of a multi-version data page collaborative sharing system with separate computing and storage logic, provided in an embodiment of this application.

[0028] The system provided in this application includes three types of functional units: primary computing node, auxiliary computing nodes, and shared log reconstruction service unit.

[0029] The primary computing unit handles read and write requests, maintains a cache of the latest version of data pages, and writes change logs to the log service. The auxiliary computing unit processes some read requests, performs log replay operations from the primary node, and maintains a local cache. The shared log reconstruction service unit centrally processes synchronization control points in the logs of each node, reconstructs cold data pages, and supports global access.

[0030] During the processing of external transaction requests, the primary computing unit generates numerous changes to memory pages within its internal buffer area. These modified memory pages are marked as temporary pages requiring subsequent persistence and stored in the computing unit's NVMe local storage. Simultaneously, the auxiliary computing unit, while processing read requests, synchronizes the modifications made by the primary computing unit to the backup computing unit via logs for log redo. Modified memory pages are also marked as temporary pages requiring subsequent persistence and stored in the auxiliary computing unit's NVMe local storage. When the log reconstruction service in the shared data area detects a new synchronization control point in the logical log, it triggers a batch page content construction operation, ensuring that the processing progress of this node does not exceed the reconstruction boundary of the slowest processing unit in the current system.

[0031] In this application, "shared storage" refers to the physical storage medium or storage volume used for persistently storing data page versions. "Shared storage service client" refers to a logical service unit deployed independently or integrated on the shared storage side, used to perform computational operations such as log detection, data page reconstruction, and synchronization control point management. "Local cache" refers to non-volatile high-speed storage media (e.g., NVMe solid-state drives) or a portion of its storage space deployed locally on each compute node, used to store copies of data pages with version identifiers later than the current synchronization control point. "Version identifier" refers to an identifier (e.g., log sequence number LSN) used to uniquely identify the order of data page versions; the version identifier monotonically increases over time, with larger values ​​indicating newer versions. "Synchronization control point" refers to the global version boundary identified and marked in the log stream by the shared storage service client, maintained uniformly by the shared log reconstruction service unit based on the processing progress of all compute nodes. Data pages with version identifiers later than the current synchronization control point are considered active data and need to be obtained or constructed from the compute node's local cache; data pages with version identifiers no later than the current synchronization control point are considered persistent data, can be directly obtained from shared storage, and can be safely evicted.

[0032] Please see Figure 2 , Figure 2This is a schematic diagram of the local cache state of each computing node after the synchronization control point, provided for embodiments of this application. Figure 2 In this example, assuming log sequence number LSN=4 is a synchronization control point, versions before LSN=4 can be directly obtained from the shared storage area, while versions after LSN=4 are stored in the NVME local cache of each compute instance. Data blocks marked in red indicate content changes after the synchronization boundary, requiring each compute node to retain a corresponding copy in its local cache; data blocks marked in blue indicate content that has not been effectively changed since the synchronization boundary, and each node can decide whether to retain a copy based on its own access frequency. Figure 2 The five compute instances (Instances 1 through 5) each maintain their own local caches. The red data blocks are cached in all instances (because data pages later than the synchronization control point must have a copy in the local cache), while the blue data blocks differ depending on the instance's access pattern—Instance 1 retains the blue data blocks (potentially recently accessed hot data), while the blue data blocks in Instance 5 have been evicted (low access frequency, safe to retrieve from shared storage). This diagram visually demonstrates the independence and flexibility of each compute node in managing its local cache: for data blocks after the synchronization boundary, all nodes must forcibly retain them; for data blocks before the synchronization boundary, each node can decide whether to evict or retain them based on its own circumstances.

[0033] Example 1: Data Page Access Method Please see Figure 3 , Figure 3 This is a flowchart illustrating a data page access method provided in an embodiment of this application. The data page access method is applied to a computing node (including a main computing unit and an auxiliary computing unit), wherein the computing node is equipped with a local cache and connected to shared storage. The method includes the following steps: Step 301: Obtain the read request for the target data page.

[0034] The compute node receives a read request from a user or an upper-layer application, the read request carrying a target version identifier for the target data page. The target version identifier indicates the version of the data page expected to be retrieved in this read operation. For example, when a user needs to read the content of a data page at log sequence number LSN=300, the target version identifier carried in the read request is LSN=300. The specific form of the target version identifier can be a log sequence number (LSN), or any other identifier that can uniquely identify the version order of data pages; this application does not limit this.

[0035] Step 302: Obtain the synchronization version identifier of the current synchronization control point.

[0036] The compute nodes obtain the synchronization version identifier of the current synchronization control point. The synchronization control point is a global version boundary uniformly maintained by the shared storage service. Compute nodes can obtain the synchronization version identifier of the current synchronization control point through the communication interface with the shared storage service, or from the synchronization control point information periodically broadcast or pushed by the shared storage service. The synchronization version identifier of the current synchronization control point is determined based on the processing progress of the slowest processing node among all compute nodes—that is, when determining the location of the synchronization control point, the shared storage service needs to refer to the node with the slowest log replay progress among all compute nodes to ensure that the logs before this synchronization control point have been replayed on all nodes or have been persistently constructed in the shared storage. This ensures that any compute node can directly obtain a complete copy from the shared storage when accessing data pages before this synchronization control point. In this way, the synchronization control point guarantees the bottom line of global consistency—that is, the read progress of any node will not exceed the processing boundary of the slowest node globally.

[0037] As a specific example of this application, assuming the synchronization version identifier of the current synchronization control point is LSN=100, all compute instances will cache copies of data pages with version identifiers greater than LSN=100 in their local cache. This means that for data pages with version identifiers later than LSN=100, compute nodes can expect them to exist in their local cache (under normal operating conditions), and thus can read them directly from the local cache without accessing shared storage or triggering log replay.

[0038] Step 303: Compare the target version identifier with the synchronization version identifier.

[0039] The compute node compares the target version identifier obtained in step 301 with the synchronization version identifier obtained in step 302 to determine whether the target version identifier is later than the synchronization version identifier. This comparison operation can be implemented through numerical comparison—since the version identifier (such as LSN) monotonically increases over time, the value of the version identifier directly reflects the order of versions: the version with the larger value is later than the version with the smaller value.

[0040] The comparison logic in this version can be expressed by the following formula:

[0041] Here, source indicates the result of reading from the source. Indicates the target version identifier of the target data page. This indicates the synchronization version identifier of the current synchronization control point. When... When the target version is later than the synchronization control point, choose to read from the local cache; when When the target version is no later than the synchronization control point, choose to read from shared storage.

[0042] Step 304: When the target version identifier is later than the synchronization version identifier, read the target data page from the local cache of the computing node.

[0043] If the comparison result shows that the target version identifier is later than the synchronization version identifier (i.e., the value of the target version identifier is greater than the value of the synchronization version identifier, such as V_target = LSN=300, V_cp = LSN=100), it indicates that the version of the target data page is after the synchronization control point and belongs to active data that has not yet been persistently constructed in shared storage. According to the cache management rules of this application, copies of data pages with version identifiers later than the current synchronization control point should be stored in the local cache of the compute node. Therefore, the compute node reads the target data page from the local cache.

[0044] Compared with existing technologies, the mechanism of this application has significant advantages. In existing technical solutions (such as the log-driven asynchronous recovery mechanism described in the background art), taking the re-reading of memory data page Page300 in the auxiliary computing instance after it has been evicted as an example, the instance needs to read the basic data page of LSN=100 from the remote shared storage area, and then obtain the complete log chain of WAL (100~300) and replay it line by line to obtain the data page of LSN=300. This process involves multiple links such as network transmission, log reading and sequential replay, resulting in high latency. In this application, since the latest version page of memory evictment is cached in the local NVME storage, the data page of LSN=300 can be directly hit from the local cache during the next read, completely skipping the replay chain of WAL logs. The version is directly hit, which greatly accelerates the access path and reduces the dependency on log reconstruction.

[0045] Step 305: When the target version identifier is not later than the synchronization version identifier, read the target data page from the shared storage.

[0046] If the comparison result shows that the target version identifier is not later than the synchronization version identifier (i.e., the value of the target version identifier is less than or equal to the value of the synchronization version identifier, such as V_target = LSN=50, V_cp = LSN=100), it indicates that the version of the target data page has been persistently constructed in shared storage at or before the synchronization control point. Therefore, the compute node reads the target data page from the shared storage. Since this version of the data page has been persistently written to disk in the shared storage, the compute node can directly obtain a complete copy of the page without waiting for any log replay or page construction process.

[0047] Through steps 301 to 305 above, the compute node dynamically decides whether to read the target data page from the local cache or from shared storage based on the comparison result between the target version identifier and the synchronization control point. This version-matching read mechanism uses the synchronization control point as a globally unified version boundary, making the selection of the data page access path deterministic and predictable. It avoids dependence on the log replay link when the cache miss occurs, significantly reduces read latency, and improves the system's responsiveness in high-concurrency read scenarios.

[0048] In one implementation, the local cache stores copies of data pages with version identifiers later than the current synchronization control point; the shared storage stores versions of data pages with version identifiers no later than the current synchronization control point. Specifically, the compute node's local cache only retains copies of data pages with version identifiers later than the current synchronization control point, while versions of data pages with version identifiers no later than the current synchronization control point are persistently stored uniformly in the shared storage. This architectural design clearly defines the version division of labor between the local cache and the shared storage, enabling the compute node to be certain that versions later than the synchronization control point exist in the local cache (during normal operation) when executing step 104, and to be certain that versions no later than the synchronization control point can be directly obtained from the shared storage when executing step 105, thus providing a reliable architectural foundation for read path selection.

[0049] In one implementation, when performing step 304, "reading the target data page from the local cache of the computing node," the following cache query and reconstruction backfilling steps may be included: Step 304a: Query whether the local cache stores a copy of the data page corresponding to the target version identifier of the target data page.

[0050] After determining that the target version identifier is later than the synchronization version identifier, when a compute node performs the operation of reading the target data page from the local cache, it first checks whether a copy of the data page corresponding to the target version identifier exists in the local cache. Although, according to cache management rules, data pages later than the synchronization control point should exist in the local cache, in actual operation, due to abnormal situations such as compute node restarts, unexpected evictions due to insufficient cache space, or cache corruption, there may still be a situation where a copy of the target version does not exist in the local cache. Therefore, step 304a provides a fault tolerance mechanism to confirm the cache hit status before actual reading.

[0051] Step 304b: If the local cache does not store a copy of the data page corresponding to the target version identifier, then obtain the base version from the shared storage, apply the incremental log between the target version identifier and the synchronization version identifier to the base version, reconstruct the target data page, and store the reconstructed target data page in the local cache.

[0052] If the query result indicates that the target version's data page copy is not stored in the local cache (i.e., a cache miss), the compute node initiates the reconstruction process. Specifically: First, the compute node sends a request to the shared storage to obtain the base version corresponding to the current synchronization control point. The base version refers to a complete copy of the data page whose version identifier is equal to the synchronization version identifier of the current synchronization control point. Since previous versions of the synchronization control point have already been persistently constructed in the shared storage, the compute node can directly obtain this base version from the shared storage without waiting for log replay.

[0053] Secondly, the compute node retrieves all incremental log records from the current synchronization control point to the target version from the log stream of the shared storage service. These incremental log records are arranged in order of log sequence number (LSN), and each record contains the specific change operation for that data page (such as updating a row, inserting a row, etc.).

[0054] Then, the compute nodes apply the changes recorded in each incremental log record to the base version in ascending order of log sequence number. This incremental log replay process can be expressed by the following formula:

[0055] in: The data page content corresponding to the target version identifier; : The content of the base version data page corresponding to the current synchronization control point; The set of incremental log records from the current synchronization control point to the target version, represented as all WAL records within the open interval (cp, target]. apply(): A function that applies each change operation in the incremental log to the base version in sequence according to the log sequence number.

[0056] For example, assuming the current synchronization control point's synchronization version identifier is LSN=100 and the target version identifier is LSN=300, the compute node obtains the base version V_base with LSN=100, and then sequentially obtains incremental logs with LSN=150, LSN=200, LSN=280, etc. (these logs belong to records within the WAL_{(100, 300]} range). After applying the change for LSN=150, the data page becomes version LSN=150; continuing to apply the change for LSN=200, the data page becomes version LSN=200; and so on, until all changes corresponding to LSN=300 are applied. At this point, the data page in memory is the target data page V_target with LSN=300. Through the above method, the compute node reconstructs and obtains the target data page.

[0057] Finally, the compute node stores the reconstructed target data page in its local cache. By writing the reconstruction result to the local cache, when the same version of the data page is read again subsequently, the compute node can directly hit the cache in step 304a without having to perform the costly reconstruction process again. This demonstrates the core advantage of this application: "direct hit after replacement, skipping the replay chain," further accelerating subsequent access paths.

[0058] If the query result of step 304a is that a copy of the target version's data page is already stored in the local cache (i.e., a cache hit), then the reconstruction process of step 304b is skipped, and the target data page is read directly from the local cache.

[0059] Through steps 304a and 304b above, the compute node can still obtain the target data page through reconstruction in the case of an exception where the local cache is not hit, and fill the reconstruction result back into the local cache to accelerate subsequent access, thereby continuously optimizing access performance while ensuring functional integrity.

[0060] Example 2: Data Page Cache Management Method Please see Figure 4 , Figure 4 This is a flowchart illustrating a data page cache management method provided in an embodiment of this application. The data page cache management method is applied to computing nodes (including a main computing unit and an auxiliary computing unit), which are equipped with local caches and connected to shared storage. The main computing unit and the auxiliary computing unit follow the same rules for local cache management—both are required to forcibly retain copies of data pages after the synchronization boundary (because these pages have not yet been persisted in shared storage), and both can autonomously decide whether to retain copies of data pages before the synchronization boundary based on their own access frequency (because these pages have been persisted in shared storage and can be retrieved again after being evicted). The method includes the following steps: Step 401: Obtain the synchronization version identifier of the current synchronization control point, and determine the synchronization version identifier of the current synchronization control point as the cache security threshold.

[0061] The compute node obtains the synchronization version identifier of the synchronization control point currently maintained by the shared storage service client and determines this synchronization version identifier as the cache security threshold for its local cache. The cache security threshold is a version boundary used to determine whether each data page replica in the local cache can be safely evicted. The specific value of this cache security threshold is equal to the synchronization version identifier of the current synchronization control point.

[0062] Step 402: Compare the version identifier of the data page to be managed with the cache security threshold.

[0063] The compute node obtains the version identifier of the data page to be managed and compares it with the cache security threshold determined in step 401. Here, the data page to be managed refers to one or more data pages currently stored in the local cache. The compute node can traverse each data page in the local cache, obtain the version identifier of each data page, and compare it one by one with the cache security threshold to determine the management category of each data page.

[0064] The comparison logic is similar to the formula in step 303 of Example 1, except that it compares the version identifier of the data page to be managed with the cache security threshold (i.e., the version identifier of the current synchronization control point), rather than the target version identifier in the read request:

[0065] Here, "action" represents the management operation performed on the data page. This indicates the version identifier of the data page to be managed. This indicates the cache security threshold (equal to the synchronization version identifier of the current synchronization control point).

[0066] Step 403: When the version identifier of the data page to be managed is later than the cache security threshold, retain a copy of the data page to be managed in the local cache.

[0067] If the comparison result shows that the version identifier of the data page to be managed is later than the cache security threshold (i.e.) For example, if the data page version is LSN=300 and the cache security threshold is LSN=100, it means that the data page has not yet been persistently constructed in the shared storage. If the data page is evicted from the local cache, subsequent accesses will require a costly log reconstruction process (as described in step 304b in Example 1) to retrieve it again, which will result in significant access latency. Therefore, the compute node retains a copy of the data page to be managed in its local cache and does not perform an eviction operation.

[0068] Step 404: When the version identifier of the data page to be managed is not later than the cache security threshold, the copy of the data page to be managed is evicted from the local cache.

[0069] If the comparison result indicates that the version identifier of the data page to be managed is not later than the cache security threshold (i.e. For example, if the data page version is LSN=50 and the cache security threshold is LSN=100, it means that the data page has been persistently constructed in shared storage and has a complete, usable copy. When local cache space needs to be released, the compute node can evict the copy of the data page to be managed from the local cache—because even after evictment, if the compute node needs to access the same version of the data page again later, it can directly retrieve it from shared storage without relying on log replay.

[0070] Another advantage of this eviction strategy lies in the decoupling of the data access path from the construction path. Since the current processing progress of the shared storage area is strictly limited by the playback speed of the slowest unit among all compute nodes, and all nodes access data based on the synchronization control point, when a compute node retrieves a data page from the shared storage, the requested data page version is either the current synchronization control point or a version prior to that point—these versions have already been persistently constructed in the shared storage and are in a fully usable state. Therefore, the compute node's shared storage access request will not touch the data content being constructed in the shared storage, thus achieving logical decoupling between the compute node access path and the shared storage construction path. This decoupling design eliminates access blocking caused by construction conflicts, reduces the need for inter-node coordination, and improves the independence and predictability of data reading. Simultaneously, when all nodes already hold copies of data blocks after the synchronization boundary in their local cache, access requests to the shared storage area will be automatically avoided, further improving the overall system response efficiency.

[0071] It should be noted that the "retention" and "eviction" in steps 403 and 404 are management operations for existing copies of data pages in the local cache. In actual implementation, compute nodes can periodically traverse the local cache to execute the above management process, or it can be triggered when the local cache space is insufficient, or it can be executed after each synchronization control point update. The specific triggering timing can be flexibly set according to system configuration and actual needs, and this application does not limit it in this way.

[0072] Through steps 401 to 404 above, compute nodes use the synchronization control point as a cache security threshold to perform fine-grained version-aware management of data pages in their local cache—data pages later than the threshold are retained, while those not later than the threshold are evicted. This mechanism allows each compute node to independently and securely manage its local cache without inter-node coordination, avoiding complex cross-node cache consistency protocols, reducing system coordination complexity, and improving scalability.

[0073] In one implementation, the version identifier of the data page obtained by the compute node from the shared storage is no later than the current synchronization control point. Specifically, since all compute nodes use the synchronization control point as the basis for access, when a compute node needs to obtain a data page from the shared storage, the version of the data page it requests must be the current synchronization control point or a version prior to the synchronization control point—these versions have already been persistently constructed in the shared storage and are in a fully usable state. Therefore, the shared storage access request of the compute node will not touch the data content being constructed in the shared storage, thereby achieving logical decoupling between the compute node access path and the shared storage construction path.

[0074] In one implementation, the current synchronization control point is a synchronization checkpoint currently visible to the shared storage service client. The synchronization version identifier of the current synchronization control point is determined based on the processing progress of the slowest processing node among all compute nodes. Specifically, when determining the location of the synchronization control point, the shared storage service client needs to monitor the log replay progress of all compute nodes, identify the slowest processing node, and use the current processing progress of the slowest node as the location of the synchronization control point—that is, the version identifier of the synchronization control point does not exceed the currently replayed version of the slowest node. In this way, it is ensured that all compute nodes can access the data page version before the synchronization control point (because the slowest node has also progressed to that point), thereby guaranteeing the bottom line of global consistency. This mechanism also limits the advancement speed of the synchronization control point to the slowest node, reflecting the system's trade-off design between consistency and performance.

[0075] Example 3: Batch Construction Method for Data Pages Please see Figure 5 , Figure 5 This is a flowchart illustrating a method for batch constructing data pages according to an embodiment of this application. This method is applied to a shared storage service client connected to multiple computing nodes. The method includes the following steps: Step 501: Detect synchronization control points appearing in the log stream.

[0076] The shared storage service continuously monitors the log streams from each compute node, detecting the presence of synchronization control points. Synchronization control points can be actively marked by the compute nodes in their logs (e.g., during batch transaction commits), or they can be automatically generated by the shared storage service based on preset strategies (e.g., at certain intervals between log entries). When the shared storage service detects a new synchronization control point in the log stream, it triggers the subsequent batch construction process.

[0077] Step 502: In response to the occurrence of the synchronization control point, using the version identifier of the synchronization control point as the reconstruction boundary, obtain the log records within the reconstruction boundary.

[0078] In response to a detected synchronization control point, the shared storage service client uses the version identifier of that synchronization control point as the reconstruction boundary and retrieves the log records within that reconstruction boundary from the log stream. Specifically, the "log records within the reconstruction boundary" refers to all log records from the previous synchronization control point to the current synchronization control point (i.e., the log interval between two adjacent synchronization control points). The shared storage service client uses all log records within this interval as the data source for batch construction.

[0079] For example, assuming the version identifier of the previous synchronization control point is LSN=100 and the version identifier of the currently detected synchronization control point is LSN=1000, the shared storage service client obtains all log records between LSN=101 and LSN=1000 as the data source for this batch construction.

[0080] Step 503: Construct data pages in batches according to the log records, wherein multiple modifications to the same data page within the reconstruction boundary are merged into a single data page write operation.

[0081] The shared storage service client constructs data pages in batches based on the log records obtained in step 502. During the batch construction process, if the same data page is modified multiple times within the reconstruction boundary (i.e., there are multiple log records for the same data page), the shared storage service client merges these multiple modifications into a single data page write operation—directly starting from the state of the data page at the beginning of the reconstruction boundary, applying all changes within the boundary, generating the final state of the data page at the end of the reconstruction boundary, and then writing it to the shared storage all at once.

[0082] For example, suppose data page X is modified 5 times within the interval from LSN=101 to LSN=1000 (at LSN=150, LSN=300, LSN=500, LSN=700, and LSN=900 respectively). If the logs are replayed one by one in the traditional way, 5 write operations would be required. However, with the batch construction method of this application, the shared storage service obtains the base version of Page X at LSN=100, applies the change operations corresponding to the 5 modifications sequentially, directly generates the final version of Page X at LSN=1000, and then performs only one write operation. Through this streamlined approach, multiple modifications to the same data page only require one disk flush, significantly reducing the amount of data flushed to disk.

[0083] Furthermore, logs between synchronization control points do not necessarily need to be persisted to disk in the order they were generated, as long as the versions prior to the synchronization control point already exist on disk. This further reduces the dependence on the log write order and improves write efficiency.

[0084] Through steps 501 to 503 above, the shared storage service client uses the synchronization control point as the reconstruction boundary, adopts an intensive approach to construct data pages in batches, and merges multiple modifications to the same data page into a single write operation, which greatly reduces the number of repeated flushes of data pages, reduces the write amplification effect of shared storage, and improves the overall system write efficiency.

[0085] Device Examples Corresponding to the above method embodiments, this application also provides a data page access device, a data page cache management device, and a data page batch construction device. Each functional unit in the above devices has a one-to-one correspondence with each step in the aforementioned method embodiments, which will be described separately below.

[0086] I. Data Page Access Device Please see Figure 6 , Figure 6 This is a schematic diagram of the structure of a data page access device provided in an embodiment of this application.

[0087] This application embodiment also provides a data page access device 600, applied to a computing node, the computing node having a local cache and being connected to shared storage. The device 600 includes: The first acquisition unit 601 is used to acquire a read request for a target data page, wherein the read request carries the target version identifier of the target data page.

[0088] The second acquisition unit 602 is used to acquire the synchronization version identifier of the current synchronization control point.

[0089] The comparison unit 603 is used to compare the target version identifier with the synchronization version identifier.

[0090] The local cache reading unit 604 is used to read the target data page from the local cache of the computing node when the target version identifier is later than the synchronization version identifier.

[0091] The shared storage read unit 605 is used to read the target data page from the shared storage when the target version identifier is not later than the synchronization version identifier.

[0092] In one embodiment, the local cache read unit 604 specifically includes: The query subunit 604a is used to query whether the local cache stores a copy of the data page corresponding to the target version identifier of the target data page; The reconstruction subunit 604b is configured to, if the local cache does not store a copy of the data page corresponding to the target version identifier, obtain a base version from the shared storage, apply the incremental log between the target version identifier and the synchronization version identifier to the base version, reconstruct the target data page, and store the reconstructed target data page in the local cache.

[0093] It should be noted that the specific functions of each unit in the data page access device 600 described above can be referred to the relevant descriptions of steps 301 to 305 and steps 304a to 304b in the aforementioned embodiment 1, and will not be repeated here.

[0094] II. Data Page Cache Management Device Please see Figure 7 , Figure 7 This is a schematic diagram of the data page cache management device provided in an embodiment of this application.

[0095] This application embodiment also provides a data page cache management device 700, applied to a computing node, wherein the computing node is equipped with a local cache and connected to shared storage. The device 700 includes: The threshold determination unit 701 is used to obtain the synchronization version identifier of the current synchronization control point and determine the synchronization version identifier of the current synchronization control point as the cache security threshold.

[0096] The cache comparison unit 702 is used to compare the version identifier of the data page to be managed with the cache security threshold.

[0097] The cache retention unit 703 is used to retain a copy of the data page to be managed in the local cache when the version identifier of the data page to be managed is later than the cache security threshold.

[0098] The cache eviction unit 704 is used to evict a copy of the data page to be managed from the local cache when the version identifier of the data page to be managed is not later than the cache security threshold.

[0099] In one implementation, the version identifier of the data page obtained by the computing node from the shared storage is no later than the current synchronization control point.

[0100] In one implementation, the current synchronization control point is a synchronization checkpoint currently visible to the shared storage service client, and the synchronization version identifier of the current synchronization control point is determined based on the processing progress of the slowest processing node among all computing nodes.

[0101] It should be noted that the specific functions of each unit in the data page cache management device 700 described above can be referred to the relevant descriptions of steps 401 to 404 in the aforementioned embodiment 2, and will not be repeated here.

[0102] III. Data Page Batch Construction Device Please see Figure 8 , Figure 8 This is a schematic diagram of the structure of the data page batch construction device provided in the embodiments of this application.

[0103] This application embodiment also provides a data page batch construction device 800, applied to a shared storage service terminal, the shared storage service terminal being connected to multiple computing nodes. The device 800 includes: The detection unit 801 is used to detect synchronization control points appearing in the log stream.

[0104] The log acquisition unit 802 is used to acquire log records within the reconstruction boundary in response to the occurrence of the synchronization control point, using the version identifier of the synchronization control point as the reconstruction boundary.

[0105] The batch construction unit 803 is used to construct data pages in batches according to the log records, wherein multiple modifications to the same data page within the reconstruction boundary are merged into a single data page write operation.

[0106] It should be noted that the specific functions of each unit in the above data page batch construction device 800 can be referred to the relevant descriptions of steps 501 to 503 in the aforementioned embodiment 3, and will not be repeated here.

[0107] IV. Explanation of the Relationship between Device Implementation Examples and System Architecture The aforementioned data page access device 600 and data page cache management device 700 can be deployed independently on the same compute node or on different compute nodes. When both are deployed on the same compute node, the data page read operation in the data page access device 600 and the cache eviction operation in the data page cache management device 700 can work together. The cache management device manages the local cache using the synchronization control point as a safety threshold, ensuring that copies of data pages later than the synchronization control point are retained in the local cache, thus providing a basis for cache hits for local cache reads in the data page access device. If the data page access device finds a cache miss during the read process (e.g., due to abnormal conditions such as node restart), it can obtain the target data page through reconstruction and backfill it into the local cache, providing a new data page state for subsequent cache management by the cache management device. The two devices are intrinsically linked through the synchronization control point, jointly realizing the collaborative sharing of multi-version data pages on the compute node side.

[0108] The data page batch construction device 800 is deployed on the shared storage service side, working in conjunction with the data page access device 600 and the data page cache management device 700 deployed on the computing nodes. The shared storage service side completes the persistent construction of data pages at the synchronization control point through the batch construction device, so that the computing node side device can directly read from the shared storage when accessing data pages no later than the synchronization control point. At the same time, the synchronization control point information generated by the batch construction device is used by the computing node side device for read path selection (data page access device) and cache eviction decision (data page cache management device). The three together constitute a complete multi-version data page collaborative sharing system.

[0109] In summary, the technical solutions provided by the embodiments of this application have the following technical effects: First, regarding read performance, the version-matching read mechanism allows compute nodes to directly determine the read source based on the comparison between the target version identifier and the synchronization control point. This avoids reliance on log replay when the cache misses, significantly reducing read latency. Simultaneously, when the local cache misses, the target data page is reconstructed by retrieving the base version from shared storage and applying incremental logs. The reconstruction result is then populated back into the local cache, allowing subsequent accesses to directly hit the cache, further accelerating the access path.

[0110] Secondly, in terms of cache management, through the page-level conflict isolation mechanism, each computing node independently manages its local cache with the synchronization control point as the cache safety threshold. Data pages before the threshold can be safely evicted without cross-node coordination, which reduces the system's coordination complexity and improves scalability.

[0111] Third, regarding shared storage write efficiency, through a log aggregation and reconstruction mechanism based on synchronization control points, the shared storage service client constructs data pages in batches with synchronization control points as boundaries, merging multiple modifications of the same data page within the boundary into a single write, which significantly reduces the number of repeated flushes of data pages and reduces the write amplification effect.

[0112] Fourth, in terms of system decoupling, through the logical decoupling design of the data generation path between the computing unit and the shared area, when the computing node accesses the shared storage, it only accesses the persistent version that is no later than the synchronization control point, and will not touch the data content being constructed in the shared storage. This achieves the independence of the access path and the construction path, and improves the parallelism and consistency guarantee capability of data access.

[0113] Fifth, in terms of hardware adaptation, this application builds an efficient cache collaboration system based on a general hardware environment (such as NVME non-volatile media), without relying on high-performance network transmission hardware (such as RDMA). Under standardized hardware conditions, it can achieve high hit rate data access optimization, which significantly reduces system deployment costs and operation and maintenance complexity.

[0114] electronic devices This application also provides an electronic device. Please refer to... Figure 9 , Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0115] like Figure 9 As shown, the electronic device 900 includes a processor 901, a memory 902, and a computer program 903 stored in the memory 902 and executable on the processor 901. When the processor 901 executes the computer program 903, it implements the data page access method, the data page cache management method, and / or the data page batch construction method as described in any of the above method embodiments.

[0116] The memory 902 may include high-speed random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device. The memory 902 may also be a combination of the above types of memory. The memory 902 is used to store the computer program 903 and other programs and data required for the operation of the electronic device 900. The memory 902 can also be used to temporarily store various types of data, such as data being processed, processed data, and data to be transmitted, to support various operations of the electronic device 900.

[0117] Processor 901 can be a general-purpose processor, such as a central processing unit (CPU), network processor (NP), etc.; it can also be a digital signal processor (DSP), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. Processor 901 executes computer program 903 stored in memory 902 and calls data stored in memory 902 to perform various functions of electronic device 900 and process data, thereby realizing the data page access method, data page cache management method, and / or data page batch construction method provided in the above-described method embodiments of this application.

[0118] In this embodiment, the electronic device 900 further includes a communication interface 904. The processor 901, memory 902, and communication interface 904 can be interconnected via a bus 905. The bus 905 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The bus 905 can be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, Figure 9 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0119] Communication interface 904 is used to enable communication between electronic device 900 and external devices (such as shared storage service providers, other computing nodes, or client devices). Specifically, communication interface 904 may include wired communication interfaces and / or wireless communication interfaces, such as Ethernet interfaces, fiber optic interfaces, Wi-Fi interfaces, Bluetooth interfaces, cellular network interfaces, etc. Electronic device 900 can interact with other computing nodes through communication interface 904 to obtain or send log streams, data page version information, etc.

[0120] It should be understood that, in practical applications, electronic device 900 may also include more than Figure 9 This can involve more or fewer components, combining some components, splitting some components, or using different component arrangements. Figure 9 The structure shown is merely an example and does not constitute any limitation on the electronic device 900.

[0121] Optionally, the electronic device 900 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services. The electronic device 900 can also be a personal computer, laptop computer, smartphone, tablet computer, or other terminal device. This application does not limit the specific type of the electronic device 900.

[0122] Computer-readable storage media This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the data page access method, data page cache management method, and / or data page batch construction method as described in any of the above method embodiments.

[0123] The computer-readable storage medium can be any tangible medium capable of storing program code, including but not limited to: USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks, etc. Specifically, the computer-readable storage medium can include, but is not limited to, the following types of storage media: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the above storage media.

[0124] Optionally, the computer-readable storage medium may be a non-transitory storage medium, meaning that when the computer program in the storage medium is executed by the processor, the method steps implemented are persistently stored in the non-transitory storage medium, rather than temporarily stored in volatile memory. Non-transitory storage media may include, but are not limited to, the various types of storage media listed above.

[0125] In this embodiment of the application, when the computer program in the computer-readable storage medium is executed by one or more processors, the following functions can be achieved: On one hand, when the processor executes the computer program, it can implement a data page access method on the computing node side, including: obtaining a read request for a target data page and its target version identifier; obtaining the synchronization version identifier of the current synchronization control point; comparing the target version identifier with the synchronization version identifier; and reading the target data page from local cache or shared storage according to the comparison result.

[0126] On the other hand, when the processor executes the computer program, it can also implement a data page cache management method on the computing node side, including: obtaining the synchronization version identifier of the current synchronization control point and determining it as a cache security threshold; comparing the version identifier of the data page to be managed with the cache security threshold; and retaining or evicting a copy of the data page to be managed in the local cache according to the comparison result.

[0127] On another aspect, when the processor executes the computer program, it can also implement a batch construction method for data pages on the shared storage service side, including: detecting synchronization control points appearing in the log stream; obtaining log records with the version identifier of the synchronization control point as the reconstruction boundary; batch constructing data pages according to the log records, and merging multiple modifications to the same data page into a single write operation.

[0128] It should be noted that when the computer program in the computer-readable storage medium is executed by the processor, more details of the method steps implemented can be found in the relevant descriptions in the foregoing method embodiments, and will not be repeated here.

[0129] Computer program products This application also provides a computer program product, including a computer program / instruction, which, when executed by a processor, implements the data page access method, data page cache management method, and / or data page batch construction method as described in any of the above method embodiments.

[0130] The computer program product can be provided in the form of a software product (such as a software development kit, application programming interface, or API), or it can be provided to users through online distribution or network download. After obtaining the computer program product, the user can install it into an electronic device, where it is loaded and executed by the processor to implement the technical solution provided in the embodiments of this application.

[0131] Specifically, the computer program product includes one or more computer-readable program instructions that can be loaded and executed by a processor to implement the steps of the data page access method, data page cache management method, and / or data page batch construction method described in the above-described method embodiments of this application.

[0132] In one implementation, when the computer program / instructions contained in the computer program product are executed by a processor, the following operations are performed: Obtain a read request for the target data page, wherein the read request carries the target version identifier of the target data page; Get the synchronization version identifier of the current synchronization control point; Compare the target version identifier with the synchronization version identifier; When the target version identifier is later than the synchronization version identifier, the target data page is read from the local cache of the computing node; When the target version identifier is not later than the synchronization version identifier, the target data page is read from the shared storage.

[0133] In another implementation, when the computer program / instructions contained in the computer program product are executed by a processor, the following operations are also performed: Obtain the synchronization version identifier of the current synchronization control point, and determine the synchronization version identifier of the current synchronization control point as the cache security threshold; Compare the version identifier of the data page to be managed with the cache security threshold; When the version identifier of the data page to be managed is later than the cache security threshold, a copy of the data page to be managed is retained in the local cache; When the version identifier of the data page to be managed is not later than the cache security threshold, the copy of the data page to be managed is evicted from the local cache.

[0134] In another embodiment, when the computer program / instructions contained in the computer program product are executed by a processor, the following operations are also performed: Detect synchronization control points appearing in the log stream; In response to the emergence of the synchronization control point, the version identifier of the synchronization control point is used as the reconstruction boundary to obtain the log records within the reconstruction boundary; Data pages are constructed in batches based on the log records, wherein multiple modifications to the same data page within the reconstruction boundary are merged into a single data page write operation.

[0135] The computer program product may be stored in one or more computer-readable storage media, which may be any medium that provides storage functionality for the computer program product, such as the various storage media listed in the "Computer-readable Storage Media" section above.

[0136] In one implementation, the computer program product can be a computer program product containing computer programs / instructions that can be in the form of source code, object code, executable files, or some intermediate form. The computer program product can be provided as a standalone software package, as a component, plugin, or patch package of an existing software system, or as part of a cloud computing service (such as SaaS, PaaS, etc.) provided to users as a service.

[0137] It should be understood that the modules or functional units in the computer program product can be implemented by hardware, software, or a combination of hardware and software. When implemented by software, the computer program product can be implemented as a computer program software product.

[0138] The specific implementation of the computer program product should not be construed as limiting the embodiments of this application, as long as the computer program / instructions it contains can implement the technical solutions described in the above method embodiments of this application when executed by a processor.

[0139] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for accessing data pages, characterized in that, Applied to a compute node, wherein the compute node is equipped with a local cache and connected to shared storage, the method includes: Obtain a read request for the target data page, wherein the read request carries the target version identifier of the target data page; Get the synchronization version identifier of the current synchronization control point; Compare the target version identifier with the synchronization version identifier; When the target version identifier is later than the synchronization version identifier, the target data page is read from the local cache of the computing node; When the target version identifier is not later than the synchronization version identifier, the target data page is read from the shared storage.

2. The method according to claim 1, characterized in that, The local cache is used to store copies of data pages with version identifiers later than the current synchronization control point; the shared storage is used to store versions of data pages with version identifiers no later than the current synchronization control point.

3. The method according to any one of claims 1 to 2, characterized in that, Before reading the target data page from the local cache of the computing node, the method further includes: Check whether the local cache stores a copy of the data page corresponding to the target version identifier of the target data page; If the local cache does not store a copy of the data page corresponding to the target version identifier, then the base version is obtained from the shared storage, and the incremental log between the target version identifier and the synchronization version identifier is applied to the base version to reconstruct the target data page, and the reconstructed target data page is stored in the local cache.

4. A data page cache management method, characterized in that, Applied to a compute node, the compute node having a local cache and connected to shared storage, the method includes: Obtain the synchronization version identifier of the current synchronization control point, and determine the synchronization version identifier of the current synchronization control point as the cache security threshold; Compare the version identifier of the data page to be managed with the cache security threshold; When the version identifier of the data page to be managed is later than the cache security threshold, a copy of the data page to be managed is retained in the local cache; When the version identifier of the data page to be managed is not later than the cache security threshold, the copy of the data page to be managed is evicted from the local cache.

5. The method according to claim 4, characterized in that, The version identifier of the data page obtained by the computing node from the shared storage is no later than the current synchronization control point.

6. The method according to any one of claims 4 to 5, characterized in that, The current synchronization control point is the synchronization checkpoint currently visible to the shared storage service client. The synchronization version identifier of the current synchronization control point is determined based on the processing progress of the slowest processing node among all computing nodes.

7. A method for batch construction of data pages, characterized in that, Applied to a shared storage service client connected to multiple computing nodes, the method includes: Detect synchronization control points appearing in the log stream; In response to the emergence of the synchronization control point, the version identifier of the synchronization control point is used as the reconstruction boundary to obtain the log records within the reconstruction boundary; Data pages are constructed in batches based on the log records, wherein multiple modifications to the same data page within the reconstruction boundary are merged into a single data page write operation.

8. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the method as described in any one of claims 1 to 7.

9. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed by a processor, implements the method as described in any one of claims 1 to 7.

10. A computer program product, characterized in that, Includes a computer program / instruction that, when executed by a processor, implements the method as described in any one of claims 1 to 7.

Images