Storage method and database system

Abstract

The invention provides a storage method and a database system. The method comprises the steps that in response to modification operation of a plurality of data pages, a plurality of log records are generated, and each log record corresponds to the modification operation of one data page; writing the plurality of log records into a log storage node; based on the plurality of log records in the log storage node, updating the plurality of data pages to obtain a plurality of updated data pages; and writing the plurality of updated data pages into a data storage node. According to the scheme, the performance of the database system can be improved.

Description

Technical Field

[0001] This application relates to the field of database technology, and in particular to a storage method and database system. Background Technology

[0002] With the rapid development of the information technology industry, the amount of data generated in various fields is growing exponentially. Data storage consistency and high-performance data access have become core issues for database systems. In a database system, data storage consistency, or data consistency, refers to the fact that data remains accurate, valid, and reliable at all times, meeting data integrity constraints. Data consistency is a core characteristic of the database management system (DBMS), the core engine of the database. Data consistency ensures that the database system maintains data accuracy and meets expectations under various scenarios, including transaction processing, concurrent operations, and system failures.

[0003] To achieve data consistency, database systems employ checkpoints to periodically write modified data from the database system to storage devices (such as disks), thus ensuring data persistence. Checkpointing is an internal operation of the database system. Through checkpointing, the database system flushes dirty pages (modified data pages that have not yet been written to disk) from memory to external storage (i.e., storage devices), achieving data integrity and consistency.

[0004] Data Manipulation Language (DML), as an important component of database system languages, is used to implement operations such as inserting, modifying, and deleting data in the database system. A large number of DML commands can generate a large number of dirty pages. During checkpoint operations in the database system, this can trigger the writing of a large number of dirty pages from memory to external storage, generating a significant transient input / output (I / O) load and impacting database performance. Summary of the Invention

[0005] To address the related technical issues, embodiments of this application provide a storage method and a database system.

[0006] The technical solution of this application embodiment is implemented as follows: This application provides a storage method applied to a database system, the database system including log storage nodes and data storage nodes, the log storage nodes being used to store log records and the data storage nodes being used to store data pages; the method includes: In response to modification operations on multiple data pages, multiple log records are generated, where each log record corresponds to a modification operation on one data page; Write the plurality of log records to the log storage node; Based on the multiple log records in the log storage node, the multiple data pages are updated to obtain the updated multiple data pages; The updated data pages are written to the data storage node.

[0007] In the above scheme, generating multiple log records includes: For each of the multiple data pages, a corresponding log record is generated for the modification operation.

[0008] In the above scheme, generating multiple log records includes: The multiple log records are generated in parallel.

[0009] In the above scheme, writing the plurality of log records to the log storage node includes: The plurality of log records are written to the log storage node in a key-value format, wherein the key of each log record includes the page information of the corresponding data page, and the value of the log record includes the modification information of the data page.

[0010] In the above scheme, writing the plurality of log records to the log storage node includes: The multiple log records are written to the log storage node in random order, wherein the order in which the multiple log records are written to the log node is unrelated to the order of the log sequence numbers of the multiple log records.

[0011] The method in the above scheme further includes: Receive a data read request sent by the client, wherein the data read request is used to request to read the data page of the target version; In response to the data read request, if the data page of the target version is stored in the data storage node, the data page of the target version is read from the data storage node; Return the target version's data page to the client.

[0012] The method in the above scheme further includes: If the target version's data page is not stored in the data storage node, one or more log records of the data page are read from the log storage node, and the base version's data page is read from the data storage node. Based on one or more log records of the data page, update the data page of the base version to obtain the data page of the target version; Return the target version's data page to the client.

[0013] In the above scheme, updating the data page of the base version to obtain the data page of the target version includes: The data pages of the base version are updated according to the log sequence numbers of the one or more log records to obtain the data pages of the target version.

[0014] The method in the above scheme further includes: During crash recovery, multiple log records after a preset consistency point are read from the log storage node, wherein the consistency point is used to indicate the starting position of log record reading during data page update; Based on the multiple log records after the consistency point, the data pages corresponding to the multiple log records are restored to obtain the restored data pages; The recovered data page is written to the data storage node.

[0015] This application also provides a database system, which includes a log storage node and a data storage node. The log storage node is used to store log records, and the data storage node is used to store data pages. The database system is used to execute the method provided in this application.

[0016] The storage method and database system provided in this application embodiment set up a log storage node for storing log records and a data storage node for storing data in the database system. The database system generates multiple log records in response to modification operations on multiple data pages. Each log record corresponds to a modification operation on a data page, thereby achieving flexible processing of log records. The persistence of multiple log records is achieved by writing the generated multiple log records to the log storage node. Multiple data pages are updated using the multiple log records in the log storage node, resulting in updated multiple data pages. The updated multiple data pages are written to the data storage node, achieving persistence of multiple data pages. Thus, the updated data pages are no longer persisted by flushing dirty pages, but by log replay, thereby eliminating the need for checkpointing operations to achieve data consistency, reducing the impact of the instantaneous I / O load caused by checkpointing operations on the database system performance, and improving the read and write performance of the database system. Attached Figure Description

[0017] Figure 1 This is a flowchart illustrating a storage method provided in an embodiment of this application; Figure 2 This is an example diagram comparing a log recording storage structure provided in an embodiment of this application; Figure 3 This is a schematic diagram illustrating the parallel generation of multiple log records according to an embodiment of this application; Figure 4 This is a schematic diagram of a log recording storage provided in an embodiment of this application; Figure 5 This is a schematic diagram of out-of-order log writing provided in an embodiment of this application; Figure 6 This is a schematic diagram illustrating a computing node refreshing log records according to an embodiment of this application; Figure 7 This is a schematic diagram of an example of a computing node obtaining a data page provided in an embodiment of this application; Figure 8 This is a schematic diagram of a second example of a computing node obtaining a data page, provided in an embodiment of this application; Figure 9 This is a schematic diagram of a multi-version file provided in an embodiment of this application; Figure 10 This is a schematic diagram of the structure of a database system example provided in an embodiment of this application; Figure 11 This is a schematic diagram of a data page modification process provided in an embodiment of this application; Figure 12 This is a schematic diagram of a log playback provided in an embodiment of this application; Figure 13 This is a schematic diagram illustrating the separation of computing nodes and storage nodes provided in an embodiment of this application. Detailed Implementation

[0018] The present application will now be described in detail with reference to the accompanying drawings and embodiments.

[0019] In database systems, a write-ahead logging (WAL) mechanism is typically used to achieve data consistency and durability. The write-ahead logging mechanism writes information about data modifications to a log file before data is permanently stored. This log is called a write-ahead log (WAL). The WAL records information about data modifications, such as the content of the changes, the modified data pages, and the type of modification operation. The WAL is the foundation for database system crash recovery.

[0020] When a database system crashes, the data temporarily stored in the database system's memory is lost. However, the Write-Ahead Log (WAL) is persistently stored on non-volatile storage media such as hard disks or solid-state drives (SSDs), and the data modification information recorded in the WAL is not lost due to the database system crash. During database system recovery, the database system reads the WAL and replays it, thus restoring the data to its state before the database system crashed.

[0021] The Write-Ahead Log (WAL) may accumulate a large number of log records. If all log records in the WAL are replayed when the database system crashes, the recovery process will take a very long time. To improve the speed of crash recovery, the database system periodically establishes a "recovery starting point," also known as a checkpoint. During database system recovery, the WAL is replayed starting from the checkpoint, ignoring log records in the WAL prior to the checkpoint, thus saving recovery time.

[0022] When establishing a checkpoint, i.e., when performing a checkpoint operation, it's necessary to ensure that data modifications made before the checkpoint are persisted. This ensures that during the checkpoint operation, the database system flushes all dirty pages from the cache pool to the persistent storage nodes. It's evident that checkpoint operations trigger a large amount of transient I / O, which can impact transaction processing performance within the same timeframe. This is especially true under high load conditions, leading to a decrease in database system access efficiency.

[0023] Normally, database systems only need to record changes to data pages when recording the Write-Ahead Log (WAL). However, when a database system crashes, data modification operations may only be partially completed, resulting in data pages containing both the original and modified data simultaneously, leading to abnormal data modification. This situation is called "block tearing" or "partial write." To reduce the occurrence of partial writes or block tearing after a database system crash, the database system typically records the complete content of the modified data page in the WAL when performing data modifications for the first time after a checkpoint is created; that is, the database system performs a Full Page Write (FPW) operation. This causes the WAL to bloat, increasing its storage overhead.

[0024] To achieve reliability and high performance, database systems typically employ a master-slave instance architecture. Each instance corresponds to a virtual or physical device. The master instance handles read and write transactions, generates the Write-Ahead Log (WAL) for data modifications, and sends the WAL to multiple slave instances. The slave instances use the WAL to ensure data consistency with the master instance. Thus, slave instances can either act as a backup in case of master instance failure, providing a usable data copy to respond to read and write requests, or provide independent data read services to alleviate the load on the master instance.

[0025] Because the primary instance needs to distribute WAL (Write-Ahead Log) data to each standby instance, this adds extra load to the primary instance. This is especially problematic in scenarios with many standby instances, such as a primary instance potentially supporting up to fifteen or more standby instances, where the primary instance faces excessively high WAL distribution load. Furthermore, the WAL bloat caused by full-page write operations further increases the amount of data distributed between the primary and standby instances, exacerbating the WAL distribution burden. WAL distribution and DML operations compete for resources, thus limiting the data read / write performance of DML operations.

[0026] Furthermore, to achieve data consistency, the primary and standby instances typically employ synchronous replication. That is, after the primary instance sends the Write-Ahead Log (WAL) to the standby instance, it waits for at least one standby instance to complete log replay before returning a successful commit response to the client. While this synchronous replication method ensures data consistency and service timeliness when the standby instance takes over in the event of a primary instance failure, the primary instance often performs data read and write tasks in a high-concurrency manner to improve performance, while the standby instance often redoes data pages serially. This causes the primary instance to hang while waiting for the standby instance's serial log redo, limiting the overall capacity of the database system.

[0027] Based on this, this application provides a storage scheme for a database system. The database system is configured with log storage nodes for storing log records and data storage nodes for storing data. In response to modification operations on multiple data pages, the database system generates multiple log records. Each log record corresponds to a modification operation on one data page, thus enabling flexible processing of log records. The persistence of multiple log records is achieved by writing them to the log storage nodes. Multiple data pages (i.e., old versions of data pages) are updated using the multiple log records in the log storage nodes, resulting in updated data pages. The updated data pages are then written to the data storage nodes, achieving persistence of the data pages. Thus, the updated data pages (i.e., new versions of data pages) are no longer persisted by flushing dirty pages, but rather by log replay. This eliminates the need for checkpointing operations to achieve data consistency, reducing the impact of the instantaneous I / O load caused by checkpointing operations on database system performance and improving the read / write performance of the database system.

[0028] For ease of understanding, this application first introduces the database system. The database system provided in this application includes one or more (one or more can be understood as at least one) computing nodes, log processing service nodes, log storage nodes, and data storage nodes.

[0029] A compute node is a computing device that drives or integrates into a database system, such as a compute server. In some implementations, a compute node can be a primary node (i.e., the primary instance) or a standby node (i.e., a standby instance). In this case, the database system includes one or more primary nodes and one or more standby nodes.

[0030] A log processing service node (referred to as a log processing service) is a service device in a database system used to process log records; it can be a computing device.

[0031] A log storage node is one or more storage devices in a database system used to provide log record storage. Log storage nodes enable low-latency log record storage. In some implementations, log storage nodes can be distributed storage nodes, thereby improving the database system's log record storage capacity.

[0032] A data storage node is one or more storage devices in a database system used to provide storage for data pages. Data storage nodes can provide a large capacity for storing data pages. In some implementations, data storage nodes can be distributed storage nodes, thereby improving the database system's storage capacity for data pages.

[0033] Based on the aforementioned database storage system, this application provides a storage method. For example... Figure 1 As shown, the method includes the following steps: Step 101: The compute node responds to multiple data page modification operations by generating multiple log records, where each log record corresponds to a data page modification operation; Step 102: The compute node writes multiple log records to the log storage node; Step 103: The log processing service node updates multiple data pages based on multiple log records in the log storage node, thus obtaining the updated multiple data pages; Step 104: The log processing service node writes the updated data pages to the data storage node.

[0034] In practical applications, the modification operations on multiple data pages in step 101 can be triggered by the client. For any compute node in the database system, the compute node can receive data modification requests from multiple clients. Each data modification request requests modification of one or more data pages, such as writing, updating, or deleting data in a data page. Each data modification request triggers modification operations on one or more data pages. The modification operations are DML operations.

[0035] In response to modification operations on multiple data pages, a compute node generates a corresponding log record in memory (i.e., local memory or local cache) for each data page modification operation. This log record can be a Write-Ahead Record (WAL). Since a log record only records the modification of a data page, the log record is incremental. In this embodiment, a log record is generated for each data page modification operation, rather than generating a log record for multiple data page modification operations that may be involved in each transaction. This is equivalent to splitting the log record, such as atomically decomposing the log record by treating a data page modification operation as an atom. Thus, each log record only involves the modification operation of one data page, thereby achieving flexible management of the log record.

[0036] For example, such as Figure 2 As shown, in the case where multiple data page modification operations correspond to one log record (i.e., XLogRecord), the modification operations of each data page (such as block1, block2, etc.) are organized in a packaged manner within the same log record (e.g., 8KB in size). This log record includes the WAL page header (i.e., XLogPageHeader), the log record header (i.e., XLogRecordHeader), the headers of multiple data pages (such as block1 header, block2 header, etc.), the modification content of multiple data pages (such as block1 data, block2 data, etc.), and the main data that may be involved. During persistence, the log record is written to the file system as a whole.

[0037] When a modification operation on one data page corresponds to one log record, modifications to multiple data pages are broken down into multiple independent log records. Each log record includes a log record header, the header of the corresponding data page, the modified content of the corresponding data page, and possibly the main data involved. Multiple log records are no longer stored as a package; instead, each log record is persisted as an independent key-value pair to the key-value storage system (i.e., the log storage node).

[0038] In some implementations, a single modification operation may result in modifications to multiple data pages. For example, if a data page runs out of space, modifications to that page may spill over to other data pages. In such cases, compute nodes generate corresponding log records for each data page's modification operation and set association information for multiple log records corresponding to the same modification operation. For example, compute nodes set association information in the metadata of multiple log records.

[0039] Association information is used to indicate multiple log records corresponding to the same modification operation. Association information can be used to identify multiple associated log records for the same modification operation. For example, association information can be implemented using indexes or pointers. For instance, a compute node can set a preset index identifier for multiple log records corresponding to the same modification operation, or set a pointer to other associated log records for each log record. The preset index identifier or pointers can be used to identify multiple log records corresponding to the same modification operation.

[0040] In this embodiment, since modification operations on different data pages correspond to different log records, the different log records are independent of each other. Before the log records are persisted to the log storage node, the compute node first generates multiple log records in parallel in memory in a lock-free manner, thus enabling the log records to be written to memory in a lock-free manner. For example, as... Figure 3 As shown, the compute node generates multiple log records in parallel in memory (such as a WAL buffer) using N backend processes (represented as backend process 1, backend process 2, ..., backend process N), in a lock-free manner. In this lock-free mode, the compute node does not limit the number of processes writing log records to memory simultaneously. In this way, the database system can concurrently generate multiple log records, thereby improving the database system's log processing capabilities in high-concurrency scenarios and enhancing the database system's read and write performance.

[0041] In step 102, after generating multiple log records, the compute node stores these log records in the log storage node, thus achieving persistent storage of the log records. For example... Figure 4 As shown, after the compute node generates multiple log records in parallel based on log record data (i.e., DATA) through N backend processes, it writes (i.e. commits) the multiple log records into the KV storage system (i.e., the log storage node).

[0042] Because log storage nodes have low latency and small log record size, compute nodes can achieve fast log record storage. In a master-slave architecture, the slave node can read log records from the log storage node, thus eliminating the need for the master node to distribute log records to the slave node. This reduces the impact of log persistence on the master node's performance and improves the read and write performance of the database system.

[0043] To achieve more flexible log management, some implementations store each log record in key-value (KV) format on compute nodes. The key (K) of each log record includes page information for the corresponding data page. For example, page information may include one or more of the following: data page identifier, storage location, and data page version (one or more can be understood as at least one). The value of the log record includes modification information for the data page (V). For example, modification information may include one or more of the following: row identifier of the modified row, data content before modification, data content after modification, modification operation type, association information, and log sequence number (LSN).

[0044] In this embodiment, WAL records are stored in key-value (KV) format. The page information corresponding to each WAL record serves as the key, and the modification information of each WAL record serves as the value. This allows for more flexible management of WAL records using the KV format. For example, when a compute node performs crash recovery by revisiting log records, a log index can be generated using the data page identifier of the key. Multiple log records corresponding to any data page can be retrieved through the log index, thereby enabling rapid recovery of the database system.

[0045] Since each log record corresponds to a modification operation on a data page, compute nodes can also write multiple log records to the log storage node in parallel when writing multiple log records. However, during this process, the compute node no longer writes the log records sequentially according to their log sequence numbers; instead, it writes them out of order. The order in which multiple log records are written to the log storage node is unrelated to the order of their log sequence numbers. This improves the log record writing speed.

[0046] For example, such as Figure 5 As shown, during the process of committing log records to the log storage node, the compute node flushes the log records that have been successfully written to memory but not yet stored in the log storage node from the commit point to the latest log record, and ignores the log records that have not yet been successfully written to memory. Each log record committed to the log storage node is stored in key-value (KV) format. After committing to the log storage node, the compute node releases the memory pages occupied by the log records and sets a new commit point.

[0047] Understandably, compute nodes can periodically commit log records from memory to the log storage node. Alternatively, compute nodes can commit log records to the log storage node when a certain number of successfully generated log records have been generated in memory. To ensure no log records are missed, the compute node sets a commit point in memory after each commit. For example, the compute node can set the commit point as the log record with the smallest sequence number in memory that has not yet been committed to the log storage node after the current commit. All log records with sequence numbers prior to the commit point have been successfully committed. When the compute node triggers another log commit, it uses the commit point set after the last commit as the starting point for this commit.

[0048] A log sequence number is a globally unique identifier for a log record, used to determine its order within the entire log collection. Typically, log sequence numbers are monotonically increasing. Compute nodes can assign corresponding log sequence numbers to log records before generating them, using these numbers to verify the order of log records. Log sequence numbers can be stored in Vlue as part of the log record's metadata. During compute node crash recovery, log records can be replayed according to their sequence numbers, restoring the node to its pre-crash state. In other words, when persistently storing log records, they are stored in an out-of-order commit and confirmation manner, improving the log record write speed.

[0049] In some implementations, modification operations on multiple data pages may belong to the same mini-transaction (MTR). A mini-transaction is the smallest unit in which a database system performs data page modification operations. One mini-transaction corresponds to modification operations on one or more data pages.

[0050] To enable log replay of the same micro-transaction, compute nodes can persist log records at the micro-transaction granularity. For example, a compute node can set a micro-transaction flag for multiple log records corresponding to the same micro-transaction (to mark the same micro-transaction), and set an indication message for the log record whose log sequence number is last among the multiple log records corresponding to the same micro-transaction. This indication message is used to indicate the last log record of the same micro-transaction. In this way, log replay can be performed at the micro-transaction granularity. That is, when a compute node reads a log record carrying the indication message, it indicates that all log records of the micro-transaction corresponding to that log record have been replayed.

[0051] In step 103, the log processing service node reads multiple log records from the log storage space and performs modification operations on the corresponding data pages based on each log record to obtain the updated data pages.

[0052] In practical applications, log processing service nodes can update the corresponding data pages sequentially according to the log sequence numbers of multiple log records. Alternatively, since the log records for different data pages are stored independently, the log processing service nodes can update different data pages in parallel based on the log records corresponding to each data page.

[0053] In step 104, after obtaining the updated data pages, the log processing service node writes the updated data pages into the data storage node, thereby achieving persistent storage of the updated data pages. In practical applications, the log processing service node writes multiple updated data pages into the data storage node in batches.

[0054] In this implementation, the data storage node supports atomic write functionality. Under atomic write, a data page is only allowed to be written completely. Even if the write process is interrupted due to a database system exception, the data page will be restored to its state before the write operation once the database system recovers. Thus, during the data page write process, "block tearing" or "partial writing" will not occur, thereby achieving atomicity and durability of data page writes.

[0055] With the atomic write capability, the database system can disable full-page write functionality. That is, the database system no longer writes the entire content of a data page to the log record, thereby reducing the log volume. Furthermore, because the data storage node provides atomic write functionality, ensuring data page integrity, the compute node can also remove the cyclic redundancy check (CR) operation that performs integrity verification on data pages, thus improving compute node performance.

[0056] In this embodiment, the modified data pages are no longer flushed to the data storage nodes through the compute nodes; that is, persistent storage of data pages is no longer achieved by flushing dirty pages through the compute nodes. Instead, persistent storage of data pages is achieved through log record replay (i.e., re-executing the modification operations corresponding to the log records to update the data pages). Figure 6 As shown, the compute node generates log records in memory (i.e., the cache pool), reads the data pages corresponding to the modification operations, and writes the generated log records to the log storage node. It does not perform the operation of writing the data pages in the local cache to the data storage node.

[0057] Therefore, compute nodes do not need to perform checkpointing operations or full-page write operations, nor do they need to maintain the integrity of data pages, thus reducing the burden on compute nodes and improving their performance. In this case, log records are equivalent to data written by compute nodes to log storage nodes; that is, logs are data. Data storage nodes use log processing service nodes to replay old versions of data pages and store new versions of data pages. The data storage nodes, as the maintainers of the data pages, ensure the integrity and persistence of the data pages.

[0058] In this embodiment, the log records information about changes to the data page during a modification operation, and are not the direct source of the data requested by the client. The data page is the storage medium and source of the data requested by the client. Therefore, the compute node also needs to return the requested data page to the client.

[0059] If the compute node is functioning normally, i.e., has not crashed, and receives a data read request from a client, this request is for reading a data page of the target version. For example... Figure 7 As shown, if the data storage node stores the target version of the data page, the compute node directly reads the target version of the data page from the data storage node into its local cache, and then passes the target version of the data page to the client.

[0060] In some cases, such as after a compute node crash recovery, the log records may not be updated in time in the data storage nodes due to the compute node's downtime and the log processing service node's replay function. In such situations, the compute node can obtain the target version of the data page through log replay. Figure 8 As shown, when the target version of the data page is not stored in the data storage node, the compute node reads one or more log records of the data page requested by the client from the log storage node and stores them in its local cache. It also reads the base version of the data page from the data storage node and stores it in its local cache. The compute node updates the base version of the data page based on the read log records. For example, it sequentially performs the modification operations recorded in the log records on the read base version of the data page according to one or more log sequence numbers, thus updating the base version of the data page to obtain the target version of the data page. This restores the target version of the data page in local memory before the crash, achieving data consistency. The compute node can also send the data from the restored target version of the data page to the client, allowing the client to obtain the target version of the data page even when it is not stored in the data storage node.

[0061] In this embodiment, the data storage node acts as a shared storage file system, capable of storing multiple versions of files. That is, the data storage node can save metadata and business data for a file in different versions. When a user reads a file through a client, the client includes the file's version identifier in the data read request. The computing node reads the target version of the file from the data storage node, as indicated by the version identifier, and returns the target version of the file to the client, such as returning the business data of the file under the target version.

[0062] For example, a file named File may have three versions, such as File-v1, File-v2, and File-v3. Figure 9 As shown, the file "File" includes metadata and custom data. The metadata includes version identifiers, such as attr1, attr2, and attr3. The custom data includes data fragments of different versions, such as slice1, slice2, and slice3. These fragments are linked, indicating their sequential order. When a client requests to read File-v3 version of "File", the compute node sequentially reads the custom data of File-v3 version through slice1, slice2, and slice3, and returns the read custom data to the client.

[0063] The following describes the database system in the embodiments of this application, taking a database system including one or more master nodes and one or more backup nodes as an example.

[0064] For example, taking a database system that includes one primary node and one secondary node as an example, such as... Figure 10 As shown, the database system includes a master node, a backup node, a log storage node, a log processing service, and a data storage node.

[0065] The primary node communicates with the log storage node, writing or reading log records from it. It also communicates with the data storage node, reading data pages from it. Similarly, the secondary node communicates with the log storage node, reading log records and data pages from it. The primary and secondary nodes can also communicate with each other; for example, the primary node can send log record metadata to the secondary node.

[0066] The log processing service node communicates with the log storage node to retrieve log records. It also communicates with the data storage node to read or write data pages.

[0067] The process of a database system modifying a data page is as follows: Figure 11 As shown. The master node receives a data modification request sent by the client. In response to the data modification request, a data page modification operation is triggered. The master node loads the corresponding data page (i.e., the old version of the data page) stored in the data storage node into its local cache, and generates a log record of the corresponding data page modification operation in its local cache.

[0068] After successfully generating a log record, the master node writes the log record to a low-latency log storage node, achieving persistent storage of the log record. When the log processing service node detects that a log record has been written to the log storage node, it reads the log record from the log storage node and the corresponding data page from the data storage node. Based on the modification operations recorded in the log record, it updates the data page to obtain the updated data page (i.e., the data page of the new version or target version), and writes the updated data page to the high-performance data storage node, achieving persistent storage of the updated data page.

[0069] The process of a database system performing log replay based on base data pages (i.e., base version data pages) and incremental log records is as follows: Figure 12 As shown, in a database system, the process of updating data pages through log replay is distributed across three locations: the Log Processing Service asynchronously processes the log records generated by the primary or master node, updates the basic version of the data pages based on the log records, and persists the updated data pages; the slave node reads log records from the log storage node to update the data pages; and the master node responds to the client's data read request by replaying the log records.

[0070] The log processing service listens for and processes log records written by the master node from the log processing nodes. It reads incremental log records from the log storage nodes and corresponding base version data pages from the data storage nodes, updating the base version data pages based on the read log records—that is, obtaining the updated data pages through log replay.

[0071] The standby node (which can also be the primary node) responds to data read requests. If the requested data page exists in its local cache (i.e., if the memory pool hits, it is replayed; otherwise, it is not), it reads the log record corresponding to the requested data page from the log storage node and builds a log index. The log index includes the data page identifier (e.g., Page0, Page1) for each data page and the log sequence number (e.g., LSN_A1 to LSN_AN) of the corresponding log record. Based on the log record corresponding to each data page in the log index, the standby node performs log replay to update each data page, obtaining the version of each data page requested by the client (i.e., the target version of the data page). The standby node then returns the obtained data page version to the client.

[0072] During a session between a compute node and a client, the compute node receives a data read request from the client, requesting the read of a data page of the target version. If the requested data page version (i.e., the target version) is not in the cache, and the data page version provided by the data storage node is inconsistent with the client's request, the compute node, through a backend process, reads one or more log records corresponding to the requested data page from the log storage node. It then constructs a log index for these log records and, based on the log records corresponding to each data page in the log index, performs log replay in order of log sequence number to obtain the target version of the data page. After completing the log replay, the compute node returns the target version of the data page obtained from the log replay to the client.

[0073] By replaying logs, the database system can return any version of the data page to the client, improving the flexibility and functionality of the database system and thus meeting the needs of more complex business scenarios.

[0074] To improve the efficiency of data page redoing via log replay, the database system also sets up consistency points. These consistency points indicate the starting position of log record reading during the data page update process. For example, a consistency point can be set as the log sequence number of a specific log record. All data page updates corresponding to log records before the consistency point (e.g., log sequence numbers before the consistency point) are persistently stored in the data storage nodes. When a compute node or log processing node redoes a data page using log records, it can directly load the base version data page corresponding to the consistency point, along with all log records generated after the consistency point. Then, the compute node or log processing node redoes the corresponding base version data page based on all log records generated after the consistency point to obtain the target version data page.

[0075] For example, after a primary node crashes and recovers, or when a standby node is added to the database system, the primary or standby node can directly load the base version data page corresponding to the consistency point and all log records generated after the consistency point. Based on all the log records generated after the consistency point, the corresponding base version data page can be updated to obtain the recovered data page or the latest data page.

[0076] In some implementations, log processing service nodes can periodically update the consistency point. Updating the consistency point does not trigger compute nodes to flush dirty pages. In special cases, such as database system migration, when establishing a consistency point, all data pages can be flushed to obtain a snapshot of all data pages, which can then serve as the base version of the data pages.

[0077] Therefore, when redoing data pages through log replay, it is not necessary to replay all log records, but only the log records after the consistency point, thereby shortening the log replay time and improving the efficiency of data page redo.

[0078] The database system architecture described above includes a compute layer and a storage layer, enabling independent deployment of compute and storage resources. The compute layer includes compute nodes and log processing service nodes. The storage layer includes log storage nodes and data storage nodes. In practical applications, the scale of compute and storage resources can be flexibly adjusted according to actual needs, allowing the database system to better adapt to dynamic load changes and the continuous growth of data storage requirements. Compared to solutions where primary and standby nodes need to maintain full copies of data, this architecture allows all compute nodes to share the same data (i.e., the data in the data storage nodes), thus saving storage costs. When a new standby node is added to the database system, the standby node can synchronize with the primary node with extremely low latency (e.g., within seconds), achieving high efficiency in standby node synchronization.

[0079] like Figure 13 As shown, in the computation layer of the database system, the master node is responsible for handling read and write tasks. It reads data pages from the data storage node in its local cache, executes modification operations on the data pages, generates log records corresponding to the data page modification operations, and writes these log records to the log storage node. The log processing node is responsible for updating data pages in the data storage node. It updates the data pages by reading them from its local cache and the log records in the log storage node, and then writes the updated data pages to the data storage node. If a backup node is added to the database system, the backup node synchronizes with the master node by reading data pages from its local cache and log records from the log storage node.

[0080] In the storage layer of a database system, log storage nodes store log records generated by the master node and provide access to these records. Log storage nodes can be built on a distributed key-value storage structure. Data storage nodes store data pages replayed based on log records by the log processing service nodes. Data storage nodes provide data page sharing, accessible to both the master and slave nodes. Data pages replayed based on log records can be persisted to disk sequentially (e.g., according to log sequence numbers), ensuring that all data pages committed before being persisted are held in the data storage nodes, providing a consistent data foundation for the compute nodes.

[0081] The separation of the computation and storage layers in a database system allows data page updates to be replayed through log recording. Compute nodes no longer flush dirty pages, thus reducing their load and improving their transaction processing capabilities. This decoupled architecture clearly separates the responsibilities of compute and storage nodes, achieving high throughput and low latency in the database system, and laying the foundation for resource expansion and flexible data management.

[0082] In this embodiment, by integrating log storage into the database system, the database system can achieve data storage without a checkpointing mechanism. When data is modified, the modification operations of the data page are stored in the database system as logs, and the logs are transmitted to the data pages through a log processing service to update the data pages. During log replay, the database system typically reads the data pages directly for replay. When the database system crashes, the logs stored in the low-latency log storage engine (i.e., log storage nodes) may not be read and updated by the data pages in a timely manner, resulting in inconsistency between the data pages and the latest data pages in the cache. In this case, the database system recovers the data pages by reading the data pages and the logs in the low-latency log storage engine, achieving data consistency after crash recovery. Thus, it is not necessary to write to both the logs and data pages simultaneously, thereby improving database system performance and reducing storage space consumption while achieving data consistency.

[0083] The database storage system provided in this application includes a computing node, a log service node, a log storage node, and a data storage node. The log storage node is used to store log records, and the data storage node is used to store data pages. The computing node is configured to generate multiple log records in response to modification operations on multiple data pages, wherein each log record corresponds to a modification operation on one data page; and write the multiple log records to the log storage node. The log service node is used to update the multiple data pages based on the multiple log records in the log storage node to obtain the updated multiple data pages; and write the updated multiple data pages into the data storage node.

[0084] In some alternative implementations, the computing node is specifically used for: For each of the multiple data pages, a corresponding log record is generated for the modification operation.

[0085] In some alternative implementations, the computing node is specifically used for: The multiple log records are generated in parallel.

[0086] In some alternative implementations, the computing node is specifically used for: The plurality of log records are written to the log storage node in a key-value format, wherein the key of each log record includes the page information of the corresponding data page, and the value of the log record includes the modification information of the data page.

[0087] In some alternative implementations, the computing node is specifically used for: The multiple log records are written to the log storage node in random order, wherein the order in which the multiple log records are written to the log node is unrelated to the order of the log sequence numbers of the multiple log records.

[0088] In some alternative implementations, the computing node is further configured to: Receive a data read request sent by the client, wherein the data read request is used to request to read the data page of the target version; In response to the data read request, if the data page of the target version is stored in the data storage node, the data page of the target version is read from the data storage node; Return the target version's data page to the client.

[0089] In some alternative implementations, the computing node is further configured to: If the target version's data page is not stored in the data storage node, one or more log records of the data page are read from the log storage node, and the base version's data page is read from the data storage node. Based on one or more log records of the data page, update the data page of the base version to obtain the data page of the target version; Return the target version's data page to the client.

[0090] In some alternative implementations, the computing node is specifically used for: The data pages of the base version are updated according to the log sequence numbers of the one or more log records to obtain the data pages of the target version.

[0091] In some alternative implementations, the computing node is further configured to: During crash recovery, multiple log records after a preset consistency point are read from the log storage node, wherein the consistency point is used to indicate the starting position of log record reading during data page update; Based on the multiple log records after the consistency point, the data pages corresponding to the multiple log records are restored to obtain the restored data pages; The recovered data page is written to the data storage node.

[0092] In practical applications, compute nodes, log processing nodes, log storage nodes, and data storage nodes can be electronic devices within a database system. The following example uses an electronic device to illustrate any node in a database system. Exemplarily, this electronic device includes: The communication interface enables information exchange with other devices (such as other nodes); A processor, connected to the communication interface, enables information interaction with other devices (such as other nodes), and when running a computer program, implements the methods provided by one or more of the above technical solutions; The computer program is stored in the memory.

[0093] Of course, in practical applications, the various components inside an electronic device (such as communication interfaces, processors, and memory) are coupled together through a bus system. The bus system is used to enable communication between these components. In addition to the data bus, the bus system also includes a power bus, a control bus, and a status signal bus.

[0094] The memory in this application embodiment is used to store various types of data to support the operation of the electronic device. Examples of such data include any computer program used to operate on the electronic device.

[0095] The methods disclosed in the embodiments of this application can be applied to the processor, or implemented by the processor. The processor may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuit of the hardware in the processor or by instructions in software form. The processor mentioned above may be a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The processor can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. A general-purpose processor may be a microprocessor or any conventional processor, etc. The steps of the methods disclosed in the embodiments of this application can be directly manifested as being executed by a hardware decoding processor, or being executed by a combination of hardware and software modules in the decoding processor. The software modules may be located in a storage medium, which is located in a memory. The processor reads the information in the memory and, in conjunction with its hardware, completes the steps of the aforementioned method.

[0096] In an exemplary embodiment, the electronic device may be implemented by one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers (MCUs), microprocessors, or other electronic components to perform the aforementioned method.

[0097] It is understood that the memory in the embodiments of this application can be volatile memory or non-volatile memory, or both. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), ferromagnetic random access memory (FRAM), flash memory, magnetic surface memory, optical disc, or compact disc read-only memory (CD-ROM); magnetic surface memory can be disk storage or magnetic tape storage. Volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Synchronous Static Random Access Memory (SSRAM), Dynamic Random Access Memory (DRAM), Synchronous Dynamic Random Access Memory (SDRAM), Double Data Rate Synchronous Dynamic Random Access Memory (DDRSDRAM), Enhanced Synchronous Dynamic Random Access Memory (ESDRAM), SyncLink Dynamic Random Access Memory (SLDRAM), and Direct Rambus Random Access Memory (DRRAM).The memories described in the embodiments of this application are intended to include, but are not limited to, these and any other suitable types of memories.

[0098] In an exemplary embodiment, this application also provides a storage medium, namely a computer storage medium, specifically a computer-readable storage medium, such as a memory that stores a computer program, which can be executed by a processor of an electronic device to complete the steps described in the aforementioned method. The computer-readable storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, Flash Memory, magnetic surface memory, optical disc, or CD-ROM.

[0099] In an exemplary embodiment, this application also provides a computer program product, including a computer program that can be executed by a processor of an electronic device to perform the steps described in the foregoing method.

[0100] It should be noted that terms such as "first" and "second" are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence.

[0101] Furthermore, the technical solutions described in the embodiments of this application can be combined arbitrarily without conflict.

[0102] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application.

Claims

1. A storage method, characterized in that, The method is applied to a database system, which includes log storage nodes and data storage nodes, wherein the log storage nodes are used to store log records and the data storage nodes are used to store data pages; the method includes: In response to modification operations on multiple data pages, multiple log records are generated, where each log record corresponds to a modification operation on one data page; Write the plurality of log records to the log storage node; Based on the multiple log records in the log storage node, the multiple data pages are updated to obtain the updated multiple data pages; The updated data pages are written to the data storage node.

2. The method according to claim 1, characterized in that, The generation of multiple log records includes: For each of the multiple data pages, a corresponding log record is generated for the modification operation.

3. The method according to claim 1, characterized in that, The generation of multiple log records includes: The multiple log records are generated in parallel.

4. The method according to any one of claims 1 to 3, characterized in that, The step of writing the plurality of log records to the log storage node includes: The plurality of log records are written to the log storage node in a key-value format, wherein the key of each log record includes the page information of the corresponding data page, and the value of the log record includes the modification information of the data page.

5. The method according to any one of claims 1 to 3, characterized in that, The step of writing the plurality of log records to the log storage node includes: The multiple log records are written to the log storage node in random order, wherein the order in which the multiple log records are written to the log node is unrelated to the order of the log sequence numbers of the multiple log records.

6. The method according to any one of claims 1 to 3, characterized in that, The method further includes: Receive a data read request sent by the client, wherein the data read request is used to request to read the data page of the target version; In response to the data read request, if the data page of the target version is stored in the data storage node, the data page of the target version is read from the data storage node; Return the target version's data page to the client.

7. The method according to claim 6, characterized in that, The method further includes: If the target version's data page is not stored in the data storage node, one or more log records of the data page are read from the log storage node, and the base version's data page is read from the data storage node. Based on one or more log records of the data page, update the data page of the base version to obtain the data page of the target version; Return the target version's data page to the client.

8. The method according to claim 7, characterized in that, Updating the data page of the base version to obtain the data page of the target version includes: The data pages of the base version are updated according to the log sequence numbers of the one or more log records to obtain the data pages of the target version.

9. The method according to any one of claims 1 to 3, characterized in that, The method further includes: During crash recovery, multiple log records after a preset consistency point are read from the log storage node, wherein the consistency point is used to indicate the starting position of log record reading during data page update; Based on the multiple log records after the consistency point, the data pages corresponding to the multiple log records are restored to obtain the restored data pages; The recovered data page is written to the data storage node.

10. A database system, characterized in that, The database system includes log storage nodes and data storage nodes, wherein the log storage nodes are used to store log records and the data storage nodes are used to store data pages; the database system is used to execute the method of any one of claims 1-9.

Images