Method, device, storage medium and program product for parallel merging of database backup sets

Abstract

This application provides a method, device, storage medium, and program product for parallel merging of database backup sets, relating to the field of distributed systems. The method includes: obtaining the dependency chain of the backup sets to be merged; obtaining data block penetration markers based on the backup set dependency chain; processing data blocks in the full backup set in parallel to a temporary directory through multiple first sub-processes; processing at least one file dependent on an incremental backup set in parallel to a temporary directory through multiple second sub-processes; merging incremental data blocks from at least one incremental backup set in parallel to a temporary directory through multiple third sub-processes; and organizing and generating a merged full backup set based on the contents of the temporary directory. This method adds parallel scheduling capabilities based on data block penetration markers, improving the execution efficiency of merging backup sets.

Description

Technical Field

[0001] This application relates to the field of distributed systems, and more particularly to a method, device, storage medium, and program product for parallel merging of database backup sets. Background Technology

[0002] With the continuous improvement of informatization and the explosive growth of data volume, enterprises have raised higher standards for the efficiency and reliability of data backup and recovery. How to build an efficient and stable backup and recovery mechanism has become an important technical issue in database system operation and maintenance.

[0003] In current implementations, database systems typically employ a strategy combining full and incremental backups to balance data protection and storage costs. Specifically, a full backup creates independent, redundant copies of all data and log files of the database instance; while incremental backups only back up data blocks that have changed since the last backup, thus saving storage space and backup time. Data recovery relies on a backup chain consisting of a full backup and subsequent incremental backups. The complete database state is reconstructed by merging incremental backup sets sequentially into the full backup.

[0004] However, the above implementation method has the drawback of low efficiency in incremental backup merging, resulting in excessively long data recovery time. Summary of the Invention

[0005] This application provides a parallel merging method, device, storage medium, and program product for database backup sets, in order to solve the technical problem of low efficiency in incremental backup merging, which leads to excessively long data recovery time.

[0006] In a first aspect, embodiments of this application provide a method for parallel merging of database backup sets, the method comprising:

[0007] Obtain the backup set dependency chain to be merged. The backup set dependency chain includes a full backup set and at least one incremental backup set.

[0008] Based on the backup set dependency chain, obtain the data block penetration marker, which is used to determine the reference source of each data block in the merge operation;

[0009] Based on data block penetration marking, perform the following operations sequentially:

[0010] Through multiple first sub-processes, data blocks in the full backup set are processed in parallel to a temporary directory; for each data block in the full backup set, a reference is established or a copy is performed in the temporary directory based on the reference source determined by the data block's penetrating tag.

[0011] The files that at least one incremental backup set depends on are processed in parallel to a temporary directory through multiple second subprocesses;

[0012] Incremental data blocks from at least one incremental backup set are merged in parallel into a temporary directory through multiple third subprocesses; each third subprocess is responsible for writing the allocated incremental data block into the corresponding target file in the temporary directory, and different third subprocesses process incremental data blocks written to different target files.

[0013] Based on the contents of the temporary directory, organize and generate a merged full backup set.

[0014] In this embodiment, by decomposing the key steps of the merging operation into tasks executed in parallel by multiple first, second, and third sub-processes, and implementing conflict-free scheduling based on data block penetration marking, CPU computation, file reading, and data writing operations can be executed in parallel. This fully utilizes multi-core and parallel I / O capabilities, shortens the merging time, and reduces the recovery waiting window. Secondly, by allocating incremental data blocks written to different target files to different third sub-processes for processing, I / O write conflicts and lock contention when concurrently writing to the same file are avoided, thus effectively utilizing disk write bandwidth. Furthermore, global scheduling based on data block penetration marking generated before merging eliminates duplicate physical copies of the same data block, achieving efficient reference-based processing to save storage overhead.

[0015] In one possible implementation, multiple first child processes process the data blocks in the full backup set in parallel to a temporary directory, including:

[0016] For data blocks that are determined to be unmodified based on data block penetration markers, the unmodified data blocks are included in a temporary directory by creating a hard link to the source data block;

[0017] For data blocks that are identified as modified based on data block penetration markers, the modified data blocks are included in a temporary directory through a copy operation.

[0018] In this implementation, by using the aforementioned decision-making based on data block penetration marking, hard links are used to reference a large amount of unmodified static data, avoiding redundant storage and improving storage efficiency. For modified data, a copy operation ensures that the merged full backup set contains the latest version of all data blocks, guaranteeing data accuracy. Furthermore, since hard link creation is much faster than physical data copying, it saves space and also improves the execution speed of the entire full backup set processing stage.

[0019] In one possible implementation, the method further includes, before executing the operations sequentially:

[0020] Obtain real-time resource load information of the system;

[0021] Based on real-time resource load information, adjust the number of multiple first child processes, second child processes, and third child processes.

[0022] This implementation introduces a dynamic resource adaptation mechanism. When the system load is light, concurrency is increased to utilize idle resources and accelerate the merging process. When the system load is heavy, concurrency is reasonably controlled to ensure the smooth execution of the merging task, thereby improving resource utilization and merging efficiency. Furthermore, by avoiding the risk of system avalanche that might result from launching high-concurrency tasks during periods of system resource bottlenecks, this mechanism further ensures the overall operational stability of the system, making backup and maintenance operations safer and more controllable.

[0023] In one possible implementation, real-time resource load information includes CPU idle rate and I / O wait time;

[0024] Adjusting the number of processes includes: adjusting the number of processes based on the comparison between CPU idle rate and a first preset threshold, and adjusting the number of processes based on the comparison between I / O wait time and a second preset threshold.

[0025] In this implementation, through this two-dimensional control based on clear quantitative indicators and thresholds, the system can achieve precise and collaborative management of computing and I / O resources, making the dynamic adjustment strategy more reliable and easier to configure, thereby achieving the goal of optimal resource utilization in complex real-world operating environments.

[0026] In one possible implementation, the step of merging incremental data blocks from at least one incremental backup set into a temporary directory in parallel via multiple third-party subprocesses further includes:

[0027] Determine the heat score of incremental data blocks;

[0028] Based on the popularity score, assign different merging priorities to incremental data blocks;

[0029] Among them, multiple third-level subprocesses process the incremental data blocks they are allocated according to the merging priority.

[0030] In this implementation, by implementing the aforementioned priority scheduling mechanism based on data popularity, multiple third-level subprocesses, working in parallel, will adjust their processing order according to the merging priority of the allocated incremental data blocks. This ensures that high-popularity, high-business-value data blocks are prioritized for merging into the temporary directory. This mechanism allows the temporary directory to contain the most critical data for business recovery in the early stages of the merging operation, thereby shortening the time window for obtaining critical data availability in emergency recovery scenarios and achieving a combination of merging efficiency and business value orientation.

[0031] In one possible implementation, obtaining the backup set dependency chain to be merged includes obtaining the backup set dependency chain containing multiple incremental backups, and the method further includes:

[0032] Divide the backup set dependency chain into at least two merge phases executed sequentially;

[0033] For each merge stage, perform the following steps: take the partial dependency chain corresponding to the current merge stage as the dependency chain of the backup set to be merged, and execute the steps of obtaining data block penetration marking, sequentially executing operations, and generating the merged full backup set.

[0034] The full backup set corresponding to the first merging stage is the original full backup set; the full backup set corresponding to other stages is the merged full backup set generated in the previous merging stage.

[0035] In this implementation, the phased, chain-like merging method allows the system to gradually merge a very long backup chain into a final full backup with controllable resource consumption and time slices. This not only avoids the long-term, high-load impact that a single merge might cause on the system, but also allows the merging process to be paused or resumed in the middle stages, improving the flexibility and reliability of large backup set maintenance operations.

[0036] In one possible implementation, after obtaining the dependency chain of the backup set to be merged, the method further includes:

[0037] Perform redundancy checks on at least one incremental backup set;

[0038] Based on the results of the redundancy detection, the incremental backup sets that are determined to be redundant are removed from the backup set dependency chain.

[0039] In this implementation, by implementing a redundancy detection and removal mechanism, backup sets that do not contain actual data changes can be effectively filtered out. This avoids performing subsequent marking analysis, task scheduling, and data I / O operations on such invalid backup sets, reducing the total amount of data to be processed and the complexity of the tasks. This not only shortens the generation time of data block penetration marking and reduces the task load of parallel subprocesses, but also speeds up the completion of the entire merging process. In addition, this mechanism helps maintain the logical clarity of the backup chain and avoids management chaos caused by the long-term retention of invalid backup sets.

[0040] In a second aspect, this application provides an electronic device, including: a processor and a memory communicatively connected to the processor;

[0041] The memory stores the instructions that the computer executes;

[0042] The processor executes computer-executable instructions stored in memory to implement any of the methods of the first aspect.

[0043] Thirdly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method of any one of the first aspects.

[0044] Fourthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the method of any one of the first aspects. Attached Figure Description

[0045] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0046] Figure 1 A schematic diagram illustrating the principle of merging backup sets provided in an embodiment of this application;

[0047] Figure 2 This application provides a schematic diagram of a scenario for serially merging backup sets in an embodiment.

[0048] Figure 3 This application provides a schematic diagram illustrating the complete process of a serially merged backup set in an embodiment.

[0049] Figure 4 A flowchart illustrating a parallel merging method for database backup sets provided in an embodiment of this application;

[0050] Figure 5 This application provides a schematic diagram illustrating the complete process of parallel merging of backup sets in an embodiment.

[0051] Figure 6 This application provides a schematic diagram of a scenario for parallel merging of backup sets.

[0052] Figure 7 This is a schematic diagram illustrating the principle and recovery scenario of a permanent incremental backup provided in an embodiment of this application.

[0053] The accompanying drawings have illustrated specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to specific embodiments. Detailed Implementation

[0054] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0055] It should be noted that the parallel merging method, device, storage medium, and program product for database backup sets provided in this application can be used in the distributed field, or in any field other than distributed. This application does not limit the application field of the parallel merging method, device, storage medium, and program product for database backup sets.

[0056] Specific application scenarios for this application include, for example, providing an efficient backup set assembly and rapid recovery solution for long backup chains containing massive (e.g., hundreds to thousands) incremental backup sets in business systems that require high availability and business continuity due to continuous data growth and backup strategy requirements.

[0057] This scenario is widely present in core database systems such as real-time transaction clearing in the financial industry, user billing and signaling management in the telecommunications industry, and electronic medical records and image archiving in the healthcare field. These systems not only require complete and reliable backup data, but also have strict limitations on the time target for data recovery. They need to be able to quickly rebuild a usable database instance from the backup in the event of data failure or logical error, in order to minimize business interruption time and service unavailability window.

[0058] For the above application scenarios, existing technical solutions typically employ a method of merging backup sets to manage and optimize long backup chains. The specific implementation process can be, for example, combined with... Figure 1 To understand, Figure 1 This is a schematic diagram illustrating the principle of merging backup sets as provided in an embodiment of this application.

[0059] Merging backup sets is a core operation in the field of database physical backup. Physical backups are mainly divided into two categories in terms of backup scale: one is a full backup, which is a complete copy of the database instance. It has a large capacity and takes a long time, but it can independently provide data redundancy. The other is an incremental backup, which only backs up the data that has changed since the last backup. It has a small capacity and takes a short time, but it needs to rely on the chain formed by previous backups to form complete redundancy.

[0060] like Figure 1 As shown, the typical implementation process of the existing technology is as follows:

[0061] First, the system maintains a backup chain consisting of a full backup and subsequent incremental backups (e.g., five). Figure 1 The first row shows one full backup set and five incremental backup sets. When the chain length increases, leading to increased management complexity and recovery risk, a merge operation is triggered. This operation selects a subset of this chain (such as the initial full backup and the four subsequent incremental backups shown in the figure), reads the data from these backup sets, and performs a series of data block input / output copies and merging processes to ultimately generate a completely new full backup (the "Full-New" backup set shown in the figure).

[0062] Therefore, the original long backup chain is replaced by a short chain consisting of the new full backup and the remaining incremental backups (the last incremental backup shown in the diagram). At the same time, the original backup set involved in the merger (i.e., the merged full backup and its four incremental backups) is usually marked as removable, thereby freeing up the storage space it occupies.

[0063] Through the above-described "merge-replace-clean" process, existing technologies aim to shorten the backup chain, improve subsequent recovery efficiency, and optimize storage space utilization.

[0064] To perform the aforementioned merge backup set operation to optimize the backup chain, existing technologies typically employ a serial processing mode. For example... Figure 2 As shown, this mode is specifically applied in the following typical scenarios: when the incremental backup chain is too long, resulting in an excessively large overall backup capacity that requires consolidation; or before performing data restoration operations based on a specific incremental backup set. Among these, Figure 2 This is a schematic diagram illustrating a scenario of serially merging backup sets, as provided in an embodiment of this application.

[0065] Reference Figure 2 The process shown on the left, before the improvement, involved a single-process serial merging operation, which consisted of three main stages:

[0066] Copy Folder: Copy the base full backup folder from the backup chain to the temporary working directory. This stage involves processing such as... Figure 2 The timeline on the right shows files 1 through 4.

[0067] Copying dependency folders: This step copies the relevant dependency data files (as a collection of folders) from the backup chain to the same temporary directory. This stage involves processing such as... Figure 2 The timeline on the right shows files a through d.

[0068] Merging Incremental Blocks: Following the order in which backups were generated, the changed data blocks recorded in each incremental backup set are read one by one and merged into the aforementioned base folder, ultimately generating a new full backup. This stage involves processing such as... Figure 2 Data 1 to data 4 are shown on the right-hand timeline.

[0069] Because this process strictly follows a single-process serial execution, the three stages mentioned above must be performed sequentially. That is, the next stage can only begin after the previous stage has completely finished, and parallel processing is not possible.

[0070] Figure 2 The timeline on the right further illustrates the efficiency bottleneck of this execution mode in long backup chain scenarios. The timeline (natural times 1 to 12) simulates the generation and merging process of the backup chain. Within the entire merging time window (from time 1 to time 12), due to the serial limitation of a single process, the system must strictly complete all steps in sequence: "copy folder (process files 1-4) → copy dependent folder (process file ad) → merge incremental blocks (process data 1-4)". This serial dependency of the three stages results in a long overall merging operation time, and the system's computing and I / O resources cannot be fully utilized for parallel acceleration, thus becoming the main obstacle to improving the overall efficiency of backup and recovery.

[0071] To improve the reliability and integrity of merging backup sets, a more standardized execution flow design has been proposed in existing technologies. The following section combines... Figure 3 This execution process will be introduced. Figure 3 This is a schematic diagram illustrating the complete process of a serial merging backup set provided in an embodiment of this application.

[0072] like Figure 3 As shown, Figure 3 This paper demonstrates a structured complete execution flow for merging backup sets, breaking down the merge operation into a series of standardized sequential steps, as follows:

[0073] Process Trigger: The process begins with the "Merge Backup Set" action, which is usually executed before the backup chain becomes too long and needs to be shortened, or before a restore is performed based on a specific incremental backup.

[0074] Preliminary preparation stage:

[0075] Precondition checks: Verify the integrity and availability of the backup set to be merged, and confirm that the system resources meet the requirements of the merge operation.

[0076] Organize the dependency list: Organize and clarify the order and dependencies of each backup set in the "full backup + incremental backup" chain that needs to be merged.

[0077] Core merging phase: This phase is the main body of the process and contains three sub-processes that must be executed sequentially; the next process can only begin after the previous process has been completed.

[0078] Step 1: Copy the backup set to a new folder: First, copy the basic full backup in the backup chain (as shown in the figure, file 1 → file 2 → … → file n) to a new temporary folder to establish the basic environment for subsequent steps.

[0079] Step 2: Copy / Link Dependency Folders: After completing the previous step, based on the dependency list, associate the required dependency files (file a → file b → … → file n in the figure) to the new folder by copying or creating hard links. Using hard links allows you to establish associations without copying data, thus saving storage space.

[0080] Step 3: Merge Incremental Block Data (Optional): After the preceding steps are complete, the system determines whether the chain to be merged contains incremental block data. If it does, all incremental backup block data (data 1 → data 2 → … → data n in the diagram) are merged one by one into the base backup of the new folder in chronological order; if it does not, this step is skipped.

[0081] Final stage:

[0082] First, the backup set manifest file is prepared, which generates metadata and a manifest file describing the structure and content of the new backup set after the merger. Then, the merger is completed, resulting in a single, independently usable merged backup set (i.e., a new full backup).

[0083] However, the solution described above has the following technical problems:

[0084] First, in existing solutions, the core operations of merging backup sets (such as copying the base backup, processing dependent files, and merging incremental data) typically employ a single-process serial execution mode. This mode requires sequential waiting between each step, making the entire merging process too time-consuming and unsuitable for the short recovery time requirements of large-scale databases.

[0085] Secondly, in a serial execution architecture, merging tasks cannot effectively utilize the server's multi-core CPU computing power and disk parallel I / O bandwidth. This results in idle and wasted hardware resources, preventing the overall system throughput performance from being fully utilized.

[0086] Furthermore, since the merge operation can only generate a new, fully usable backup after all steps are completed, the system cannot provide instant recovery capabilities based on this backup chain during the entire lengthy merge process, thus affecting the availability of database services and business continuity.

[0087] Furthermore, as business operations continue, the backup chain grows, leading to increasingly complex internal dependencies. This not only increases the difficulty of daily operations and maintenance management, but also significantly raises the risk of the entire dependency chain breaking and recovery failing due to the corruption or loss of a single backup file.

[0088] The parallel merging method for database backup sets provided in this application aims to solve the aforementioned technical problems of existing technologies. By constructing a metadata indication mechanism that can accurately describe the source and dependencies of data blocks, the originally serial operation process of merging backup sets is reconstructed into a multi-task parallel processing flow with data block scheduling granularity. This achieves coordinated optimization of computing resources and I / O bandwidth while ensuring data consistency, thereby improving merging efficiency and reducing system overhead.

[0089] Specifically, the backup chain is first analyzed globally to generate indication information that uniquely determines the final ownership of each data block, providing a basis for scheduling subsequent parallel tasks. Then, based on this indication information, the data reading, file processing, and block writing operations involved in the merging process are decomposed into multiple independent and non-conflicting fine-grained tasks, which are then executed through multi-process concurrent scheduling.

[0090] Under this architecture, steps that must be executed sequentially in traditional processes can be carried out in parallel, and the system can make full use of multi-core computing power and parallel I / O bandwidth. At the same time, based on the instruction information, the copy or link operation can be determined at the data block level, thereby improving the merging speed while reducing the storage occupation of redundant data.

[0091] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0092] First, combine Figures 4 to 6 This application describes a parallel merging method for database backup sets provided in its embodiments. Figure 4 This is a flowchart illustrating a parallel merging method for database backup sets provided in an embodiment of this application. Figure 5 This application provides a schematic diagram illustrating a complete process for parallel merging of backup sets in an embodiment. Figure 6 This is a schematic diagram illustrating a scenario of parallel merging of backup sets provided in an embodiment of this application. The executing entity in this embodiment can be a database server, a database backup system, or a device with computing capabilities. This embodiment uses a database backup system as an example for illustration. Figure 4 As shown, the method includes the following steps:

[0093] S401. Obtain the dependency chain of the backup set to be merged.

[0094] Specifically, after detecting triggering conditions that require a merge operation (e.g., the backup chain length exceeds a preset threshold, or a user manually initiates a merge command), the database backup system determines the target scope of the merge operation. The system reads and parses the backup set dependency chain corresponding to the target scope from the backup metadata repository. The backup set dependency chain includes a full backup set that forms the basis of this merge, and at least one incremental backup set generated sequentially based on the full backup set. These backup sets together constitute a complete data change history chain.

[0095] S402. Obtain the data block penetration marker based on the backup set dependency chain.

[0096] This step is crucial for achieving efficient parallel merging. By determining the final valid data source for each data block involved in the merge, repeated I / O copies of the same data block are avoided in subsequent merges, achieving reference rather than copying.

[0097] Specifically, the database backup system recursively analyzes the reference relationships of each data block by parsing the manifest files of each backup set in the backup set dependency chain. For example, taking the recovery of a target table file as an example, the system obtains the file information from the manifest of the latest incremental backup set (e.g., marked D); based on the block reference information recorded in the manifest, it loads the manifest of the previous backup set it depends on (e.g., C); this process is repeated recursively until it traces back to the source backup set at the file level (e.g., the full backup set A). By analyzing the page mapping information of each backup set in this chain, the system can determine which of backup sets A, B, C, and D the latest valid version of any data block in the target file is stored in.

[0098] Based on the above analysis, the system generates a global, static mapping table for all data blocks that need to be merged; this table serves as a data block penetration marker. This marker precisely records the final source from which each data block should be used in this merge (e.g., the Kth data block of the target file originates from backup set C). This set of markers constitutes a conflict-free operation guide table for all subsequent parallel subtasks, eliminating the need for the system to traverse lengthy dependency chains in real-time when merging each data block, thus providing a solid foundation for large-scale parallel processing.

[0099] S403. Through multiple first sub-processes, the data blocks in the full backup set are processed in parallel to the temporary directory.

[0100] The database backup system, based on the data block penetration markers generated in S402, launches multiple first sub-processes to process the full backup set in parallel. The parallel optimization mechanism for the merging process in this application can be found in [link to relevant documentation]. Figure 5 The diagram illustrates a specific pattern for refactoring the serial processing of three key stages into parallel processing. For Figure 5 For details on the execution process and the meaning of each module, please refer to the above. Figure 3 The descriptions in the text are for reference only and will not be repeated here.

[0101] Specifically for this step (corresponding to...) Figure 5 The optimization of the process of copying the backup set to a new folder lies in refactoring the original sequential copying of individual files into a concurrent execution mode of multiple first child processes. Each first child process is assigned a portion of the data blocks (or files) in the full backup set for processing. For each assigned data block, the first child process queries the data block's pass-through marker. If the marker indicates that the data block's ultimate source is the current full backup set itself, the first child process prioritizes creating hard links for the corresponding files in the temporary directory pointing to the original data block to save space; if the system does not support hard links, physical copying is performed. Through this multi-process parallel execution, the basic framework for new backups can be quickly established by fully utilizing multi-core CPUs and parallel I / O capabilities.

[0102] S404. Through multiple second subprocesses, the files on which at least one incremental backup set depends are processed in parallel to a temporary directory.

[0103] Incremental backup sets typically include not only changes to data blocks but also necessary dependent files such as log files, metadata files, or configuration files. In this step, the system starts several secondary child processes, such as... Figure 5 As shown in the step of copying / linking dependent folders, this step employs a parallelization strategy similar to S403, with multiple second subprocesses concurrently processing the list of dependent files (files a to n as shown in the figure). Multiple second subprocesses work simultaneously, each responsible for copying or linking a portion of the dependent files from the storage location of each incremental backup set to the corresponding location in the temporary directory initially established in S403, thereby reducing the waiting latency caused by serial processing.

[0104] S405. Through multiple third-party processes, incremental data blocks from at least one incremental backup set are merged in parallel into a temporary directory.

[0105] The system launches multiple third-party child processes based on the data block penetration marking. For example... Figure 5As shown in the incremental data merging stage, the core of parallelization in this stage lies in the concurrent merging of incremental data blocks by multiple third-party subprocesses, and the use of task scheduling to ensure that any target file is written by only one third-party subprocess at any given time. Each third-party subprocess is assigned a batch of incremental data blocks that need to be modified. It reads the incremental data blocks it is responsible for and determines, based on the data block's penetrating marker, which target file in the temporary directory and its specific offset position should be written to that data block. Then, it writes the updated data to that position.

[0106] Furthermore, the task scheduler, based on the tagging information, ensures that incremental data blocks for processing different target files are allocated to different third-party child processes. For example, child process A is specifically responsible for writing to the file corresponding to table A, and child process B is specifically responsible for writing to the file corresponding to table B. This design avoids the complex lock management required when multiple processes concurrently write to the same file, avoids I / O write conflicts between child processes, achieves parallel disk writing, and thus maximizes I / O throughput.

[0107] The parallel processing architecture constructed in steps S403, S404, and S405 can improve its overall execution mode and efficiency through... Figure 6 This is visually demonstrated. For example... Figure 6 As shown, this application will transform the original serial process (corresponding to the above) Figure 2 The content shown on the right side of the middle section is restructured into three groups of parallel subprocesses. For example, multiple first subprocesses may contain, for example, ... Figure 6 The child processes 1 through 4 shown correspond to files 1 through 4, respectively. The same applies to multiple second and third child processes.

[0108] In the improved model, the tasks of copying the basic backup, processing dependent files, and merging incremental blocks are broken down and carried out simultaneously by multiple groups of subprocesses. Figure 6 The timeline on the right clearly shows that, due to parallelization, a large number of I / O operations are executed concurrently, resulting in a significant reduction in the completion time of the entire merge operation (e.g., from time 1 to time 3) compared to the serial mode (e.g., from time 1 to time 12), achieving an order-of-magnitude improvement in efficiency. This architecture is particularly suitable for long backup chain scenarios, enabling the merge operation to be compressed from hours to minutes.

[0109] S406. Based on the contents of the temporary directory, organize and generate a merged full backup set.

[0110] After all child processes S403 through S405 have completed execution, the temporary directory contains all the files and data blocks required to form a complete and consistent database instance. In this step, the system performs final cleanup work on the temporary directory, such as generating a new backup set manifest file, updating checksums, and reorganizing the directory structure. Finally, the cleaned temporary directory is packaged or renamed to a new, independent full backup set. The original long backup chain (full + multiple incremental backups) is replaced by this new full backup set, thus shortening the backup chain and saving significant time for subsequent recovery operations.

[0111] The parallel merging method for database backup sets provided in this embodiment decomposes the key steps of the merging operation into tasks executed in parallel by multiple first, second, and third sub-processes. Conflict-free scheduling is achieved based on data block penetration marking, allowing CPU computation, file reading, and data writing operations to be executed in parallel. This fully utilizes multi-core and parallel I / O capabilities, shortens merging time, and reduces the recovery waiting window. Secondly, by allocating incremental data blocks written to different target files to different third sub-processes, I / O write conflicts and lock contention when concurrently writing to the same file are avoided, ensuring effective utilization of disk write bandwidth. Furthermore, global scheduling based on data block penetration marking generated before merging eliminates duplicate physical copies of the same data block, achieving efficient reference-based processing to save storage overhead.

[0112] The foregoing embodiments have detailed the parallel merging method for database backup sets according to this application. To further illustrate the practical application of this method in database backup systems, the following will combine... Figure 7 To elaborate further, Figure 7 This is a schematic diagram illustrating the principle and recovery scenario of a permanent incremental backup provided in an embodiment of this application. Figure 7 This paper demonstrates the basic principles of the incremental backup system upon which the method in this application is based and the data recovery process.

[0113] like Figure 7 As shown above, under the permanent incremental backup strategy, the database system performs a full backup only once in the initial stage (indicated by the blank block labeled 'a' in the diagram). All subsequent backup operations are performed as incremental backups (indicated by gray blocks of varying degrees labeled 'b' to 'f' in the diagram). Each incremental backup set only records the data blocks that have changed since the last backup; unchanged areas (labeled 'b' in the diagram) do not need to be stored, thus achieving high storage space utilization in operations and maintenance.

[0114] However, as the incremental backup chain grows, the dependency chain that needs to be traced during data recovery also becomes longer, thus affecting recovery efficiency. To address this, the system introduces a backup aggregation and merging mechanism: periodically merging a long chain consisting of "full backups + multiple incremental backups" to generate a new, independent full backup (e.g., ...). Figure 7 (The continuous color blocks of different colors corresponding to "Sunday" below). The parallel merging method for database backup sets provided in embodiments S401 to S406 of this application is designed to optimize this merging operation.

[0115] The following is an introduction to the core principles of data block pass-through marking:

[0116] The key to supporting the above-mentioned efficient merging and rapid recovery is the data block penetration marking technology (i.e., the core data generated in embodiment S402). The core of this technology lies in: by parsing the backup set dependency chain, tracing and recording the physical storage source of the final valid version of each data block, thereby avoiding repeated I / O copies of the same data block during merging or recovery. The corresponding working principle can be understood in conjunction with the recovery process (using...). Figure 7 (Example: Recovery table file 16384 shown)

[0117] Dependency chain tracing: The system retrieves information about the target file and its previous backup set (e.g., C) from the list of the target recovery point (e.g., incremental backup set D), and recursively loads the lists of backup sets C, B, etc., until it traces back to the source backup set at the file level (e.g., full backup set A).

[0118] Block-level mapping resolution: During the tracing process, the system synchronously acquires and analyzes the page mapping information of the file in each backup set (A, B, C, D) to determine the specific location in which backup set the latest valid version is stored for any data block in the target file.

[0119] Generate global tags: The results of the above tracing and analysis are integrated to generate a global "data block → final source" mapping table, which is the data block penetration tag. This tag allows the system to locate data directly based on the tag in any subsequent operation (merging or recovery) without having to traverse the lengthy dependency chain in real time.

[0120] In summary, the parallel merging method for database backup sets provided in this application offers an efficient technical means for maintaining and optimizing the backup chain in permanent incremental backup mode. By implementing this method, the problem of low merging efficiency caused by long backup chains can be systematically solved, thereby ensuring the efficiency and stability of the backup system in actual operation and maintenance.

[0121] Optionally, multiple first sub-processes can be used to process data blocks in the full backup set in parallel to a temporary directory. The core of this approach is to distinguish the status of data blocks based on the information recorded by the data block penetration markers and to adopt differentiated processing strategies to achieve the optimal balance between storage space and processing efficiency.

[0122] During the execution of embodiment S403, each first subprocess will execute the following specific logic when processing its allocated data block:

[0123] The first subprocess first queries the data block penetration marker corresponding to the data block. This marker precisely indicates the final valid source of the data block in this merge.

[0124] Then, differentiated processing will be applied to the following different situations:

[0125] Scenario 1: Processing unmodified data blocks

[0126] If a data block's traceability indicates that its ultimate valid source is the currently processed full backup set itself, it means that this data block has not been modified in subsequent incremental backup chains. For such data blocks, the first child process will create a hard link in a temporary directory for the corresponding target file pointing to the original data block in the full backup set. This operation only creates a new directory entry in the file system without copying the physical data, thus saving storage overhead while incorporating the data block.

[0127] Scenario 2: Processing modified data blocks

[0128] If a data block's traceback flag indicates that its final valid source is a subsequent incremental backup set, it means that the data block has been modified in the backup chain, and its latest content does not exist in the current full backup set. For such data blocks, since the correct content cannot be obtained by referencing the original full backup block, the first child process will perform a physical copy operation. That is, based on the flag's indication, it will read the latest content of the data block from the incremental backup set that stores the final valid version and write it to the corresponding target file location in a temporary directory.

[0129] By employing the aforementioned decision-making based on data block penetration tagging, hard links are used to reference large amounts of unmodified static data, avoiding redundant storage and improving storage efficiency. For modified data, replication operations ensure that the merged full backup set contains the latest versions of all data blocks, guaranteeing data accuracy. Furthermore, since hard link creation is much faster than physical data replication, it saves space and improves the overall execution speed of the full backup set processing.

[0130] Optionally, embodiments of this application also provide a dynamic resource adaptation mechanism for parallel execution processes. Before initiating parallel processing based on data block penetration marking, the real-time operating status of the system is first evaluated, and the scale of parallel subprocesses is dynamically adjusted accordingly to achieve adaptive utilization of computing and I / O resources, thereby improving merging efficiency while ensuring overall system stability.

[0131] Specifically, after acquiring the data block penetration markers, the database backup system first collects real-time resource load information. This process is mainly achieved by querying the operating system kernel status, and the metrics of interest include, but are not limited to: the current utilization and idle rate of each CPU core, the I / O throughput and request queue length of disk devices, and memory usage pressure. These real-time data collectively reflect the system's resource reserves and bottlenecks at the moment the merge task is about to be executed.

[0132] Subsequently, the system analyzes the above information based on a pre-defined decision logic and determines the number of parallel subprocesses accordingly. This decision logic follows the principle of optimal resource utilization: if a high CPU idle rate and low I / O latency are detected, it indicates that the system has sufficient parallel processing capacity. In this case, the initial number of the first, second, and third subprocesses can be appropriately increased to more fully parallelize the tasks and shorten the merging time window. Conversely, if the CPU is nearing saturation or the I / O queue is severely congested, it indicates that system resources are strained. In this case, the number of subprocesses will be actively reduced to decrease the pressure of concurrent tasks on the system and avoid performance degradation or impact on other services due to excessive resource contention.

[0133] After making a dynamic decision on the number of processes, the system continues to execute subsequent operations with the adjusted concurrency configuration, including processing the full backup set through multiple first child processes, processing dependent files through multiple second child processes, and merging incremental data blocks through multiple third child processes.

[0134] By introducing a dynamic resource adaptation mechanism, the system accelerates the merging process by increasing concurrency to utilize idle resources when the system load is light, and ensures smooth merging by reasonably controlling concurrency when the system load is heavy, thereby improving resource utilization and merging efficiency. Furthermore, by avoiding the risk of system avalanche that might result from launching high-concurrency tasks during periods of system resource bottlenecks, this mechanism further ensures the overall operational stability of the system, making backup and maintenance operations safer and more controllable.

[0135] Optionally, real-time resource load information may include two core measurable metrics: CPU idle rate and I / O wait time. The system adjusts the number of processes based on the comparison results of these two metrics with preset thresholds: when the monitored CPU idle rate is higher than the first preset threshold, it indicates that the processor computing resources are sufficient, and the system will tend to increase the number of the first, second, and third subprocesses to improve the parallel computing throughput; conversely, if the CPU idle rate is lower than the threshold, it indicates that the CPU resources have reached a bottleneck, and the number of processes needs to be reduced to alleviate resource contention and blocking.

[0136] Meanwhile, the system monitors the IO wait time in parallel. If it is lower than the second preset threshold, it indicates that the disk IO response is fast and the bandwidth is sufficient, and the number of I / O intensive subprocesses (such as the first and second subprocesses) can be maintained or increased. If the IO wait time is higher than the threshold, it indicates that the IO subsystem is close to saturation. At this time, the number of related subprocesses must be reduced to prevent a sharp drop in performance due to excessive concurrent IO requests.

[0137] Through this dual-dimensional control based on clear quantitative indicators and thresholds, the system can achieve precise and collaborative management of computing and I / O resources, making dynamic adjustment strategies more reliable and easier to configure, thereby achieving the goal of optimal resource utilization in complex real-world operating environments.

[0138] Optionally, during the parallel merging of incremental data blocks, this embodiment also introduces scheduling optimization based on data access patterns. That is, before performing the merge, the system performs a heat analysis on the incremental data blocks and assigns differentiated merging priorities to different data blocks based on the analysis results, thereby ensuring that critical data is processed first.

[0139] Specifically, before initiating multiple third-party subprocesses to merge incremental data blocks, the system first determines the "heat score" of each incremental data block to be merged. The heat score is a quantitative indicator generated by analyzing database runtime logs, performance probe records, or system table statistics. It comprehensively reflects characteristics such as the recent access frequency, modification frequency, and timeliness of the data block. For example, data blocks belonging to core transaction tables or frequently queried indexes are typically assigned higher heat scores because they have a greater impact on business continuity; while data blocks belonging to archive tables or sparsely accessed data blocks correspond to lower heat scores.

[0140] Based on the calculated popularity score, the system assigns a merging priority to each incremental data block. Generally, the higher the popularity score, the higher the merging priority assigned to the data block. Subsequently, when assigning tasks to multiple third-party child processes, the task scheduler schedules them according to this priority. A typical implementation uses a priority queue for management: high-priority incremental data blocks are placed at the head of the queue first, so they can be processed first by idle third-party child processes; while low-priority incremental data blocks are arranged at the back of the queue.

[0141] By implementing the aforementioned priority scheduling mechanism based on data popularity, multiple third-party processes, working in parallel, will adjust their processing order according to the merging priority of the incremental data blocks they are assigned. This ensures that high-popularity, high-business-value data blocks are prioritized for merging into the temporary directory. This mechanism allows the temporary directory to contain the most critical data for business recovery in the early stages of the merging operation, thereby shortening the time window for obtaining critical data availability in emergency recovery scenarios and achieving a combination of merging efficiency and business value orientation.

[0142] Optionally, for ultra-long backup chains consisting of full backups and numerous (e.g., dozens or even hundreds) incremental backups, embodiments of this application provide a phased, progressive merging strategy. This involves breaking down a one-time, potentially extremely time-consuming long-chain merging task into multiple sequentially executed, smaller-scale merging stages, thereby reducing the complexity and resource pressure of a single operation.

[0143] Specifically, after obtaining the complete dependency chain of the backup set to be merged (e.g., full backup F and subsequent incremental backups I1 to I50), the system first logically divides the long backup dependency chain into at least two sequentially executed merge stages based on preset strategies (e.g., setting an upper limit on the number of incremental backups in a single-stage merge) or dynamic conditions (e.g., assessing the estimated time and resource consumption of a single merge). For example, the chain "F + I1 to I50" can be divided into two stages: the first stage processes "F + I1 to I20" (denoted as intermediate result), and the second stage processes "intermediate result + I21 to I50".

[0144] Subsequently, the system executes a complete, as described above, once independently for each merge stage in sequence. Figure 4 The merging process in the corresponding embodiment is as follows: For the first merging stage, the input dependency chain of the backup set to be merged is the first segmented sub-chain (e.g., "F+I1 to I20"), and the corresponding full backup set is the original full backup set F. The system obtains data block penetration markers for this first segmented sub-chain and performs operations in parallel through multiple sub-processes, finally generating the output of this stage, which is a merged full backup set (which can be denoted as F0).

[0145] Next, for the second and subsequent merge stages, the input backup set dependency chain to be merged is the sub-chain corresponding to the current stage (e.g., "I21 to I50"). The full backup set that this sub-chain depends on is no longer the original F, but the intermediate full backup set F0 generated in the previous merge stage. The system will use F0 as a basis to obtain data block penetration markers for the new sub-chain (I21 to I50) and restart the parallel merge process to generate the next intermediate full backup set or the final full backup set.

[0146] This phased, chain-like merging method allows the system to gradually merge an extremely long backup chain into a final full backup with controllable resource consumption and time slices. This not only avoids the long-term, high-load impact that a single merge might cause on the system, but also allows the merging process to be paused or resumed in the middle stages, improving the flexibility and reliability of large backup set maintenance operations.

[0147] Optionally, this embodiment of the application adds a preprocessing step before starting the merge process, which aims to identify and eliminate invalid redundancies in the backup chain, thereby further simplifying the merge task and improving overall efficiency. That is, before performing any calculations or data transfer based on the backup set dependency chain, the incremental backup sets contained therein are analyzed to filter out those backup sets that do not introduce any actual data changes.

[0148] Specifically, after retrieving the dependency chain of the backup sets to be merged from the backup metadata repository, the system does not immediately begin acquiring data block penetration tags or initiating parallel processes. Instead, it first initiates a redundancy detection process. This process determines whether each incremental backup set contains valid changes by analyzing its metadata information. Common detection methods include, but are not limited to: comparing the hash values ​​(e.g., MD5) of corresponding data files in adjacent incremental backup sets; analyzing the list of changed data blocks recorded in the incremental backup manifest (if the list is empty or completely identical to the previous backup set); or verifying whether the creation timestamp of the backup set within a specific time window and the associated database log sequence number indicate actual data writes.

[0149] Based on the redundancy detection results, the system generates a filtered backup set dependency chain. Specifically, all incremental backup sets deemed redundant are removed from the original backup set dependency chain. For example, if the detection finds that incremental backup set I2, compared to I1, has no changed hash values ​​for any of its corresponding data files and no new data block changes are recorded, then I2 is considered a redundant backup and will be removed from the merged dependency chain. Subsequently, all subsequent steps (including obtaining data block penetration markers, parallel processing, etc.) will be executed based on this filtered backup set dependency chain.

[0150] By implementing a redundancy detection and removal mechanism, backup sets that do not contain actual data changes can be effectively filtered out. This avoids performing subsequent marking analysis, task scheduling, and data I / O operations on such invalid backup sets, reducing the total amount of data to be processed and the complexity of the tasks. This not only shortens the generation time of data block penetration marking and reduces the task load of parallel subprocesses, but also speeds up the completion of the entire merging process. In addition, this mechanism helps maintain the logical clarity of the backup chain and avoids management chaos caused by the long-term retention of invalid backup sets.

[0151] The electronic device provided in this application embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0152] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the methods in any of the above method embodiments.

[0153] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the methods in any of the above method embodiments.

[0154] All or part of the steps in the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a readable memory. When the program is executed, it performs the steps of the above method embodiments; and the aforementioned memory (storage medium) includes: read-only memory (ROM), RAM, flash memory, hard disk, solid-state drive, magnetic tape, floppy disk, optical disk, and any combination thereof.

[0155] This application describes embodiments with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processing unit of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processing unit of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0156] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0157] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0158] Obviously, those skilled in the art can make various modifications and variations to the embodiments of this application without departing from the spirit and scope of this application. Therefore, if these modifications and variations to the embodiments of this application fall within the scope of the claims of this application and their equivalents, this application also intends to include these modifications and variations.

[0159] In this application, the term "comprising" and its variations can refer to non-limiting inclusion; the term "or" and its variations can refer to "and / or". The terms "first", "second", etc., in this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. In this application, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0160] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0161] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0162] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

[0163] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0164] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0165] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for parallel merging of database backup sets, characterized in that, The method includes: Obtain the backup set dependency chain to be merged, the backup set dependency chain including a full backup set and at least one incremental backup set; Based on the backup set dependency chain, obtain data block penetration markers, which are used to determine the reference source of each data block in the merge operation; Based on the data block penetration marker, perform the following operations sequentially: Through multiple first sub-processes, the data blocks in the full backup set are processed in parallel to a temporary directory; wherein, for each data block in the full backup set, a reference is established or a copy is performed in the temporary directory according to the reference source determined by the data block's penetrating tag. The files on which the at least one incremental backup set depends are processed in parallel to the temporary directory through multiple second sub-processes; Incremental data blocks from at least one incremental backup set are merged in parallel into the temporary directory through multiple third sub-processes; wherein each third sub-process is responsible for writing the allocated incremental data block into the corresponding target file in the temporary directory, and different third sub-processes process incremental data blocks written to different target files. Based on the contents of the temporary directory, the data is organized and generated into a merged full backup set.

2. The method according to claim 1, characterized in that, The process of processing data blocks from the full backup set in parallel to a temporary directory through multiple first sub-processes includes: For data blocks that are determined to be unmodified according to the data block penetration marker, the unmodified data blocks are included in the temporary directory by creating a hard link to the source data block; For data blocks that are determined to have been modified based on the data block penetration marker, the modified data blocks are included in the temporary directory through a copy operation.

3. The method according to claim 1, characterized in that, Before performing the operations sequentially, the method further includes: Obtain real-time resource load information of the system; Based on the real-time resource load information, the number of the plurality of first sub-processes, second sub-processes, and third sub-processes is adjusted.

4. The method according to claim 3, characterized in that, The real-time resource load information includes CPU idle rate and I / O wait time; Adjusting the number of processes includes: adjusting the number of processes based on a comparison between the CPU idle rate and a first preset threshold, and adjusting the number of processes based on a comparison between the I / O wait time and a second preset threshold.

5. The method according to claim 1, characterized in that, The step of merging incremental data blocks from at least one incremental backup set into the temporary directory in parallel through multiple third-party subprocesses further includes: Determine the heat score of the incremental data block; Based on the heat score, assign different merging priorities to the incremental data blocks; The plurality of third subprocesses process the incremental data blocks allocated to them according to the merging priority.

6. The method according to any one of claims 1-5, characterized in that, The method of obtaining the backup set dependency chain to be merged includes obtaining the backup set dependency chain containing multiple incremental backups, and the method further includes: The backup set dependency chain is divided into at least two merge phases executed sequentially; For each merge stage, perform the following operations: take the partial dependency chain corresponding to the current merge stage as the dependency chain of the backup set to be merged, and execute the steps of obtaining data block penetration marking, sequentially executing the operations, and generating the merged full backup set. The full backup set corresponding to the first merging stage is the original full backup set; the full backup set corresponding to other stages is the merged full backup set generated in the previous merging stage.

7. The method according to claim 1, characterized in that, After obtaining the dependency chain of the backup set to be merged, the method further includes: Redundancy detection is performed on the at least one incremental backup set; Based on the results of the redundancy detection, the incremental backup sets that are determined to be redundant are removed from the backup set dependency chain.

8. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1 to 7.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1 to 7.

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

Images