Database state evaluation method and device, storage medium and electronic equipment

Abstract

The invention discloses a database state evaluation method and device, a storage medium and electronic equipment. The method comprises the steps that performance index description information matched with a performance index is obtained, and the performance index is an index influencing the performance of database operation; under the condition that the database state meets the abnormal state condition, determining a weight adjustment strategy according to the performance index description information; according to a weight adjustment strategy, weight parameters matched with all database indexes are determined, and the database indexes are used for indicating the performance of database operation; and determining a state evaluation result of the database according to the weight parameters matched with the database indexes respectively. According to the method and the device, the technical problem of inaccurate database state evaluation is solved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of databases, and in particular, to a database state evaluation method and device, a storage medium, and an electronic device. BACKGROUND

[0002] Currently, when processing large-scale online services, a database health inspection tool is usually relied on to monitor and maintain the stable operation of the database. However, in the modern IT architecture of high distribution and micro-service, the database is often not worked in isolation, but closely cooperates with other middleware such as cache, message queue, load balancing and other components. For example, in actual business scenarios, a decrease in Redis cache hit rate will cause a sharp increase in database query pressure, and Kafka message backlog may cause database write delay.

[0003] The prior art usually ignores the mutual influence between the middleware and the database, which greatly limits the comprehensiveness and accuracy of the database health evaluation. That is, in the prior art, since the performance indicators of the middleware are not considered to affect the performance of the associated database, the technical problem of inaccurate state evaluation of the database is caused.

[0004] In view of the above problems, no effective solution has been proposed so far. SUMMARY

[0005] The embodiments of the present application provide a database state evaluation method and device, a storage medium and an electronic device to at least solve the technical problem of inaccurate state evaluation of the database.

[0006] According to an aspect of the embodiments of the present application, a database state evaluation method is provided, comprising: obtaining performance indicator description information matched with a performance indicator, wherein the performance indicator is an indicator affecting the performance of a database operation; in a case where it is determined that a database state satisfies an abnormal state condition, determining a weight adjustment strategy according to the performance indicator description information; determining a weight parameter respectively matched with each database indicator according to the weight adjustment strategy, wherein the database indicator is used to indicate the performance of the database operation; and determining a state evaluation result of the database according to the weight parameter respectively matched with each database indicator.

[0007] According to another aspect of the embodiments of this application, a database status evaluation apparatus is also provided, comprising: an acquisition unit for acquiring performance indicator description information matching performance indicators, wherein the performance indicators are indicators that affect the performance of database operations; a first determination unit for determining a weight adjustment strategy based on the performance indicator description information when it is determined that the database status meets abnormal status conditions; a second determination unit for determining weight parameters that match each database indicator respectively according to the weight adjustment strategy, wherein the database indicators are used to indicate the performance of database operations; and a third determination unit for determining the database status evaluation result based on the weight parameters that match each database indicator respectively.

[0008] Optionally, the first determining unit mentioned above includes a fourth determining module, used to determine that the database status meets the abnormal status conditions when the performance status parameter indicated by the performance indicator description information is an abnormal status value; determine the abnormal type according to the performance indicator description information; and determine the weight adjustment strategy according to the abnormal type.

[0009] Optionally, the fourth determining module is further configured to, when determining that the anomaly type is an abnormal load transfer type caused by operational load transfer based on the performance indicator description information, determine that the weight adjustment direction indicated by the weight adjustment strategy is to increase the weight parameter matching the first type of database indicator, wherein the first type of database indicator is an indicator indicating database query performance; and when determining that the anomaly type is an abnormal resource release type caused by resource processing pressure release based on the performance indicator description information, determine that the weight adjustment direction indicated by the weight adjustment strategy is to decrease the weight parameter matching the second type of database indicator, wherein the second type of database indicator is an indicator indicating database write performance.

[0010] Optionally, the fourth determining module described above is also used to determine the anomaly level parameter that matches the database metric, and the correlation parameter between the database metric and the performance metric; determine the parameter adjustment factor that matches the database metric based on the anomaly level parameter and the correlation parameter; and determine the weight parameter that matches the database metric based on the parameter adjustment factor that matches the database metric and the weight adjustment direction.

[0011] Optionally, the fourth determining module is further used to determine the anomaly level parameter matching the database metric based on the metric deviation information, task impact degree, and anomaly duration; and to determine the correlation parameter between the database metric and the performance metric based on the relationship graph, wherein the relationship graph is constructed based on the database metric and the performance metric.

[0012] Optionally, the third determining unit mentioned above includes a fifth determining module, used to determine the expected load state that matches each database indicator; and to determine the database status assessment result based on the expected load state of each database indicator and the weight parameters that match it.

[0013] Optionally, the first determining unit includes a prediction module, used to determine fault propagation information and database anomaly type, wherein the fault propagation information is used to indicate the predicted changes in database indicators; to determine predicted fault information based on the fault propagation information and anomaly type; and to determine early warning description information based on the predicted fault information, wherein the early warning description information is used to indicate the scope of business affected by the fault path indicated by the predicted fault information.

[0014] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, wherein a computer program is stored in the computer program, and the computer program is configured to execute the above-described database state evaluation method at runtime.

[0015] According to another aspect of the embodiments of this application, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the above-described database status evaluation method through the computer program.

[0016] In this embodiment, performance indicator description information matching the performance indicators is obtained, wherein the performance indicators are indicators that affect the performance of database operations; when it is determined that the database state meets the abnormal state conditions, a weight adjustment strategy is determined based on the performance indicator description information; weight parameters matching each database indicator are determined according to the weight adjustment strategy, wherein the database indicators are used to indicate the performance of database operations; and the database state evaluation result is determined based on the weight parameters matching each database indicator. This realizes the ability to dynamically adjust weight parameters based on middleware correlation, dynamic business load, and real-time performance indicator status, thereby more accurately evaluating the current health status of the database and solving the technical problem of inaccurate database state evaluation. Attached Figure Description

[0017] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0018] Figure 1 This is a schematic diagram of an application environment for an optional database status evaluation method according to an embodiment of this application;

[0019] Figure 2This is a flowchart of an optional database status evaluation method according to an embodiment of this application;

[0020] Figure 3 This is a flowchart of another optional method for evaluating the database status according to an embodiment of this application;

[0021] Figure 4 This is a flowchart of an optional fault prediction method according to an embodiment of this application;

[0022] Figure 5 This is a schematic diagram of an optional database status evaluation method according to an embodiment of this application;

[0023] Figure 6 This is a schematic diagram of the structure of an optional database status evaluation device according to an embodiment of this application;

[0024] Figure 7 This is a schematic diagram of the structure of an optional electronic device according to an embodiment of this application. Detailed Implementation

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

[0026] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0027] According to one aspect of the embodiments of this application, a method for evaluating database status is provided. Optionally, as an optional implementation, the above-described database status evaluation method may be applied to, but is not limited to, [examples of other methods]. Figure 1 In the environment shown.

[0028] Server 112 includes a database 114 and a processing engine 116; terminal device 102 includes a display 108, a processor 106, and a memory 104; the server and terminal device can interact via network 110.

[0029] Server 112 executes S102 to obtain performance metric description information that matches the performance metrics, where the performance metrics are those that affect the performance of database operations.

[0030] S104, if it is determined that the database state meets the abnormal state conditions, determine the weight adjustment strategy based on the performance index description information;

[0031] S106, Determine the weight parameters that match each database metric according to the weight adjustment strategy, wherein the database metric is used to indicate the performance of database operations.

[0032] S108, determine the database status assessment result based on the weight parameters matched with each database indicator.

[0033] Optionally, in this embodiment, the terminal device can be a terminal device configured with a target client, which may include, but is not limited to, at least one of the following: mobile phone (such as Android phone, iOS phone, etc.), laptop computer, tablet computer, PDA, MID (Mobile Internet Devices), PAD, desktop computer, smart TV, etc. The target client may be a video client, instant messaging client, browser client, educational client, etc. The network may include, but is not limited to, wired network and wireless network, wherein the wired network includes: local area network, metropolitan area network and wide area network, and the wireless network includes: Bluetooth, WIFI and other networks that enable wireless communication. The server may be a single server, a server cluster composed of multiple servers, or a cloud server. The above is only an example, and no limitation is made in this embodiment.

[0034] Alternatively, as an alternative implementation method, such as Figure 2 As shown, the methods for evaluating the database status mentioned above include:

[0035] S202, Obtain performance metric description information that matches the performance metrics, where the performance metrics are those that affect the performance of database operations;

[0036] S204, If it is determined that the database state meets the abnormal state conditions, the weight adjustment strategy is determined based on the performance index description information;

[0037] S206, Determine the weight parameters that match each database metric according to the weight adjustment strategy, wherein the database metric is used to indicate the performance of database operations;

[0038] S208, determine the database status assessment result based on the weight parameters matched with each database indicator.

[0039] In step S202, performance indicator description information matching the performance indicator is obtained, wherein the performance indicator is an indicator that affects the performance of database operations. Optionally, the aforementioned performance indicator may specifically be middleware indicator, such as cache middleware indicator (including cache hit rate, cache utilization, etc.), message queue middleware indicator (including message backlog, message queue latency, etc.), and load balancing middleware indicator (including request processing time, number of connections, etc.); the aforementioned performance indicator description information is specifically the parameter value corresponding to the performance indicator, such as cache hit rate value, message queue latency time, etc.

[0040] In step S204, if it is determined that the database state meets the abnormal state conditions, a weight adjustment strategy is determined based on the performance index description information.

[0041] As an alternative implementation, for example, if the query latency exceeds a threshold or the CPU utilization is close to full load, the database is considered to be in an abnormal state; when a significant increase in query latency is detected, the weight of the query latency performance metric will be temporarily increased to highlight its negative impact on the database health.

[0042] In step S206, weight parameters that match each database metric are determined according to the weight adjustment strategy, wherein the database metrics are used to indicate the performance of database operations.

[0043] Optionally, the aforementioned database metrics include resource usage metrics (CPU utilization, disk I / O, etc.), query response time, transaction processing latency, number of queries processed per second (QPS), master-slave replication latency, etc. The larger the weight parameter, the stronger the influence of the corresponding metric on the evaluation results of the database.

[0044] Further in step S208 above, the status assessment result of the database is determined according to the weight parameters matched with each database indicator. For example, if all indicators perform well and the weight parameters are evenly distributed, the assessment result will be displayed as "healthy"; if several key indicators are seriously out of the normal range, even if other indicators are normal, the assessment result may be displayed as "warning" or "fault".

[0045] Using flowcharts Figure 3 The scoring process described above is explained below:

[0046] S302, Load Static Weights (Preset Values); Used to initialize the baseline weights for each database metric, serving as a benchmark for scoring. Initial weights can be assigned to each metric based on historical experience or industry standards. Example: CPU utilization: 20%, query latency: 15%, connection count: 10%, disk I / O: 15%, transaction success rate: 20%, replication latency (master-slave): 20%, weight normalization: ensures the sum of all weights is 100%. Multiple weight templates can be preset for different business scenarios (such as financial transactions, e-commerce promotions), automatically switching according to the scenario.

[0047] S304 is used to detect middleware anomalies; it monitors the operational status of the middleware cluster and identifies anomalies that may affect database health. Anomaly detection methods include: threshold alerts: preset thresholds for key middleware metrics (e.g., Redis cache hit rate <70%, Kafka message backlog >5000); time-series anomaly detection: using algorithms (e.g., moving average, STL decomposition) to identify sudden increases or decreases in metrics; correlation analysis: combining multiple middleware metrics for joint judgment (e.g., a decrease in Redis hit rate and an increase in Kafka consumption latency), etc. Example: A Redis cache hit rate is detected to drop sharply from 75% to 60% for 5 minutes → marked as a "cache anomaly event".

[0048] S304-1, Is there an anomaly? If an anomaly is detected, execute S306, matching the dynamic weight adjustment rule according to the anomaly type. The rule base design can be in the following format: IF <middleware exception condition> THEN <adjustment action>; rule examples: RULE-001: IF Redis cache hit rate < 70% THEN, increase the query latency weight of the associated database by 10%; RULE-002: IF Kafka message backlog > 10,000 THEN, increase the write latency weight of the associated database by 15%.

[0049] The matching logic includes exact matching: directly hitting the anomaly type (such as low Redis hit rate); and fuzzy matching: matching compound anomaly scenarios through similarity algorithms (such as cosine similarity).

[0050] Output a list of matched rules and their adjustment parameters (such as weight increase and effective time).

[0051] S308 calculates the dynamic adjustment factor, quantifies the impact of middleware anomalies on database metrics, and generates weight adjustment coefficients.

[0052] For example, the factor formula is: Dynamic adjustment factor = α × anomaly level + β × topological correlation degree; α is the anomaly level coefficient, which divides the levels according to the severity of the anomaly (e.g., levels 1-3, corresponding to coefficients of 0.1, 0.3, and 0.5); β is the topological correlation degree coefficient, which calculates the correlation strength between the middleware and the database based on the dependency graph (0-1).

[0053] Example: The Redis cache hit rate anomaly level is 2 (α = 0.3), its topological correlation with MySQL query latency is 0.8 (β = 0.5), the dynamic adjustment factor = 0.3 × 2 + 0.5 × 0.8 = 1.0, and the final weight = original weight × (1 + 1.0). It should be noted that the same anomaly may trigger different adjustment factors at different times or in different business scenarios (e.g., the β coefficient is higher during peak sales periods).

[0054] S310, Comprehensive Score Calculation: Combining static weights and dynamic adjustment factors, the final health score is calculated. Calculation formula: Comprehensive Score = Σ(Indicator Value × Final Weight of Indicator).

[0055] S312 outputs health status levels; level classifications include: Green (Normal): score ≥ 80; Yellow (Warning): 60 ≤ score < 80; Red (Severe): score < 60; level expansion: can be further subdivided into more levels (such as dark green, light green, orange, red) or customized thresholds based on business needs. Alarm strategy: Yellow level triggers early warning notification, red level triggers automatic capacity expansion or rate limiting.

[0056] If no abnormalities are found, the static score is calculated directly, which is the database health level obtained by weighted summation based on the preset static weights of the database indicators.

[0057] Through the above-described embodiments described in this application, performance indicator description information matching the performance indicators is obtained, wherein the performance indicators are indicators that affect the performance of database operations; when it is determined that the database state meets the abnormal state conditions, a weight adjustment strategy is determined based on the performance indicator description information; weight parameters matching each database indicator are determined according to the weight adjustment strategy, wherein the database indicators are used to indicate the performance of database operations; and the database state evaluation result is determined based on the weight parameters matching each database indicator. This achieves the ability to dynamically adjust weight parameters based on middleware correlation, dynamic business load, and real-time performance indicator status, thereby more accurately evaluating the current health status of the database and solving the technical problem of inaccurate database state evaluation.

[0058] In one optional implementation, when it is determined that the database state meets the abnormal state conditions, a weight adjustment strategy is determined based on the performance metric description information, including:

[0059] S1. If the performance status parameter indicated by the performance indicator description information is an abnormal status value, determine that the database status meets the abnormal status conditions.

[0060] S2, determine the anomaly type based on the performance indicator description information, and determine the weight adjustment strategy based on the anomaly type.

[0061] In step S1 above, if the performance status parameter indicated by the performance indicator description information is an abnormal state value, the database state is determined to meet the abnormal state conditions. For example, this can be done by: judging whether the actual value of the key performance indicator exceeds the preset threshold of the performance indicator, using algorithms (such as moving average, STL decomposition) to identify sudden increases or decreases in the performance status parameter of the performance indicator, and thus determining that the database is in an abnormal state that may affect normal operation.

[0062] Further in step S2 above, the anomaly type is determined based on the performance metric description information, and a weight adjustment strategy is determined based on the anomaly type. The anomaly types include, but are not limited to, cache pressure anomalies, resource contention anomalies, etc. The corresponding weight adjustment strategies are, for example: if the Redis cache hit rate anomaly is identified as a cache pressure type, the weight of metrics related to database query latency and transaction processing time is increased, because cache invalidation increases the database query load; if the CPU utilization anomaly is identified as a resource contention type, the weight of metrics related to disk I / O and memory utilization is increased, so that these metrics are given more attention when resources are scarce.

[0063] For example, if an abnormal cache hit rate (cache pressure) is detected, the weight of performance metrics related to database queries is increased, because cache misses will lead to more database queries; if an abnormal CPU utilization (resource contention) is detected, the weight of metrics related to disk I / O and memory usage may be increased, and so on.

[0064] By combining the analysis of abnormal middleware metrics with database metrics, and dynamically adjusting weight parameters according to the type of middleware anomaly, the evaluation results are ensured to reflect business changes in a timely manner, thus improving the accuracy of the evaluation.

[0065] In one optional implementation, the anomaly type is determined based on the performance metric description information, and a weight adjustment strategy is determined based on the anomaly type, including:

[0066] S1, if the anomaly type is determined to be an anomaly load transfer type caused by operation load transfer based on the performance indicator description information, the weight adjustment direction indicated by the weight adjustment strategy is determined to be to increase the weight parameter that matches the first type of database indicator, wherein the first type of database indicator is an indicator that indicates the database query performance.

[0067] S2, if the anomaly type is determined to be an abnormal resource release type caused by the release of resource processing pressure based on the performance indicator description information, the weight adjustment direction indicated by the weight adjustment strategy is determined to be to reduce the weight parameter that matches the second type of database indicator, where the second type of database indicator is an indicator that indicates the database write performance.

[0068] As an optional implementation, in step S1 above, the abnormal load transfer type is caused by the performance degradation or failure of middleware (such as a caching system), which leads to the transfer of the query load originally borne by the middleware to the database, thereby increasing the query pressure on the database and causing an abnormal database state. In the case of abnormal load transfer, more attention needs to be paid to the database query performance indicators. The weight adjustment strategy will indicate to increase the weight parameters that match the first type of database indicators, that is, indicators that can reflect the database query efficiency and response time, including database indicators such as database query latency, query throughput, transaction processing time, etc.

[0069] As an optional implementation, in step S2 above, the abnormal resource release type refers to the reduced processing pressure of database resources (such as CPU, memory, and disk) during business downtime. However, this resource release does not bring performance improvement but may instead lead to a decrease in write performance, such as abnormal database status caused by adjustments to the write caching strategy due to excessive disk idle time. In abnormal situations of abnormal resource release type, it is necessary to reduce the focus on database write performance indicators to avoid evaluation bias caused by resource release. Therefore, the weight adjustment strategy is to indicate the reduction of weight parameters that match the second type of database indicators, that is, those indicators that can reflect database write efficiency and response time, including database indicators such as database write latency, write throughput, and transaction commit time.

[0070] It should be noted that this application can also determine the anomaly type based on three-level rules. The first level is a preset basic rule template. For example, when the cache hit rate decreases, the system will automatically increase the weight of database query latency to reflect the increase in query pressure; while the connection pool recycling speed will increase the weight of database connection number, indicating that resource release anomalies may reduce the focus on connection number.

[0071] The second layer involves automatically deriving corresponding weight adjustment rules from the topology dependency graph when encountering anomalies not covered in the basic rule template. First, the system checks if the newly occurring anomaly is related to a historical event. If so, it generates temporary rules by extracting correlations from historical metrics. If not, the system initiates real-time correlation analysis to infer the potential impact of the anomaly on database metrics based on the current cluster's operating status. The generated temporary rules are cached in the rule base for immediate weight adjustment decisions, ensuring the evaluation can adapt to unknown or low-frequency anomalies.

[0072] The third layer involves long-term evolution and optimization. Machine learning techniques are used to dynamically correct the parameters and directions in the rule base, continuously collecting actual fault data and comparing it with the rule prediction results. If an incorrect rule action is detected (e.g., a predicted increase in weights that should actually be decreased), the system will adjust the weight adjustment factor in the opposite direction. If the rule's magnitude deviation exceeds a preset threshold (e.g., 20%), the weight adjustment coefficient is calibrated proportionally to the error, reducing the discrepancy between prediction and reality. Through continuous training with real data and fine-tuning of rule parameters, the prediction accuracy of the rule base is improved.

[0073] In one optional implementation, weight parameters matching each database metric are determined according to a weight adjustment strategy, including:

[0074] S1, determine the anomaly level parameter that matches the database metric, and the correlation parameter between the database metric and the performance metric;

[0075] S2, determine the parameter adjustment factor that matches the database indicators based on the anomaly level parameter and the correlation parameter;

[0076] S3, determine the weight parameters that match the database indicators based on the adjustment factor and weight adjustment direction of the parameters matching the database indicators.

[0077] Optionally, the above parameter adjustment factor = α × anomaly level parameter + β × correlation parameter; if the weight adjustment direction is to increase, then the weight parameter = original static weight × (1 + parameter adjustment factor); if the weight adjustment direction is to decrease, then the weight parameter = original static weight × (1 - parameter adjustment factor).

[0078] For example, taking query latency as an example, the initial weight is set to 15%. When the system detects an abnormal state where the Redis cache hit rate is lower than 70%, the rule matching process is triggered. For example, the matched rule is that when the Redis hit rate is lower than 70%, the weight of query latency needs to be increased.

[0079] Assuming the Redis hit rate anomaly level is 2 (α = 0.3), the correlation parameter between query latency and Redis is 0.8, and β = 0.5, then the parameter adjustment factor is 2 × 0.3 + 0.5 × 0.8 = 1.0, and the weight parameter = 15% × (1 + 1.0) = 30%.

[0080] By using the above method, parameter adjustment factors are generated based on the anomaly level and correlation determined by the indicators. Then, the weight parameters are dynamically adjusted according to the parameter adjustment factors, so that the database status assessment is closer to the actual needs of business scenarios and system health status, and the sensitivity and accuracy of the assessment are improved.

[0081] In one alternative implementation, determining anomaly level parameters that match database metrics and correlation parameters between database metrics and performance metrics includes:

[0082] S1, Determine the anomaly level parameters that match the database indicators based on the indicator deviation information, task impact degree, and anomaly duration.

[0083] S2, determine the correlation parameters between database metrics and performance metrics based on the relationship graph, where the relationship graph is constructed based on database metrics and performance metrics.

[0084] In step S1 above, the anomaly level parameter matching the database metrics is determined based on the metric deviation information matching the database metrics, the degree of task impact, and the duration of the anomaly. The metric deviation information can be specifically represented by the metric deviation degree, and the degree of task impact can be determined based on the business level.

[0085] Optionally, the anomaly level parameters are determined using a three-dimensional grading method, comprehensively judging from three dimensions: technical indicators, business impact, and duration.

[0086] The deviation of technical indicators is weighted at 40%: Deviation = (Current value - Baseline value) / Baseline value × 100%; Baseline value determination method: Static baseline = Operation and maintenance preset threshold (e.g., Redis hit rate baseline = 85%); Dynamic baseline is calculated based on historical data (average of the same time period in the past 7 days).

[0087] When the deviation is 10% or less, the technical metric score is 0, such as when the Redis hit rate drops from 85% to 77%, the deviation is 9.4%. When the deviation is between 10% and 30%, the technical metric score is 1, such as when the Kafka message backlog increases from 1000 to 1300, the deviation is 30%. When the deviation is between 30% and 50%, the technical metric score is 2, such as when the connection pool utilization jumps from 40% to 70%, the deviation is 75%. When the deviation exceeds 50%, the technical metric score is 3, representing an extremely severe performance degradation, such as when the CPU utilization surges from 50% to 100%, the deviation is 100%.

[0088] The determination of the scope of business impact is based on whether and how the abnormal event affects core business processes. The calculation method involves analyzing the business dependency graph to identify the types of businesses affected. The impact score for each affected business is as follows: A business impact score of 3 is given when an abnormal event causes a degradation of the SLA (Service Level Agreement) for core business processes, such as a payment success rate decrease of more than 5%; a business impact score of 2 is given if core business processes are affected but the SLA is not downgraded, such as an increase in order query latency without affecting the success rate; a business impact score of 1 is given when an abnormal event affects secondary core business processes, such as an increase in the timeout rate of a product recommendation interface; and a business impact score of 0 is given when the abnormal event only affects non-core business processes, such as delays in operations and maintenance monitoring data.

[0089] The formula for calculating the persistence score is: Persistence Score = min(Persistence Duration / Unit Time, 3). The unit time is determined according to the level of business impact. Specifically: for Level 1 anomalies (such as a decrease in payment success rate), the unit time is defined as 10 minutes; for Level 2 anomalies (such as an increase in order query delay), the unit time is defined as 5 minutes; and for Level 3 anomalies (such as a sudden increase in connection pool usage), the unit time is defined as 2 minutes.

[0090] As an alternative implementation, suppose that during a system monitoring session, the Redis cache hit rate dropped by 30% for 6 minutes, and this anomaly affected the secondary core business: the product search interface. Based on the above rules, the following assessment can be made:

[0091] Technical deviation score: Based on the fact that Redis's cache hit rate dropped by 35%, falling into the 30% to 50% range, the technical deviation score is 2.

[0092] Business Impact Score: The product search interface is a secondary core business, and its business impact score is 1.

[0093] Duration score: Given that the business impact level is 2, the corresponding unit time is set to 5 minutes. The anomaly lasts for 6 minutes, so the duration score = min(6 / 5,3) = 1.2.

[0094] The scores from the three dimensions are weighted and averaged to obtain the total score: Total score = 2 × 40% + 1 × 40% + 1.2 × 20% = 1.64. According to the rounding principle, the final grade is 2.

[0095] By accurately determining the correlation between anomaly level parameters and indicators, the accuracy of parameter adjustment factors is improved, which in turn improves the accuracy of weight adjustment and the accuracy of database status assessment results.

[0096] In one optional implementation, the database state assessment result is determined based on weight parameters matched with each database metric, including:

[0097] S1, determine the expected load state that matches each database metric respectively;

[0098] S2 determines the database status assessment result based on the expected load status of each database indicator and the corresponding weight parameters.

[0099] In step S1 above, the desired load state matching each database metric is determined. Specifically, the desired load state can be a preset metric value based on historical data.

[0100] Further in step S2 above, the database status assessment result is determined based on the expected load status of each database indicator and the weight parameters that match it.

[0101] Optionally, the above-mentioned expected load status is a preset indicator value, and the static weight can be a preset initial weight value, such as the indicator value of CPU utilization = 80% and static weight = 20%, the indicator value of query latency = 150ms and static weight = 15%, etc. The above-mentioned status evaluation result = Σ(expected load status × weight parameter); weight parameter = static weight × (1 + / - parameter adjustment factor).

[0102] In an optional implementation, after determining the weight adjustment strategy based on the performance metric description information when it is determined that the database state meets the abnormal state conditions, the method further includes:

[0103] S1, determine the fault propagation information and the anomaly type of the database, wherein the fault propagation information is used to indicate the predicted changes in database indicators;

[0104] S2, determine the predicted fault information based on fault propagation information and anomaly type;

[0105] S3, determine the warning description information based on the predicted fault information, wherein the warning description information is used to indicate the scope of business affected by the fault path indicated by the predicted fault information.

[0106] In step S1 above, fault propagation information and database anomaly types are determined. The fault propagation information is used to indicate changes in predicted database metrics. This fault propagation information can be, for example, the preliminary propagation probability output by a CNN model, such as "the probability of a sudden increase in database QPS due to Kafka backlog is 75%." The anomaly type can be determined by a rule engine traversing a preset rule base for matching, such as a message queue backlog anomaly type; this is merely one example.

[0107] Further in step S2, the predicted fault information is determined based on the fault propagation information and the anomaly type. This can be achieved by passing logical parameters from the rules to the simulator, such as the initial node of the propagation path (Kafka backlog), the impact coefficient (e.g., every 10,000 backlogs causes a 20% increase in database QPS), the time decay factor, etc. The simulator generates a fault chain based on the rule parameters and real-time data. For example, the fault chain is: Kafka backlog → MySQL write delay → slave replication delay → front-end API timeout.

[0108] Further, in step S3 above, early warning description information is determined based on the predicted fault information. This description information indicates the scope of business affected by the fault path indicated by the predicted fault information. For example, the output multi-dimensional impact metrics might be: Performance impact: The database QPS is expected to reach the threshold limit within 15 minutes; Business impact: The order payment interface success rate may drop to 90%; Resource impact: The slave thread pool utilization rate will exceed 85%.

[0109] Before predicting fault paths, it is necessary to first define the preset propagation paths of the rule engine. These paths are used to abstract the known fault propagation logic between the middleware and the database into executable rules, which serve as the input basis for the simulator. These rules can be summaries of expert experience, historical fault analysis, or industry best practices.

[0110] Rule types and examples include: direct dependency rules, condition: middleware A's metric X exceeds the threshold; action: trigger an increase in the weight of the associated database B's metric Y; example: IF Redis cache hit rate <70%, THEN the associated MySQL query latency weight coefficient +15%;

[0111] Cascading propagation rules, condition: Middleware A's anomaly causes database B's metrics to be abnormal; action: predict that database B's anomaly may further affect middleware C; example: IF Kafka backlog > 10,000 records → MySQL write latency > 2 seconds, THEN predict that downstream Elasticsearch index latency will increase.

[0112] Timing decay rule, condition: middleware exception duration exceeds threshold; action: adjust the severity level of the propagation path; example: IF RabbitMQ queue backlog continues for 30 minutes without recovery THEN database health score decline rate doubles.

[0113] The following is a flowchart Figure 4 A complete explanation of the above fault prediction process is provided:

[0114] Based on S402-1, middleware exception events; S402-2, database metric exceptions, determine the corresponding metrics; S402-3, determine the data based on the topology dependency graph.

[0115] S404, Input the indicators and data into the graph neural network model GNN; S406, Calculate the probability of fault propagation;

[0116] S408 calculates and matches in the rule engine based on probability and anomaly type; specifically, it can include the initial propagation probability from the GNN model as input (e.g., "the probability of Kafka backlog causing a sudden increase in database QPS is 75%); the rule engine traverses the preset rule base and matches the current anomaly type (e.g., message queue backlog); output: a list of matched rules (e.g., rule numbers R01, R02).

[0117] S410, the simulator performs path simulation; specifically, the logical parameters in the rules are passed to the simulator, such as: the initial node of the propagation path (Kafka backlog), the impact coefficient (every 10,000 backlogs cause the database QPS to increase by 20%), and the time decay factor (the impact coefficient increases to 40% after the anomaly lasts for 1 hour).

[0118] Execution path simulation: The simulator generates a fault chain based on rule parameters and real-time data, such as: fault chain: Kafka backlog → MySQL write delay → slave replication delay → front-end API timeout; and can adjust the propagation speed according to the current cluster load (such as CPU utilization).

[0119] S412, Impact Scope Prediction, Outputs Multidimensional Impact Indicators.

[0120] Understandably, the above fault prediction process includes dynamic weight allocation: the rule engine adjusts the edge weights of the GNN model (such as the connection weights from the middleware to the database) according to preset logic, making the model more inclined to the propagation path defined by experts.

[0121] Formula example: Adjusted edge weight = Original weight × (1 + Rule confidence × Urgency coefficient) Where, the rule confidence comes from historical data verification, and the urgency coefficient is manually set by the operation and maintenance personnel.

[0122] Discrete event simulation: The simulator decomposes the fault propagation process into a series of discrete events, which are progressively advanced in time slices to simulate the propagation path of the fault from the middleware to the database. The process is meticulously decomposed and simulated in chronological order, which improves the precision and accuracy of the prediction.

[0123] For example: Time slice T1: 8000 records backlog in Kafka → MySQL write latency increases by 200ms; Time slice T2: Write latency triggers slave replication thread blocking → Slave latency increases to 5s; Time slice T3: Frontend query request times out due to slave latency → API error rate exceeds 5%.

[0124] Random disturbance injection: In order to more realistically simulate the actual operating environment, the simulator also uses the Monte Carlo method to inject random disturbances, such as network jitter and node failures, which helps to assess the potential fluctuations in system performance and the possibility of fault propagation under unpredictable conditions.

[0125] The system's evaluation and prediction results will in turn influence the optimization of the rule base. If the accuracy of a rule's prediction is consistently below a predetermined threshold (e.g., accuracy below 60%), the system will trigger an alarm, prompting operations and maintenance personnel to conduct manual review and rule adjustment. Conversely, if the prediction result deviates slightly from the actual result (e.g., deviation less than 10%), the rule parameters will be automatically fine-tuned, such as adjusting the influence coefficient, to further improve the model's predictive ability.

[0126] This feedback optimization closed-loop mechanism ensures that the rule base and model can be continuously iterated and optimized to adapt to constantly changing business scenarios and system states, thereby improving the accuracy of overall assessment and prediction.

[0127] like Figure 5 The following is a complete block diagram of this solution:

[0128] Middleware cluster: This refers to the middleware services used, including Redis, Kafka, and RabbitMQ. Database cluster: This refers to the database services used, including MySQL, Oracle, and MongoDB.

[0129] The data acquisition module is multi-protocol adapted to collect various performance metrics of the database and middleware, such as database QPS (queries per second), lock wait time, middleware message backlog, and cache hit rate.

[0130] The data caching and preprocessing module cleans, aligns, and filters outliers from the collected raw data, preparing it for subsequent analysis and modeling.

[0131] The topology analysis module parses the middleware configuration, builds a dependency graph between the database and the middleware, and identifies critical paths, such as the relationship between Redis cache hit rate and database query pressure.

[0132] The dynamic scoring model receives static weights and dynamic weight adjustment factors to calculate the health score of the database.

[0133] Fault propagation prediction engine: Based on graph neural networks (GNN) and rule engine, it predicts middleware anomalies and generates reports on the potential impact on the database cluster, including fault propagation paths.

[0134] Visualization and Alarm Platform: Provides a visual interface for health reports and fault prediction suggestions. When the health score or fault prediction reaches a preset threshold, an alarm is automatically triggered.

[0135] For example, during a major e-commerce promotion, the database health assessment scenario is as follows: Data collection database metrics: MySQL master database QPS = 12000, slave database replication latency = 5s; Middleware metrics: Redis cache hit rate drops to 65%, Kafka order topic backlog = 8000 records.

[0136] Topology analysis: It was found that the Kafka order service relies on write operations to the MySQL order table, and the Redis cache is associated with the product query interface.

[0137] Dynamic scoring: Due to Kafka backlog, dynamic adjustments were triggered: the weight of MySQL write latency was increased from 10% to 25%; the overall score dropped from 85 points (green) to 62 points (yellow), triggering a scaling-up alarm.

[0138] Fault prediction: When the simulated Redis cache hit rate continues to drop to 50%, it is predicted that the database QPS will exceed the capacity limit, and read-only slave databases will be started in advance to distribute the load.

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

[0140] According to another aspect of the embodiments of this application, a database status evaluation apparatus for implementing the above-described database status evaluation method is also provided. For example... Figure 6 As shown, the device includes:

[0141] Unit 602 retrieves performance metric description information that matches the performance metrics, where the performance metrics are those that affect the performance of database operations.

[0142] The first determining unit 604 determines the weight adjustment strategy based on the performance index description information when it is determined that the database status meets the abnormal status conditions.

[0143] The second determining unit 606 determines the weight parameters that match each database indicator according to the weight adjustment strategy, wherein the database indicator is used to indicate the performance of database operations.

[0144] The third determining unit 608 determines the state evaluation result of the database based on the weight parameters matched with each database indicator.

[0145] Optionally, the first determining unit 604 mentioned above includes a fourth determining module, used to determine that the database status meets the abnormal status conditions when the performance status parameter indicated by the performance indicator description information is an abnormal status value; determine the abnormal type according to the performance indicator description information; and determine the weight adjustment strategy according to the abnormal type.

[0146] Optionally, the fourth determining module is further configured to, when determining that the anomaly type is an abnormal load transfer type caused by operational load transfer based on the performance indicator description information, determine that the weight adjustment direction indicated by the weight adjustment strategy is to increase the weight parameter matching the first type of database indicator, wherein the first type of database indicator is an indicator indicating database query performance; and when determining that the anomaly type is an abnormal resource release type caused by resource processing pressure release based on the performance indicator description information, determine that the weight adjustment direction indicated by the weight adjustment strategy is to decrease the weight parameter matching the second type of database indicator, wherein the second type of database indicator is an indicator indicating database write performance.

[0147] Optionally, the fourth determining module described above is also used to determine the anomaly level parameter that matches the database metric, and the correlation parameter between the database metric and the performance metric; determine the parameter adjustment factor that matches the database metric based on the anomaly level parameter and the correlation parameter; and determine the weight parameter that matches the database metric based on the parameter adjustment factor that matches the database metric and the weight adjustment direction.

[0148] Optionally, the fourth determining module is further used to determine the anomaly level parameter matching the database metric based on the metric deviation information, task impact degree, and anomaly duration; and to determine the correlation parameter between the database metric and the performance metric based on the relationship graph, wherein the relationship graph is constructed based on the database metric and the performance metric.

[0149] Optionally, the third determining unit 608 mentioned above includes a fifth determining module, used to determine the expected load state that matches each database indicator; and to determine the database status assessment result based on the expected load state of each database indicator and the weight parameters that match it.

[0150] Optionally, the first determining unit 604 includes a prediction module, used to determine fault propagation information and the anomaly type of the database, wherein the fault propagation information is used to indicate the predicted changes in database indicators; to determine predicted fault information based on the fault propagation information and the anomaly type; and to determine early warning description information based on the predicted fault information, wherein the early warning description information is used to indicate the scope of business affected by the fault path indicated by the predicted fault information.

[0151] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, wherein a computer program is stored in the computer program, and the computer program is configured to execute the above-described database state evaluation method at runtime.

[0152] According to another aspect of the embodiments of this application, an electronic device for implementing the above-described database state evaluation method is also provided. This electronic device may be... Figure 1 The terminal device or server shown. This embodiment uses a mobile phone or computer as an example for illustration. Figure 7 As shown, the electronic device includes a memory 702 and a processor 704. The memory 702 stores a computer program, and the processor 704 is configured to execute the steps of any of the above method embodiments through the computer program.

[0153] Optionally, in this embodiment, the aforementioned electronic device may be located in at least one of a plurality of network devices in a computer network.

[0154] Optionally, in this embodiment, the processor can be configured to perform the following steps via a computer program:

[0155] S1, obtain performance metric description information that matches the performance metrics, where the performance metrics are the metrics that affect the performance of database operations;

[0156] S2, if it is determined that the database state meets the abnormal state conditions, determine the weight adjustment strategy based on the performance index description information;

[0157] S3, determine the weight parameters that match each database metric according to the weight adjustment strategy, where the database metrics are used to indicate the performance of database operations;

[0158] S4. Determine the database status assessment result based on the weight parameters matched with each database indicator.

[0159] Alternatively, as those skilled in the art will understand, Figure 7The structure shown is for illustrative purposes only. Electronic devices can also be smartphones (such as Android phones, iOS phones, etc.), tablets, PDAs, mobile internet devices (MIDs), PADs, and other terminal devices. Figure 7 This does not limit the structure of the aforementioned electronic devices. For example, the electronic device may also include components that are more... Figure 7 The more or fewer components shown (such as network interfaces, etc.), or having the same Figure 7 The different configurations shown.

[0160] The memory 702 can be used to store software programs and modules, such as the program instructions / modules corresponding to the database status evaluation method and apparatus in this embodiment. The processor 704 executes various functional applications and data processing by running the software programs and modules stored in the memory 702, thereby implementing the aforementioned database status evaluation method. The memory 702 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 702 may further include memory remotely located relative to the processor 704, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof. As an example, such as... Figure 7 As shown, the memory 702 may include, but is not limited to, the acquisition unit 602, the first determination unit 604, the second determination unit 606, and the third determination unit 608 in the database state evaluation device. Furthermore, it may include, but is not limited to, other module units in the database state evaluation device, which will not be elaborated upon in this example.

[0161] Optionally, the transmission device 706 described above is used to receive or send data via a network. Specific examples of the network described above may include wired networks and wireless networks. In one example, the transmission device 706 includes a Network Interface Controller (NIC), which can be connected to other network devices and a router via a network cable to communicate with the Internet or a local area network. In another example, the transmission device 706 is a radio frequency (RF) module, used for wireless communication with the Internet.

[0162] In addition, the aforementioned electronic device also includes a display 708 and a connection bus 710 for connecting the various module components in the aforementioned electronic device.

[0163] In other embodiments, the aforementioned terminal device or server can be a node in a distributed system, wherein the distributed system can be a blockchain system, which is a distributed system formed by connecting multiple nodes through network communication. The nodes can form a point-to-point network, and any form of computing device, such as a server, terminal, or other electronic device, can become a node in the blockchain system by joining this point-to-point network.

[0164] According to one aspect of this application, a computer-readable storage medium is provided, wherein a processor of a computer device reads computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, causing the computer device to perform the methods provided in the various optional implementations described above;

[0165] Optionally, in this embodiment, the computer-readable storage medium may be configured to store a computer program for performing the following steps:

[0166] S1, obtain performance metric description information that matches the performance metrics, where the performance metrics are the metrics that affect the performance of database operations;

[0167] S2, if it is determined that the database state meets the abnormal state conditions, determine the weight adjustment strategy based on the performance index description information;

[0168] S3, determine the weight parameters that match each database metric according to the weight adjustment strategy, where the database metrics are used to indicate the performance of database operations;

[0169] S4. Determine the database status assessment result based on the weight parameters matched with each database indicator.

[0170] Optionally, in embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0171] Optionally, in this embodiment, those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0172] If the integrated units in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in the aforementioned computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause one or more computer devices (which may be personal computers, servers, or network devices, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application.

[0173] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0174] In the several embodiments provided in this application, it should be understood that the disclosed client can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units is only a logical functional division, and 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. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between units or modules, and may be electrical or other forms.

[0175] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0176] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0177] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for evaluating the state of a database, characterized in that, include: Obtain performance metric description information that matches the performance metrics, wherein the performance metrics are those that affect the performance of database operations; If the database state is determined to meet the abnormal state conditions, a weight adjustment strategy is determined based on the performance indicator description information. According to the weight adjustment strategy, weight parameters are determined to match each database metric respectively, wherein the database metrics are used to indicate the performance of the database operation; The database status assessment result is determined based on the weight parameters matched with each database indicator.

2. The method according to claim 1, characterized in that, The step of determining a weight adjustment strategy based on the performance metric description information when the database state meets the abnormal state conditions includes: If the performance status parameter indicated by the performance indicator description information is an abnormal status value, it is determined that the database status meets the abnormal status condition. The anomaly type is determined based on the performance metric description information, and the weight adjustment strategy is determined based on the anomaly type.

3. The method according to claim 2, characterized in that, The step of determining the anomaly type based on the performance indicator description information and determining the weight adjustment strategy based on the anomaly type includes: If the anomaly type is determined to be an anomaly load transfer type caused by operation load transfer based on the performance indicator description information, the weight adjustment direction indicated by the weight adjustment strategy is determined to be to increase the weight parameter that matches the first type of database indicator, wherein the first type of database indicator is an indicator that indicates the database query performance. If the anomaly type is determined to be an abnormal resource release type caused by the release of resource processing pressure based on the performance indicator description information, the weight adjustment direction indicated by the weight adjustment strategy is determined to be to reduce the weight parameter that matches the second type of database indicator, wherein the second type of database indicator is an indicator that indicates the database write performance.

4. The method according to claim 3, characterized in that, The step of determining the weight parameters that match each database indicator according to the weight adjustment strategy includes: Determine the anomaly level parameter that matches the database metric, and the correlation parameter between the database metric and the performance metric; Based on the anomaly level parameter and the correlation parameter, determine the parameter adjustment factor that matches the database indicator; The weight parameter that matches the database indicator is determined based on the parameter adjustment factor that matches the database indicator and the weight adjustment direction.

5. The method according to claim 4, characterized in that, The determination of the anomaly level parameter matching the database metric and the correlation parameter between the database metric and the performance metric includes: The anomaly level parameter matching the database indicator is determined based on the indicator deviation information, task impact degree, and anomaly duration. The correlation parameter between the database metric and the performance metric is determined based on the relationship graph, wherein the relationship graph is constructed based on the database metric and the performance metric.

6. The method according to claim 1, characterized in that, The step of determining the database status assessment result based on the weight parameters matched with each database indicator includes: Determine the desired load state that matches each of the aforementioned database metrics; The state assessment result of the database is determined based on the expected load state of each of the database metrics and the corresponding weight parameters.

7. The method according to claim 1, characterized in that, After determining the weight adjustment strategy based on the performance metric description information when the database state meets the abnormal state conditions, the method further includes: Determine the fault propagation information and the anomaly type of the database, wherein the fault propagation information is used to indicate the predicted changes in database indicators; Based on the fault propagation information and the anomaly type, predictive fault information is determined; Early warning description information is determined based on the predicted fault information, wherein the early warning description information is used to indicate the scope of services affected by the fault path indicated by the predicted fault information.

8. A database status evaluation device, characterized in that, include: The acquisition unit acquires performance indicator description information that matches the performance indicators, wherein the performance indicators are those that affect the performance of database operations. The first determining unit determines a weight adjustment strategy based on the performance index description information when it is determined that the database state meets the abnormal state conditions. The second determining unit determines weight parameters that match each database indicator according to the weight adjustment strategy, wherein the database indicators are used to indicate the performance of the database operation. The third determining unit determines the database status evaluation result based on the weight parameters that are matched with each database indicator.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored program, wherein the program is executed by a processor to perform the method described in any one of claims 1 to 7.

10. An electronic device, comprising: A memory and a processor, the memory being used to store a computer program, characterized in that the processor is used to perform the steps of the method according to any one of claims 1 to 7 when the computer program is invoked.

Images