Method, device and equipment for evaluating configuration changes to a database

Abstract

The present specification provides an evaluation method, device and equipment for configuration change of a database, the method comprising: in response to a user's configuration adjustment verification request for a target database deployed in a production environment, creating a first simulation database with the same hardware specifications and software parameters as the target database in a simulation environment, and synchronizing a database copy of the target database to the first simulation database; determining a verification scheme provided by the user, and making corresponding configuration changes to the first simulation database according to the content of the configuration changes defined in the verification scheme; collecting service requests processed by the target database, and importing the first simulation database after the configuration changes for playback; in the process of playing back the service requests in the first simulation database, collecting the running performance indicators of the first simulation database after the configuration changes to evaluate the feasibility of the verification scheme.

Description

Technical Field

[0001] This specification relates to the field of database technology, and more particularly to an evaluation method, apparatus, and device for making configuration changes to a database. Background Technology

[0002] With the acceleration of digital transformation, core service systems are increasingly reliant on databases, and the performance and stability of these databases directly impact user experience and service continuity. However, in the context of rapid service growth, databases often face capacity and performance bottlenecks, necessitating performance tuning. Traditional performance tuning relies heavily on the experience and judgment of operations personnel, lacking the ability to quantitatively assess the actual effects of changes in real-world service scenarios. Implementing changes directly in the production environment for performance evaluation can negatively impact database service quality; for example, it may cause service instability or even outages, posing serious service risks.

[0003] Therefore, there is an urgent need for an evaluation method for database configuration changes that do not affect the service quality of the database in the production environment. Summary of the Invention

[0004] In view of the above, one or more embodiments of this specification provide the following technical solutions: According to a first aspect of one or more embodiments of this specification, an evaluation method for configuration changes to a database is proposed, the method comprising: In response to a user's configuration adjustment verification request for a target database deployed in a production environment, a first simulation database with the same hardware specifications and software parameters as the target database is created in a simulation environment, and a database copy of the target database is synchronized to the first simulation database. Determine the verification scheme provided by the user, and make corresponding configuration changes to the first simulation database according to the content of the configuration change to the first simulation database defined in the verification scheme; Collect the service requests processed by the target database and import the first simulation database with the modified configuration for playback; During the process of replaying the service request in the first simulation database, the operating performance indicators of the first simulation database after the configuration change are collected to evaluate the feasibility of the verification scheme.

[0005] According to a second aspect of one or more embodiments of this specification, an evaluation apparatus for making configuration changes to a database is provided, the apparatus comprising: A creation module is used to respond to a user's configuration adjustment verification request for a target database deployed in a production environment, create a first simulation database in a simulation environment with the same hardware specifications and software parameters as the target database, and synchronize a database copy of the target database to the first simulation database. The configuration module is used to determine the verification scheme provided by the user, and to make corresponding configuration changes to the first simulation database according to the content of the configuration change of the first simulation database defined in the verification scheme. The replay module is used to collect the service requests processed by the target database and import the first simulation database with the changed configuration for replay. The data acquisition module is used to collect the operating performance indicators of the first simulation database after configuration changes during the process of replaying the service request in the first simulation database, so as to evaluate the feasibility of the verification scheme.

[0006] According to a third aspect of one or more embodiments of this specification, an electronic device is provided, comprising: processor; Memory used to store processor-executable instructions; The processor executes executable instructions to implement the steps of the method as described in any of the above embodiments.

[0007] According to a fourth aspect of one or more embodiments of this specification, a computer-readable storage medium is provided that stores computer instructions thereon, which, when executed by a processor, implement the steps of the method as described in any of the above embodiments.

[0008] According to a fifth aspect of one or more embodiments of this specification, a computer program product is provided, comprising a computer program / instructions that, when executed by a processor, implement the steps of the method as described in any of the above embodiments.

[0009] As can be seen from the above embodiments, the evaluation method for database configuration changes provided in this embodiment includes: responding to a user's configuration adjustment verification request for a target database deployed in a production environment, creating a first simulation database with the same hardware specifications and software parameters as the target database in a simulation environment, and synchronizing a database copy of the target database to the first simulation database; determining the verification scheme provided by the user, and making corresponding configuration changes to the first simulation database according to the content of configuration changes to the first simulation database defined in the verification scheme; collecting service requests processed by the target database, and importing them into the first simulation database after configuration changes for playback; during the playback of the service requests in the first simulation database, collecting the operating performance indicators of the first simulation database after configuration changes to evaluate the feasibility of the verification scheme.

[0010] Using the above approach, firstly, this embodiment achieves high-fidelity restoration of the target database by constructing a first simulation database in the simulation environment that is completely identical to the target database in the production environment, avoiding the impact of directly changing configurations on the target database. Secondly, by supporting user-defined verification schemes and implementing corresponding configuration changes on the first simulation database, this embodiment can flexibly simulate various optimization scenarios and replay them in conjunction with real service requests from the target database, thereby accurately evaluating the effect of the changes under actual load. Finally, by collecting runtime performance indicators in real time during the replay process, the performance of the first simulation database after configuration changes can be quantitatively compared, providing a basis for decision-making on the configuration optimization of the target database, thereby improving the security of decisions regarding configuration changes to the target database. Attached Figure Description

[0011] Figure 1 This is a schematic diagram of a database evaluation system provided in an exemplary embodiment.

[0012] Figure 2 This is an exemplary embodiment providing a process for evaluating a database configuration change. Figure 1 .

[0013] Figure 3 This is a flowchart of a playback process provided in an exemplary embodiment.

[0014] Figure 4 This is a flowchart illustrating an exemplary embodiment for obtaining performance metrics of a target database.

[0015] Figure 5 This is an exemplary embodiment providing a process for evaluating a database configuration change. Figure 2 .

[0016] Figure 6 This is a schematic diagram of the structure of a device provided in an exemplary embodiment.

[0017] Figure 7 This is a block diagram of an evaluation apparatus for making configuration changes to a database, provided in an exemplary embodiment. Detailed Implementation

[0018] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0019] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this manual are all information and data authorized by the user or fully authorized by all parties. The collection, use and processing of related data shall comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals shall be provided for users to choose to authorize or refuse.

[0020] In related technologies, stress testing or traffic replay techniques are typically used for pre-verification to mitigate the threat of configuration changes to production databases. However, existing stress testing tools usually build load models based on simulated service requests, making it difficult to accurately reproduce complex and ever-changing real service requests. While existing database traffic replay solutions can achieve "replay as is," i.e., replaying historical SQL requests under the same configuration to reproduce system behavior, they generally lack support for "change scenarios." Furthermore, these technologies directly evaluate and test the production environment database, which can impact the service quality of the production database.

[0021] This specification provides one or more embodiments of a method for evaluating configuration changes to a database. By constructing a first simulated database in a simulation environment that is completely identical to the target database in the production environment, a high-fidelity restoration of the target database is achieved, avoiding the impact of directly making configuration changes to the target database. This embodiment supports user-defined verification schemes and implements corresponding configuration changes to the first simulated database, flexibly simulating various optimization scenarios and replaying them in conjunction with real service requests from the target database, thereby accurately evaluating the effect of the changes under actual load. This embodiment collects runtime performance indicators in real time during replay, allowing for quantitative comparison of the performance of the first simulated database after configuration changes, providing a basis for decision-making regarding the configuration optimization of the target database, and thus improving the security of decisions regarding target database configuration changes.

[0022] The technical solutions provided by one or more embodiments of this specification will be described below.

[0023] refer to Figure 1 , Figure 1 This is a schematic diagram of a database evaluation system 10 provided in an exemplary embodiment. (As shown...) Figure 1 As shown, the database evaluation system may include an evaluation device 11 for configuring database changes, a target database 12, a first simulation database 12, and a configuration center 13. The evaluation device 11 is used to create the first simulation database 12 in the simulation environment and synchronize a copy of the target database to the first simulation database 12. Users can provide verification schemes at the configuration center 13. The evaluation device 11 is also used to obtain the user-provided verification scheme from the configuration center 13 and then make corresponding configuration changes to the first simulation database 12. The evaluation device 11 collects service requests from the target database and imports the service requests into the first simulation database after configuration changes for playback. Furthermore, the evaluation device 11 collects the operational performance indicators of the first simulation database after configuration changes to evaluate the feasibility of the verification scheme.

[0024] The aforementioned evaluation device 11 and configuration center 13 for database configuration changes can be deployed on the same or different servers or server clusters. Furthermore, the evaluation device 11 and configuration center 13 for database configuration changes can be completely independent, and the configuration center 13 can also be embedded in the evaluation device 11 for database configuration changes as a component or plug-in.

[0025] The aforementioned production environment refers to the operational environment that actually provides services to the outside world, supports real user access, and processes real data. A production environment is a complete operating system composed of multiple hardware and software components. These components include servers, virtual machines, network devices, operating systems, middleware, and application services.

[0026] The aforementioned simulation environment refers to a test platform built in an isolated, non-production area that replicates the hardware and software configuration, data status, and service load of the production environment as closely as possible. It is used to safely simulate and verify the effects of system changes, fault recovery, performance tuning, and other operations. The simulation environment is also a complete operating system composed of multiple hardware and software components.

[0027] In addition, users can send a configuration adjustment verification request for the target database deployed in the production environment to the evaluation device 11 for database configuration changes via the terminal device. The terminal device can also receive the verification scheme provided by the user and send the verification scheme to the evaluation device 11 for database configuration changes.

[0028] The aforementioned terminal device accesses the database configuration change evaluation device 11 via any type of wired or wireless network. The aforementioned terminal device may correspond to terminal devices such as smartphones, tablets, laptops, desktop computers, PCs (Personal Computers), PDAs (Personal Digital Assistants), wearable devices (e.g., smart glasses, smartwatches), smart in-vehicle devices, or game consoles.

[0029] The target database described above is a collection of data organized according to a specific data model and running in a production environment. The target database provides unified data definition, manipulation, querying, and control functions, ensuring data consistency, integrity, security, and efficient access.

[0030] refer to Figure 2 , Figure 2 This is a flowchart of an exemplary embodiment of an evaluation method for making configuration changes to a database.

[0031] In this embodiment, the above-described evaluation method for database configuration changes can be applied to, for example... Figure 1 The evaluation device 11 shown is for making configuration changes to the database. For example... Figure 2 As shown, the above-mentioned evaluation method for database configuration changes may include the following steps: Step 202: In response to the user's configuration adjustment verification request for the target database deployed in the production environment, create a first simulation database with the same hardware specifications and software parameters as the target database in the simulation environment, and synchronize a database copy of the target database to the first simulation database.

[0032] Hardware specifications include the number of CPU (Central Processing Unit) cores and memory size. Additional specifications may include disk and network specifications. Disk specifications include capacity, disk type, and number of disks, while network specifications include bandwidth, latency, and throughput. Software parameters include database operating parameters, such as maximum number of connections, SQL (Structured Query Language) execution memory ratio, date format, and timeout configuration. Database copies include baseline data and database objects from the target database. Database objects include at least one of the following: table structure, view definition, stored functions, index definition, and statistics relied upon by the query optimizer. Baseline data refers to the actual data records stored in each table of the target database.

[0033] In addition, the first simulation database and the target database are the same version.

[0034] It is understood that this embodiment creates a first simulation database in a simulation environment that is completely isolated from the production environment, which can be used for evaluation after the configuration of the first simulation database is changed.

[0035] In some embodiments, the hardware resource configuration information of the target database is obtained, and a first simulation database with the same hardware resource specifications as the target database is created in the simulation environment based on the hardware resource configuration information; the database operating parameters of the target database are obtained and applied to the first simulation database; and a database copy of the target database is synchronized to the first simulation database.

[0036] For example, the evaluation device for making configuration changes to the database can automatically view the hardware resource configuration information of the target database (such as 2 CPU cores and 8G memory), and then create a first simulation database in the simulation environment based on the obtained hardware resource configuration information of the target database. During the creation of the first simulation database, the same hardware resource configuration information (such as 2 CPU cores and 8G memory) as the target database will be configured for the first simulation database.

[0037] Then, after the first simulation database is created, the evaluation device that modifies the database configuration can read the database operating parameters from the target database and apply these parameters completely to the simulation database to ensure that the simulation database and the target database operate in the same way. Then, the baseline data (including data before synchronization and incremental data during synchronization) and database objects in the target database are synchronized to the first simulation database. After synchronizing the baseline data and database objects in the target database to the first simulation database, a first simulation database that is completely consistent with the target database is obtained.

[0038] In this embodiment, baseline data in the target database can be synchronized to the first simulation database using either snapshots or logical replication. Snapshot replication involves statically copying or recording the baseline data and database objects of the target database at preset intervals to create a consistent database copy, which is then copied to the first simulation database. Logical replication involves gradually synchronizing the database copy to the first simulation database by fetching the baseline data and database objects from the target database. During logical replication, the baseline data includes all data prior to synchronization and incremental data generated during the synchronization process.

[0039] Furthermore, the evaluation device for configuring and changing the database can configure the necessary account, password, and network connection information for the first simulated database, enabling testers to successfully connect to and use it. After obtaining a first simulated database consistent with the target database, a notification message can be output to inform the user that the first simulated database has been created and is ready for use.

[0040] In summary, this embodiment obtained a first simulated database that is identical to the target database deployed in the production environment in terms of hardware specifications, software parameters, and database copy. This allows subsequent performance evaluations based on the first simulated database to characterize the performance of the target database without affecting the service quality of the target database.

[0041] Step 204: Determine the verification scheme provided by the user, and make corresponding configuration changes to the first simulation database according to the content of the configuration change for the first simulation database defined in the verification scheme.

[0042] Users can input a verification plan via a terminal device, which defines the configuration changes to the first simulation database. The evaluation device that performs the database configuration changes can determine the verification plan from the terminal device.

[0043] In some embodiments, the configuration changes to the first simulation database defined in the verification scheme include at least one of the following: changes to the hardware resource specifications of the first simulation database, changes to database objects in the first simulation database, and changes to the traffic multiplier of the service request replay.

[0044] The hardware resource specification change information is used to indicate adjustments to the hardware resource specifications of the first simulation database. For example, the hardware resource specification change information is "the hardware resource specifications of the first simulation database are changed from 2 CPU cores and 8G memory to 4 CPU cores and 16G memory", or the hardware resource specification change information is "the hardware resource specifications of the first simulation database are changed from 2 CPU cores and 8G memory to 1 CPU core and 4G memory".

[0045] The database object change information is used to indicate the addition and / or deletion of indexes in the first simulation database. For example, the database object change information is "Add first index a1 in the first simulation database", or "Delete second index a2 in the first simulation database".

[0046] The information regarding changes to the traffic multiplier for service request replay is used to adjust the traffic replay multiplier for service requests. For example, the information could be: "Adjust the traffic for service request replay of the first simulation database to twice the current traffic." Or, "Adjust the traffic for service request replay of the first simulation database to 0.5 times the current traffic."

[0047] In this embodiment, the user can provide a verification scheme according to their needs, and this embodiment does not limit the specific verification scheme.

[0048] Furthermore, after determining the verification scheme, corresponding configuration changes can be made to the first simulation database. For example, if it is necessary to change the hardware resource specifications, the evaluation device that makes the configuration changes to the database can first query the current hardware resource specifications of the first simulation database (such as 2 CPU cores and 8G memory), then determine the change target (such as 4 CPU cores and 16G memory), and then perform the hardware resource change operation.

[0049] The first simulation database supports automatic hardware resource specification changes. For example, in this embodiment, the evaluation device for configuring the database can input the change target on the management page corresponding to the first simulation database, submit a request, and wait for the first simulation database to automatically complete the resource configuration update. In this embodiment, the first simulation database can also be configured in other ways, and this is not limited.

[0050] It is understandable that after the hardware resource specifications of the first simulation database are changed, the hardware resource specifications of the first simulation database will be changed to the input "change target". For example, if the change target is "4 CPU cores and 16G memory", then the hardware resource specifications of the first simulation database after the change will be "4 CPU cores and 16G memory".

[0051] To add or delete indexes in the first simulation database, you can write and execute the corresponding DDL (Data Definition Language) statements. For example, to add a first index a1 to the first simulation database, you can write and execute the DDL statement for "Add first index a1" to add the first index a1 to the first simulation database. After adding the first index a1, you can verify whether the first index a1 exists in the first simulation database. If it does, then the addition of the first index a1 was successful.

[0052] In this embodiment, both adding and / or deleting indexes can be configured by the user. This embodiment can verify whether adding and / or deleting indexes is reasonable. Reasonable addition and / or deletion of indexes can effectively reduce the load on the first simulation database.

[0053] In this embodiment, the traffic multiplier can be configured for the first simulation database. During playback, service requests can be sent to the first simulation database according to the traffic multiplier to evaluate the threshold number of QPS (Queries Per Second) that the first simulation database can bear under the change of traffic multiplier.

[0054] For example, when the target database's load pressure is low (below the alarm threshold), a traffic multiplier greater than 1 can be configured to simulate the increase in service request traffic. By compressing the interval between service request executions, the service request density per unit time is increased, thereby increasing the database's load pressure. This confirms the threshold number of QPS (Queries Per Second) that the first simulated database can handle when its load is below the alarm threshold. For instance, if the alarm threshold is 80%, the threshold number of QPS that can be handled is 4000. If the target database's current service request traffic is configured to have a QPS of 1000, meaning 1000 service requests are sent to the target database per second, and the load under this traffic is 30%, then the traffic multiplier can be increased. For example, if the traffic multiplier is 4 times, then 4000 service requests are sent to the first simulated database per second. If the first simulated database completes all 4000 service requests and its load is below the alarm threshold, then... If the traffic multiplier is configured to 4.1 times, then 4100 service requests will be sent to the first simulation database per second. If the load on the first simulation database is greater than or equal to the alarm threshold when processing these 4100 service requests, it can be determined that the threshold number of QPS that the first simulation database can bear without changing the hardware resource specifications and indexes is 4000. It can also be determined that the threshold number of QPS that the target database can bear is 4000.

[0055] When the target database's load is low (greater than or equal to the alarm threshold), the traffic multiplier can be configured to be less than 1. This simulates a reduction in service request traffic, increasing the interval between service request executions and decreasing the service request density per unit time, thereby reducing the database's load. This allows us to confirm the threshold number of QPS that the first simulated database can handle when its load is below the alarm threshold. For example, if the alarm threshold is 80%, the threshold number of QPS that can be handled is 4000. If the target database's current traffic configuration is 5000 QPS and its load is 90%, the traffic multiplier can be reduced. For instance, a traffic multiplier of 0.8 would send 4000 service requests per second to the first simulated database. If the first simulated database completes all 4000 service requests and its load is below the alarm threshold, this is considered a successful test. If the traffic multiplier is configured to 0.9, the first simulated database will process 4500 service requests per second. If the load on the first simulated database is greater than or equal to the alarm threshold when processing these 4500 service requests, it can be determined that the threshold number of QPS that the first simulated database can bear without changing the hardware resource specifications and indexes is 4000. It can also be determined that the threshold number of QPS that the target database can bear is 4000.

[0056] In this embodiment, the traffic multiple can be an integer multiple or a non-integer multiple, and there is no limitation thereto. Furthermore, depending on the configuration of the traffic multiple, the threshold number of QPS that the target database can handle varies in this embodiment. It can be understood that if the threshold number of QPS that the target database can handle is within a certain range, the target database will not generate load alarms when processing service requests within that range.

[0057] In some embodiments, the verification scheme includes: the target operating performance index provided by the user, and the corresponding configuration change of the first simulation database, including: obtaining the operating performance index of the target database and the first hardware resource specification of the target database; determining the second hardware resource specification of the first simulation database based on the operating performance index of the target database, the target operating performance index and the first hardware resource specification; and configuring the hardware resource specification of the first simulation database to the second hardware resource specification.

[0058] In some embodiments, the user-provided verification scheme includes: target performance metrics, that is, the target performance metrics that the user expects the target database to achieve after the configuration change.

[0059] In this embodiment, a preset algorithm can be used to calculate the operating performance indicators of the target database, the target operating performance indicators, and the first hardware resource specifications to obtain the second hardware resource specifications. It can be understood that this preset algorithm can predict the second hardware resource specifications required to achieve the target operating performance indicators.

[0060] For example, in the expansion mode, if the target database's performance index QPS is 1000 and the user-defined target performance index QPS is 10000, the first simulation database cannot achieve the target performance index under the first hardware resource specification (such as 2 CPU cores and 8G memory). Therefore, it is necessary to configure and change the first simulation database to the second hardware resource specification (such as 4 CPU cores and 16G memory). Under the second hardware resource specification, the first simulation database can achieve a QPS of 10000.

[0061] For the scaling-down mode, if the target database's performance metrics (QPS) are 1000 and the user-defined target performance metrics (QPS) are 500, the first simulated database has a low load (e.g., 30%) under the first hardware resource specification (e.g., 2 CPU cores and 8GB memory), meaning the hardware resource utilization is low. Therefore, the first simulated database can be configured to change to the second hardware resource specification (e.g., 1 CPU core and 2GB memory). Under the second hardware resource specification, the performance metrics and load of the first simulated database can be evaluated.

[0062] In some embodiments, the user-provided verification scheme includes a load threshold. This means that if the user wants the target database to maintain its current performance metrics while having a load greater than a load threshold (e.g., 60%) and less than an alarm threshold (e.g., 80%), then the target database's performance metrics (QPS) are 1000. If the first simulated database, with a first hardware resource specification (e.g., 2 CPU cores and 8GB memory), has a load of only 30% (less than 60%), then a second hardware resource specification can be determined based on the first hardware resource specification, the target database's performance metrics, the current load, and the load threshold. Therefore, by configuring and changing the first simulated database to the second hardware resource specification (e.g., 1 CPU core and 4GB memory), the user can evaluate whether the first simulated database can achieve a QPS of 1000 and a load greater than 60% under this second hardware resource specification.

[0063] In this embodiment, the verification scheme is provided by the user. The user can directly provide the adjustments, such as hardware resource specifications, adding and / or deleting indexes, and the playback traffic multiplier. The user can also provide the target performance indicators that the target database should achieve after the configuration change; this embodiment does not limit this.

[0064] In summary, this embodiment avoids errors caused by human error by explicitly driving configuration changes to the first simulation database based on the configuration change content defined in the user-provided verification scheme. This embodiment can automatically parse the content in the verification scheme, such as hardware specification adjustments, index additions / deletions, and traffic multiplier modifications, and accurately execute the corresponding operations on the target database, improving the accuracy and consistency of configuration management.

[0065] Step 206: Collect the service requests processed by the target database and import the first simulation database with the changed configuration for playback.

[0066] In this embodiment, at least a portion of the service requests processed by the target database can be imported into the first simulation database after configuration changes for playback.

[0067] The service request can be an operation initiated to the target database to complete a certain service function, and the service request can be in SQL form. In this embodiment, the service request is processed by the target database.

[0068] Furthermore, the process of replaying service requests in the first simulated database is the same as the process of processing service requests in the target database. Specifically, refer to... Figure 3 Step 206 includes the following steps: Step 2062: Collect the service requests processed by the target database, as well as the timestamp and transaction identifier of the service requests.

[0069] The timestamp and transaction identifier are used to restore the original execution order and transaction context of the service request.

[0070] It is understandable that when collecting service requests for target data processing, the timestamp and transaction record of the service request are simultaneously collected. Specifically, the collected service request record includes: the service request (i.e., the complete service request text), the timestamp, and the transaction identifier. Furthermore, the service request record may also include at least one of the following: the executing user, the client identifier, and the application identifier. The timestamp includes: the start time, end time, and execution time of the corresponding service request. The transaction identifier is used to preserve the transaction context.

[0071] In some embodiments, a traffic acquisition component is deployed in the production environment, and the traffic acquisition component has read-only permissions; the acquisition of service requests processed by the target database includes: using the traffic acquisition component to filter service requests that conform to a pre-configured acquisition strategy from the log table of the target database.

[0072] It is understandable that a non-intrusive traffic acquisition component is deployed in the production environment. This traffic acquisition component has read-only permissions and will not modify any data and / or configuration in the target database.

[0073] The data collection strategy is pre-configured and is used to define the collection scope. The strategy includes at least one of the following: a collection time window, a filtered user identifier, an application identifier, the type of service request, and exclusion of sensitive service requests. For example, a collection time window of the most recent 24 hours means collecting service requests from the most recent 24 hours. A filtered user identifier of user identifier b means not collecting service requests from user identifier b. An application identifier of application identifier c means collecting service requests from application identifier c. A service request type of DML (Data Manipulation Language) means collecting DML type service requests. Excluding sensitive service requests means not collecting service requests containing password fields.

[0074] In this embodiment, the target database in the production environment has its auditing function enabled. This auditing function, by default, records the service requests processed by the target database, along with the timestamps and transaction identifiers of those service requests, and stores these service requests, timestamps, and transaction identifiers in a log table in the production environment. Subsequently, the traffic collection component retrieves service requests from this log table according to the collection strategy.

[0075] In some embodiments, the method further includes: grouping the service requests according to transaction identifiers to obtain multiple groups of service requests, wherein service requests belonging to the same group have the same transaction identifier, and service request records belonging to the same group are sorted according to timestamps.

[0076] It is understandable that multiple service requests in a set of service requests have the same transaction identifier, and these multiple service requests are arranged in chronological order according to their timestamps.

[0077] Furthermore, one group of service requests from the multiple groups can be treated as an ordered message unit and written into a preset message queue, and then the service requests in the message queue can be consumed by the first simulation database.

[0078] Step 2064: Import the service request, along with its timestamp and transaction identifier, into the first simulation database after the configuration change, so that the first simulation database can replay the service request according to its timestamp and transaction identifier.

[0079] In this embodiment, the first simulation database processes service requests sequentially according to the order of the timestamps, and the transaction identifier is used to indicate that when the first simulation database processes service requests with different transaction identifiers, it can execute these service requests according to the context order indicated by the transaction identifier.

[0080] The step of importing the modified first simulation database for playback includes: importing at least one set of service requests into the modified first simulation database for playback.

[0081] In this embodiment, if the service requests for the first simulation database after the configuration change are imported include multiple sets, then these multiple sets of service requests have transactional relationships. For example, the transactions of the multiple sets of service requests are "query product inventory", "lock inventory", "create order record" and "deduct user account balance". Although these transactions appear as multiple independent service requests, they must be processed as a whole in the service logic to ensure data consistency.

[0082] In this embodiment, grouping and sorting service requests according to transaction identifiers and timestamps can maintain the original execution order and transaction boundaries of multiple service requests belonging to the same transaction identifier, so as to facilitate accurate replay in the first simulation database.

[0083] In this scenario, after making configuration changes to the first simulated database (such as adjusting table structure, indexing strategy, or simulating new service rules), the system needs to import the aforementioned multiple sets of transactionally related service requests as a whole into the simulation environment for testing. This verifies whether the configuration changes will affect the integrity, atomicity, and eventual consistency of the original transactions, thereby ensuring the stability and reliability of the system before real deployment.

[0084] Step 208: During the process of replaying the service request in the first simulation database, collect the operating performance indicators of the first simulation database after the configuration change to evaluate the feasibility of the verification scheme.

[0085] The performance metrics include at least one of the following: CPU utilization, memory utilization, average processing latency of service requests, QPS of actual processing, and slow query ratio.

[0086] For example, if the QPS of the replay traffic is 4000, that is, 4000 service requests are sent to the first simulation database every second. The first simulation database actually processes 3000 service requests per second, so the actual QPS of the processing is 3000.

[0087] In this embodiment, preset performance indicator thresholds can be set, such as a CPU utilization threshold of 80%, a memory utilization threshold of 85%, and an average processing latency threshold of 200 milliseconds for service requests. During playback, it is determined whether the collected performance indicators exceed the performance indicator thresholds. If they do, the verification scheme is deemed infeasible. If they do not exceed the thresholds, the verification scheme is deemed feasible.

[0088] In summary, this embodiment achieves high-fidelity replication of the target database by constructing a first simulated database in the simulation environment that is completely identical to the target database in the production environment, avoiding the impact of directly changing configurations on the target database. This embodiment supports user-defined verification schemes and implements corresponding configuration changes to the first simulated database, enabling flexible simulation of various optimization scenarios. By combining this with replays of real service requests from the target database, the effectiveness of the changes under actual loads can be accurately evaluated. This embodiment collects runtime performance indicators in real time during replay, allowing for quantitative comparison of the performance of the first simulated database after configuration changes. This provides a basis for decision-making regarding the configuration optimization of the target database, thereby improving the security of decisions regarding target database configuration changes.

[0089] In some embodiments, reference is made to Figure 4 The process of obtaining the performance metrics of the target database includes the following steps: Step 402: Create a second simulation database in the simulation environment that has the same hardware specifications and software parameters as the target database.

[0090] In this embodiment, the method for creating the second simulation database is the same as the method for creating the first simulation database. For details, please refer to the creation process of the first simulation database described above, which will not be repeated here.

[0091] Step 404: Import the service request into the second simulation database for playback.

[0092] In this embodiment, no configuration changes are made to the second simulation database, allowing the second simulation database to replay service requests.

[0093] The method of importing service requests into the second simulation database can be the same as that of importing service requests into the first simulation database after configuration changes, as described above, and will not be repeated here.

[0094] For example, if the target database has hardware resources of 2 CPU cores and 8GB of memory, and the QPS for processing service requests is 3000, then the hardware resources of the second simulation database also have 2 CPU cores and 8GB of memory. Without changing the database objects in the second simulation database, a service request is sent to the second simulation database according to the QPS of 3000, so that the second simulation database can replay the received service request.

[0095] Step 406: During the process of replaying the service request in the second simulation database, collect the operating performance indicators of the second simulation database, and determine the operating performance indicators of the second simulation database as the operating performance indicators of the target database.

[0096] In this embodiment, the performance indicators of the second simulation database can be determined as the performance indicators of the target database.

[0097] For example, the performance metrics collected for the second simulation database are: CPU utilization of 60%, memory utilization of 65%, average processing latency of 10 milliseconds for service requests, and QPS of 2000 for the actual processing.

[0098] In summary, this embodiment ensures a high degree of consistency between the test and production environments by constructing a second simulated database with the same hardware specifications and software parameters as the target database within a simulation environment, thereby improving the accuracy of performance evaluation. Furthermore, this embodiment imports the actual service requests processed by the target database into the second simulated database for replay, realistically replicating the load and operational scenarios of the target database in actual operation. During the replay process, this embodiment collects the performance metrics of the second simulated database and equates them to the performance metrics of the target database, achieving a non-intrusive and high-fidelity performance evaluation of the target database.

[0099] refer to Figure 5 , Figure 5 This is a flowchart of an exemplary embodiment of an evaluation method for configuring changes to a database, specifically including the following steps: Step 502: In response to the user's configuration adjustment verification request for the target database deployed in the production environment, multiple first simulation databases with the same hardware specifications and software parameters as the target database are created in the simulation environment, and the database copy of the target database is synchronized to the multiple first simulation databases.

[0100] In this embodiment, multiple first simulation databases are created. The creation process of each first simulation database can refer to step 202 above, and will not be repeated here.

[0101] In this embodiment, creating multiple first simulation databases enables parallel verification of various verification schemes.

[0102] In this embodiment, the second simulation database can be created simultaneously with multiple first simulation databases, and there is no limitation on this.

[0103] Step 504: Determine the multiple verification schemes provided by the user, and make corresponding configuration changes to the multiple first simulation databases according to the different content of configuration changes to the first simulation database defined in the multiple verification schemes.

[0104] In this embodiment, the number of multiple first simulation databases is greater than or equal to the number of multiple verification schemes, so as to realize the verification of multiple verification schemes.

[0105] There are multiple first simulation databases and multiple verification schemes, and the configuration changes made to the first simulation databases by the multiple verification schemes are not completely the same.

[0106] For example, there are multiple verification schemes such as verification scheme f1, verification scheme f2, verification scheme f3, verification scheme f4, and verification scheme f5. Verification scheme f1 involves "changing the hardware resource specifications of the first simulation database to 4 CPU cores and 16GB of memory." Verification scheme f2 involves "deleting the first index a1 from the hardware resource specifications of the first simulation database." Verification scheme f3 involves "adding the first index a2 to the hardware resource specifications of the first simulation database." Verification scheme f4 involves configuring the traffic multiplier of the first simulation database to 2 times. Verification scheme f5 involves configuring the traffic multiplier of the first simulation database to 3 times.

[0107] For multiple first simulation databases such as first simulation database k1, first simulation database k2, first simulation database k3, first simulation database k4 and first simulation database k5, the configuration of first simulation database k1 is modified using verification scheme f1, the configuration of first simulation database k2 is modified using verification scheme f2, the configuration of first simulation database k3 is modified using verification scheme f3, the configuration of first simulation database k4 is modified using verification scheme f4, and the configuration of first simulation database k5 is modified using verification scheme f5.

[0108] In summary, in this embodiment, the verification scheme and the first simulation database are in one-to-one correspondence. It can be understood that each first simulation database is configured and modified based on the target database.

[0109] The configuration change method for each of the first simulation databases can be referred to in step 204 above, and will not be repeated here.

[0110] Step 506: Collect the service requests processed by the target database, and import multiple first simulation databases with modified configurations for parallel playback.

[0111] It is understandable that each of the first simulation databases independently replays the same service requests. For example, after the configuration of the first simulation databases k1 to k5 is changed using their respective verification schemes, the service requests are replayed separately.

[0112] The specific implementation process of each first simulation database playback service request can be referred to step 206 above, and will not be repeated here.

[0113] Step 508: During the process of replaying the service request in parallel on multiple first simulation databases, collect the running performance indicators of each of the multiple first simulation databases.

[0114] During the playback process, the performance metrics of each first simulation database are collected to obtain the performance metrics of each first simulation database in multiple first simulation databases.

[0115] In this embodiment, the method for collecting the performance indicators of each first simulation database can refer to step 208 above, and will not be repeated here.

[0116] Step 510: Based on the performance metrics of the target database and the performance metrics of each of the first simulation databases, generate a performance comparison report and output the performance comparison report.

[0117] The performance comparison includes the performance metrics of the target database and the performance metrics of each verification scheme f1. For example, the generated performance comparison report is shown in Table 1, and the report can be visualized.

[0118] Table 1 In this embodiment, the performance comparison report may further include verification schemes with improved operating performance metrics and verification schemes with decreased operating performance metrics. Furthermore, it may output the growth rate or reduction rate of the operating performance metrics corresponding to each verification scheme relative to the operating performance metrics of the target database. For example, the average processing latency of verification scheme f1 is reduced by 50% relative to the average processing latency of the target database.

[0119] In this embodiment, generating a performance comparison report can guide users to make corresponding configuration changes to the target database based on a verification scheme that can improve operational performance indicators.

[0120] In the actual evaluation process, users can provide a large number of verification schemes for verification in order to obtain a verification scheme that meets the user's needs.

[0121] For example, users can initially provide different traffic multipliers to test the QPS (queries per second) that the first simulated database can handle before a load alarm. For instance, with a target database traffic of 2000, multiple first simulated databases can replay service requests at traffic levels of 2500, 3000, 3500, 4000, 4500, and 5000. If the first simulated database does not trigger a load alarm at a traffic level of 4500, but does trigger one at a traffic level of 5000, then the threshold number of service requests the target database can handle is determined to be 4500, and the performance metrics tested at a traffic level of 4500 are recorded. The corresponding performance metrics can then be output.

[0122] If the user expects the target database to handle a threshold of 10,000 service requests, then the aforementioned 4,500 does not meet the user's requirements. The user can then provide a verification plan for scaling up. For example, one verification plan could be a traffic multiplier of 5 and hardware resource specifications of 4 CPU cores and 16GB of memory. Another verification plan could be a traffic multiplier of 5 and hardware resource specifications of 8 CPU cores and 32GB of memory. In this case, the hardware resource specifications of one of the first simulation databases could be configured to be changed to 4 CPU cores and 16GB of memory, and service requests could be replayed to this modified first simulation database at a QPS of 10,000 to collect the corresponding performance metrics. Similarly, the hardware resource specifications of the other first simulation database could be configured to be changed to 8 CPU cores and 32GB of memory, and service requests could be replayed to this modified first simulation database at a QPS of 10,000 to collect the corresponding performance metrics.

[0123] If the user-provided verification scheme includes deleting and / or adding indexes, and tests the threshold number of service requests that the first simulated database can handle after deleting and / or adding indexes, then configuration changes can be made to the first simulated database based on the deletion and / or addition of indexes. During replay, different traffic multipliers can be used for replays of multiple first simulated databases with different configuration changes. For example, the first verification scheme is: adding the first index a1 with a traffic multiplier of 1.5. The second verification scheme is: adding the first index a1 with a traffic multiplier of 2. The third verification scheme is: adding the first index a1 with a traffic multiplier of 2.5. The fourth verification scheme is: adding the first index a1 with a traffic multiplier of 3. These four verification schemes can then be verified on four first simulated databases respectively, thereby obtaining the threshold number of service requests that the first simulated database can handle after adding the first index a1.

[0124] In this embodiment, the user can provide any verification scheme according to actual needs, and this embodiment does not limit it.

[0125] In this embodiment, a first simulation database evaluates only one verification scheme. If a first simulation database evaluates multiple verification schemes, the previous verification scheme will generate new incremental data in the first simulation database after evaluation. Consequently, subsequent verification schemes will not be evaluated based on the first simulation data with the same configuration as the original target database, which will lead to evaluation errors in the verification schemes.

[0126] In summary, this embodiment creates multiple first simulated databases in a simulation environment that are completely identical to the target database in terms of hardware specifications and software parameters, and synchronizes their database copies. This highly replicates the real state of the production environment, providing a high-fidelity test foundation for subsequent configuration adjustment verification and significantly improving the credibility of the verification results. Furthermore, this embodiment implements one-to-one configuration changes for each of the multiple simulated databases for various user-provided verification schemes, and replays real service requests collected from the production environment in parallel. This not only achieves efficient and isolated comparative evaluation of multiple verification schemes but also avoids service interruptions or performance risks associated with direct trial and error in the production environment. Finally, this embodiment collects the operational performance indicators of each first simulated database in real time during the replay process and compares them with the operational performance indicators of the original target database, automatically generating a performance comparison report. This allows users to quickly and objectively evaluate the actual effects of different verification schemes, enabling them to make better configuration decisions and improve the security of target database operation and maintenance.

[0127] Corresponding to the aforementioned embodiments of the evaluation method for database configuration changes, this specification also provides embodiments of an evaluation apparatus for database configuration changes.

[0128] refer to Figure 6 , Figure 6 This is a schematic diagram of the structure of a device provided in an exemplary embodiment. For example... Figure 6 As shown, device 600 mainly consists of a communication interface 602, a user interface 604, a processor 606, and a data storage 608. These components are interconnected and communicate with each other via a system bus, network, or other connection mechanism 610. The communication interface 602 enables device 600 to communicate with other devices, access networks, and transmission networks via analog or digital modulation. For example, the communication interface 602 may include a chipset and antenna for wireless communication with a radio access network or access point. Furthermore, the communication interface 602 can be a wired interface such as Ethernet, Token Ring, or a USB port, or a wireless interface such as Wi-Fi, Bluetooth, Global Positioning System (GPS), or a wide-area wireless interface (e.g., WiMAX or LTE). Of course, the communication interface 602 can also support other forms of physical layer interfaces and standard or proprietary communication protocols. The communication interface 602 may also include multiple physical communication interfaces, such as Wi-Fi, Bluetooth, and wide-area wireless interfaces.

[0129] User interface 604 includes receiving user input and providing output to the user. Therefore, user interface 604 may include input components such as a keypad, keyboard, touch-sensitive or presence-sensitive panel, computer mouse, trackball, joystick, microphone, still camera, and video camera, and output components such as a display screen (which may be combined with a touch-sensitive panel), CRT, LCD, LED, display using DLP technology, printer, and other similar devices known or developed in the future. User interface 604 may also generate auditory output via speakers, speaker jacks, audio output ports, audio output devices, headphones, and other similar devices known or developed in the future. In some embodiments, user interface 604 may include software, circuitry, or other forms of logic capable of transmitting and receiving data from external user input / output devices. Additionally or alternatively, device 600 may support remote access from other devices via communication interface 602 or another physical interface (not shown). User interface 604 may be configured to receive user input, the position and movement of which may be indicated by indicators or cursors described herein. User interface 604 may also be configured as a display device for rendering or displaying text fragments.

[0130] Processor 606 may contain one or more general-purpose processors and / or special-purpose processors.

[0131] Data storage 608 may include one or more volatile and / or non-volatile storage components and may be integrated wholly or partially with processor 606. Data storage 608 may include removable and non-removable components.

[0132] Processor 606 is capable of executing program instructions 618 (e.g., compiled or uncompiled program logic and / or machine code) stored in data storage 608 to perform the various functions described herein. Data storage 608 may contain a non-transitory computer-readable medium on which program instructions are stored, which, when executed by device 600, enable device 600 to perform any methods, processes, or functions disclosed in this specification and / or the accompanying drawings. Execution of program instructions 618 by processor 606 may result in processor 606 using data 612.

[0133] For example, program instructions 618 may include an operating system 622 (e.g., an operating system kernel, device drivers, and / or other modules) installed on device 600 and one or more applications 620 (e.g., a browser, social application, or game application). Similarly, data 612 may include operating system data 616 and application data 614. Operating system data 616 is primarily accessible to the operating system 622, while application data 614 is primarily accessible to one or more applications 620. Application data 614 may reside in a file system visible or hidden from the user of device 600.

[0134] Application 620 can communicate with operating system 622 through one or more application programming interfaces (APIs). These APIs help application 620 read and / or write application data 614, transmit or receive information via communication interface 602, receive or display information on user interface 604, etc.

[0135] In some terminology, application 620 may be simply referred to as "app". Furthermore, application 620 can be downloaded to device 600 through one or more online app stores or app markets. However, applications can also be installed on device 600 in other ways, such as through a web browser or a physical interface on device 600 (e.g., a USB port).

[0136] refer to Figure 7 , Figure 7 This is a block diagram of an evaluation apparatus for making configuration changes to a database, provided in an exemplary embodiment. This evaluation apparatus for making configuration changes to a database can be applied to, for example... Figure 6 The device shown is used to implement the technical solution described in this specification.

[0137] The aforementioned evaluation apparatus for making database configuration changes may include: The creation module 71 is used to respond to a user's configuration adjustment verification request for a target database deployed in the production environment, create a first simulation database with the same hardware specifications and software parameters as the target database in the simulation environment, and synchronize a database copy of the target database to the first simulation database. Configuration module 72 is used to determine the verification scheme provided by the user, and to make corresponding configuration changes to the first simulation database according to the content of configuration changes to the first simulation database defined in the verification scheme. The playback module 73 is used to collect the service requests processed by the target database and import the first simulation database with the changed configuration for playback; The acquisition module 74 is used to acquire the operating performance indicators of the first simulation database after configuration changes during the process of replaying the service request in the first simulation database, so as to evaluate the feasibility of the verification scheme.

[0138] In some embodiments, when the playback module 73 collects service requests processed by the target database, it is specifically used for: Collect the service requests processed by the target database, as well as the timestamps and transaction identifiers of the service requests. The timestamps and transaction identifiers are used to reconstruct the original execution order and transaction context of the service requests. The process of replaying the first simulation database after the configuration changes includes: The service request, along with its timestamp and transaction identifier, is imported into the first simulation database after the configuration change, so that the first simulation database can replay the service request according to its timestamp and transaction identifier.

[0139] In some embodiments, a traffic acquisition component is deployed in the production environment, and the traffic acquisition component has read-only permissions; when the playback module 73 collects service requests processed by the target database, it is specifically used for: The traffic collection component filters service requests that match the pre-configured collection strategy from the log table of the target database.

[0140] In some embodiments, the apparatus further includes: The grouping module (not shown in the figure) is used to group the service requests according to the transaction identifier to obtain multiple groups of service requests. The service requests belonging to the same group have the same transaction identifier, and the service request records belonging to the same group are sorted by timestamp. When the playback module 73 imports the first simulation database after the configuration change for playback, it is specifically used to: import at least one set of service requests into the first simulation database after the configuration change for playback.

[0141] In some embodiments, the verification scheme includes: the target runtime performance indicators provided by the user, and the configuration module 72, when making corresponding configuration changes to the first simulation database, is specifically used for: Obtain the operating performance indicators of the target database and the first hardware resource specifications of the target database; Based on the target database's operating performance indicators, the target operating performance indicators, and the first hardware resource specifications, determine the second hardware resource specifications of the first simulation database; The hardware resource specifications of the first simulation database are changed to the second hardware resource specifications.

[0142] In some embodiments, when the configuration module 72 obtains the operating performance metrics of the target database, it is specifically used for: Create a second simulation database in a simulation environment that has the same hardware specifications and software parameters as the target database; Import the service request into the second simulation database for replay; During the process of replaying the service request in the second simulation database, the operating performance indicators of the second simulation database are collected, and the operating performance indicators of the second simulation database are determined as the operating performance indicators of the target database.

[0143] In some embodiments, there are multiple first simulation databases and multiple verification schemes, and the configuration changes made to the first simulation databases defined by the multiple verification schemes are not completely the same; When the configuration module 72 makes corresponding configuration changes to the first simulation database, it is specifically used to: make one-to-one corresponding configuration changes to the multiple first simulation databases according to the different contents of the configuration changes to the first simulation database defined in the multiple verified schemes. When the playback module 73 imports the first simulation database after configuration changes for playback, it is specifically used to: import multiple first simulation databases after configuration changes for parallel playback.

[0144] In some embodiments, the acquisition module 74 is specifically used for: During the parallel replay of the service request in multiple first simulation databases, the running performance indicators of each of the multiple first simulation databases are collected. Based on the performance metrics of the target database and the performance metrics of each of the first simulation databases, a performance comparison report is generated and output.

[0145] In some embodiments, the configuration changes to the first simulation database defined in the verification scheme include at least one of the following: changes to the hardware resource specifications of the first simulation database, changes to database objects in the first simulation database, and changes to the traffic multiplier of the service request replay.

[0146] For ease of description, the above devices are described by dividing them into various modules or units based on their functions. Of course, when implementing one or more of these specifications, the functions of each module or unit can be implemented in one or more software and / or hardware components, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0147] Based on the same concept as the methods described above, this specification also provides an electronic device, including: a processor; a memory for storing processor-executable instructions; wherein the processor performs the steps of the methods as described in any of the above embodiments by executing the executable instructions.

[0148] Based on the same concept as the methods described above, this specification also provides a computer-readable storage medium having computer instructions stored thereon that, when executed by a processor, implement the steps of the methods as described in any of the above embodiments.

[0149] Based on the same concept as the methods described above, this specification also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the methods as described in any of the embodiments above.

[0150] What those skilled in the art will understand is: In this specification, the terms "comprising," "including," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, product, 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 process, method, product, or apparatus. Without further limitation, the presence of additional identical or equivalent elements in the process, method, product, or apparatus that includes elements is not excluded.

[0151] In this specification, “a,” “an,” and “the” do not specifically refer to the singular, but may also include the plural.

[0152] In this specification, ordinal numbers such as "first," "second," etc., do not necessarily indicate order; they are often used to distinguish between objects. For example, "first server" and "second server" usually refer to two servers. To differentiate between these two servers, they are described as "first server" and "second server." Of course, sometimes these two servers may be the same server.

[0153] In this specification, unless explicitly stated otherwise, "receiving and sending data" does not necessarily mean direct receiving and sending; it can also mean indirect receiving and sending. For example, A receiving data sent by B can be understood as A directly receiving the data sent by B, or it can be understood as A indirectly receiving the data sent by B through other entities such as C. Similarly, B sending data to A can be understood as B sending the data directly to A, or it can be understood as B indirectly sending the data to A through other entities such as C. Here, C can be one entity, or it can be two or more entities.

[0154] In this specification, unless explicitly stated otherwise, the relationships between structures can be direct or indirect. For example, when describing "A is connected to B," unless it is explicitly stated that A and B are directly connected, it should be understood that A can be directly connected to B or indirectly connected to B. Similarly, when describing "A is on top of B," unless it is explicitly stated that A is directly above B (AB is adjacent and A is above B), it should be understood that A can be directly above B or indirectly above B (AB is separated by other elements, and A is above B). And so on.

[0155] This specification uses specific terms to describe embodiments thereof. Terms such as "an embodiment," "one embodiment," and / or "some embodiments" refer to a particular feature, structure, or characteristic associated with at least one embodiment of this specification. Therefore, it should be emphasized and noted that references to "an embodiment," "one embodiment," or "an alternative embodiment" in different locations throughout this specification do not necessarily refer to the same embodiment. Furthermore, those skilled in the art can combine and integrate the different embodiments or examples described herein, as well as the features of those different embodiments or examples, without contradiction.

[0156] Although one or more embodiments of this specification provide method steps as shown in the embodiments or flowcharts, it is understood that the order of steps listed in the embodiments or flowcharts is only one way of executing many steps and does not represent the only execution order. Therefore, when the claims involve method steps, the changes and adjustments to the order of such steps, or the parallelism between steps, are also within the scope of protection of the claims.

Claims

1. A method for evaluating configuration changes to a database, the method comprising: In response to a user's configuration adjustment verification request for a target database deployed in a production environment, a first simulation database with the same hardware specifications and software parameters as the target database is created in a simulation environment, and a database copy of the target database is synchronized to the first simulation database. Determine the verification scheme provided by the user, and make corresponding configuration changes to the first simulation database according to the content of the configuration change to the first simulation database defined in the verification scheme; Collect the service requests processed by the target database and import the first simulation database with the modified configuration for playback; During the process of replaying the service request in the first simulation database, the operating performance indicators of the first simulation database after the configuration change are collected to evaluate the feasibility of the verification scheme.

2. The method according to claim 1, wherein collecting the service requests processed by the target database includes: Collect the service requests processed by the target database, as well as the timestamps and transaction identifiers of the service requests. The timestamps and transaction identifiers are used to reconstruct the original execution order and transaction context of the service requests. The process of replaying the first simulation database after the configuration changes includes: The service request, along with its timestamp and transaction identifier, is imported into the first simulation database after the configuration change, so that the first simulation database can replay the service request according to its timestamp and transaction identifier.

3. The method according to claim 1, wherein a traffic acquisition component is deployed in the production environment, and the traffic acquisition component has read-only permissions; the acquisition of service requests processed by the target database includes: The traffic collection component filters service requests that match the pre-configured collection strategy from the log table of the target database.

4. The method according to claim 3, further comprising: The service requests are grouped according to the transaction identifier to obtain multiple groups of service requests. Service requests belonging to the same group have the same transaction identifier, and the service request records belonging to the same group are sorted by timestamp. The process of importing and replaying the first simulation database after configuration changes includes: importing at least one set of service requests into the first simulation database after configuration changes and replaying them.

5. The method according to any one of claims 1 to 4, wherein the verification scheme comprises: The target performance metrics provided by the user, and the corresponding configuration changes to the first simulation database, include: Obtain the operating performance indicators of the target database and the first hardware resource specifications of the target database; Based on the target database's operating performance indicators, the target operating performance indicators, and the first hardware resource specifications, determine the second hardware resource specifications of the first simulation database; The hardware resource specifications of the first simulation database are changed to the second hardware resource specifications.

6. The method according to claim 5, wherein obtaining the operating performance indicators of the target database includes: Create a second simulation database in a simulation environment that has the same hardware specifications and software parameters as the target database; Import the service request into the second simulation database for replay; During the process of replaying the service request in the second simulation database, the operating performance indicators of the second simulation database are collected, and the operating performance indicators of the second simulation database are determined as the operating performance indicators of the target database.

7. The method according to claim 6, wherein the number of the first simulation databases is multiple, the number of verification schemes is multiple, and the configuration changes to the first simulation databases defined by the multiple verification schemes are not completely the same; The step of making corresponding configuration changes to the first simulation database includes: making one-to-one configuration changes to the multiple first simulation databases according to the different contents of configuration changes to the first simulation database defined in the multiple verified schemes. The process of importing and replaying the first simulation database after configuration changes includes: importing multiple first simulation databases after configuration changes and replaying them in parallel.

8. The method according to claim 7, wherein collecting the operational performance indicators of the first simulation database after configuration changes to evaluate the feasibility of the verification scheme includes: During the parallel replay of the service request in multiple first simulation databases, the running performance indicators of each of the multiple first simulation databases are collected. Based on the performance metrics of the target database and the performance metrics of each of the first simulation databases, a performance comparison report is generated and output.

9. The method according to any one of claims 1 to 4, wherein the content of the configuration change for the first simulation database defined in the verification scheme includes at least one of the following: change information of the hardware resource specifications of the first simulation database, change information of the database objects in the first simulation database, and change information of the traffic multiple of the service request replay.

10. An evaluation apparatus for configuring changes to a database, the apparatus comprising: A creation module is used to respond to a user's configuration adjustment verification request for a target database deployed in a production environment, create a first simulation database in a simulation environment with the same hardware specifications and software parameters as the target database, and synchronize a database copy of the target database to the first simulation database. The configuration module is used to determine the verification scheme provided by the user, and to make corresponding configuration changes to the first simulation database according to the content of the configuration change of the first simulation database defined in the verification scheme. The replay module is used to collect the service requests processed by the target database and import the first simulation database with the changed configuration for replay. The data acquisition module is used to collect the operating performance indicators of the first simulation database after configuration changes during the process of replaying the service request in the first simulation database, so as to evaluate the feasibility of the verification scheme.

11. An electronic device, comprising: processor; Memory used to store processor-executable instructions; The processor implements the steps of the method as described in any one of claims 1 to 9 by executing the executable instructions.

12. A computer-readable storage medium having stored thereon computer instructions that, when executed by a processor, implement the steps of the method as claimed in any one of claims 1 to 9.

13. A computer program product comprising a computer program / instructions that, when executed by a processor, implement the steps of the method as claimed in any one of claims 1 to 9.

Images