Method and device for performance optimization of cluster database, electronic equipment and storage medium

Abstract

This application discloses a performance optimization method, apparatus, electronic device, and storage medium for clustered databases, relating to the field of computer technology. Through this application, by determining the node affiliation of database record access requests and forwarding them hierarchically according to the logical master node and the current data master node, and by queuing and delaying concurrent access requests for the same record during record migration according to timestamps, the request forwarding path and concurrent request processing order are standardized. This fundamentally avoids timing conflicts during master node migration, effectively controlling the number of hops in access requests, improving the access processing efficiency of the CTDB database cluster, enhancing the throughput and operational stability of the distributed system, and adapting to the technical requirements of cross-node data synchronization scenarios such as Samba clusters.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to methods, apparatus, electronic devices and storage media for optimizing the performance of clustered databases. Background Technology

[0002] Clustered Trivial Database (CTDB), as an important distributed key-value storage component of clustered database management systems, is widely used in scenarios such as Samba clusters that require cross-node data synchronization. Related technologies utilize data migration routing algorithms and the collaborative work of dynamically assigning node roles to construct a distributed database access system.

[0003] In existing CTDB access methods, when multiple clients concurrently access the same record, timing conflicts during the migration process of the designated master node can cause requests to be repeatedly sent back to the local master node, forming a vicious cycle with uncontrollable N_hop count, which affects the throughput and stability of the distributed system. Summary of the Invention

[0004] This application provides a method, apparatus, electronic device, and storage medium for optimizing the performance of clustered databases, in order to at least solve the vicious cycle of uncontrollable N_hop hop count in related technologies, which affects the throughput and stability of the system.

[0005] This application provides a performance optimization method for clustered databases, including:

[0006] Retrieve database record access requests; If it is determined that the current node is not the target data master node of the record access request, the record access request is forwarded to the logical master node of the record access request; The record access request is forwarded to the current data master node, and other access requests for the same record received during the record migration are queued and delayed according to the timestamp.

[0007] Optionally, if it is determined that the current node is not the target data master node of the record access request, forwarding the record access request to the logical master node of the record access request includes: Calculate the fixed logical master node of the record access request based on the record identifier information of the record access request; The access request is directly routed to the logical master node.

[0008] Optionally, forwarding the record access request to the current data master node includes: A delayed processing queue is created for the record access request, and the record access request is marked as being in the migration processing state; Subsequent access requests for the same record received during the record access request migration processing state are added to the delayed processing queue.

[0009] Optionally, the method further includes: Based on the order of requests in the delayed processing queue, the next access request in the queue is forwarded to the corresponding data master node.

[0010] Optionally, the data master node is the node where the data copy of the access request is located; the logical master node is a fixed coordination node corresponding to the access request of the record, determined according to a predefined mapping rule.

[0011] Optionally, the method further includes: Verify whether the version information of the record access request matches the current data version.

[0012] This application also provides a performance optimization device for clustered databases, including: The retrieval unit is used to retrieve database record access requests; The forwarding unit is used to forward the record access request to the logical master node of the record access request if it is determined that the current node is not the target data master node of the record access request. The processing unit is used to forward the record access request to the current data master node and to queue and delay other access requests for the same record received during the record migration according to the timestamp.

[0013] Optionally, the forwarding unit is further configured to: Calculate the fixed logical master node of the record access request based on the record identifier information of the record access request; The access request is directly routed to the logical master node.

[0014] Optionally, the processing unit is further configured to: A delayed processing queue is created for the record access request, and the record access request is marked as being in the migration processing state; Subsequent access requests for the same record received during the record access request migration processing state are added to the delayed processing queue.

[0015] Optionally, the device further includes: The forwarding unit is also used to forward the next access request in the delayed processing queue to the corresponding data master node according to the order of requests in the queue.

[0016] Optionally, the data master node is the node where the data copy of the access request is located; the logical master node is a fixed coordination node corresponding to the access request of the record, determined according to a predefined mapping rule.

[0017] Optionally, the device further includes: The verification unit is used to verify whether the version information of the record access request matches the current data version.

[0018] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for executing the computer program to implement the steps of any of the above-described cluster database performance optimization methods.

[0019] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of any of the above-described cluster database performance optimization methods.

[0020] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described cluster database performance optimization methods.

[0021] This application addresses the technical problem of uncontrollable N_hop counts when multiple clients concurrently access the same record, leading to repeated requests to the local master node and thus affecting the throughput and stability of the distributed system. By determining the node affiliation of database record access requests and forwarding them hierarchically according to the logical master node and the current data master node, and by queuing and delaying concurrent access requests for the same record during record migration based on timestamps, this application standardizes the request forwarding path and concurrent request processing order. This fundamentally avoids timing conflicts during master node migration. Therefore, it solves the technical problem in existing CTDB access methods where timing conflicts during master node migration cause requests to be repeatedly sent back to the local master node, resulting in uncontrollable N_hop counts. This achieves the technical effect of effectively controlling the number of hops in access requests, improving the access processing efficiency of the CTDB database cluster, enhancing the throughput and operational stability of the distributed system, and adapting to the needs of cross-node data synchronization scenarios such as Samba clusters. Attached Figure Description

[0022] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0023] Figure 1 A flowchart illustrating a performance optimization method for a clustered database provided in an embodiment of this application; Figure 2 This is a schematic diagram illustrating a process for accessing database records, provided in an embodiment of this application. Figure 3 A schematic diagram of the structure of a performance optimization device for a clustered database provided in an embodiment of this application; Figure 4 This is a schematic diagram of another performance optimization device for clustered databases provided in an embodiment of this application. Detailed Implementation

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

[0025] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0026] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0027] The embodiments of this application provide a performance optimization method for clustered databases, and the method is described in detail below in conjunction with the execution flow of the performance optimization method for clustered databases. Figure 1 This is a flowchart illustrating a performance optimization method for a clustered database provided in an embodiment of this application.

[0028] like Figure 1 As shown, the method includes the following steps: Step 101: Obtain database record access requests; In practical applications, database record access requests typically contain unique identifiers for the data record to be accessed, such as the key in key-value data. This request can be initiated on any CTDB cluster node. When a client needs to read or modify a record, it sends an access request to a CTDB node it is connected to or that is determined by a load balancing strategy. This node, as the initial receiver of the request, is responsible for acquiring and handling this access request, thereby triggering subsequent optimization processes. This step provides a clear processing object and target for the entire performance optimization method, ensuring that subsequent node judgment, message forwarding, and concurrency control operations revolve around this specific access request. Acquiring the database record access request is a prerequisite for the implementation of the entire method; it enables the system to identify the specific data record that needs to be accessed, thus laying the foundation for addressing the problem of excessive access hops under high concurrency through fixed-hop paths and delayed queue mechanisms. The implementation of this step ensures that the optimization process is clearly targeted and operable.

[0029] Step 102: If it is determined that the current node is not the target data master node of the record access request, forward the record access request to the logical master node of the record access request. The target data master node refers to the cluster node where the latest version of the record currently resides, and its identity may change dynamically due to data migration; while the logical master node is the fixed node that belongs to the record throughout its lifecycle, calculated based on the record key value using a specific algorithm such as hash modulo. The core optimization of step 102 lies in directly directing requests received by non-target data master nodes to the fixed logical master node, effectively avoiding the invalid redirection that may occur in existing technologies, where requests are mistakenly forwarded to a non-real target data master node first.

[0030] Once the current node determines that it is not the target data master node, it no longer follows the original complex and potentially error-prone forwarding logic. Instead, it calculates its logical master node based on the record key value and sends the access request message directly to that logical master node. This design simplifies the message forwarding process, improves path determinism, and ensures that even in high-concurrency scenarios, requests can be quickly guided to a fixed node that can authoritatively guide its next step. This reduces the uncertainty and potential hops of requests roaming within the cluster, making it a key element in achieving the overall performance optimization goal.

[0031] Step 103: Forward the record access request to the current data master node, and queue and delay other access requests for the same record received during the record migration according to the timestamp.

[0032] A data master node is the node in the cluster that records the latest version of a data record in real time, and its identity may change dynamically due to migration operations. A logical master node, as the fixed coordinator of the records, possesses the accurate location information of the current data master node, thus enabling it to precisely direct access requests to the correct node that can ultimately process the request and complete the core operations of data access or modification.

[0033] When a logical master node forwards a request to a data master node, it assigns a processing status to the record and creates a delayed processing queue. If, while the record is being migrated to or processed by the data master node, the logical master node receives access requests for the same record from other nodes, it adds these newly arriving concurrent requests to the delayed queue in the order they arrived at the logical master node, i.e., according to their timestamps, for them to wait in line.

[0034] This mechanism ensures that at any given time, only one migration or processing flow occurs for the same record, and subsequent requests must wait in sequence. Once the current data master node has completed processing and migrating the previous request, the logical master node will be notified of the operation's completion via callbacks or other means. It will then retrieve the next waiting request from the delayed queue in timestamp order, process it, and forward it to the latest data master node. This timestamp-based delayed processing method effectively avoids the ping-pong effect—where multiple concurrent requests cause records to be migrated multiple times back and forth between nodes—thus strictly controlling the number of hops per record access to a fixed value, significantly improving system processing efficiency and stability in high-concurrency scenarios.

[0035] In some embodiments, forwarding the record access request to the logical master node of the record access request if it is determined that the current node is not the target data master node of the record access request includes: Calculate the fixed logical master node of the record access request based on the record identifier information of the record access request; The access request is directly routed to the logical master node.

[0036] Based on the record identification information carried in the record access request, the fixed logical master node corresponding to the record access request is calculated. The record identification information is typically key data that uniquely identifies a database record, such as the key in a key-value pair. The calculation process is based on a predetermined, cluster-consistent algorithm, such as performing a modulo operation on the hash value of the record key, with the modulus being the total number of nodes in the cluster. The logical master node calculated by this deterministic algorithm remains fixed for the same record and does not change with the actual storage location of the record data in the cluster, i.e., the data master node, thus providing a stable and predictable initial forwarding target for the request.

[0037] After calculating the fixed logical master node, the current node directly routes the access request message to that logical master node. Direct routing here means that the destination of the network message is explicitly set to the calculated logical master node address, without passing through other potentially erroneous nodes for relay or probing.

[0038] The key benefit of this mechanism is that it avoids an invalid forwarding and extra network hops caused by sending a request to a node that may no longer be the data master when the true data master node is uncertain. By directly locating the fixed logical master node, the request can quickly reach the coordinating node that can make authoritative decisions and guide its next flow along the shortest and most certain path, laying an efficient foundation for subsequent processes. This method of calculating fixed nodes and direct routing is one of the core manifestations of this approach in optimizing access paths and reducing addressing overhead.

[0039] In some embodiments, forwarding the record access request to the current data master node includes: A delayed processing queue is created for the record access request, and the record access request is marked as being in the migration processing state; Subsequent access requests for the same record received during the record access request migration processing state are added to the delayed processing queue.

[0040] When a logical master node decides to forward a received record access request to the current data master node, it synchronously creates a delayed processing queue for that record and uses a specific identifier to indicate that the record is in a migration processing state. This delayed processing queue acts as a buffer to manage multiple access requests for the same data record that arrive within a specific time window. The operations of creating the queue and identifying the state are atomic, ensuring the consistency of state determination.

[0041] While the record is in the migration processing state specified by the identifier, if the logical master node receives subsequent access requests for the same record identifier, the system will add these subsequent requests to the end of the corresponding delayed processing queue created earlier, in the order they arrived, and wait for them, instead of immediately initiating a new forwarding or migration process.

[0042] This mechanism ensures that for the same record, at most one active migration or processing procedure is executing at any given time. Only when the current data master node completes processing the previous request, and the logical master node receives the completion notification and clears the migration processing status flag, will it retrieve the next waiting request from the head of the record's delayed processing queue, calculate the latest data master node for it, and re-initiate the forwarding process. In this way, the delayed processing queue effectively serializes concurrent accesses that may cause conflicts, fundamentally eliminating the ping-pong problem caused by multiple requests competing for the same record, which leads to the record repeatedly migrating back and forth between nodes. This ensures the stability and predictable performance of the system under high-concurrency access scenarios.

[0043] In some embodiments, the method further includes: Based on the order of requests in the delayed processing queue, the next access request in the queue is forwarded to the corresponding data master node.

[0044] Based on the method for establishing and managing the delayed processing queue as described in claim 3, the method of the present invention further includes a subsequent processing flow for requests waiting in the queue. Specifically, when the logical master node confirms through callbacks or other notification mechanisms that the currently active migration or processing operation has been completed, i.e., the record is no longer in the migration processing state, it will retrieve the next access request from the queue and process it according to the entry order of the requests in the corresponding delayed processing queue. The order here typically refers to the time sequence in which the requests arrive at the logical master node and are added to the queue, which is guaranteed by the queue's own first-in-first-out characteristic or the timestamp recorded by the system.

[0045] When the logical master node processes the next request, it first needs to re-determine the latest data master node for the record at the current moment, because the actual location of the record may have changed normally after the previous processing. Then, the logical master node forwards the access request retrieved from the queue to the newly determined, latest data master node, thus initiating a new round of access and migration processes. This process repeats until the delayed processing queue becomes empty.

[0046] By strictly following the queue order to process subsequent requests, the system effectively resolves concurrency conflicts and avoids ping-pong migration of records, while also fairly ensuring that all concurrent access requests are eventually executed, and that their execution order is consistent with the order in which the requests arrive at the logical master node. This maintains the orderliness and predictability of processing, further improving the overall stability of the system and the reliability of access request processing in high-concurrency scenarios.

[0047] In some embodiments, the data master node is the node where the data copy of the record access request is located; the logical master node is a fixed coordination node corresponding to the record access request, determined according to a predefined mapping rule.

[0048] A data master node is the actual node in the cluster where the data replica corresponding to a record access request resides. It holds the latest version of the record and is the real entity that performs data read and write operations. Its identity is not fixed and may change dynamically due to load balancing, node failure recovery, or explicit migration operations. Therefore, the data master node for the same record may be different at different times.

[0049] The logical master node is a fixed coordinating node determined according to predefined mapping rules, and this node is permanently associated with the record access request. The predefined mapping rules are typically calculated based on the unique identifier information of the record using a deterministic algorithm consistent across all cluster nodes, such as performing a hash modulo operation on the record key.

[0050] For any given record, its logical master node remains fixed under unchanged cluster configuration and does not change with the actual physical location of the data replica. The main role of the logical master node is as the record's metadata manager and access coordinator. It maintains the location information of the record's current data master node and serves as the first unified forwarding target for all access requests issued by non-data master nodes.

[0051] This architectural design, which clearly divides the responsibilities of nodes into dynamic data holders and fixed coordinators, is the foundation for the performance optimization achieved by this method. By using a fixed logical master node as the initial "inquiry point," requests are prevented from blindly probing among dynamically changing nodes; while the dynamic data master node ensures the flexibility of data management and the distributability of the load. The collaborative work of both allows access requests to reach the target with the fewest and most deterministic hops, effectively solving the problem of excessively high hop counts and instability caused by dynamic changes in the target node under high concurrency.

[0052] In some embodiments, the method further includes: Verify whether the version information of the record access request matches the current data version.

[0053] When the data master node processes a record access request, or during the process of the logical master node coordinating and forwarding requests, the process involves matching and verifying the version information carried in the record access request against the current data version of the record. The version information in the record access request is typically filled in by the client or the node initiating the request when constructing the request, aiming to identify the data version state on which the request is based or expected. The current data version refers to the latest version identifier stored in the data master node. The verification and matching process determines whether the version information in the request is consistent with the current data version in the system or conforms to some expected correlation, such as whether the requested version is equal to or earlier than the current version.

[0054] If the verification result matches, it indicates that the data state upon which the request depends does not conflict with the current system status, and subsequent access, modification, or migration operations can proceed safely. This verification mechanism effectively prevents data inconsistencies caused by operations based on outdated data versions, such as lost updates or data overwriting errors.

[0055] Especially in high-concurrency environments, multiple clients may read older versions of the same record almost simultaneously and attempt to initiate updates based on them. Version verification acts as a security barrier, ensuring that only requests based on the latest data state or meeting specific version conditions are processed correctly. This maintains the strong consistency semantics of the distributed database, improving the accuracy of business logic and the overall reliability of the system. Although this step does not directly participate in hop count optimization, by ensuring the correctness of each access operation, it indirectly enhances the robustness and availability of the entire optimization method in complex real-world scenarios.

[0056] The following example illustrates a performance optimization method for a clustered database provided in this application.

[0057] Please see Figure 2 , Figure 2 This is a schematic diagram illustrating a process for accessing database records, provided in an embodiment of this application.

[0058] CTDB is a clustered database used to store key-value data. Its key roles are the local master node (Lmaster) and the designated master node (Dmaster). The Lmaster is the result of taking the hsh value of a certain record modulo all CTDB nodes, and it is a fixed node that does not change. The Dmaster is the node where the latest version of the current record is located. The Lmaster node records the Dmaster, which is the actual dmaster.

[0059] 1. Read the database record based on the key, then determine if it is the Dmaster node. If not, it needs to send a message to the CTDB CURRENT on this node. 2. This node's CTDB will also read local database records, calculate the Lmaster node for that record, and then send a REQ_CALL message to the Lmaster node. 3. After receiving the message, the Lmaster node adds a delayed processing queue based on the key, indicating that the record is being migrated, and then forwards it to the actual Dmaster node. 4. The Dmaster node returns the latest data to the client. 5. If other nodes concurrently access the record at this time, they also need to send a message to the Lmaster node. Then, based on the key, the node finds the delayed processing queue, indicating that the record is being migrated. The message is then added to the delayed queue to wait for the previous migration to complete. 6. After the last migration is completed, the next message in the delayed queue will be processed via a callback notification.

[0060] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0061] Embodiments of this application also provide a performance optimization device for clustered databases, such as... Figure 3 As shown, it includes: Acquisition unit 21 is used to acquire database record access requests; Forwarding unit 22 is used to forward the record access request to the logical master node of the record access request if it is determined that the current node is not the target data master node of the record access request. Processing unit 23 is used to forward the record access request to the current data master node and to queue and delay other access requests for the same record received during the record migration according to the timestamp.

[0062] Furthermore, in one possible implementation of this application embodiment, the forwarding unit 22 is further configured to: Calculate the fixed logical master node of the record access request based on the record identifier information of the record access request; The access request is directly routed to the logical master node.

[0063] Furthermore, in one possible implementation of this application embodiment, the processing unit 23 is further configured to: A delayed processing queue is created for the record access request, and the record access request is marked as being in the migration processing state; Subsequent access requests for the same record received during the record access request migration processing state are added to the delayed processing queue.

[0064] Furthermore, in one possible implementation of this application embodiment, the device further includes: Forwarding unit 22 is also used to forward the next access request in the queue to the corresponding data master node according to the order of requests in the delayed processing queue.

[0065] Furthermore, in one possible implementation of this application embodiment, the data master node is the node where the data copy of the record access request is located; the logical master node is a fixed coordination node corresponding to the record access request, determined according to a predefined mapping rule.

[0066] Furthermore, in one possible implementation of the embodiments of this application, such as Figure 4 As shown, the device further includes: Verification unit 24 is used to verify whether the version information of the record access request matches the current data version.

[0067] For a description of the features in the embodiment corresponding to the performance optimization device for cluster databases, please refer to the relevant description in the embodiment corresponding to the performance optimization method for cluster databases, which will not be repeated here.

[0068] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any of the above embodiments of the cluster database performance optimization method.

[0069] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described embodiments of the cluster database performance optimization method.

[0070] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0071] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described embodiments of the cluster database performance optimization method.

[0072] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described embodiments of the cluster database performance optimization method.

[0073] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0074] The above provides a detailed description of a performance optimization method, apparatus, electronic device, and storage medium for a clustered database provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A performance optimization method for a clustered database, characterized in that, include: Retrieve database record access requests; If it is determined that the current node is not the target data master node of the record access request, the record access request is forwarded to the logical master node of the record access request; The record access request is forwarded to the current data master node, and other access requests for the same record received during the record migration are queued and delayed according to the timestamp.

2. The method according to claim 1, characterized in that, The step of forwarding the record access request to the logical master node of the record access request if it is determined that the current node is not the target data master node of the record access request includes: Calculate the fixed logical master node of the record access request based on the record identifier information of the record access request; The access request is directly routed to the logical master node.

3. The method according to claim 1, characterized in that, The step of forwarding the record access request to the current data master node includes: A delayed processing queue is created for the record access request, and the record access request is marked as being in the migration processing state; Subsequent access requests for the same record received during the record access request migration processing state are added to the delayed processing queue.

4. The method according to claim 3, characterized in that, The method further includes: Based on the order of requests in the delayed processing queue, the next access request in the queue is forwarded to the corresponding data master node.

5. The method according to claim 1, characterized in that, The data master node is the node where the data copy of the access request is located; the logical master node is a fixed coordination node corresponding to the access request of the record, determined according to a predefined mapping rule.

6. The method according to claim 1, characterized in that, The method further includes: Verify whether the version information of the record access request matches the current data version.

7. A performance optimization device for a clustered database, characterized in that, include: The retrieval unit is used to retrieve database record access requests; The forwarding unit is used to forward the record access request to the logical master node of the record access request if it is determined that the current node is not the target data master node of the record access request. The processing unit is used to forward the record access request to the current data master node and to queue and delay other access requests for the same record received during the record migration according to the timestamp.

8. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the performance optimization method for a clustered database as described in any one of claims 1 to 6 when executing the computer program.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein when the computer program is executed by a processor, it implements the steps of the performance optimization method for the clustered database as described in any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the performance optimization method for a clustered database as described in any one of claims 1 to 6.

Images