Database request analysis method, system, electronic device and storage medium

Abstract

The present application discloses a database request analysis method, system, electronic device, and storage medium. The method comprises: obtaining a database request sequence initiated by a target user from a database audit log; screening a target database request sequence belonging to a target application from the database request sequence; and determining the target user's request behavior pattern based on the target database request sequence. Since the database requests obtained from the audit log include database requests from multiple applications, and the database requests from different applications are interspersed, the target database requests belonging to the target application are screened out from the obtained database requests, and then the target user's request behavior pattern is identified based on the target database requests, so as to reduce the impact of the interspersed situation of different applications on the request behavior pattern recognition result, thereby obtaining a more explanatory and accurate request behavior pattern recognition result, which is used to assist the target user in optimizing database access performance.

Description

Technical Field

[0001] The present application relates to the field of database technology, and in particular to a database request analysis method, system, electronic device, and storage medium. Background Art

[0002] By analyzing and mining data on a large number of database requests, we can help optimize database performance or accurately recommend relevant products to users. Therefore, data mining of database requests has many important meanings.

[0003] At present, although there are some solutions to achieve database autonomous services by analyzing database requests, the complexity of actual industrial data leads to low accuracy and low interpretability of the analysis results in practical applications. Summary of the Invention

[0004] The purpose of this application is to propose a database request analysis method, system, electronic device and storage medium to address the deficiencies of the above-mentioned existing technologies, and this purpose is achieved through the following technical solutions.

[0005] A first aspect of the present application provides a database request analysis method, the method comprising:

[0006] Obtain the database request sequence initiated by the target user from the database audit log;

[0007] Filtering a target database request sequence belonging to a target application from the database request sequence;

[0008] A request behavior pattern of the target user is determined according to the target database request sequence, where the request behavior pattern includes at least one sub-database request sequence.

[0009] A second aspect of the present application provides a database request analysis system, the system comprising:

[0010] Audit module, used to generate audit logs for the database containing user-initiated database requests;

[0011] The analysis module is used to execute the steps of the method described in the first aspect above.

[0012] The third aspect of the present application proposes an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the method described in the first aspect above.

[0013] The fourth aspect of the present application proposes a computer-readable storage medium having a computer program stored thereon, wherein the program is executed by a processor to implement the steps of the method described in the first aspect above.

[0014] Based on the database request analysis method and system described in the first and second aspects above, this application has at least the following beneficial effects or advantages:

[0015] Since the database audit log includes all operation records of users on the database, all database requests initiated by the target user can be obtained from the audit log. Since the obtained database requests include database requests initiated by users in multiple applications, database requests from different applications are interspersed. If the request behavior pattern is directly identified, it will affect the original request behavior pattern of the application, and it is impossible to obtain a meaningful and explainable request behavior pattern. Therefore, before performing request behavior pattern recognition, the target database requests belonging to the target application are filtered out from the obtained database requests, and then the request behavior pattern of the target user is identified based on the target database requests, so as to reduce the impact of the interspersal of different applications on the request behavior pattern recognition results, and obtain more explainable and accurate request behavior pattern recognition results to assist the target user in optimizing database access performance. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0017] Figure 1 This is a flow chart of an embodiment of a method for analyzing database requests according to an exemplary embodiment;

[0018] Figure 2 FIG1 is a schematic diagram of a target database request sequence screening process according to an exemplary embodiment;

[0019] Figure 3 The figure is a schematic diagram of a specific determination process of a request behavior pattern according to an exemplary embodiment;

[0020] Figure 4 Based on Figure 3 The illustrated embodiment shows an example diagram of obtaining a state transition probability matrix from a prefix tree;

[0021] Figure 5 1 is a schematic structural diagram of a database request analysis system according to an exemplary embodiment;

[0022] Figure 6 is a schematic diagram of a hardware structure of an electronic device according to an exemplary embodiment;

[0023] Figure 7 The figure is a schematic structural diagram of a storage medium according to an exemplary embodiment. DETAILED DESCRIPTION

[0024] Exemplary embodiments will be described in detail herein, with examples illustrated in the accompanying drawings. In the following description, when referring to the drawings, identical numerals in different figures represent identical or similar elements, unless otherwise indicated. The embodiments described in the following exemplary embodiments are not intended to represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.

[0025] The terms used in this application are for the purpose of describing specific embodiments only and are not intended to limit this application. As used in this application and the appended claims, the singular forms "a," "an," "the," and "the" are intended to include the plural forms, unless the context clearly indicates otherwise. It should also be understood that the term "and / or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

[0026] It should be understood that although the terms first, second, third, etc. may be used in this application to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from each other. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining".

[0027] All cloud service providers provide DAS (Database Autonomy Service), a cloud service that uses machine learning and expert experience to achieve database self-perception, self-repair, self-optimization, self-operation and maintenance, and self-security.

[0028] At present, although there are some solutions for data mining of large numbers of database requests for database autonomy, the mining results are of low accuracy and low interpretability due to the large number and complexity of database request data in actual industrial scenarios.

[0029] In order to solve the above technical problems, the present application proposes a database request analysis method. Since the audit log of the database includes all operation records of the user on the database, the full database requests of the target user can be obtained from the audit log. In actual application scenarios, since the obtained database requests include database requests initiated by the user in multiple applications, database requests from different applications are interspersed together. If the request behavior pattern is directly identified, the original request behavior pattern will be destroyed, and a meaningful and interpretable request behavior pattern cannot be obtained. Therefore, before performing request behavior pattern recognition, the target database requests belonging to the target application are screened out from the full database requests, and then the request behavior pattern of the target user is identified based on the target database requests, so as to reduce the impact of the interspersal of different applications on the request behavior pattern recognition results, thereby obtaining a more interpretable and accurate request behavior pattern recognition result to assist the target user in optimizing database access performance.

[0030] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiment of the present application will be clearly and completely described below in conjunction with the drawings in the embodiment of the present application.

[0031] Figure 1 This is a flowchart of an embodiment of a database request analysis method according to an exemplary embodiment of the present application, including the following steps:

[0032] Step 101: Obtain a database request sequence initiated by a target user from the audit log of the database.

[0033] The target user is authorized to operate the cloud service database and needs to optimize database access performance. Audit logs include all user operations on the database, including detailed data related to the database request initiated by the user and other operations beyond the database request.

[0034] Specifically, since the detailed data of a database request includes user information, operation statement text, execution information of the database request, etc., a database request sequence consisting of all database requests initiated by the target user can be obtained from the audit log based on the user information of the target user.

[0035] In step 101 , the database request sequence is a sequence formed by arranging the database requests in order of timestamps from front to back.

[0036] Alternatively, in order to correlate database anomalies with request behaviors, the database request sequence initiated by the target user within a target time range can be obtained from the audit log. The target time range is a time range in which the target user operates the database abnormally.

[0037] Step 102: Filter the target database request sequence belonging to the target application from the database request sequence.

[0038] The target application can be an application provided by the cloud service for operating a database. Cloud services typically offer a variety of different applications to implement different application scenarios. Users can initiate database requests by entering specific operation statements in the application's interface based on their actual needs. Alternatively, the target application can be a user's own application, which they use to operate the database and generate database requests.

[0039] It can be seen that the database request sequence obtained in step 101 will include database requests initiated by users in different application scenarios, resulting in database requests from different applications being interspersed. If the request behavior pattern is directly identified at this time, the original request behavior pattern of the application will be destroyed, and a meaningful and explainable request behavior pattern cannot be obtained. Therefore, step 102 reduces the impact of application interspersal by filtering out the target database requests belonging to the target application from the full database requests.

[0040] For the specific implementation process of step 102 for selecting the target database request sequence, see Figure 2 As shown, step 102 further includes:

[0041] Step 1021: Determine the text semantic feature vector of each database request in the database request sequence.

[0042] Step 1022: Obtain execution information of each database request.

[0043] Before performing target database request screening, various attribute information of the database request is extracted through steps 1021 and 1022. In an embodiment of the present application, the various attribute information of the database request includes the text semantic feature vector of the database request and the comprehensive attributes of the execution information, so as to enhance the screening effect.

[0044] The text semantic feature vector represents the attributes of the operation statement text of the database request, and the execution information represents the resource usage attributes of the database request.

[0045] Optionally, for the text semantic feature vector, the text semantic feature vector of the operation statement text can be extracted using a pre-trained language model. The language model can be a model with strong generalization ability, such as a BERT model, which converts the operation statement text into a multi-dimensional feature vector.

[0046] As for execution information, since the audit log records the detailed data of the database request, the execution information of the database request can be obtained from the detailed data.

[0047] Schematically, the execution information includes execution time, execution thread, number of scanned rows, etc.

[0048] It is worth noting that the embodiment of the present application does not specifically limit the execution order of step 1021 and step 1022.

[0049] Step 1023: Based on the text semantic feature vector and the execution information, the target database request belonging to the target application is filtered from the database request sequence.

[0050] Among them, the text semantic feature vector and execution information of the database request can reflect the usage scenario of the database request.

[0051] In an optional embodiment, the text semantic feature vector and execution information of each database request in the database request sequence can be input into a pre-trained classification model to obtain a prediction result, which is used to indicate whether the database request belongs to the target application, thereby determining the sequence composed of database requests whose prediction results are that they belong to the target application as the target database request sequence.

[0052] Among them, after using the classification model to learn the various attribute information of the database request belonging to the target application, the classification model can be used to predict whether the database request belongs to the target application based on the various attribute information of the input database request, and obtain accurate prediction results.

[0053] In another optional embodiment, considering that the large number of requests in a database request sequence may reduce screening efficiency, the database request sequence can be first divided into multiple database request groups. Then, for each database request group, the textual semantic feature vectors and execution information of each database request in the database request group are input into a classification model pre-trained for that database request group to obtain a prediction result. This prediction result is used to indicate whether the database request belongs to the target application. Finally, the sequence consisting of database requests predicted to belong to the target application is determined as the target database request sequence. In this way, by dividing the sequence into multiple groups and using a classification model for prediction for each group, the amount of prediction data for each classification model can be reduced, effectively improving screening efficiency.

[0054] Illustratively, the database request sequence may be divided according to the execution thread of each database request, or may be divided evenly. This application does not impose any specific limitation on the specific division method.

[0055] It should be noted that before using the classification model for prediction, the classification model needs to be trained. The training process of the classification model can be as follows: a training set containing database requests belonging to the target application and database requests that do not belong to the target application can be obtained, and the text semantic feature vectors and execution information of each database request in the training set can be obtained. The text semantic feature vectors and execution information of each database request in the training set can then be used to train the model to obtain the classification model.

[0056] The database requests belonging to the target application and the database requests not belonging to the target application can be marked with different tags respectively.

[0057] Step 103: Determine the target user's request behavior pattern based on the target database request sequence.

[0058] The request behavior pattern includes at least one sub-database request sequence, that is, the combination of each sub-database request sequence represents a behavior habit of a target user accessing the database.

[0059] It is worth noting that each sub-database request sequence included in the request behavior pattern is included in the target database request sequence.

[0060] Taking the database request being an SQL (Structured Query Language) request as an example, the SQL template identifier of the SQL request is used to represent the database request sequence. Assuming that the target database request sequence = abababadac, the determined request behavior pattern includes a sub-database request sequence = ba. It can be seen that "ba" is included in "abababadac", indicating that after the user uses the SQL template identified as b to initiate a database request, he will then use the SQL template identified as a to initiate a database request.

[0061] It should be noted that an SQL template is a general format for an SQL statement of a certain operation type. Typically, multiple SQL templates are provided for each operation type. By directly entering the corresponding parameter values ​​in the SQL template, a specific SQL statement can be generated.

[0062] In an optional embodiment, when performing request behavior pattern recognition, the request behavior pattern of the target user may be determined by determining the correlation probability between database requests in the target database request sequence, and then based on the correlation probability and the target database request sequence.

[0063] The correlation probability between database requests is the probability of database request association. Since database requests initiated by users have a certain correlation relationship, the correlation probability between database requests can be used to more accurately identify the request behavior pattern of the target database request sequence.

[0064] In an optional implementation, the correlation probability between database requests may be a state transition probability of a Markov model. The target database request sequence is mined using the Markov model to obtain a request behavior pattern. The specific implementation process may include:

[0065] Step 1031: Determine the state transition probability between database requests in the target database request sequence, and determine the target order of the Markov model according to the state transition probability.

[0066] Among them, when establishing the model, a reasonable order range of the Markov model can be set, and then according to the state transition probability, a target order can be selected within this order range that can better express the data without overfitting the model.

[0067] In a specific embodiment, for each order in a preset order range, a prefix tree of the target database request sequence is established according to the order, a corresponding state transition probability matrix is ​​determined according to the prefix tree, and a model cost value of the order is determined according to the state transition probability matrix, and then the order corresponding to the minimum model cost value is selected as the target order of the Markov model.

[0068] Among them, the order of the Markov model determines the height of the prefix tree. For example, in the 1st-order Markov model, since the future state only depends on the previous state, a prefix tree with a height of 2 is needed to calculate the state transition probability; in the 2nd-order Markov model, since the future state depends on the previous two states, a prefix tree with a height of 3 is needed to calculate the state transition probability.

[0069] Still taking the database request as an SQL request and using the SQL template identifier of the SQL request to represent the database request sequence as an example, assuming that the target database request sequence T = abababadac, see Figure 4 As shown, it is a prefix tree with a height of 2 established for the 1st-order Markov model. Figure 4 It can be seen that the prefix tree with a height of 2 has 2 layers of nodes, node n0 is the root node, node n1 indicates that a appears 5 times in the sequence, node n5 indicates that ab appears 3 times in the sequence, and so on.

[0070] Specifically, in order to reduce calculations and improve the generalization ability of the Markov model, the state transition probability matrix can be calculated according to the MDL (Minimum Description Length) principle of the pruning model. That is, the size of the state transition probability matrix is ​​first determined according to the number of request types contained in the target database request sequence and the order of the Markov model, and then the state transition probability of each element in the matrix is ​​calculated using the established prefix tree.

[0071] Among them, the size of the state transfer matrix is ​​|T| 阶数 ×|T|, |T| is the number of request types in the target database request sequence.

[0072] Furthermore, in the process of calculating the state transition probability using the MDL principle, a threshold τ = 1 / |T| is first determined, and then the method of using the threshold τ to judge the state transition probability is: (a) if Prob(x|seq) is greater than or equal to the threshold τ, then the state transition probability Prob(x|seq) is equal to the calculated value; (b) if the remaining state transition probabilities do not meet condition (a), then the remaining state transition probabilities are considered to be uniformly distributed.

[0073] Continue to see above Figure 4 As shown, the number of request types in the target database request sequence |T|=4, which includes four types: SQL template a, SQL template b, SQL template c, and SQL template d. Therefore, the size of the state transition probability matrix is ​​|T| 阶数 ×|T|=4 1 ×4. Threshold τ=1 / |T|=1 / 4. Taking the first column of the state transition probability matrix corresponding to the leftmost branch of the prefix tree as an example, Prob(b|a)=val(n5) / val(n1)=3 / 5>1 / 4, Prob(c|a)=val(n6) / val(n1)=1 / 5<1 / 4, Prob(d|a)=val(n7) / val(n1)=1 / 5<1 / 4, Prob(a|a)=0 / val(n1)=0<1 / 4. Since the three state transition probabilities Prob(c|a), Prob(d|a), and Prob(a|a) are all less than the threshold τ, these three state transition probabilities are uniformly distributed, and the specific probability values ​​should be: (1-Prob(b|a)) / 3=2 / 15. The state transition probabilities of other columns are also calculated according to the above principle, and the final result is as follows Figure 4 The state transition probability matrix shown.

[0074] Furthermore, the model cost is calculated based on the MDL principle of the pruning model:

[0075] cost(x,M θ(k))=2log k+1+2log m+1+m((k+1)log|T|+2log n)-log Prob(x|M θ(k) )

[0076] Where k is the order of the Markov model; m is the number of state transition probabilities greater than the threshold τ in the state transition probability matrix; |T| is the number of request types in the sequence; n is the length of the sequence; Prob(x|M θ(k) ) is the probability value obtained by multiplying the state transition probabilities of the target database request sequence. Taking the first-order Markov model as an example, as mentioned above Figure 4 As shown, the state transition probability of the target database request sequence is multiplied to obtain Prob(x|M θ(1) ):

[0077] Prob(x|M θ(1) )

[0078] =Prob(a)×Prob(b|a)×Prob(a|b)×Prob(b|a)×Prob(a|b)×Prob(b|a)×Prob(a|b)×Prob(d|a)×Prob(a|d)×Prob(c|a)

[0079] Step 1032: Analyze the target database request using the target order Markov model to obtain the target user's request behavior pattern.

[0080] In specific implementation, the request behavior pattern includes at least one sub-database request sequence. The principle of analyzing it as a sub-database request sequence is: taking the k-order Markov model as an example, a threshold θ for selecting a sub-database request sequence can be pre-set. If the state transition probability Prob(s|c1...ck)≥θ, then c1...cks is considered to be a sub-database request sequence, and if the state transition probability Prob(s|c1...ck)<θ, then c1...ck is considered to be a sub-database request sequence.

[0081] See above Figure 4As shown, taking the Markov model of order k=1 as an example, the threshold θ=0.7 is pre-set, and a sub-database request sequence is defined as a pattern. In the target database request sequence T=abababadac, the pattern is first initialized to the first one in the sequence T: a, and then Prob(T[2]T[1])=Prob(b|a)=3 / 5<0.7 is calculated, so the first pattern is a; then the next pattern is initialized to b, and Prob(T[3]T[2])=Prob(a|b)=1>0.7 is calculated, and then the pattern is updated to ba, and Prob(T [4]T[3])=Prob(b|a)=3 / 5<0.7, so ba is the second pattern; initialize the next pattern to b, calculate Prob(T[5]T[4])=Prob(b|a)=3 / 5<0.7, Prob(T[6]T[5])=Prob(b|a)=3 / 5<0.7, then update the pattern to ba, calculate Prob(T[7]T[6])=Prob(a|b)=1>0.7, so ba is the third pattern; continue the calculation to get the pattern of sequence T is {a, ba, ba, ba, da, c}.

[0082] It's important to note that a long and complex sequence of target database requests may contain many recurring patterns. For such cases, loop detection can be performed and patterns can be merged for identical loops. For example, the three "ba"s in the pattern {a, ba, ba, ba, da, c} of sequence T can be merged into a single pattern, resulting in the final pattern of sequence T being {a, ba, da, c}.

[0083] It can be understood that the above-mentioned scheme of using the state transition probability of the Markov model to mine request behavior patterns is only a specific example. Other types of related probability methods of request behavior pattern mining are also within the scope of protection of this application. For example, the association probability of the directed graph or undirected graph of the probabilistic graphical model can also be used to mine request behavior patterns.

[0084] It should be noted that after executing step 103, the request template used by each database request in each sub-database request sequence contained in the request behavior pattern can be obtained, and optimization suggestions can be determined based on the operation type of each database request in each sub-database request sequence contained in the request behavior pattern. Then, a visual interface including the request behavior pattern, the obtained request template and the optimization suggestions can be output for users to optimize database performance.

[0085] For example, an optimization suggestion for parallel execution can be given for database requests of the same operation type in a sub-database request sequence.

[0086] It should be further explained that, for the request behavior pattern analysis solution of steps 101 to 103 , the analysis results may be verified to prove the accuracy of the analysis solution of steps 101 to 103 .

[0087] Optionally, you can obtain the timestamp range to which the database request sequence belongs, and obtain a pre-collected application log generated by the target user and within the timestamp range. The application log records the database request sequence initiated by the target user and belonging to the target application, and then verify the correctness of the request behavior pattern based on the application log.

[0088] Among them, the collection of application logs is specifically used for verification of analysis results. In actual industrial scenarios, the user's database requests will not be recorded during the operation of the cloud service application.

[0089] Specifically, in the process of verifying the correctness of the request behavior pattern based on the application log, for each sub-database request sequence included in the request behavior pattern, the sub-database request sequence can be determined to be correct based on the combination of the application log containing the sub-database request sequence, and the sub-database request sequence can be determined to be incorrect based on the combination of the application log not containing the sub-database request sequence. Therefore, based on these sub-database request sequences that have been verified as correct or incorrect, the accuracy of the solution of the embodiment of the present application can be obtained.

[0090] At this point, the above is completed Figure 1 As shown in the analysis process, since the database audit log includes all operation records of the user on the database, the full database request of the target user can be obtained from the audit log. Since the full database request obtained includes database requests initiated by the user in multiple applications, database requests from different applications are interspersed together. If the request behavior pattern is directly identified, it will affect the original request behavior pattern of the application, and it is impossible to obtain a meaningful and explainable request behavior pattern. Therefore, before performing request behavior pattern recognition, the target database requests belonging to the target application are filtered out from the full database requests, and then the request behavior pattern of the target user is identified based on the target database requests, so as to reduce the impact of the interspersal of different applications on the request behavior pattern recognition results, and obtain a more explainable and accurate request behavior pattern recognition result to assist the target user in optimizing database access performance.

[0091] Corresponding to the aforementioned embodiment of the database request analysis method, the present application also provides an embodiment of a database request analysis system.

[0092] Figure 5 This is a schematic diagram of a database request analysis system according to an exemplary embodiment of the present application. The system is used to execute the database request analysis method provided in any of the above embodiments, such as Figure 5 As shown, the database request analysis system includes:

[0093] Audit module 510, used to generate audit logs for the database containing user-initiated database requests;

[0094] The analysis module 520 is configured to execute the database request analysis method described above.

[0095] The implementation process of the functions and effects of each module in the above system is specifically described in the implementation process of the corresponding steps in the above method, which will not be repeated here.

[0096] For the system embodiment, since it basically corresponds to the method embodiment, the relevant parts can be referred to the partial description of the method embodiment. The system embodiment described above is only illustrative, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution of this application. A person of ordinary skill in the art can understand and implement it without paying any creative work.

[0097] An embodiment of the present application further provides an electronic device corresponding to the database request analysis method provided in the aforementioned embodiment, to execute the aforementioned database request analysis method.

[0098] Figure 6 This is a hardware structure diagram of an electronic device according to an exemplary embodiment of the present application. The electronic device includes: a communication interface 601, a processor 602, a memory 603, and a bus 604. The communication interface 601, the processor 602, and the memory 603 communicate with each other via the bus 604. The processor 602 can execute the database request analysis method described above by reading and executing machine-executable instructions corresponding to the control logic of the database request analysis method in the memory 603. The specific content of this method is described in the above embodiment and will not be repeated here.

[0099] The memory 603 mentioned in this application can be any electronic, magnetic, optical or other physical storage device, which can contain stored information, such as executable instructions, data, etc. Specifically, the memory 603 can be RAM (Random Access Memory), flash memory, a storage drive (such as a hard disk drive), any type of storage disk (such as an optical disk, DVD, etc.), or a similar storage medium, or a combination thereof. The communication connection between the system network element and at least one other network element is realized through at least one communication interface 601 (which can be wired or wireless), and the Internet, wide area network, local area network, metropolitan area network, etc. can be used.

[0100] The bus 604 may be an ISA bus, a PCI bus, or an EISA bus, etc. The bus may be divided into an address bus, a data bus, a control bus, etc. The memory 603 is used to store programs, and the processor 602 executes the programs after receiving an execution instruction.

[0101] The processor 602 may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method can be completed by an integrated logic circuit of the hardware in the processor 602 or an instruction in the form of software. The above-mentioned processor 602 can be a general-purpose processor, including a network processor (NP), a digital signal processor (DSP), an application-specific integrated circuit (ASIC), an off-the-shelf programmable gate array (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, etc. The various methods, steps and logic block diagrams disclosed in the embodiments of the present application can be implemented or executed. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc. The steps of the method disclosed in conjunction with the embodiments of the present application can be directly embodied as a hardware decoding processor for execution, or can be completed by a combination of hardware and software modules in the decoding processor.

[0102] The electronic device provided in the embodiment of the present application and the database request analysis method provided in the embodiment of the present application are based on the same inventive concept and have the same beneficial effects as the methods adopted, operated or implemented by them.

[0103] The present application also provides a computer-readable storage medium corresponding to the database request analysis method provided in the above embodiment. Figure 7 As shown, the computer-readable storage medium is a CD 30 on which a computer program (ie, a program product) is stored. When the computer program is run by a processor, the database request analysis method provided by any of the aforementioned embodiments will be executed.

[0104] It should be noted that examples of the computer-readable storage medium may also include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other optical or magnetic storage media, which are not listed here one by one.

[0105] The computer-readable storage medium provided in the above-mentioned embodiments of the present application and the database request analysis method provided in the embodiments of the present application are based on the same inventive concept and have the same beneficial effects as the methods adopted, run or implemented by the application programs stored therein.

[0106] Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the present application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The description and examples are to be considered as exemplary only, and the true scope and spirit of the present application are indicated by the following claims.

[0107] It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

[0108] The above description is only a preferred embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application shall be included in the scope of protection of the present application.

Claims

1. A database request analysis method, characterized in that: The method comprises: Obtain the database request sequence initiated by the target user from the database audit log; Filtering a target database request sequence belonging to a target application from the database request sequence; Determining a request behavior pattern of the target user according to the target database request sequence, wherein the request behavior pattern includes at least one sub-database request sequence; The step of screening the target database request sequence belonging to the target application from the database request sequence includes: Determining a text semantic feature vector of each database request in the database request sequence; Obtaining execution information of each database request; Filtering target database requests belonging to a target application from the database request sequence based on the text semantic feature vector and the execution information; The step of screening a target database request sequence belonging to a target application from the database request sequence based on the text semantic feature vector and the execution information includes: Inputting the text semantic feature vector and execution information of each database request in the database request sequence into a pre-trained classification model to obtain a prediction result; or dividing the database request sequence into a plurality of database request groups, and for each database request group, inputting the text semantic feature vector and execution information of each database request in the database request group into a pre-trained classification model for the database request group to obtain a prediction result; The prediction result is used to indicate whether the database request belongs to the target application; and a sequence of database requests whose prediction results indicate that they belong to the target application is determined as a target database request sequence.

2. The method according to claim 1, characterized in that The method also includes a classification model training process: Obtaining a training set including database requests belonging to a target application and database requests not belonging to the target application; Obtaining text semantic feature vectors and execution information of each database request in the training set; Model training is performed using the text semantic feature vectors and execution information of each database request in the training set to obtain the classification model.

3. The method according to claim 1 or 2, characterized in that Determining the request behavior pattern of the target user according to the target database request sequence includes: determining correlation probabilities between database requests in the target database request sequence; Based on the correlation probability and the target database request sequence, a request behavior pattern of the target user is determined.

4. The method according to claim 1 or 2, characterized in that After determining the request behavior pattern of the target user according to the target database request sequence, the method further includes: Obtain the timestamp range to which the database request sequence belongs; Acquire a pre-collected application log generated by the target user and within the timestamp range; the application log records a sequence of database requests belonging to the target application initiated by the target user; The correctness of the request behavior pattern is verified based on the application log.

5. The method according to claim 4, characterized in that The correctness verification of the request behavior pattern according to the application log includes: For each sub-database request sequence included in the request behavior pattern, determining that the sub-database request sequence is correct based on a combination of the sub-database request sequence included in the application log; According to the fact that the application log does not include the combination form of the sub-database request sequence, it is determined that the sub-database request sequence is incorrect.

6. The method according to claim 1 or 2, characterized in that After determining the request behavior pattern of the target user according to the target database request sequence, the method further includes: Obtaining a request template used by each database request in each sub-database request sequence included in the request behavior pattern; Determining optimization suggestions based on the operation type of each database request in each sub-database request sequence included in the request behavior pattern; The output includes a visualization interface of the request behavior pattern, the obtained request template, and the optimization suggestions.

7. The method according to claim 1, characterized in that The step of obtaining the database request sequence of the target user from the audit log of the database includes: Obtain a sequence of database requests initiated by a target user within a target time range from the audit log of the database; the target time range is the time range during which abnormalities in the target user's database operations occur.

8. A database request analysis system, characterized in that: The system comprises: Audit module, used to generate audit logs for the database containing user-initiated database requests; An analysis module, configured to execute the steps of the method according to any one of claims 1 to 7.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: The processor executes the program to implement the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: The program is executed by a processor to implement the steps of the method according to any one of claims 1 to 7.

Images