Database product state detection method, system, and electronic device

Abstract

The application discloses a database product state detection method, system and electronic equipment. The method comprises the following steps: acquiring at least one query operation responded by a database product in a historical detection period; identifying at least one fluctuation query operation in the at least one query operation, wherein the fluctuation query operation is a query operation with a response time exceeding a time threshold in the at least one query operation; determining a state detection index of the database product based on the at least one fluctuation query operation and the at least one query operation, wherein the state detection index is used to represent a stability state of the database product; and determining that the database product is in an abnormal stability state in the historical detection period if the state detection index is greater than a state detection index threshold. The application solves the technical problem of low state detection efficiency of the database product.

Description

Technical Field

[0001] This application relates to the field of data management technology, and more specifically, to a method, system, and electronic device for detecting the status of a database product. Background Technology

[0002] Currently, the state stability issues of database products with a large customer base are highly complex. When an urgent state stability problem occurs, the entire process—from problem discovery to reporting a work order, to frontline R&D personnel investigating and ultimately resolving the issue—is time-consuming, impacting usability. Therefore, there is a technical problem of low efficiency in state detection for database products.

[0003] There is currently no effective solution to the above problems. Summary of the Invention

[0004] This application provides a method, system, and electronic device for detecting the status of database products, in order to at least solve the technical problem of low efficiency in detecting the status of database products.

[0005] According to one aspect of the embodiments of this application, a state detection method for a database product is provided, applied to a cloud server, on which the database product is deployed. The method may include: acquiring at least one query operation responded to by the database product during a historical detection period; identifying at least one fluctuating query operation among the at least one query operation, wherein the fluctuating query operation is a query operation whose response time exceeds a time threshold; determining a state detection index for the database product based on the at least one fluctuating query operation and the at least one query operation, wherein the state detection index is used to characterize the stability state of the database product; if the state detection index is greater than a state detection index threshold, then it is determined that the database product is in an abnormal stability state during the historical detection period.

[0006] According to another aspect of the embodiments of this application, a state detection method for a database product is also provided, applied to a cloud server, on which the database product is deployed. The method may include: obtaining at least one query operation responded to by the database product during a historical detection period by calling a first interface, wherein the first interface includes a first parameter, and the parameter value of the first parameter is at least one query operation; identifying at least one fluctuating query operation among the at least one query operation, wherein the fluctuating query operation is a query whose response time exceeds a time threshold among the at least one query operation; determining a state detection index for the database product based on the at least one fluctuating query operation and the at least one query operation, wherein the state detection index is used to characterize the stability state of the database product; if the state detection index is greater than the state detection index threshold, determining that the database product is in an abnormal stability state during the historical detection period; and outputting a prompt message indicating an abnormal stability state by calling a second interface, wherein the second interface includes a second parameter, and the parameter value of the second parameter is the prompt message indicating an abnormal stability state.

[0007] According to another aspect of the embodiments of this application, a state detection device for a database product is also provided. The device may include: an acquisition unit, configured to acquire at least one query operation responded to by the database product during a historical detection period; a first identification unit, configured to identify at least one fluctuating query operation among the at least one query operation, wherein the fluctuating query operation is a query operation whose response time exceeds a time threshold among the at least one query operation; a first determination unit, configured to determine a state detection index of the database product based on the at least one fluctuating query operation and the at least one query operation, wherein the state detection index is used to characterize the stability state of the database product; and a second determination unit, configured to determine that the database product is in an abnormal stability state during the historical detection period when the state detection index is greater than the state detection index threshold.

[0008] According to another aspect of the embodiments of this application, a state detection device for a database product is also provided. The device may include: a first calling unit, configured to call a first interface to obtain at least one query operation responded by the database product during a historical detection period, wherein the first interface includes a first parameter, and the parameter value of the first parameter is at least one query operation; a second identification unit, configured to identify at least one fluctuating query operation among the at least one query operation, wherein the fluctuating query operation is a query whose response time exceeds a time threshold among the at least one query operation; a third determining unit, configured to determine a state detection index for the database product based on the at least one fluctuating query operation and the at least one query operation, wherein the state detection index is used to characterize the stability state of the database product; a fourth determining unit, configured to determine that the database product is in an abnormal stability state during the historical detection period when the state detection index is greater than the state detection index threshold; and a second calling unit, configured to call a second interface to output a prompt message indicating an abnormal stability state, wherein the second interface includes a second parameter, and the parameter value of the second parameter is the prompt message indicating an abnormal stability state.

[0009] According to another aspect of the embodiments of this application, a state detection system for a database product is also provided. The state detection system may include: a client for uploading a state detection command for the database product; a cloud server for responding to the state detection command by acquiring at least one query operation responded by the database product during a historical detection period; identifying at least one fluctuating query operation among the at least one query operation, wherein the fluctuating query operation is a query whose response time exceeds a time threshold among the at least one query operation; determining a state detection index for the database product based on the at least one fluctuating query operation and the at least one query operation, wherein the state detection index is used to characterize the stability state of the database product; if the state detection index is greater than the state detection index threshold, determining that the database product is in an abnormal stability state during the historical detection period; and returning an abnormal stability state prompt message to the client.

[0010] According to another aspect of the embodiments of this application, an electronic device is also provided, including a memory and a processor. The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions, wherein the computer-executable instructions are executed by the processor to perform the steps of a database product status detection method.

[0011] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored program, wherein, when the program processor is running, the program controls the device where the computer storage medium is located to execute a state detection method for a database product.

[0012] According to another aspect of the embodiments of this application, a computer program product is also provided, including computer instructions, which, when executed by a processor, implement the steps of the state detection method of the database product of the embodiments of this application.

[0013] In this embodiment, at least one query operation responded by the database product during a historical testing period is obtained; among the at least one query operation, at least one fluctuating query operation is identified, wherein the fluctuating query operation is a query operation whose response time exceeds a time threshold; based on the at least one fluctuating query operation and the at least one query operation, a state detection index of the database product is determined, wherein the state detection index is used to characterize the stability state of the database product; if the state detection index is greater than the state detection index threshold, it is determined that the database product is in an abnormal stability state during the historical testing period. In other words, in this embodiment, the status detection index is determined based on at least one fluctuating query operation and at least one query operation within a historical detection period. Therefore, the status detection index can accurately represent the proportion of fluctuating query operations within the historical detection period. Based on this, the status detection index of the database product is compared with the status detection index threshold. If the status detection index is greater than the status detection index threshold, it is determined that the database product is in an abnormally stable state. That is, in this embodiment, no manual investigation is required. The status detection index threshold is used as a data reference. When the status detection index is greater than the status detection index threshold, it can be automatically determined that the database product is in an abnormally stable state, which greatly reduces the investigation time when the database product has problems and provides a basic preparation for the automated operation and maintenance of the database product, improves the user experience, and thus solves the technical problem of low status detection efficiency of the database product.

[0014] It is worth noting that the general description above and the detailed description that follow are merely for illustrative purposes and do not constitute a limitation on this application. Attached Figure Description

[0015] 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:

[0016] Figure 1 This is a hardware structure block diagram of a computer terminal (or mobile device) for implementing a status detection method for a database product according to an embodiment of this application.

[0017] Figure 2 This is a structural block diagram of a computing environment according to an embodiment of this application;

[0018] Figure 3This is a structural block diagram of a service mesh according to an embodiment of this application;

[0019] Figure 4 This is a flowchart of a database product detection method according to an embodiment of this application;

[0020] Figure 5 This is a method for detecting the status of a database product according to an embodiment of this application;

[0021] Figure 6 This is a schematic diagram of a database product status detection system according to an embodiment of this application;

[0022] Figure 7 This is a schematic diagram illustrating the change of the upper limit of volatility as a function of the median historical response time of an SQL pattern, according to an embodiment of this application.

[0023] Figure 8 This is a schematic diagram illustrating the change of the upper limit of volatility as a function of the median historical response time of the SQL pattern, according to another embodiment of this application.

[0024] Figure 9 This is a flowchart of a root cause investigation method based on temporal correlation according to an embodiment of this application;

[0025] Figure 10 This is a schematic diagram of a status detection device for a database product according to an embodiment of this application;

[0026] Figure 11 This is a schematic diagram of a status detection device for a database product according to an embodiment of this application;

[0027] Figure 12 This is a structural block diagram of a computer terminal according to an embodiment of this application. Detailed Implementation

[0028] 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.

[0029] 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.

[0030] First, some nouns or terms that appear in the description of the embodiments of this application shall be interpreted as follows:

[0031] Query response time is the time elapsed between when a query operation is sent to the database system and when the database system returns the query result corresponding to the query operation.

[0032] The query language pattern is used to indicate the pattern or wildcard used in the query statement to match part or all of the text data. Queries with the same query language pattern refer to query statements with the same structure and syntax. For example, replacing specific parameters in the query language with wildcards will result in a query language template.

[0033] State detection metrics are indicators used to characterize whether a database product is in a stable state.

[0034] Median response time is the response time corresponding to the median of multiple response time values.

[0035] Target anomaly indicators are query indicators that cause instability issues in database products.

[0036] Example 1

[0037] According to an embodiment of this application, a state detection method for a database product is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0038] The method embodiment provided in Embodiment 1 of this application can be executed on a mobile terminal, computer terminal, or similar computing device. Figure 1 This is a hardware structure block diagram of a computer terminal (or mobile device) for implementing a state detection method for a database product, according to an embodiment of this application. Figure 1 As shown, the computer terminal 10 (or mobile device) may include one or more processors 102 (shown as 102a, 102b, ..., 102n in the figure) (processor 102 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission module 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a Universal Serial Bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0039] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10 (or mobile device). As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0040] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the database product status detection method in this embodiment. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby realizing the aforementioned database product status detection method. The memory 104 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 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the computer terminal 10 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.

[0041] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0042] The display can be, for example, a touchscreen liquid crystal display (LCD), which allows the user to interact with the user interface of the computer terminal 10 (or mobile device).

[0043] Figure 1 The hardware structure block diagram shown can serve not only as an exemplary block diagram of the aforementioned computer terminal 10 (or mobile device), but also as an exemplary block diagram of the aforementioned server. In one optional embodiment, Figure 2 The use of the above is illustrated in a block diagram. Figure 1 The computer terminal 10 (or mobile device) shown is an embodiment of a computing node in computing environment 201. Figure 2 A block diagram of a computing environment is shown, such as Figure 2 As shown, computing environment 201 includes multiple computing nodes (such as servers) running on a distributed network (represented as 210-1, 210-2, ..., in the diagram). Each computing node contains local processing and memory resources, and end user 202 can remotely run applications or store data within computing environment 201. Applications can be provided as multiple services 220-1, 220-2, 220-3, and 220-4 within computing environment 201, representing services "A", "D", "E", and "H", respectively.

[0044] End user 202 can provide and access services through a web browser or other software application on a client. In some embodiments, the provisioning and / or requests of end user 202 can be provided to ingress gateway 230. Ingress gateway 230 may include a corresponding agent to handle the provisioning and / or requests for services (one or more services provided in computing environment 201).

[0045] Services are provided or deployed based on various virtualization technologies supported by the computing environment 201. In some embodiments, services may be provided based on virtual machine (VM)-based virtualization, container-based virtualization, and / or similar methods. VM-based virtualization can simulate a real computer by initializing a virtual machine, executing programs and applications without directly accessing any actual hardware resources. While the machine is virtualized by a virtual machine, container-based virtualization can launch containers to virtualize an entire operating system (OS), allowing multiple workloads to run on a single OS instance.

[0046] In one embodiment based on container virtualization, several containers of a service can be assembled into a Pod (e.g., a Kubernetes Pod). For example, such as Figure 2 As shown, service 220-2 can be equipped with one or more Pods 240-1, 240-2, ..., 240-N (collectively referred to as Pods). A Pod can include a proxy 245 and one or more containers 242-1, 242-2, ..., 242-M (collectively referred to as containers). One or more containers within a Pod handle requests related to one or more corresponding functions of the service. Proxy 245 typically controls service-related network functions such as routing and load balancing. Other services can also be equipped with Pods similar to Pods.

[0047] During operation, executing a user request from end user 202 may require invoking one or more services in computing environment 201, and executing one or more functions of one service may require invoking one or more functions of another service. For example... Figure 2 As shown, service "A" 220-1 receives user requests from terminal user 202 from ingress gateway 230. Service "A" 220-1 can call service "D" 220-2, and service "D" 220-2 can request service "E" 220-3 to perform one or more functions.

[0048] The aforementioned computing environment can be a cloud computing environment, where resource allocation is managed by cloud services, allowing functionality development without needing to consider implementation, adjustment, or server scaling. This computing environment allows developers to execute event-responsive code without building or maintaining complex infrastructure. Services can be partitioned into a set of functions that can automatically and independently scale, rather than scaling a single hardware device to handle potential loads.

[0049] In another alternative embodiment, Figure 3 The use of the above is illustrated in a block diagram. Figure 1 The computer terminal 10 (or mobile device) shown is an embodiment of a service mesh. Figure 3 A structural block diagram of a service mesh is shown, such as Figure 3 As shown, the service mesh 300 is mainly used to facilitate secure and reliable communication between multiple microservices. Microservices refer to the decomposition of an application into multiple smaller services or instances, which are distributed across different clusters / machines.

[0050] like Figure 3 As shown, a microservice may include application service instance A and application service instance B, which together form the functional application layer of service mesh 300. In one implementation, application service instance A runs as a container / process 308 on machine / workload container group 314 (Pod), and application service instance B runs as a container / process 310 on machine / workload container group 316 (Pod).

[0051] In one implementation, application service instance A can be to obtain at least one query operation responded by the database product during a historical detection period and to identify at least one fluctuating query operation in the at least one query operation; application service instance B can be to determine the status detection indicators of the database product based on at least one fluctuating query operation and at least one query operation.

[0052] like Figure 3 As shown, application service instance A and grid agent (sidecar) 303 coexist in machine workload container group 614, and application service instance B and grid agent 305 coexist in machine workload container 314. Grid agents 303 and 305 form the data plane layer of service mesh 300. Grid agents 303 and 305 run as containers / processes 304 and 306 respectively, and can receive requests 312 for product query services. Grid agent 303 and application service instance A can communicate bidirectionally, and grid agent 305 and application service instance B can also communicate bidirectionally. Furthermore, grid agents 303 and 305 can also communicate bidirectionally with each other.

[0053] In one implementation, traffic from application service instance A is routed to the appropriate destination via mesh proxy 303, and network traffic from application service instance B is routed to the appropriate destination via mesh proxy 305. It should be noted that the network traffic mentioned here includes, but is not limited to, Hypertext Transfer Protocol (HTTP), Representational State Transfer (REST), high-performance, general-purpose open-source frameworks (Google Remote Procedure Call, gRPC), and open-source in-memory data structure storage systems (Redis), etc.

[0054] In one implementation, the functionality of the extended data plane layer can be achieved by writing custom filters for the proxy (Envoy) in service mesh 300. The service mesh proxy configuration can enable the service mesh to correctly proxy service traffic, achieving service interoperability and service governance. Mesh proxies 303 and 305 can be configured to perform at least one of the following functions: service discovery, health checking, routing, load balancing, authentication and authorization, and observability.

[0055] like Figure 3 As shown, the service mesh 300 also includes a control plane layer. This control plane layer can consist of a set of services running in a dedicated namespace, hosted by a managed control plane component 301 within machine / workload container groups (machine / Pods) 302. Figure 3 As shown, the managed control plane component 301 communicates bidirectionally with grid agents 303 and 305. The managed control plane component 301 is configured to perform various control and management functions. For example, it receives telemetry data from grid agents 303 and 305 and can further aggregate this telemetry data. In addition to these services, the managed control plane component 301 can also provide a user-facing Application Programming Interface (API) to facilitate manipulation of network behavior and the provision of configuration data to grid agents 303 and 305.

[0056] Under the aforementioned operating environment, this application provides the following: Figure 4 The database product testing method shown is applied to a cloud server, where the database product is deployed. Figure 4 This is a flowchart of a database product detection method according to an embodiment of this application. Figure 4 As shown, the method may include the following steps:

[0057] Step S401: Obtain at least one query operation responded by the database product within the historical detection period.

[0058] In the technical solution provided in step S401 of this application, the database product includes query objects corresponding to various query operations. For example, the database product can be a database system or a database cluster, without specific limitations. At least one query operation can be a total query of the database product within the historical detection time period. The query operation can be an operation to retrieve and obtain data from the database product through a query statement. At least one query operation can be executed by Structured Query Language (SQL). The historical detection time period is used to indicate a period of time in the past. The duration of the historical detection time period can be preset. For example, the historical detection time period can be the past minute, the past hour, etc., without specific limitations.

[0059] In this embodiment, at least one query operation responded to by the database product within a historical detection period can be obtained through the historical query records of the database product. Each query operation corresponds to a query response time, which is used to indicate the time elapsed between the query operation being sent to the database product and the database product returning the query result corresponding to the query operation.

[0060] For example, you can obtain the query operations responded to by the database product and the corresponding query response time by querying the database product's logs or using testing tools.

[0061] Step S402: In at least one query operation, identify at least one fluctuating query operation.

[0062] In the technical solution provided by step S402 of this application, as described in step S401, at least one query operation corresponds to a query response time. Based on this, after obtaining at least one query operation that the database product responded to within the historical detection period, at least one fluctuating query operation can be identified based on the query response time corresponding to the at least one query operation. A fluctuating query operation is a query operation among the at least one query operation whose response time exceeds a time threshold. This response time can also be referred to as query response time, query execution time, etc., without specific limitations here. The time threshold can be determined based on the historical query response time of historical query operations that match the query pattern of the query operation. The query pattern indicates the pattern corresponding to the query language of the query operation, such as a Structured Query Language pattern (SQL pattern). The query type of the above query operation is the same as the query type of the historical query operation, including parameters under the same SQL pattern, which can be replaced by wildcards.

[0063] In this embodiment, the query response time corresponding to at least one query operation is compared with a time threshold. If the query response time of one of the at least one query operations exceeds the time threshold, the query operation is determined to be a fluctuating query operation. According to this method, at least one fluctuating query operation can be identified among at least one query operation.

[0064] Optionally, for each query operation within the historical detection period, the corresponding SQL pattern can be determined. Then, multiple historical response times corresponding to query operations with the same SQL pattern within periods prior to the historical detection period can be identified. Based on these multiple historical response times, a target response time can be determined. This target response time can be any one of the average response time, median response time, or maximum response time from the multiple historical response times; no specific restrictions are imposed here. After determining the target response time, a time threshold can be obtained by multiplying the target response time by a fluctuation limit multiplier. After determining the time threshold, the query response time of the current query operation can be compared with this time threshold. If the query response time of the current query operation is greater than the time threshold, the query operation is determined to be a fluctuating query operation. The fluctuation limit multiplier can be preset; for example, it can be 2; no specific restrictions are imposed here.

[0065] For example, assuming the fluctuation limit multiplier is 2, a query operation is identified as a fluctuation query operation if its query response time exceeds twice the median of the historical response times of query operations with the same SQL pattern as the query operation in the period before the historical detection period.

[0066] Step S403: Based on at least one fluctuation query operation and at least one query operation, determine the status detection indicators of the database product.

[0067] In the technical solution provided by step S403 of this application, after determining at least one fluctuating query operation, a status detection index of the database product can be determined based on the at least one fluctuating query operation and at least one query operation. The status detection index is used to characterize the stability state of the database product. For example, the status detection index can be a response time volatility index, which can be used to represent the query response time volatility rate. The query response time volatility rate can be the ratio of the number of fluctuating queries in the historical detection period to the total number of queries in the database product.

[0068] In this embodiment, at least one fluctuation query operation is used to indicate a query operation whose query response time exceeds a time threshold among at least one query operation responded to by the database product during the historical detection period. At least one query operation is used to indicate the total number of query operations responded to by the database product during the historical detection period. Based on this, the state detection index of the database product can be determined according to the ratio of the number of at least one fluctuation query operations to the number of at least one query operations during the historical detection period. That is, the query response time fluctuation rate of the database product can be determined, and then the stability state of the database product during the historical detection period can be determined according to the fluctuation rate.

[0069] Step S404: If the status detection index is greater than the status detection index threshold, then it is determined that the database product is in an abnormal stability state during the historical detection period.

[0070] In the technical solution provided in step S404 of this application, after determining the status detection index of the database product, the status detection index can be compared with the status detection index threshold to determine the stability status of the database product within a historical time period. The status detection index threshold is a threshold for judging whether the database product is in an abnormal stability state; the specific value of this threshold can be preset and is not specifically limited here.

[0071] In this embodiment, if the state detection index is greater than the state detection index threshold, it is determined that the database product is in an abnormal stability state during the historical detection period.

[0072] For example, suppose the status detection index threshold is 20%. That is, when the ratio of the number of fluctuating query operations to the total number of queries in the historical detection period is greater than 20%, it indicates that the database product is in an abnormal stability state. As described in step S403 above, the status detection index of the database product can be the query response time volatility of the database product in the historical detection period, that is, the ratio of the number of at least one fluctuating query operation to the number of at least one query operation in the historical detection period. Based on this, the status detection index of the database product can be compared with the status detection index threshold of 20%. If the status detection index is greater than 20%, it means that the status detection index of the database product is greater than the status detection index threshold, and it can be determined that the database product is in an abnormal stability state. Conversely, if the status detection index is less than 20%, it means that the status detection index of the database product is not greater than the status detection index threshold, that is, the database product is in a normal stability state.

[0073] Based on steps S401 to S404 of the above embodiments, the status detection index is determined based on at least one fluctuating query operation and at least one query operation within the historical detection period. Therefore, the status detection index can accurately represent the proportion of fluctuating query operations within the historical detection period. Based on this, the status detection index of the database product is compared with the status detection index threshold. If the status detection index is greater than the status detection index threshold, it can be determined that the database product is in an abnormally stable state. That is, no manual investigation is required. The status detection index threshold is used as a data reference. When the status detection index is greater than the status detection index threshold, it can be automatically determined that the database product is in an abnormally stable state, which greatly reduces the investigation time when the database product has problems and provides a basic preparation for the automated operation and maintenance of the database product, improves the user experience, and thus solves the technical problem of low status detection efficiency of the database product.

[0074] The method described in this embodiment will be further described below.

[0075] As an optional implementation, step S403, based on at least one waveform query operation and at least one query operation, determines the status detection index of the database product, including: counting the number of fluctuating queries that perform fluctuating query operations and the total number of queries that perform query operations; determining the proportion of fluctuating query count to the total number of queries; and using the proportion as the status detection index of the database product.

[0076] In this embodiment, at least one fluctuating query operation is used to indicate a query operation whose response time exceeds a time threshold among at least one query operation responded to by the database product within the historical detection period. At least one query operation is used to indicate the total number of query operations responded to by the database product within the historical detection period. Based on this, the number of fluctuating queries executed by the database product within the historical period, and the total number of queries executed, can be statistically analyzed. Then, the ratio of the number of fluctuating queries executed to the total number of queries executed within the historical period can be determined, and this ratio can be used as a status detection indicator for the database product; that is, the status detection indicator is the query response time fluctuation rate within the historical detection period.

[0077] For example, assuming the historical monitoring period is the past minute, within the past minute, the database product responded to 10 fluctuating query operations, and the total number of query operations responded to was 50. Since the ratio between the fluctuating query count and the total number of queries is 20%, that is, the fluctuating query count of the database product accounts for 20% of the total number of queries in the past minute, based on this, 20% can be determined as the status monitoring indicator of the database product, that is, the query response time fluctuation rate in the past minute is 20%.

[0078] As an optional implementation method, the state detection method for the database product further includes: if the proportion is greater than a preset proportion threshold, then determining that the state detection index is greater than the state detection index threshold, wherein the state detection index threshold includes the proportion threshold.

[0079] In this embodiment, the percentage threshold is a data parameter used to measure whether the status detection index of the database product is greater than the status detection index threshold. Based on this, after determining the percentage of fluctuating query quantity in the database product to the total number of queries during the historical detection period, the percentage can be compared with the preset percentage threshold. If the percentage is greater than the percentage threshold, it can be determined that the status detection index is greater than the status detection index threshold.

[0080] Optionally, if the proportion of fluctuating query counts in the database product to the total number of queries during the historical detection period is not greater than the proportion threshold, then it can be determined that the status detection index is not greater than the status detection index threshold.

[0081] As an optional implementation, the state detection method for database products further includes: determining a query pattern that matches at least one query operation; and determining a time threshold based on the query pattern.

[0082] In this embodiment, query operations can be executed using a query language, which in turn corresponds to different query modes. Therefore, after identifying at least one query operation responded to by the database product within a historical time period, the query mode matching that query operation can be determined based on the query language corresponding to that at least one query operation. Different query modes correspond to different time thresholds. Therefore, after determining the query mode corresponding to a query operation, a corresponding time threshold can be determined based on that query mode. Specifically, the time threshold corresponding to a query mode can be determined based on the median query response time of query operations of that query mode over a period preceding the historical detection time period.

[0083] For example, the query language can be SQL, and the corresponding query pattern can be SQLpattern. SQL Pattern indicates the result obtained after templated SQL. Based on the SQL language corresponding to each query operation within a historical detection period, the SQL pattern corresponding to that query operation can be determined, and then the time threshold corresponding to that query operation can be obtained based on the SQL pattern.

[0084] As an optional implementation, determining a time threshold based on a query pattern includes: acquiring at least one historical query operation that matches the query pattern within a preset time period prior to the historical detection period of the database product; determining the historical response time of the historical query operation; and determining the time threshold based on the historical response time.

[0085] In this embodiment, the data source range and precision for time threshold statistics can vary depending on the application scenario. For example, the preset time period can be one week, half a month, one month, etc., prior to the historical detection period; no specific limitation is made here. At least one historical query operation matching the query pattern can be a query operation within the preset time period corresponding to a query pattern similar to or identical to the query pattern. The historical response time can be the query response time of at least one historical query matching the query pattern within the preset time period.

[0086] For example, taking a week prior to the historical detection period as a preset timeframe, and assuming the query pattern is SQLpattern, we can determine the query response times of multiple historical queries corresponding to the same or similar SQLpatterns within the past week based on the SQL pattern. These determined query response times are then used as the historical response times corresponding to the query operations of the SQLpattern. After determining the historical response times of the historical queries matching the SQL pattern, a time threshold can be determined based on these historical response times.

[0087] As an optional implementation, determining a time threshold based on historical response times includes: determining a target response time based on multiple historical response times corresponding to multiple historical query operations, wherein the target response time is used to describe the overall statistical result of multiple historical response times; and determining a time threshold based on the target response time.

[0088] In this embodiment, after determining the historical response times of multiple historical query operations that match the query pattern, a target response time can be further determined based on the multiple historical response times corresponding to the multiple historical query operations. The target response time can be any one of the following: the median response time of the multiple historical response times, the average response time of the multiple historical response times, the response time corresponding to the percentile of the multiple historical response times (e.g., the P80 of the multiple historical response times), or the maximum response time of the multiple historical response times. No specific restrictions are placed on the determination of the target response time here.

[0089] For example, the median response time can be determined based on the median of multiple historical response times; the average response time can be determined based on the average of multiple historical response times; the P80 of multiple historical response times can be determined based on the 80th percentile of multiple historical response times, that is, based on 80% of multiple historical response times; the maximum response time can be determined based on the maximum value of multiple historical response times. The target response time can be one of the above response times, or it can be other response times besides the above response times, without specific restrictions here.

[0090] As an optional implementation, determining a time threshold based on the target response time includes: determining an adjustment parameter based on the target response time, wherein the adjustment parameter is used to represent the multiple by which the target response time is adjusted; adjusting the target response time according to the adjustment parameter; and determining the adjusted target response time as the time threshold.

[0091] In this embodiment, the adjustment parameter represents the multiplier by which the target response time is adjusted, for example, the upper limit multiplier for fluctuation in query operations. Since the query operations responded to by the database product may be short or long, short queries typically indicate fast, simple database query operations with shorter response times, while long queries typically indicate complex, time-consuming database query operations with longer response times. Therefore, to avoid misjudgment of fluctuations, a larger fluctuation range can be set for short query operations with shorter response times; that is, a larger adjustment parameter is set for short query operations, and a smaller fluctuation range is set for long query operations with longer response times; that is, a smaller adjustment parameter is set for long query operations. The adjustment parameter can be determined by the target response time of the query operation. For example, the target response time can be the median of the historical response times of historical query operations consistent with the query pattern of the query operation.

[0092] For example, assuming the upper limit of volatility is y times, the target response time can be adjusted based on this upper limit of volatility y. For instance, the target response time can be multiplied by the upper limit of volatility to obtain the adjusted target response time, which can then be determined as the time threshold. For example, assuming the upper limit of volatility is 2, then twice the target response time can be determined as the time threshold.

[0093] For example, the adjustment parameters can be determined by the weighting function of the following function.

[0094] y = e^-(median historical response time of SQL_Pattern / 200 - 2) + 2

[0095] Where y can be used to represent the adjustment parameter, and the median historical response time of the SQL pattern can be used to indicate the median historical response time of historical query operations in the period before the historical detection period, wherein the query pattern of the historical query operations in the period before the historical detection period is consistent with the query pattern of the query operations in the historical detection period.

[0096] As an optional implementation method, the state detection method for the database product further includes: determining a target anomaly index for the database product based on a state detection index corresponding to an abnormal stability state, wherein the target anomaly index is used to put the database product into an abnormal stability state.

[0097] In this embodiment, as described above, when the state detection index is greater than the state detection index threshold, it is determined that the database product is in an abnormal stability state. When the database product is continuously in an abnormal stability state, it can be determined that there are abnormal indicators in the database product. The target abnormal indicator of the database product can be determined based on the state detection index corresponding to the abnormal stability state.

[0098] For example, when a database product is in an abnormal stability state, the target abnormality index of the database product can be determined based on the state detection index under the abnormal stability state. This target abnormality index is the root cause of the database product's abnormality. By determining the target abnormality index in the database product, the root cause of the database product's abnormality can be identified.

[0099] As an optional implementation, the target anomaly indicator of the database product is determined based on the state detection indicators corresponding to the abnormal stability state. This includes: determining the abnormal period in which the database product is in an abnormal stability state within the historical detection period based on the state detection indicators; determining the test period of the target anomaly indicator based on the abnormal period; identifying the test period as the historical detection period, and returning to the process of executing the following steps to obtain the state detection indicators within the test period: obtaining at least one query operation responded by the database product within the historical detection period; and determining the target anomaly indicator based on the state detection indicators within the test period.

[0100] In this embodiment, the state detection index is used to indicate the stability state of the database product. The state detection index is obtained through fluctuation query operations and total query operations within the historical detection period. Based on this, when it is determined from the state detection index that the database product is in an abnormal stability state within the historical period, the abnormal period when the database product is in an abnormal stability state can be further determined. The abnormal period is used to indicate the time interval of abnormal fluctuation in the response time of the database product to the fluctuation query operation.

[0101] Optionally, after identifying the abnormal period in which the database product exhibits an abnormal stability state, the start time of the fluctuation anomaly can be further determined. This start time is the time it takes for the database product to respond to the fluctuation query operation. After determining the start time of the fluctuation anomaly, a period can be extended forward from this start time; for example, it can be extended forward by 30 minutes, without specific limitations. For ease of explanation, this extended time period can be called the preceding period. Based on this, the period formed by the abnormal period and the preceding period can be defined as the period to be tested, i.e., the time range to be tested.

[0102] Optionally, after determining the period to be tested, the period to be tested can be designated as a historical detection period, and the aforementioned steps S401 to S403 can be executed to obtain the state detection indicators within the period to be tested.

[0103] Optionally, after determining the status detection indicators for the period to be tested, the target anomaly indicators of the database product can be determined based on the status detection indicators for the period to be tested.

[0104] As an optional implementation, the target anomaly indicator is determined based on the state detection indicators during the test period, including: acquiring candidate anomaly indicators of the database product during the test period, wherein the candidate anomaly indicator is an indicator to be determined that causes the database product to be in an abnormally stable state; acquiring the correlation between the state detection indicators and the candidate anomaly indicators during the test period, wherein the correlation is used to represent the degree of correlation between the state detection indicators and the candidate anomaly indicators during the test period; and determining the candidate anomaly indicator as the target anomaly indicator in response to the correlation being greater than a correlation threshold, wherein the target anomaly indicator is used to cause the database product to be in an abnormally stable state.

[0105] In this embodiment, the candidate anomaly indicator is an indicator to be determined that causes the database product to be in an abnormal stability state. This candidate anomaly indicator can be a core indicator of the database product. Based on this, candidate anomaly indicators of the database product can be obtained within the test period. Then, the correlation between the state detection indicator and the candidate anomaly indicator within the test period can be obtained. The correlation is then compared with a correlation threshold. If the correlation is greater than the correlation threshold, the candidate anomaly indicator is determined as the target anomaly indicator. The correlation threshold can be preset; for example, the correlation threshold can be 0.8. This is further exemplified here.

[0106] For example, candidate anomaly indicators can be cluster anomaly correlation indicators, which may include pattern-level indicators, scan data volume, memory usage, data transmission volume, Java Virtual Machine (JVM) memory usage, JVM garbage collection (GC) time, network rewrite rate, and transaction per second (TPS), etc., without specific restrictions here.

[0107] As an optional implementation method, obtaining the correlation between the state detection index and the candidate anomaly index within the test period includes: obtaining a first feature vector of the state detection index; obtaining a second feature vector of the candidate anomaly index; and determining the similarity between the first feature vector and the second feature vector as the correlation.

[0108] In this embodiment, the detection period corresponding to the state detection index is the same as the detection period corresponding to the candidate anomaly index. Therefore, the number of data points corresponding to both is also the same, and the two state detection indices can be equated to two feature vectors. For ease of explanation, the feature vector corresponding to the state detection index can be called the first feature vector, and the feature vector corresponding to the candidate anomaly index can be called the second feature vector. Then, the similarity between the first feature vector and the second feature vector is calculated, and this similarity is determined as the correlation between the state detection index and the candidate anomaly index within the test period.

[0109] For example, the similarity between the first feature vector and the second feature vector can be determined by the cosine similarity algorithm. This is only an example and does not limit the process of determining the similarity between the first feature vector and the second feature vector.

[0110] As an optional implementation, obtaining the first feature vector of the state detection index includes: normalizing the state detection index to obtain the first feature vector; obtaining the second feature vector of the candidate anomaly index includes: normalizing the candidate anomaly index to obtain the second feature vector.

[0111] In this embodiment, when obtaining the first feature vector of the state detection index, the state detection index can be normalized to obtain the first feature vector. Similarly, when obtaining the second feature vector of the candidate anomaly index, the second feature vector of the candidate anomaly index can be normalized to obtain the second feature vector.

[0112] For example, z-score normalization can be used to normalize the state detection metric to obtain the first feature vector, and the candidate anomaly metric can be normalized to obtain the second detection metric. It should be noted that z-score normalization results in a mean of 0 and a variance of 1 for both the state detection metric and the candidate anomaly metric. This 0 mean facilitates subsequent calculation of the similarity between the first feature vector of the state detection metric and the second feature vector of the candidate anomaly metric.

[0113] As an optional implementation method, the target abnormal indicator is determined based on the abnormal period, including: determining the preceding period before the start time of the abnormal period; and determining the abnormal period and the preceding period as the target period.

[0114] In this embodiment, as described above, the start time of the abnormal period is the time from when the database product responds to the fluctuating query. The preceding period, which precedes the start time of the abnormal period, can be a period extended forward from the start time of the abnormal period, for example, 30 minutes forward; no specific limitation is made here. After obtaining the preceding period, since the abnormal period and the preceding period are two adjacent periods, the period consisting of the abnormal period and the preceding period can be determined as the period to be tested.

[0115] As an optional implementation method, the target anomaly index of the database product is determined based on the state detection index, including: inputting the state detection index into a machine learning model for prediction to obtain the target anomaly index, wherein the machine learning model is trained based on the state detection index sample and the anomaly index sample of the database product, the state detection index sample is used to characterize the abnormal stability state of the database product, and the anomaly index sample is used to make the database product be in the abnormal stability state corresponding to the state detection index sample.

[0116] In this embodiment, when determining the target anomaly indicators of a database product based on state detection indicators, a machine learning model can be used to predict the target anomaly indicators of the database product.

[0117] For example, the machine learning model is a model pre-trained based on abnormal indicator samples of different database products in abnormal stability states. Based on this machine learning model, abnormal indicators of database products can be predicted. Based on this, state detection indicators can be input into the machine learning model to automatically predict target abnormal indicators of database products.

[0118] In the above steps, the status detection index is determined based on at least one fluctuating query operation and at least one query operation within the historical detection period. Therefore, this status detection index can accurately represent the proportion of fluctuating query operations within the historical detection period. Based on this, the status detection index of the database product is compared with the status detection index threshold. If the status detection index is greater than the status detection index threshold, it can be determined that the database product is in an abnormally stable state. That is, no manual investigation is required. Using the status detection index threshold as a data reference, when the status detection index is greater than the status detection index threshold, it can be automatically determined that the database product is in an abnormally stable state. This greatly reduces the troubleshooting time when the database product has problems and provides a basic preparation for the automated operation and maintenance of the database product, improves the user experience, and thus solves the technical problem of low status detection efficiency of the database product.

[0119] Under the aforementioned operating environment, this application also provides, for example: Figure 5The status detection method for the database product shown is applied to a cloud server, where the database product is deployed. Figure 5 This is a method for detecting the status of a database product according to an embodiment of this application. For example... Figure 5 As shown, the method may include the following steps:

[0120] Step 501: By calling the first interface, obtain at least one query operation responded by the database product during the historical detection period.

[0121] In the technical solution provided in step S501 of this application, the first interface can be an interface for data interaction between the cloud server and the client. The server can obtain at least one query operation responded to by the database product during the historical detection period by calling the first interface. This at least one query operation is used to indicate all query operations responded to by the database product during the historical detection period.

[0122] Step S502: In at least one query operation, identify at least one fluctuating query operation.

[0123] In the technical solution provided by step S502 of this application, at least one query operation corresponds to a query response time. Based on this, after obtaining at least one query operation that the database product responded to within the historical detection period, at least one fluctuating query operation can be identified according to the query response time corresponding to the at least one query operation. The fluctuating query operation is a query operation whose response time exceeds a time threshold among the at least one query operations. The response time can also be called query response time, query execution time, etc., without specific limitations here. The time threshold can be determined based on the historical query response time of historical query operations that match the query pattern of the query operation. The query pattern is used to indicate the pattern corresponding to the query language of the query operation, such as the structured query language pattern (SQL pattern).

[0124] Step S503: Based on at least one fluctuation query operation and at least one query operation, determine the status detection indicators of the database product.

[0125] In the technical solution provided by step S503 of this application, after determining at least one fluctuation query operation, a status detection index of the database product can be determined based on the at least one fluctuation query operation and the at least one query operation. The status detection index is used to characterize the stability state of the database product. For example, the status detection index can be the query response time volatility, which can be the ratio of the number of fluctuation queries in the historical detection period to the total number of queries in the database product.

[0126] Step S504: If the status detection index is greater than the status detection index threshold, then it is determined that the database product is in an abnormal stability state during the historical detection period.

[0127] In the technical solution provided in step S504 of this application, after determining the status detection index of the database product, the status detection index can be compared with the status detection index threshold to determine the stability status of the database product within a historical time period. The status detection index threshold is a threshold for judging whether the database product is in an abnormal stability state; the specific value of this threshold can be preset and is not specifically limited here.

[0128] In this embodiment, if the state detection index is greater than the state detection index threshold, it is determined that the database product is in an abnormal stability state during the historical detection period. The specific implementation method can be found in step S404 above, and will not be repeated here.

[0129] Step S505: Output the prompt message of the abnormal stable state by calling the second interface.

[0130] In the technical solution provided in step S505 of this application, the second interface can be an interface for data interaction between the cloud server and the client. After determining the stability status of the database product, if the database product is in an abnormal stability status, the cloud server can output the abnormal stability status prompt information of the database product to the client through the second interface for display, so that the user can troubleshoot the cause of the abnormality based on the content displayed on the client.

[0131] In the technical solutions provided in steps S501 to S505 of this application, the stability status of the database product is determined by a status detection index. Since the status detection index is determined based on at least one fluctuating query operation and at least one query operation within a historical detection period, the status detection index can accurately represent the proportion of fluctuating query operations within the historical detection period. Based on this, the status detection index of the database product is compared with a status detection index threshold. If the status detection index is greater than the status detection index threshold, it is determined that the database product is in an abnormally stable state. That is, no manual investigation is required. The status detection index threshold is used as a data reference. When the status detection index is greater than the status detection index threshold, it can be automatically determined that the database product is in an abnormally stable state, which greatly reduces the investigation time when the database product has problems and provides a basic preparation for the automated operation and maintenance of the database product, improves the user experience, and thus solves the technical problem of low status detection efficiency of the database product.

[0132] Figure 6This is a schematic diagram of a status detection system for a database product according to an embodiment of this application. The status detection system 600 for the database product may include a client 601 and a cloud server 602.

[0133] Client 601 is used to upload status detection commands for database products.

[0134] In this embodiment, the status detection instruction is used to indicate at least one query operation responded to by the detection database product during the historical detection period. The status detection instruction can be entered by the user into the client and uploaded to the cloud server through the client.

[0135] Cloud server 602 is used to respond to status detection commands and obtain at least one query operation responded by the database product during the historical detection period; among the at least one query operation, at least one fluctuating query operation is identified, wherein the fluctuating query operation is the query whose response time exceeds a time threshold among the at least one query operation; based on the at least one fluctuating query operation and the at least one query operation, the status detection index of the database product is determined, wherein the status detection index is used to characterize the stability state of the database product; if the status detection index is greater than the status detection index threshold, it is determined that the database product is in an abnormal stability state during the historical detection period; and the abnormal stability state prompt information is returned to the client.

[0136] In this embodiment, after responding to the status detection command sent by the client, the cloud server can obtain at least one query operation responded to by the database product within the historical detection period, wherein the at least one query operation refers to all query operations responded to by the database product within the historical detection period. After obtaining the at least one query operation responded to by the database product within the historical detection period, at least one fluctuating query operation can be identified among the at least one query operation, wherein the fluctuating query operation is a query whose response time exceeds a time threshold among the at least one query operation. Based on the at least one fluctuating query operation and the at least one query operation, the status detection index of the database product can be determined. If the status detection index is greater than the status detection index threshold, it is determined that the database product is in an abnormal stability state within the historical detection period. After determining that the database product is in an abnormal stability state, the abnormal stability state prompt information can be returned to the client so that the user can troubleshoot the cause of the database product's abnormality based on the abnormal stability state.

[0137] The technical solutions of the embodiments of this application will be further illustrated below with reference to preferred embodiments.

[0138] Currently, stability issues for database products with a large customer base are highly complex. When an urgent stability problem arises, the entire process—from customer discovery of the issue to reporting a support ticket, to frontline R&D personnel investigating and resolving the problem—is time-consuming, impacting usability. Therefore, there is a technical problem of low detection efficiency for database products.

[0139] However, this application provides a method for detecting the state of a database product, which involves obtaining at least one query operation responded by the database product during a historical detection period; identifying at least one fluctuating query operation among the at least one query operation, wherein the fluctuating query operation is a query operation whose response time exceeds a time threshold; determining a state detection index for the database product based on the at least one fluctuating query operation and the at least one query operation, wherein the state detection index is used to characterize the stability state of the database product; and determining that the database product is in an abnormal stability state during the historical detection period if the state detection index is greater than the state detection index threshold. In other words, in this embodiment, the status detection index is determined based on at least one fluctuating query operation and at least one query operation within a historical detection period. Therefore, the status detection index can accurately represent the proportion of fluctuating query operations within the historical detection period. Based on this, the status detection index of the database product is compared with the status detection index threshold. If the status detection index is greater than the status detection index threshold, it can be determined that the database product is in an abnormally stable state. That is, no manual investigation is required. The status detection index threshold is used as a data reference. When the status detection index is greater than the status detection index threshold, it can be automatically determined that the database product is in an abnormally stable state, which greatly reduces the investigation time when the database product has problems and provides a basic preparation for the automated operation and maintenance of the database product, improves the user experience, and thus solves the technical problem of low status detection efficiency of the database product.

[0140] The following section will provide further details on query response time volatility.

[0141] In this embodiment, to automatically detect anomalies in the database product, anomaly detection metrics need to be set. These metrics should not be too detailed, lest they only detect some localized problems, nor too coarse, lest they lead to a large number of false positives. Since query response time volatility is a metric that users directly experience, it is used as the anomaly detection metric. The database product can be a database cluster; no specific restrictions are imposed here.

[0142] Query response time volatility is calculated by combining the query response time of a query operation's query pattern (e.g., SQL pattern) over a period of time with the historical response time of that query pattern. A query operation can be classified as volatile when its execution time exceeds y times the median of the historical response times of queries with the same SQL pattern.

[0143] The query response time volatility of a database product is defined as the percentage of fluctuating query counts to the total number of queries within a given period (default is 1 minute), used to determine whether the system is currently in an abnormal state. By default, 20% is used as the threshold for determining abnormality. That is, if 20% of queries have fluctuating response times within the past minute, the algorithm will automatically determine that the system is currently in an abnormal state, and subsequent actions may include telephone alerts, automatic fault reporting, etc.

[0144] The method for determining the upper limit of volatility will be explained in more detail below.

[0145] In this embodiment, the volatility cap can be set to a fixed value, such as 2. However, a fixed value can only be suitable for some situations. For example, if the volatility cap is fixed at 2, a query response time exceeding twice the median historical response time of the SQL pattern will be judged as a volatile query. This applies to queries with long execution times. However, database products often contain a large number of short queries. When a query with a historical median response time of only 10ms encounters factors that cause it to fluctuate to more than 20ms, it does not necessarily mean that its fluctuation is abnormal. Otherwise, there would be a large number of misjudgments of volatility in the database product. Therefore, it is necessary to give queries with shorter response times a larger normal fluctuation range to avoid misjudgments, while setting a basically reasonable volatility cap for larger queries. Large queries can be processes that query and analyze large amounts of data, usually involving data in large databases or data warehouses, requiring the use of complex query languages ​​and techniques to process and analyze large amounts of data.

[0146] Optionally, for large queries, if the time granularity is 1 minute, there is a high probability that the large query will span two or more time granularities. This means that a large query may affect the stability of the cluster over a period of time. If cluster stability issues occur over a period of time, they may be related to the large query. Therefore, it is inaccurate to only collect various metrics for large queries at the start or end time granularity. A better approach is to collect all metrics for the large query at every time granularity it experiences, that is, to include the resource overhead for each time period throughout its entire lifecycle, to better describe the cluster pressure.

[0147] Alternatively, the specific value of the volatility cap ratio can be determined by a function, as shown in the following formula.

[0148] y = e^-(median historical response time of SQL_Pattern / 200 - 2) + 2

[0149] Where y is used to indicate the upper limit of volatility.

[0150] Figure 7 This is a schematic diagram illustrating the change of the upper limit of volatility as a function of the median historical response time of an SQL pattern, according to an embodiment of this application. Figure 7 As shown, the horizontal axis indicates the median historical response time of the SQL Pattern, and the vertical axis indicates the value of the volatility cap multiplier y calculated by the above function. The value is approximately 9 times the median historical response time of around 10ms, and approximately 2.05 times the median historical response time of around 1s, eventually converging to 2. This function allows for a wider range of volatility for small queries, while the volatility limit becomes increasingly stringent as the query time increases, eventually converging to twice the median historical response time of the SQL Pattern.

[0151] Figure 8 This is a schematic diagram illustrating the change of another volatility ceiling multiple as a function of the median historical response time of the SQL pattern, according to an embodiment of this application. Figure 8 As shown, the horizontal axis represents the median historical response time of the SQL Pattern, and the vertical axis represents the upper limit of response time fluctuation calculated by the above function. It can be seen that when the median historical response time of the SQL Pattern is between 0 and 1000, the upper limit of fluctuation increases rapidly, which aligns with the expectation that short queries will have a higher upper limit of fluctuation. However, when the median historical response time of the SQL Pattern is above 1000, the upper limit of fluctuation increases at a linear rate with a slope close to 2.

[0152] The following section will further introduce the algorithm for abnormal fluctuations in response time based on time series.

[0153] To replace the manual troubleshooting process and simplify the troubleshooting workflow, this application provides a root cause analysis algorithm based on time-series correlation to identify abnormal query indicators that cause abnormal stability of database products. These abnormal query indicators include the response time of query operations, the number of times data in the dataset is randomly rearranged (shuffle data volume), the amount of data scanned, memory usage, etc., without specific limitations here.

[0154] In a database system, if there are continuous fluctuations in query response time, it can be determined that the core indicators of the database product are abnormal. Among them, abnormal query patterns are the primary cause of database product stability problems; that is, the abnormal query pattern is also known as the abnormal pattern. Figure 9 This is a flowchart of a root cause analysis method based on temporal correlation, according to an embodiment of this application. Figure 9 As shown, the method includes the following steps:

[0155] Step S901: Calculate the query response time volatility index of the database product.

[0156] In this embodiment, an index of the fluctuation in query response time of the database product within a historical detection period can be calculated to find the time when the fluctuation anomaly started. The historical detection period can be the past minute, and there is no limitation here.

[0157] Step S902: Determine the time period to be tested based on the query response time volatility index.

[0158] In this embodiment, after determining the start time of the fluctuation anomaly through step S901, a period of time can be extended forward from the start time of the fluctuation anomaly, for example, 30 minutes, and this extended period is determined as the preceding period. This preceding period is then merged with the time interval in which the fluctuation anomaly occurred to obtain the period to be measured.

[0159] Step S903: Determine the query response time volatility index data within the period to be tested.

[0160] In this embodiment, a data point can be defined as a 1-minute time granularity. That is, a data point is recorded every 1 minute, and then the query response time volatility index data within the test period is calculated based on the collected data points. Here, defining a data point as a 1-minute time granularity means that data is collected and recorded at 1-minute intervals when collecting and recording data, and each data point can be used to represent the data collected and recorded within 1 minute.

[0161] Step S904: Collect all query metrics responded to by the database product during the test period.

[0162] In this embodiment, all query metrics responded to by the database product during the testing period can be collected, and the query metrics corresponding to all query patterns (SQL patterns) can be aggregated using an aggregation method. These query metrics may include core metrics of the database product such as scan data volume, memory usage, and data transfer volume. The aggregation method can be a summation method. Optionally, this embodiment uses the summation method to aggregate query metrics corresponding to query patterns by adding up all query metrics for the same query pattern to obtain the overall metric data for that query pattern. For example, the scan data volume, memory usage, and data transfer volume of the same SQL pattern can be added together to obtain the overall data volume for that SQL pattern.

[0163] Step S905: Normalize the query response time volatility index and query index for the period to be tested.

[0164] In this embodiment, the response time volatility and query metrics (e.g., scan data volume, memory usage) within the test period can be normalized using z-score normalization, without any specific limitations.

[0165] Step S906: Perform feature amplification processing on the normalized query response time volatility and query indicators.

[0166] In this embodiment, a feature amplification algorithm can be used to amplify the query response time volatility and query metrics to more clearly observe data points that are far from the mean.

[0167] Step S907: Calculate the similarity between the query response time volatility and the query metric.

[0168] In this embodiment, the similarity between query response time volatility and query metric can be calculated. For example, the feature vectors corresponding to query response time volatility and query metric can be determined respectively, and then the similarity between the two can be determined by the cosine similarity algorithm.

[0169] Step S908: Based on similarity and similarity threshold, identify abnormal query indicators that are highly correlated with query response time fluctuations.

[0170] In this embodiment, after calculating the similarity, the similarity can be compared with a similarity threshold. If the similarity is greater than the similarity threshold, it indicates that the query metric corresponding to that similarity is an abnormal query metric. The similarity threshold can be preset, for example, 0.8; no specific limitation is made here.

[0171] In this embodiment, by calculating abnormal query metrics that are highly correlated with query response time volatility, it is possible to automatically identify abnormal query metrics whose correlation with query response time volatility exceeds a threshold, thereby achieving the goal of automatically determining the root cause of database product stability anomalies. It should be noted that other core metrics of the database product, such as JVM memory usage and write data volume (TPS), can be aggregated into a feature vector, and then their similarity can be calculated with the query response time volatility vector. This automatically determines the root cause of current system anomalies, significantly saving troubleshooting time and improving customer experience.

[0172] It should be noted that 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 application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or refuse.

[0173] 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.

[0174] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, they can also be implemented by hardware. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0175] Example 2

[0176] According to an embodiment of this application, a state detection device for a database product that implements the state detection method for the above-described database product is also provided. Figure 10 This is a schematic diagram of a status detection device for a database product according to an embodiment of this application, such as... Figure 10As shown, the status detection device 1000 of the database product may include: an acquisition unit 1001, a first identification unit 1002, a first determination unit 1003, and a second determination unit 1004.

[0177] The acquisition unit 1001 is used to acquire at least one query operation responded by the database product during the historical detection period.

[0178] The first identification unit 1002 is used to identify at least one fluctuating query operation in at least one query operation, wherein the fluctuating query operation is a query operation in at least one query operation whose response time exceeds a time threshold.

[0179] The first determining unit 1003 is used to determine the state detection index of the database product based on at least one fluctuation query operation and at least one query operation, wherein the state detection index is used to characterize the stability state of the database product.

[0180] The second determining unit 1004 is used to determine that the database product is in an abnormal stability state during the historical detection period when the state detection index is greater than the state detection index threshold.

[0181] It should be noted that the aforementioned acquisition unit 1001, first identification unit 1002, first determination unit 1003, and second determination unit 1004 correspond to steps S401 to S404 in Embodiment 1. The four units and their corresponding steps implement the same instances and application scenarios, but are not limited to the content disclosed in Embodiment 1. It should also be noted that the aforementioned modules or units can be hardware or software components stored in a memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, ..., 102n). These modules can also run as part of a device in the computer terminal 10 provided in Embodiment 1.

[0182] According to an embodiment of this application, a state detection device for a database product that implements the state detection method for the above-described database product is also provided. Figure 11 This is a schematic diagram of a status detection device for a database product according to an embodiment of this application, such as... Figure 11 As shown, the status detection device 1100 of the database product may include: a first calling unit 1101, a second identification unit 1102, a third determining unit 1103, a fourth determining unit 1104, and a second calling unit 1105.

[0183] The first calling unit 1101 is used to call the first interface to obtain at least one query operation responded by the database product during the historical detection period. The first interface includes a first parameter, and the parameter value of the first parameter is at least one query operation.

[0184] The second identification unit 1102 is used to identify at least one fluctuating query operation in at least one query operation, wherein the fluctuating query operation is a query in at least one query operation whose response time exceeds a time threshold.

[0185] The third determining unit 1103 is used to determine the state detection index of the database product based on at least one fluctuation query operation and at least one query operation, wherein the state detection index is used to characterize the stability state of the database product.

[0186] The fourth determining unit 1104 is used to determine that the database product is in an abnormal stability state during the historical detection period when the state detection index is greater than the state detection index threshold.

[0187] The second calling unit 1105 is used to call the second interface to output the prompt information of the abnormal stable state. The second interface includes a second parameter, and the parameter value of the second parameter is the prompt information of the abnormal stable state.

[0188] It should be noted that the first calling unit 1101, the second identification unit 1102, the third determining unit 1103, the fourth determining unit 1104, and the second calling unit 1105 mentioned above correspond to steps S501 to S505 in Embodiment 1. The five units and the corresponding steps implement the same instances and application scenarios, but are not limited to the content disclosed in Embodiment 1. It should be noted that the above modules or units can be hardware or software components stored in memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, ..., 102n). The above modules can also be part of a device and run in the computer terminal 10 provided in Embodiment 1.

[0189] It should be noted that the preferred implementation schemes involved in the above embodiments of this application are the same as the schemes, application scenarios and implementation processes provided in Embodiment 1, but are not limited to the schemes provided in Embodiment 1.

[0190] Example 3

[0191] Embodiments of this application may provide an electronic device that includes a computer terminal, which may be any one of a group of computer terminals. Optionally, in this embodiment, the computer terminal may also be replaced by a mobile terminal or other terminal device.

[0192] Optionally, in this embodiment, the computer terminal may be located in at least one of a plurality of network devices in a computer network.

[0193] In this embodiment, the computer terminal described above can execute the program code for the following steps in the database product status detection method: obtaining at least one query operation responded by the database product during a historical detection period; identifying at least one fluctuating query operation among the at least one query operation, wherein the fluctuating query operation is a query operation whose response time exceeds a time threshold among the at least one query operation; determining a status detection index of the database product based on the at least one fluctuating query operation and the at least one query operation, wherein the status detection index is used to characterize the stability state of the database product; if the status detection index is greater than the status detection index threshold, it is determined that the database product is in an abnormal stability state during the historical detection period.

[0194] Optionally, Figure 12 This is a structural block diagram of a computer terminal according to an embodiment of this application. Figure 12 As shown, the computer terminal A may include: one or more (only one is shown in the figure) processors 1202, memory 1204, memory controller, and peripheral interfaces, wherein the peripheral interfaces are connected to a radio frequency module, an audio module, and a display.

[0195] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the database product status detection method and apparatus in this application embodiment. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby realizing the aforementioned database product status detection method. The memory 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 may further include memory remotely located relative to the processor, and these remote memories can be connected to computer terminal A 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.

[0196] The processor can invoke information and application programs stored in the memory via a transmission device to perform the following steps: acquiring at least one query operation responded to by the database product during a historical testing period; identifying at least one fluctuating query operation among the at least one query operation, wherein the fluctuating query operation is a query operation whose response time exceeds a time threshold; determining a state detection index of the database product based on the at least one fluctuating query operation and the at least one query operation, wherein the state detection index is used to characterize the stability state of the database product; if the state detection index is greater than the state detection index threshold, it is determined that the database product is in an abnormal stability state during the historical testing period.

[0197] Optionally, the processor may also execute program code that performs the following steps: counts the number of fluctuating queries that perform fluctuating query operations and the total number of queries that perform query operations; determines the proportion of fluctuating queries to the total number of queries; and uses the proportion as a status detection indicator for the database product.

[0198] Optionally, the processor may also execute program code that performs the following steps: if the percentage is greater than a preset percentage threshold, then determine that the state detection index is greater than the state detection index threshold, wherein the state detection index threshold includes the percentage threshold.

[0199] Optionally, the processor may also execute program code that performs the following steps: determining a query pattern that matches at least one query operation; and determining a time threshold based on the query pattern.

[0200] Optionally, the processor may also execute program code that performs the following steps: obtains at least one historical query operation matching the query pattern within a period prior to the historical detection period of the database product; determines the historical response time of the historical query operation; and determines a time threshold based on the historical response time.

[0201] Optionally, the processor may also execute program code that performs the following steps: determining a target response time based on multiple historical response times corresponding to multiple historical query operations, wherein the target response time is used to describe the overall statistical result of multiple historical response times; and determining a time threshold based on the target response time.

[0202] Optionally, the processor may also execute program code that performs the following steps: determining adjustment parameters based on the target response time, wherein the adjustment parameters represent the multiple by which the target response time is adjusted; adjusting the target response time according to the adjustment parameters; and determining the adjusted target response time as a time threshold.

[0203] Optionally, the processor may also execute program code that performs the following steps: determining a target anomaly index for the database product based on a state detection index corresponding to an abnormal stability state, wherein the target anomaly index is used to bring the database product into an abnormal stability state.

[0204] Optionally, the processor may also execute program code that performs the following steps: based on state detection indicators, determine the abnormal period in which the database product is in an abnormal stability state within the historical detection period; based on the abnormal period, determine the test period for the target abnormal indicator; determine the test period as the historical detection period, and return to execute the following steps to obtain the state detection indicators within the test period: obtain at least one query operation responded by the database product within the historical detection period; based on the state detection indicators within the test period, determine the target abnormal indicator.

[0205] Optionally, the processor may also execute program code that performs the following steps: obtaining candidate anomaly indicators of the database product during the test period, wherein the candidate anomaly indicators are indicators to be determined that cause the database product to be in an abnormal stability state; obtaining the correlation between the state detection indicators and the candidate anomaly indicators during the test period, wherein the correlation is used to represent the degree of correlation between the state detection indicators and the candidate anomaly indicators during the test period; and determining the candidate anomaly indicator as the target anomaly indicator in response to the correlation being greater than the correlation threshold, wherein the target anomaly indicator is used to cause the database product to be in an abnormal stability state.

[0206] Optionally, the processor may also execute program code that performs the following steps: obtaining a first feature vector of the state detection index; obtaining a second feature vector of the candidate anomaly index; and determining the similarity between the first feature vector and the second feature vector as the correlation.

[0207] Optionally, the processor may also execute program code that performs the following steps: determining the preceding time period before the start time of the abnormal time period; and determining the abnormal time period and the preceding time period as the time period to be tested.

[0208] Optionally, the processor may also execute program code that performs the following steps: inputting state detection metrics into a machine learning model for prediction to obtain target anomaly metrics, wherein the machine learning model is trained based on state detection metric samples and anomaly metric samples of the database product, the state detection metric samples are used to characterize the abnormal stability state of the database product, and the anomaly metric samples are used to make the database product be in the abnormal stability state corresponding to the state detection metric samples.

[0209] This application provides a method for detecting the status of a database product. The method uses a status detection index to measure the stability of the database product. This index is determined based on at least one fluctuating query operation and at least one query operation within a historical detection period. Therefore, the status detection index accurately represents the proportion of fluctuating query operations within the historical detection period. Based on this, the status detection index is compared with a status detection index threshold. If the status detection index is greater than the threshold, the database product is determined to be in an abnormally stable state. This eliminates the need for manual investigation. By using the status detection index threshold as a data reference, the database product can be automatically determined to be in an abnormally stable state when the status detection index exceeds the threshold. This significantly reduces the troubleshooting time when database product problems occur and provides a foundation for automated operation and maintenance of database products, improving user experience and thus solving the technical problem of low status detection efficiency for database products.

[0210] Those skilled in the art will understand that Figure 12 The structure shown is for illustrative purposes only. The computer terminal can also be a smartphone (such as an Android phone, an iOS phone, etc.), a tablet computer, a handheld computer, a mobile internet device (MID), a PAD, and other terminal devices. Figure 12 This does not limit the structure of the aforementioned electronic device. For example, computer terminal A may also include components that are more... Figure 12 The more or fewer components shown (such as network interfaces, display devices, etc.), or having the same Figure 12 The different configurations shown.

[0211] 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.

[0212] Example 4

[0213] Embodiments of this application also provide a computer-readable storage medium. Optionally, in this embodiment, the storage medium can be used to store the program code executed by the status detection method of the database product provided in Embodiment 1.

[0214] Optionally, in this embodiment, the storage medium may be located in any computer terminal in a group of computer terminals in a computer network, or in any mobile terminal in a group of mobile terminals.

[0215] Optionally, in this embodiment, the storage medium is configured to store program code for performing the following steps: obtaining at least one query operation responded by the database product during a historical detection period; identifying at least one fluctuating query operation among the at least one query operation, wherein the fluctuating query operation is a query operation whose response time exceeds a time threshold; determining a state detection index of the database product based on the at least one fluctuating query operation and the at least one query operation, wherein the state detection index is used to characterize the stability state of the database product; if the state detection index is greater than the state detection index threshold, it is determined that the database product is in an abnormal stability state during the historical detection period.

[0216] Embodiments of this application also provide a computer program product, including computer instructions, which, when executed by a processor, implement the state detection method for the database product provided in the embodiments of this application.

[0217] In this embodiment, the aforementioned computer instructions may be stored in read-only memory (ROM) or loaded from storage units into random access memory (RAM) to be executed by the processor in various appropriate actions and processes in the database product status detection method.

[0218] In some embodiments, some or all of the above-described computer instructions may be loaded and / or installed on an electronic device via a read-only memory and / or a communication unit. When the computer instructions are loaded into random access memory and executed by a computing unit, one or more steps of the status detection method for the database product described above may be performed.

[0219] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0220] 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.

[0221] In the several embodiments provided in this application, it should be understood that the disclosed technical content 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 displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0222] 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.

[0223] 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.

[0224] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a 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 a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0225] 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 detecting the status of a database product, characterized in that, Applied to a cloud server, on which a database product is deployed, the method includes: Obtain at least one query operation from the database product during the historical detection period; In the at least one query operation, at least one fluctuating query operation is identified, wherein the fluctuating query operation is a query operation in the at least one query operation whose response time exceeds a time threshold; Based on the at least one fluctuation query operation and the at least one query operation, a state detection index for the database product is determined, wherein the state detection index is used to characterize the stability state of the database product. If the state detection index is greater than the state detection index threshold, then the database product is determined to be in an abnormal stability state during the historical detection period. The method further includes: determining a target response time for the query operation based on multiple historical response times within a time period prior to the historical detection period, wherein the multiple historical response times correspond to historical query operations, and the historical query operations and the query operation have the same query mode; and determining a time threshold corresponding to the query operation based on the target response time and the fluctuation upper limit multiple. The method further includes: determining the upper limit of fluctuation based on the target response time, wherein the upper limit of fluctuation is inversely proportional to the target response time of the query operation; Determining the time threshold corresponding to the query operation based on the target response time and the upper limit of fluctuation includes: determining the time threshold corresponding to the query operation based on the product between the upper limit of fluctuation and the target response time; The method further includes: determining a query pattern matched by the at least one query operation; and determining the time threshold based on the query pattern.

2. The method according to claim 1, characterized in that, Based on the at least one fluctuation query operation and the at least one query operation, the status detection indicators of the database product are determined, including: The number of fluctuation queries that were executed during the fluctuation query operation, and the total number of queries that were executed during the query operation are counted. Determine the percentage of the fluctuating query count relative to the total query count; The percentage is used as the status detection indicator for the database product.

3. The method according to claim 2, characterized in that, The method further includes: If the percentage is greater than a preset percentage threshold, then the state detection index is determined to be greater than the state detection index threshold, wherein the state detection index threshold includes the percentage threshold.

4. The method according to claim 1, characterized in that, Determining the time threshold based on the query pattern includes: Obtain at least one historical query operation of the database product that matches the query pattern within a preset time period before the historical detection period; Determine the historical response time of the historical query operation; The time threshold is determined based on the historical response time.

5. The method according to claim 4, characterized in that, Determining the time threshold based on the historical response time includes: Based on the multiple historical response times corresponding to the multiple historical query operations, a target response time is determined, wherein the target response time is used to describe the overall statistical result of the multiple historical response times; The time threshold is determined based on the target response time.

6. The method according to claim 5, characterized in that, Determining the time threshold based on the target response time includes: Based on the target response time, adjustment parameters are determined, wherein the adjustment parameters represent the multiple by which the target response time is adjusted; Adjust the target response time according to the adjustment parameters; The adjusted target response time is determined as the time threshold.

7. The method according to any one of claims 1 to 6, characterized in that, The method further includes: Based on the state detection index corresponding to the abnormal stability state, a target anomaly index for the database product is determined, wherein the target anomaly index is used to bring the database product into the abnormal stability state.

8. The method according to claim 7, characterized in that, Based on the state detection index corresponding to the abnormal stability state, the target abnormal index of the database product is determined, including: Based on the state detection indicators, the abnormal period in which the database product was in the abnormal stability state during the historical detection period is determined; Based on the abnormal time period, determine the test period for the target abnormal indicator; The period to be tested is determined as the historical detection period, and the process is returned to start from the following steps to obtain the status detection indicators within the period to be tested: obtain the at least one query operation responded by the database product within the historical detection period; Based on the state detection indicators during the test period, the target anomaly indicator is determined.

9. The method according to claim 8, characterized in that, Based on the state detection indicators during the test period, the target anomaly indicator is determined, including: Obtain candidate anomaly indicators of the database product during the test period, wherein the candidate anomaly indicators are indicators to be determined that cause the database product to be in the abnormal stability state. Obtain the correlation between the state detection index and the candidate anomaly index during the test period, wherein the correlation is used to represent the degree of correlation between the state detection index and the candidate anomaly index during the test period; In response to the correlation being greater than the correlation threshold, the candidate anomaly indicator is determined as the target anomaly indicator.

10. The method according to claim 9, characterized in that, Obtaining the correlation between the state detection index and the candidate anomaly index within the test period includes: Obtain the first feature vector of the state detection index; Obtain the second feature vector of the candidate anomaly index; The similarity between the first feature vector and the second feature vector is determined as the relevance.

11. The method according to claim 8, characterized in that, Based on the abnormal time period, the time period to be measured for the target abnormal indicator is determined, including: Determine the preceding time period that precedes the start time of the abnormal time period; The abnormal period and the preceding period are determined as the period to be tested.

12. The method according to claim 7, characterized in that, Based on the state detection index corresponding to the abnormal stability state, the target abnormal index of the database product is determined, including: The state detection index is input into a machine learning model for prediction to obtain the target anomaly index. The machine learning model is trained based on state detection index samples and anomaly index samples of the database product. The state detection index samples are used to characterize the abnormal stability state of the database product, and the anomaly index samples are used to make the database product be in the abnormal stability state corresponding to the state detection index samples.

13. A method for detecting the status of a database product, characterized in that, Applied to a cloud server, on which a database product is deployed, the method includes: By calling the first interface, at least one query operation responded by the database product during the historical detection period is obtained, wherein the first interface includes a first parameter, and the parameter value of the first parameter is the at least one query operation; In the at least one query operation, at least one fluctuating query operation is identified, wherein the fluctuating query operation is a query in the at least one query operation whose response time exceeds a time threshold; Based on the at least one fluctuation query operation and the at least one query operation, a state detection index for the database product is determined, wherein the state detection index is used to characterize the stability state of the database product. If the state detection index is greater than the state detection index threshold, then the database product is determined to be in an abnormal stability state during the historical detection period. The abnormal stable state prompt information is output by calling the second interface, wherein the second interface includes a second parameter, and the parameter value of the second parameter is the prompt information of the abnormal stable state; The method further includes: determining the target response time of the query operation based on multiple historical response times within the time period prior to the historical detection period, wherein the multiple historical response times correspond to historical query operations, and the historical query operations and the query operation have the same query mode; and determining the time threshold corresponding to the query operation based on the target response time and the fluctuation upper limit multiple. The method further includes: determining the upper limit of fluctuation based on the target response time, wherein the upper limit of fluctuation is inversely proportional to the target response time of the query operation; Determining the time threshold corresponding to the query operation based on the target response time and the upper limit of fluctuation includes: determining the time threshold corresponding to the query operation based on the product between the upper limit of fluctuation and the target response time; The method further includes: determining a query pattern matched by the at least one query operation; and determining the time threshold based on the query pattern.

14. A status detection system for a database product, characterized in that, include: The client is used to upload status detection commands for database products; The cloud server is used to respond to the status detection command and obtain at least one query operation responded by the database product during the historical detection period; In the at least one query operation, at least one fluctuating query operation is identified, wherein the fluctuating query operation is a query in the at least one query operation whose response time exceeds a time threshold; based on the at least one fluctuating query operation and the at least one query operation, a status detection index of the database product is determined, wherein the status detection index is used to characterize the stability state of the database product; if the status detection index is greater than the status detection index threshold, it is determined that the database product is in an abnormal stability state during the historical detection period; and a prompt message of the abnormal stability state is returned to the client. The cloud server is further configured to: determine the target response time of the query operation based on multiple historical response times within the time period prior to the historical detection period, wherein the multiple historical response times correspond to historical query operations, and the historical query operations have the same query mode as the query operation; and determine the time threshold corresponding to the query operation based on the target response time and the fluctuation upper limit multiple. The cloud server is further configured to: determine the upper limit of fluctuation based on the target response time, wherein the upper limit of fluctuation is inversely proportional to the target response time of the query operation; The cloud server is also used to determine the time threshold corresponding to the query operation based on the target response time and the fluctuation limit multiplier through the following steps: determining the time threshold corresponding to the query operation based on the product between the fluctuation limit multiplier and the target response time; The cloud server is further configured to: determine the query pattern matched by the at least one query operation; and determine the time threshold based on the query pattern.

15. An electronic device, characterized in that, include: Memory, which stores executable programs; A processor for running the program, wherein the program, when running, performs the method according to any one of claims 1 to 13.

16. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored program, wherein, when the program is executed, it controls the device on which the storage medium is located to perform the method according to any one of claims 1 to 13.

17. A computer program product comprising computer instructions that, when executed by a processor, implement the method of any one of claims 1 to 13.

Images