Request processing method and apparatus

Abstract

This specification provides a request processing method and apparatus. The request processing method includes: receiving a query request submitted to a target database; determining a target rule set corresponding to the target resource group of the query request based on a preset mapping relationship between resource groups and rule sets; determining a target rule matching the query request in the target rule set, and determining a query control strategy corresponding to the target rule; updating the query request by executing the query control strategy, and accessing the target database in response to the updated query request.

Description

Technical Field

[0001] This specification relates to the field of database technology, and in particular to request processing methods and apparatus. Background Technology

[0002] With the development of internet technology, more and more information is becoming digitized. To facilitate data maintenance, service providers are increasingly integrating various database servers into a unified database. This is partly due to considerations of service comprehensiveness; a unified database is easier to maintain and use, and also provides convenient multi-source data analysis, helping to uncover more value from the data. On the other hand, from a resource utilization perspective, a shared database system often means lower costs compared to multiple database systems. Under this trend, shared databases often run various types of workloads. These different workloads are applied to different scenarios, providing corresponding query services to users. However, without workload limitations, other concurrent queries in the database system will have to wait for running queries to release resources before they can be executed, significantly impacting the overall performance of the database system. Therefore, an effective solution is urgently needed to address these issues. Summary of the Invention

[0003] In view of the above, embodiments of this specification provide a request processing method. One or more embodiments of this specification also relate to a request processing apparatus, a computing device, a computer-readable storage medium, and a computer program, to address the technical deficiencies existing in the prior art.

[0004] According to a first aspect of the embodiments of this specification, a request processing method is provided, including:

[0005] Receive query requests submitted for the target database;

[0006] Based on the preset mapping relationship between resource groups and rule sets, determine the target rule set corresponding to the target resource group of the query request;

[0007] Determine the target rule that matches the query request from the target rule set, and determine the query control strategy corresponding to the target rule;

[0008] The query request is updated by executing the query control strategy, and the target database is accessed in response to the updated query request.

[0009] According to a second aspect of the embodiments of this specification, a request processing apparatus is provided, comprising:

[0010] The receiving module is configured to receive query requests submitted to the target database;

[0011] The determination module is configured to determine the target rule set corresponding to the target resource group of the query request based on a preset mapping relationship between resource groups and rule sets.

[0012] The matching module is configured to determine the target rule that matches the query request in the target rule set, and to determine the query control strategy corresponding to the target rule;

[0013] The update module is configured to update the query request by executing the query control strategy, and access the target database in response to the updated query request.

[0014] According to a third aspect of the embodiments of this specification, a computing device is provided, comprising:

[0015] Memory and processor;

[0016] The memory is used to store computer-executable instructions, and the processor is used to implement the steps of any of the above-described request processing methods when executing the computer-executable instructions.

[0017] According to a fourth aspect of the embodiments of this specification, a computer-readable storage medium is provided that stores computer-executable instructions that, when executed by a processor, implement the steps of the above-described request processing method.

[0018] According to a fifth aspect of the embodiments of this specification, a computer program is provided, wherein when the computer program is executed in a computer, it causes the computer to perform the steps of the above-described request processing method.

[0019] The request processing method provided in this specification aims to improve resource utilization and reduce query overhead. Upon receiving a query request for a target database, it determines the target resource group for the query request based on a pre-defined mapping relationship between resource groups and rule sets. It also determines the target rule set associated with the target resource group, thereby reducing the number of rule matches and saving resource consumption. Next, it identifies the target rule for matching the query request from the target rule set and determines the corresponding query control strategy. Finally, it updates the query request by executing the query control strategy to access the target database based on the updated query request. This method effectively reduces the computational load of matching rules and improves rule matching speed, enabling rapid response to query requests accessing the target database. Attached Figure Description

[0020] Figure 1This is a flowchart illustrating a request processing method provided in one embodiment of this specification;

[0021] Figure 2 This is a schematic diagram of rule updating in a request processing method provided in one embodiment of this specification;

[0022] Figure 3 This is a flowchart illustrating the processing procedure of a request processing method provided in one embodiment of this specification;

[0023] Figure 4 This is a schematic diagram of the structure of a request processing device provided in one embodiment of this specification;

[0024] Figure 5 This is a structural block diagram of a computing device provided in one embodiment of this specification. Detailed Implementation

[0025] Many specific details are set forth in the following description to provide a full understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this specification. Therefore, this specification is not limited to the specific implementations disclosed below.

[0026] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of this specification. The singular forms “a,” “described,” and “the” as used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

[0027] It should be understood that although the terms first, second, etc., may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first may also be referred to as second without departing from the scope of one or more embodiments of this specification, and similarly, second may also be referred to as first. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to a determination."

[0028] First, the terms and concepts used in one or more embodiments of this specification will be explained.

[0029] Workload: A type of query request in a database that shares some common characteristics. These query requests can be abstracted into a category of Workload, such as request source query requests, priority query requests, performance target query requests, etc. Query requests can be distinguished into different types of Workloads by customizing their characteristics.

[0030] Workload manager: A core component of a database, it uses various strategies to manage and control the query load of the database, thereby meeting query performance metrics as much as possible and making full use of system resources.

[0031] Action: The control methods provided by the workload manager, including kill log resubmit, etc. Different Actions express different control operations on query requests.

[0032] OLTP (On-Line Transaction Processing) is also known as transaction-oriented processing. Its basic characteristic is that user data received by the front end can be immediately transmitted to the computing center for processing and the processing results can be given in a very short time. It is one of the ways to respond quickly to user operations.

[0033] OLAP (Online Analytical Processing) enables analysts to quickly, consistently, and interactively view information from various perspectives to achieve a deeper understanding of data. It features FASMI (Fast Analysis of Shared Multidimensional Information), where F stands for Fast, meaning the system can respond to most user analysis requests within seconds; A stands for Analyzability, meaning users can define new specialized calculations without programming, incorporate them as part of the analysis, and receive reports in the desired manner; M stands for Multidimensional, meaning it provides multidimensional views and analyses of the data; and I stands for Information, meaning it allows for timely access to information and the management of large volumes of information.

[0034] This specification provides a request processing method, and also relates to a request processing apparatus, a computing device, a computer-readable storage medium, and a computer program, which will be described in detail in the following embodiments.

[0035] In practical applications, shared databases, due to their integration of multiple data sources, need to run various types of workloads to respond to front-end query demands. For example, OLTP queries are characterized by low resource overhead and short execution time, but place high demands on overall system performance; OLAP queries, on the other hand, are often very complex, resource-intensive, and time-consuming, but offer higher accuracy. Different types of workloads often have different performance requirements from users. Within the database, concurrently running queries often share the database system's CPU, memory, and disk I / O resources. Some types of queries can consume significant system resources. If the execution of these workloads is not restricted, other concurrent queries in the database system will have to wait for the running query to release its resources before they can execute, impacting the overall performance of the database system.

[0036] In view of this, the request processing method provided in this specification, in order to improve resource utilization and reduce query overhead, can, upon receiving a query request submitted to the target database, determine the target resource group of the query request based on a preset mapping relationship between resource groups and rule sets, and determine the target rule set associated with the target resource group, thereby reducing the number of rule matches and saving resource consumption. Then, the target rule matching the query request is determined from the target rule set, and the corresponding query control strategy is determined. Finally, the query request is updated by executing the query control strategy to access the target database according to the updated query request. This achieves the determination of query matching rules by matching target rules, and the restriction of query requests according to the control of these rules, effectively reducing the computational load of matching rules and improving the rule matching speed, so as to quickly complete the response of query request access to the target database.

[0037] Figure 1 A flowchart of a request processing method according to an embodiment of this specification is shown, which specifically includes the following steps.

[0038] Step S102: Receive a query request submitted for the target database.

[0039] The request processing method provided in this specification is applied to the Workload Manager. After receiving a query request, the Workload Manager can match a set of rules to the resource group pointed to by the query request, and filter out the control corresponding to the target rule from the set to restrict the query request, thereby effectively improving resource utilization and query efficiency.

[0040] Based on this, the target database specifically refers to a shared database that integrates at least one type of data, and this database corresponds to at least one resource group. The resources of this resource group are used to respond to query requests and access the target database. Specifically, the at least one resource group corresponding to the target database refers to a set of resources that provide query resources, including but not limited to CPU resources, memory resources, and disk resources. Correspondingly, a query request specifically refers to a query request that needs to access the target database at the current moment. This query request needs to access the data contained in the target database to perform downstream processing based on the access results. For example, if the target database stores transaction data, a query request could be a request to access transaction failure data between time T1 and T2; or, if the target database stores game data, a query request could be a request to access player data who is not logged into the game.

[0041] In practical applications, considering that the target database stores data from various service scenarios, the query requests submitted to the target database at the same time may be of multiple types, and different types of query requests will access different data in the database. For ease of description, this embodiment only uses the process of a query request accessing the target database as an example to illustrate the request processing method provided in this specification. Descriptions of other scenarios can refer to the same or corresponding descriptions in this embodiment, and will not be elaborated upon here.

[0042] Furthermore, considering the complexity of the service dimensions involved in the target database, resulting in a large number of associated rules, in order to reduce the computational load and resource consumption when matching rules, the matched rules can be pruned based on the query stage information of the query request to reduce the matching time wasted by useless rules. In this embodiment, the specific implementation method is as follows:

[0043] Determine the query stage information corresponding to the query request; accordingly, determining the target rule set corresponding to the target resource group of the query request based on the preset mapping relationship between resource groups and rule sets includes: determining the initial rule set corresponding to the target resource group of the query request based on the preset mapping relationship between resource groups and rule sets; filtering rules associated with the query stage information from the initial rule set to construct the target rule set.

[0044] Specifically, query stage information refers to the information corresponding to the lifecycle of a query request. Different lifecycles of a query request will be matched with different rules to update the query request, enabling finer-grained rule division according to the lifecycle, thereby reducing the computational resources consumed when matching rules. The query stage information corresponding to the query request, i.e., the lifecycle, can be determined by querying the code describing the lifecycle at the code level after receiving the query request, based on the query results. This helps reduce the number of rules matched later. The query stage information includes at least one of the following: before queuing, during queuing, before generating and executing the task, before task release, before scheduling, and during task execution. The rules that can be executed in different query stages are pre-defined; therefore, after receiving the query request, the matched rules can be pruned by determining the query stage information.

[0045] Correspondingly, the mapping relationship between resource groups and rule sets specifically refers to recording the pre-defined association relationships of rule sets for each resource group. This is used during the rule matching phase to direct the query request to the target resource group. By reading this mapping relationship, the initial rule set corresponding to the target resource group can be determined. Specifically, the initial rule set refers to the set of all rules associated with the target resource group; correspondingly, the target rule set refers to the set of rules in the initial rule set that match the current query.

[0046] Based on this, upon receiving a query request from the associated target database, the current lifecycle of the query request can be determined by querying the code of the associated query request. Then, based on the target resource group pointed to by the query request and the mapping relationship between the resource group and the rule set, the initial rule set for the associated query request is determined. Then, the initial resource set is pruned according to the generation cycle, that is, rules with an index relationship with the current lifecycle of the query request are selected from the initial resource set to form the target rule set, which can be used to update the query request in the future.

[0047] In other words, to improve rule matching efficiency, the rule matching time can be shortened by reducing the number of matching rules. This is known as rule pruning. The workload manager divides the rules stored in memory into two storage spaces: query and cluster. Each storage space pre-creates indexes based on lifecycle and resource group, effectively pruning most invalid rules during the rule matching phase. Specifically, it determines the initial set of rules corresponding to the target resource group pointed to by the query request, and then filters the initial set of rules according to the indexes between lifecycle and resource group to construct the target set of rules based on the filtering results.

[0048] In summary, by pruning the initial rule set in conjunction with query phase information, the number of rules matching a query request can be effectively reduced, thereby improving query efficiency and enabling a faster response time for query requests.

[0049] Furthermore, considering that the data stored in the target database is updated in real time, and as the data increases, in order to ensure that query requests in any scenario can be responded to by accessing the target database, the rules of the target database will be updated according to changes in the developers. This allows for matching corresponding query requests to access the target database during the application phase. In this embodiment, the specific implementation method is as follows: steps S1022 to S1028:

[0050] Step S1022: Receive a rule change instruction carrying rule description information.

[0051] Step S1024: Determine the metadata database associated with the target database and write the rule description information into the metadata database.

[0052] Step S1026: In the rule change node of the target database, read the rule description information from the meta database.

[0053] Step S1028: Transform the rule description information according to the preset rule structure, and update the mapping relationship between the resource group and the rule set according to the transformation result.

[0054] Specifically, rule description information refers to the descriptive information provided by developers when modifying rules associated with the target database, adding new rules, or deleting existing rules. This text-based description simplifies rule changes for developers. Correspondingly, rule change instructions are commands submitted for modifying, deleting, or adding rules. These can be commands to add, delete, or modify rules. The metadata database is a relational database that records metadata associated with the target database. This metadata describes data attributes and supports functions such as indicating storage location, historical data, resource lookup, and file records. In other words, the metadata database is a repository for organizing, storing, and managing data according to a data structure.

[0055] Correspondingly, a rule change node specifically refers to a node that can transform and process the rule description information after it has been written into the metadata database. This node is used to determine the rules that need to be changed based on the rule description information, and to process the corresponding rules in response to rule change instructions.

[0056] Based on this, when a user needs to change the rules, the system can receive a rule change command uploaded by the user, carrying rule description information. At this point, the metadata database associated with the target database can be identified, and the rule description information is then persisted to the metadata database. Upon successful writing, the rule change node can be triggered to execute the rule change process. In other words, at the rule change node in the target database, the successfully persisted rule description information can be read from the metadata database. Then, the rule description information is transformed according to a preset rule structure. Based on the transformation result, the text-formatted rules are converted into a format matching the rule structure to obtain the rules that need to be changed. Since the rules in the target database have changed, to ensure that the changed rules are updated promptly and do not affect the application phase, the mapping relationship between resource groups and rule sets can be updated based on the transformation result. This allows subsequent request processing operations to be completed based on the updated mapping relationship.

[0057] In practice, after submitting a rule change command through the target database's operations and maintenance interface, the user can first clarify their change requirements. Then, the rule description information carried in the rule is persisted to the metadata database. Simultaneously, the workload manager will import the rules that need to be changed from the metadata database. In memory, the rule description information will be transformed according to the rule structure to obtain the rule object, i.e., the rule that needs to be changed. Finally, the mapping relationship between resource groups and rule sets will be updated based on the changed rules.

[0058] In practical applications, users will send rule change instructions via HTTP requests on the front end. The workload manager of the target database will receive the instructions through a RESTful interface. At this point, the rule description information is persisted to the metadata database. After successful persistence, the rule change method of the workload manager is called to re-import the rules that need to be changed from the metadata database. During the import process, the rules are converted into a rule description that meets the current usage scenario. Afterwards, the rules are indexed or updated to facilitate subsequent use.

[0059] In summary, during the rule change phase, by using a preset rule structure to transform the rule description information, the rules that need to be changed can meet the rule format of the target database, thereby standardizing rule management, making rule maintenance more convenient, and making the rules involved in the target database more standardized.

[0060] Based on this, considering that the rule that needs to be changed is the rule that accesses the target database through a related query request, in order to convert the text description format rule into a preset rule structure format during the conversion stage, this can be done by creating a rule template. In this embodiment, the specific implementation method is as follows:

[0061] Create a rule template according to a preset rule structure and determine the rule structure dimension associated with the rule template; extract rule sub-description information from the rule description information according to the rule structure dimension, and add the rule sub-description information to the rule template to obtain the rule to be written; update the mapping relationship between the resource group and the rule set according to the rule to be written.

[0062] Specifically, the preset rule structure refers to the structure that must be followed when adding rules to the target database; that is, any rule must exist according to the preset rule structure. Correspondingly, the rule structure dimension refers to the dimension corresponding to different types of attributes in the rule structure; correspondingly, the rule sub-description information refers to the description information corresponding to different rule structure dimensions in the rule description information, and its expression form is text type; correspondingly, the rule to be written refers to the rule that needs to be changed for the target database.

[0063] Based on this, the rule structure dimension includes at least one of the following: rule attribute dimension, rule state dimension, rule control dimension, and rule time dimension; correspondingly, the rule description information includes at least one of the following: rule attribute description information, rule state description information, rule control description information, and rule time description information.

[0064] Specifically, the rule attribute dimension refers to the dimension of the basic attribute information of the corresponding rule, which includes, but is not limited to, rule identifier, name, owner, description, and type. Correspondingly, the rule status dimension refers to the dimension of the status attribute information of the corresponding rule; this includes, but is not limited to, rule priority, version, effective resource group, and startup status. Correspondingly, the rule control dimension refers to the dimension of the control attribute information of the corresponding rule; this includes, but is not limited to, rule predicate logic and control strategy. Correspondingly, the rule time dimension refers to the dimension of the time attribute information of the corresponding rule; this includes, but is not limited to, rule creation time and modification time.

[0065] Correspondingly, the rule attribute description information is the basic attribute information of the rule in text format; the rule status description information is the rule status attribute information in text format; the rule control description information is the rule control attribute information in text format; and the rule time description information is the rule time attribute information in text format.

[0066] Based on this, when updating the mapping relationship according to the changed rules, a rule template can be created according to the preset rules, and the rule structure dimension associated with the rule template can be determined. This allows the rule sub-description information to be extracted from the rule description information according to the rule structure dimension, and then the rule sub-description information can be added to the rule template to obtain the rule to be written. Finally, the mapping relationship between the resource group and the rule set can be updated according to the rule to be written. This allows the application phase to be affected by the rule to be written, so as to respond to query requests more accurately.

[0067] In practical applications, the rule format defined in the target database can be represented using JSON, including various attributes. Taking a single rule as an example, it can include the following attributes: rule unique identifier, rule name, rule creator, rule description information, rule type, rule priority, rule version information, resource group in which the rule is effective, whether the rule is enabled, whether the rule is a system content rule, rule creation time, rule modification time, rule effective time, rule expiration time, the last modifier of the rule, the rule's predicate logic, the rule's action, and the rule's action_atrrs, etc.

[0068] The rule names facilitate user differentiation; rule creators can easily identify and communicate with the rule creator in case of issues, ensuring rule maintenance; rule descriptions help understand the rule's purpose during rule changes; rule types differentiate between rules targeting clusters or queries, aiding in pruning; rule priorities ensure only the highest-priority rule takes effect when multiple rules meet execution conditions; and rule version information follows the workload manager version to prevent compatibility issues. The resource group to which the rule applies specifies the group; the predicate logic represents the rule's conditions, defining the conditions under which the rule can execute; the rule's action is the control action taken after the rule meets its conditions, such as kill or log, primarily relying on control mechanisms provided by the database system; and the rule's `action_atrrs` assigns attributes to the action, such as configuring the target priority level for actions that adjust priority.

[0069] In practice, the workload manager will automatically calculate the lifecycle of a rule based on the attributes defined in the rule definition and the action executed, and then bind the associated lifecycle to ensure that the rule can only take effect when the query matches the lifecycle in which it is located.

[0070] It should be noted that the predicate logic representing the conditions of the rules allows for user-input constant values ​​on both sides of the conditions, as well as performance metrics from the system level or attributes of the query itself, providing ample flexibility for users. To reduce learning costs and improve rule matching performance, restrictions can be preset for the target database. Specifically, the predicate logic can be configured to support simplified CNF (conjunctive normal form) expressions, with conditions linked by AND. Supported computer-recognizable operators include >, >=, <, <=, =, and !. =, equal, not_equal; where equal / not_equal are used for string comparison, and other operators are used for numerical comparison; the left value of the expression has the following cases: (1) Take the value from the metric; similar to ${metric.XX}, where XX is a string representing the metric name, and the type of the metric value may be long / double; (2) Take the value from the session; similar to ${session.XX}, where XX is a string representing the query attribute name, and the type of the attribute value can be string or long / double. The specific type can be inferred by combining the operator and the right value during calculation;

[0071] The right value of the expression can also be one of the following: (1) a value from the metric; (2) a value from the session; (3) a constant filled in by the user. The constant may be a string or a number. The specific type needs to be inferred by combining the operator and the left value.

[0072] Based on this, if the operator is a string type (equal / not_equal): both sides are compared as strings; in this case, the left value needs to be retrieved from the session, while the right value cannot be a metric. If the operator is a numeric type: one case is that both the left and right values ​​are metrics: they are compared as numbers, with type upcasting (long -> double); the second case is that only one side is a metric, and the other side is a session value or constant: the other side is converted to long or double according to the type of the metric; the third case is that neither side is a metric (e.g., the left side is a session value, and the right side is a constant): both are uniformly converted to double for comparison. Furthermore, if the type is incorrect, it indicates that the matching rule has failed, and relevant logs can be generated for feedback.

[0073] It should be noted that the lvalue / rvalue type and operator type of the rule will be validated when the rule is saved and updated.

[0074] For example, when developers need to add rules to the target database, they can send a command to add the rule through the front-end interface. Based on the received command, the rule is persisted to the metadata database. Then, the rule engine is triggered to import the new rule from the metadata database and create an index for it. This allows the newly added rule to be used to update query requests during the application phase.

[0075] See Figure 2 The diagram illustrates that when developers submit rule adjustment commands via the front end (including but not limited to deletion, addition, and modification), the rules in text format can first be written to the metadata database. After triggering the rule engine, the engine can import the rules from the metadata database and index them for easy use in the application phase. During the application phase, a metrics collection server can collect system operation metrics and store them in its own memory, thereby controlling query requests based on this metrics. When a query request from a related cluster is received, the rules matching the cluster are retrieved to control the query request. When a related query request is received, if the current stage is before the query enters the database execution engine, the rules matching the query can be retrieved and controlled in a single instance; if the current stage is after the query has started execution, the rules matching the query can be retrieved and controlled periodically.

[0076] In summary, during the mapping relationship update phase, by transforming the rule description information according to the preset rule structure, the changed rules can exist in the set structure, making the rules involved in the target database more standardized. Furthermore, by setting the rule structure, the information required by the scenario can be clearly defined, making it easier to update the rules, thereby making rule management more standardized.

[0077] Step S104: Determine the target rule set corresponding to the target resource group of the query request based on the preset mapping relationship between resource groups and rule sets.

[0078] Specifically, after receiving the query request for the associated target database, and considering that the target database is a shared database with a large number of rules, using a full-scale calculation of the query request to match the rules would consume a large amount of computing resources from the target database. Therefore, in order to reduce resource consumption and improve the efficiency of calculating and matching rules, the mapping relationship between the preset resource groups and rule sets of the target database can be determined first. Then, based on the target resource group pointed to by the query request, the mapping relationship can be queried. Based on the query results, the target rule set corresponding to the target resource group can be determined, which facilitates the subsequent matching of target rules in the target rule set and updating of the query request.

[0079] In practical applications, when a user submits a query request, the target resource group will be specified by the user so that the query request can be executed through the user-specified resource group, thereby enabling access to the target database.

[0080] Furthermore, in determining the target rule set, to ensure that the target rule set is associated with the query request and corresponds to the target resource group specified by the user, it needs to be determined based on the identifier. In this embodiment, the specific implementation method is as follows:

[0081] The target resource group of the query request is determined, and the resource group identifier corresponding to the target resource group is read; the mapping relationship between the preset resource group and the rule set is queried according to the resource group identifier to obtain the rule set identifier; the target rule set is determined in the rule storage space according to the rule set identifier.

[0082] Specifically, the resource group identifier refers to the unique identifier of the target resource group, used to identify the resource group selected by the user within the resource group cluster. Correspondingly, the rule set identifier refers to the identifier of the rule set corresponding to the target resource group, used to filter the identifiers of rules associated with the target resource group from the global rules of the target database, and to form the target rule set after determining the rules based on the filtering results.

[0083] Therefore, upon receiving a query request, it can be parsed to obtain the resource group identifier corresponding to the target resource group. Then, the mapping relationship between the preset resource group and rule set is queried according to the resource group identifier. Based on the query results, the rule set identifier corresponding to the resource group identifier is determined. Finally, rules are selected from the rule storage space according to the rule set identifier to form the target rule set.

[0084] For example, the target database corresponds to M resource groups, namely M1, M2, ..., Mn. When a query request is received from a user targeting the target database, it is determined that the user has selected resource group M3. In order to access the target database by executing the query request through resource group M3, the resource group identifier ID_M3 corresponding to resource group M3 can be determined first. Then, based on resource group identifier ID_M3, the mapping relationship between resource group and rule set is queried, and the rule set identifier is determined to be ID_Q3. At this time, the rules matching the query request can be read from the rule storage space corresponding to the target database according to the rule set identifier ID_Q3. Based on the reading results, the rules matching the query request are determined to form the target rule set {Q31, Q32, ..., Q3n}.

[0085] In summary, by determining the rule set identifier based on the resource group identifier, and reading the rules associated with the query request from the rule storage space according to the rule set identifier to form the target rule set, it can be ensured that all rules contained in the target rule set match the query request. This reduces the number of matching rules while ensuring that no rules are lost, thus enabling accurate updates to the query request in the future.

[0086] Step S106: Determine the target rule that matches the query request in the target rule set, and determine the query control strategy corresponding to the target rule.

[0087] Specifically, after determining the target rule set comprised of the rules associated with the query request, further considering that the target rule set contains multiple rules matching the query request, if all rules were executed, multiple responses to the query request would occur, and it would be unclear how to respond to the query request after accessing the target database. Therefore, after determining the target rule set, we can identify the target rules matching the query request within the target rule set, and then determine the query control strategy corresponding to the target rules. This allows us to update the query request by executing the query control strategy to complete the access to the target database. Here, the target rule specifically refers to the rule in the target rule set with the highest relevance to the query request, and the corresponding query control strategy refers to the action that can restrict the query request.

[0088] Furthermore, in the stage of filtering target rules from the target database, in order to accurately filter the target rules with the highest relevance to the query request from the set, the request-related rules that match the query request can be determined by traversing the rules. Then, the target rule is selected according to the priority of the request-related rules. In this embodiment, the specific implementation method is as follows: steps S1062 to S1064:

[0089] Step S1062: Traverse the rules contained in the target rule set, and determine at least one request association rule that matches the query request based on the traversal results.

[0090] Specifically, traversing the rules contained in the target rule set refers to iterating through the attributes of the rules. By traversing, the attribute information in the rules used to determine whether they match the query request can be determined. Then, according to the relevance of the attribute information to the query request, rules are selected from the set as at least one request-related rule. Correspondingly, the request-related rule specifically refers to the rule in the target rule set that matches the query request, and its matching relationship represents the compatibility between the rule and the query request.

[0091] Based on this, after determining the target rule set, the rules contained in the target rule set can be traversed. That is, the attribute information that makes up each rule is traversed to determine the attribute information in each rule that represents the relevance to the query request based on the traversal results. Then, based on the attribute information, it is determined whether the current rule matches the query request, so as to filter out the matching rules as request association rules, so as to facilitate the subsequent determination of the target rule from multiple request association rules.

[0092] Furthermore, in order to ensure that the selected rules match the query request and thus guarantee accuracy when filtering the association rules, this embodiment is implemented as follows:

[0093] The execution information of the rules in the target rule set is determined based on the traversal results; the execution information of the rules in the target rule set is compared with the preset execution conditions; and the rule that satisfies the execution conditions is selected as at least one request association rule for matching the query request based on the comparison results.

[0094] Specifically, execution information refers to the predicate logic corresponding to each rule, used to clarify the relationship between each rule and the query request. Correspondingly, execution conditions specifically refer to checking whether the predicate logic in the execution information is true. Based on this, by traversing each rule, the execution information of each rule can be determined, that is, all the predicate logic corresponding to each rule. At this point, the execution information can be compared with preset execution conditions to determine whether all the predicate logic of each rule is true based on the comparison result. Rules where all predicate logic is true are selected as request association rules to facilitate subsequent filtering of target rules according to rule priority.

[0095] In summary, by examining the complete predicate logic of each rule, it is possible to determine whether the current rule matches the query request. Based on the examination results, the relevant rules for the request are filtered from the target rule set, thereby eliminating rules with low relevance, reducing the number of rule matches, and effectively improving the query request response efficiency.

[0096] Step S1064: Select the request association rule with the highest priority from the at least one request association rule as the target rule.

[0097] Specifically, after identifying at least one request association rule that matches the query request, in order to accurately respond to the query request, the request association rule with the highest priority can be selected from the at least one request association rule and used as the target rule.

[0098] In practice, the priority of each request association rule can be determined based on the priority association attribute information in its structure. That is, the rule's attribute information includes priority attribute information; the priority of a rule can be determined by reading the value of the priority attribute information, with a higher value indicating a higher priority. By comparing the values, the request association rule with the highest priority can be identified and used as the target rule.

[0099] In practical applications, considering the large number of rules, matching each rule one by one to select the target rule would consume significantly more time. Therefore, to save rule matching time and improve processing efficiency, rules can be sorted according to priority during the indexing stage after rule import. Based on this, when selecting a target rule, matching can proceed according to the priority-based rules. Only the first matching rule needs to be returned as the target rule for subsequent use. In other words, the first matching rule is the highest priority target rule that matches the query request. For example, if the priorities of rules Q1, Q2, and Q3 are Q1 > Q2 > Q3, after receiving a query request, matching can be performed according to the rule priority. If rule Q2 meets the conditions, it can be used as the target rule for the query request. During this process, because rule Q3 has a lower priority than rule Q2, rule Q3 will not be matched, thus saving rule matching time.

[0100] Following the previous example, after determining the target rule set {Q31, Q32, ..., Q3n}, we can iterate through the attribute information of each rule to determine all the predicate logic for each rule based on the iteration results. Then, we can determine whether all the predicate logic of each rule is true. Based on the result, we select the rule whose predicate logic is true as the request association rule. That is, in the target rule set {Q31, Q32, ..., Q3n}, rules Q33, Q34, Q35, and Q36 can be used as request association rules. Furthermore, since the rules were sorted from high to low priority during the rule import and indexing stage, we can directly match the first rule that meets the conditions as the target rule. That is, if the first rule that meets the conditions is determined to be Q35, then rule Q35 is selected as the target rule for matching the query request for subsequent use.

[0101] In summary, by traversing the execution information of each rule, request-related rules can be filtered from the target rule set. Since the rules were sorted by priority during indexing, matching only in sequence and selecting the first matching rule as the target rule effectively saves rule matching time and improves processing efficiency. Furthermore, during the rule change phase, text-formatted rules are converted to a preset rule structure format, including the operator and its left and right attribute values, metrics, and session data, to improve rule matching efficiency. It should be noted that all metrics require real-time up-to-date data; therefore, the metrics in the rules only need to specify attribute names, not specific values. Specific values ​​can be retrieved in real-time during matching, i.e., determined using a functional approach, and then used for subsequent processing.

[0102] In addition, when determining the target rule that matches the query request from the target rule set, the rules in the target rule set can be sorted according to priority order first, and then the execution information of each rule can be traversed to select the rule with the highest priority and whose execution information meets the conditions as the target rule. In specific implementation, the selection can be made according to the actual application scenario, and this embodiment does not impose any limitations here.

[0103] Step S108: Update the query request by executing the query control strategy, and access the target database in response to the updated query request.

[0104] Specifically, after determining the target rules for matching the query request, in order to enable the query request to quickly access the target database and receive feedback on the query request, the query request can be updated according to the query control policy of the target rules. This allows the query request to be restricted by the query control policy, enabling the restricted query request to access the target database. Furthermore, when accessing the target database, the updated query request is executed through the target resource group, thereby improving resource utilization while reducing resource consumption.

[0105] In practical applications, different target rules correspond to different query control strategies, and different query control strategies will impose different restrictions on query requests. Therefore, when updating query requests according to query control strategies, different methods will be used. The specific implementation methods are as follows:

[0106] (1) When the query control strategy is a query update strategy, determine the attribute information corresponding to the query request; update the attribute information to the target attribute information according to the query update strategy, and update the query request according to the target attribute information to obtain the target query request; access the target database based on the target query request.

[0107] Specifically, the query update strategy refers to the strategy used to update the query request, such as updating the query request's priority or attribute parameters. Correspondingly, attribute information refers to the basic information that makes up the query request, describing it to access the target database. Correspondingly, target attribute information refers to the attribute information updated according to the query update strategy—that is, attribute information restricted by the query update strategy. Updating the query request with this updated attribute information before accessing the target database can be more accurate and efficient.

[0108] Based on this, when the query control strategy is a query update strategy, it means that the attribute parameters of the query request need to be changed in the current lifecycle in order to access the target database using the changed query request. Therefore, the query request can be parsed first to obtain the attribute information corresponding to the query request, then the attribute information can be updated according to the query update strategy to obtain the target attribute information, and then the query request can be updated according to the target attribute information to obtain the target query request. Finally, the target database can be accessed according to the target query request.

[0109] Using the previous example, after determining that the query request matches rule Q35, we can first determine the action corresponding to rule Q35. If we determine that the action corresponding to rule Q35 is the priority for updating the query request, then we can adjust the priority of the query request according to the action corresponding to rule Q35 to obtain a target rule with a low priority or a high priority. Then, during the database access phase, we can execute the query request according to the updated priority to read data from the target database and provide feedback to the user who submitted the query request.

[0110] In practical implementation, considering that different queries often correspond to different levels of importance in real-world application scenarios, applying the same strategy to control queries of arbitrary importance would lead to a decline in overall system performance and low resource utilization. Therefore, when controlling various types of queries, large or unimportant queries can be restricted to reduce their response speed. This allows smaller and more important queries to receive more system resources, resulting in faster response times and ultimately better overall cluster performance.

[0111] In summary, by updating the query request attribute information, the updated query request can be used to complete the access to the target database. This allows for different control methods to be applied to different queries, thereby improving the overall performance of the cluster and effectively increasing resource utilization.

[0112] (2) When the query control strategy is a query restriction strategy, the query request is processed according to the query restriction strategy; query feedback information is generated according to the processing result as a response to the query request accessing the target database.

[0113] Specifically, the query restriction strategy refers to the strategy for restricting query requests. This restriction can be understood as stopping the query request from accessing the database and releasing the query request. Correspondingly, the query feedback information refers to the information generated after the query request is released, which is used to remind the user who submitted the query request.

[0114] Based on this, if the query control strategy is a query restriction strategy, it means that the query request at the current stage cannot access the target database normally. At this time, the query request can be processed according to the query restriction strategy, so as to release the query request based on the processing result and generate query feedback information, which can be used as the response for the query request to access the target database.

[0115] Using the previous example, after determining that the query request matches rule Q35, we can first determine the action corresponding to rule Q35. If the action corresponding to rule Q35 is determined to be kill, that is, delete the query request, then we can release the query request according to the action corresponding to rule Q35 and provide feedback to the user who submitted the query request.

[0116] In summary, by adopting different query control strategies to update query requests, different restrictions can be imposed on query requests, thereby improving the overall performance of the cluster.

[0117] In addition, indicator information can be collected periodically from the indicator collection server to control query requests using the indicator information in memory. In this embodiment, the specific method is as follows:

[0118] In response to an information collection request submitted by the indicator collection server, the system receives indicator information; creates a target query control strategy based on the indicator information; updates the query request by executing the target query control strategy; and accesses the target database in response to the updated query request.

[0119] Specifically, a metric collection server refers to a server that collects metric information about the system's operation. Correspondingly, metric information refers to information that restricts query requests. For example, {$metric.PATTERN_RT_P50} is the median RT of a certain query pattern in its historical execution; {$metric.CLUSTER_RC_CPU_USAGE_MAX} is the maximum CPU utilization of the access node in the past 5 minutes; these can all be used as judgment conditions for rules.

[0120] Based on this, after receiving the indicator information in response to the information collection request submitted by the indicator collection server, a target query control strategy can be created based on the indicator information. Then, the query request is updated by executing the target query control strategy, and the target database can be accessed in response to the updated query request. The relevant description of updating the query request can be found in the same or similar descriptions in the above embodiments, and no limitation is made here.

[0121] For example, if {$metric.PATTERN_RT_P50}>30000then kill means that for queries whose historical median RT of the pattern exceeds 30 seconds, the kill operation will be executed directly.

[0122] The request processing method provided in this specification aims to improve resource utilization and reduce query overhead. Upon receiving a query request for a target database, it determines the target resource group for the query request based on a pre-defined mapping relationship between resource groups and rule sets. It also determines the target rule set associated with the target resource group, thereby reducing the number of rule matches and saving resource consumption. Next, it identifies the target rule for matching the query request from the target rule set and determines the corresponding query control strategy. Finally, it updates the query request by executing the query control strategy to access the target database based on the updated query request. This method effectively reduces the computational load of matching rules and improves rule matching speed, enabling rapid response to query requests accessing the target database.

[0123] The following is in conjunction with the appendix Figure 3 Taking the application of the request processing method provided in this specification in a shared database scenario as an example, the request processing method will be further explained. Figure 3 The present specification illustrates a flowchart of a request processing method according to an embodiment, which includes the following steps.

[0124] Step S302: Receive a query request submitted for the shared database.

[0125] Step S304: Determine the query stage information corresponding to the query request.

[0126] Step S306: Determine the initial rule set corresponding to the target resource group of the query request based on the preset mapping relationship between resource groups and rule sets.

[0127] Step S308: Filter the rules associated with the query stage information from the initial rule set to construct the target rule set.

[0128] Step S310: Traverse the rules contained in the target rule set and determine the execution information of the rules in the target rule set based on the traversal results.

[0129] Step S312: Compare the execution information of the rules in the target rule set with the preset execution conditions.

[0130] Step S314: Select the rule that meets the execution conditions based on the comparison results, and use it as at least one request association rule to match the query request.

[0131] Step S316: Select the request association rule with the highest priority from at least one request association rule as the target rule.

[0132] Step S318: Determine the query control strategy corresponding to the target rule.

[0133] Step S320: If the query control strategy is a query update strategy, determine the attribute information corresponding to the query request.

[0134] Step S322: Update the attribute information to the target attribute information according to the query update strategy, and update the query request according to the target attribute information to obtain the target query request.

[0135] Step S324: Access the shared database based on the target query request.

[0136] In summary, this method determines the query matching rules by matching target rules and restricts query requests according to these rules. This effectively reduces the computational load of matching rules and improves the rule matching speed, enabling faster response from query requests to the target database.

[0137] Corresponding to the above method embodiments, this specification also provides embodiments of a request processing apparatus. Figure 4 A schematic diagram of a request processing apparatus according to one embodiment of this specification is shown. Figure 4 As shown, the device includes:

[0138] The receiving module 402 is configured to receive query requests submitted to the target database;

[0139] The determination module 404 is configured to determine the target rule set corresponding to the target resource group of the query request based on a preset mapping relationship between resource groups and rule sets.

[0140] The matching module 406 is configured to determine the target rule that matches the query request in the target rule set, and to determine the query control strategy corresponding to the target rule;

[0141] The update module 408 is configured to update the query request by executing the query control strategy and access the target database in response to the updated query request.

[0142] In an optional embodiment, the request processing apparatus further includes:

[0143] The information determination module is configured to determine the query stage information corresponding to the query request.

[0144] Accordingly, the determining module 404 is further configured to:

[0145] Based on the preset mapping relationship between resource groups and rule sets, determine the initial rule set corresponding to the target resource group of the query request; filter the rules associated with the query stage information from the initial rule set to construct the target rule set.

[0146] In an optional embodiment, the determining module 404 is further configured to:

[0147] The target resource group of the query request is determined, and the resource group identifier corresponding to the target resource group is read; the mapping relationship between the preset resource group and the rule set is queried according to the resource group identifier to obtain the rule set identifier; the target rule set is determined in the rule storage space according to the rule set identifier.

[0148] In an optional embodiment, the matching module 406 is further configured to:

[0149] Traverse the rules contained in the target rule set, and determine at least one request association rule that matches the query request based on the traversal results; select the request association rule with the highest priority from the at least one request association rule as the target rule.

[0150] In an optional embodiment, the matching module 406 is further configured to:

[0151] The execution information of the rules in the target rule set is determined based on the traversal results; the execution information of the rules in the target rule set is compared with the preset execution conditions; and the rule that satisfies the execution conditions is selected as at least one request association rule for matching the query request based on the comparison results.

[0152] In an optional embodiment, the update module 408 is further configured to:

[0153] When the query control strategy is a query update strategy, the attribute information corresponding to the query request is determined; the attribute information is updated to target attribute information according to the query update strategy, and the query request is updated according to the target attribute information to obtain the target query request; the target database is accessed based on the target query request.

[0154] In an optional embodiment, the request processing apparatus further includes:

[0155] The restriction module is configured to process the query request according to the query restriction policy when the query control policy is a query restriction policy; and to generate query feedback information based on the processing result as a response to the query request accessing the target database.

[0156] In an optional embodiment, the request processing apparatus further includes:

[0157] The mapping update module is configured to receive a rule change instruction carrying rule description information; determine the meta-database associated with the target database and write the rule description information into the meta-database; read the rule description information from the meta-database at the rule change node of the target database; transform the rule description information according to a preset rule structure; and update the mapping relationship between the resource group and the rule set based on the transformation result.

[0158] In an optional embodiment, the update mapping module is further configured to:

[0159] Create a rule template according to a preset rule structure and determine the rule structure dimension associated with the rule template; extract rule sub-description information from the rule description information according to the rule structure dimension, and add the rule sub-description information to the rule template to obtain the rule to be written; update the mapping relationship between the resource group and the rule set according to the rule to be written.

[0160] In an optional embodiment, the request processing apparatus further includes:

[0161] The access module is configured to receive indicator information in response to an information collection request submitted to the indicator collection server; create a target query control strategy based on the indicator information; update the query request by executing the target query control strategy; and access the target database in response to the updated query request.

[0162] In one optional embodiment, the rule structure dimension includes at least one of the following:

[0163] Rule attribute dimension, rule state dimension, rule control dimension, rule time dimension;

[0164] Accordingly, the rule description information includes at least one of the following:

[0165] Rule attribute description information, rule status description information, rule control description information, and rule time description information.

[0166] The request processing apparatus provided in this specification, in order to improve resource utilization and reduce query overhead, can, upon receiving a query request submitted to a target database, determine the target resource group of the query request based on a preset mapping relationship between resource groups and rule sets, and determine the target rule set associated with the target resource group. This reduces the number of rule matches and saves resource consumption. Then, it determines the target rule matching the query request from the target rule set, determines the query control strategy corresponding to the target rule, and updates the query request by executing the query control strategy to access the target database according to the updated query request. This achieves the goal of determining the query matching rule by matching the target rule and restricting the query request according to the control of that rule, effectively reducing the computational load of matching rules and improving the rule matching speed to quickly complete the response of the query request to access the target database.

[0167] The above is an illustrative scheme of a request processing device according to this embodiment. It should be noted that the technical solution of this request processing device and the technical solution of the above-described request processing method belong to the same concept. For details not described in detail in the technical solution of the request processing device, please refer to the description of the technical solution of the above-described request processing method.

[0168] Figure 5 A structural block diagram of a computing device 500 according to one embodiment of this specification is shown. The components of the computing device 500 include, but are not limited to, a memory 510 and a processor 520. The processor 520 is connected to the memory 510 via a bus 530, and a database 550 is used to store data.

[0169] The computing device 500 also includes an access device 540, which enables the computing device 500 to communicate via one or more networks 560. Examples of these networks include a Public Switched Telephone Network (PSTN), a Local Area Network (LAN), a Wide Area Network (WAN), a Personal Area Network (PAN), or a combination of communication networks such as the Internet. The access device 540 may include one or more of any type of wired or wireless network interface (e.g., a Network Interface Card (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) interface, a Wi-MAX interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, a Near Field Communication (NFC) interface, and so on.

[0170] In one embodiment of this specification, the above-described components of the computing device 500 and Figure 5 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 5 The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this specification. Those skilled in the art can add or replace other components as needed.

[0171] The computing device 500 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or PCs. The computing device 500 can also be a mobile or stationary server.

[0172] The processor 520 is configured to execute the following computer-executable instructions, which, when executed by the processor, implement the steps of the above-described request processing method.

[0173] The above is an illustrative scheme of a computing device according to this embodiment. It should be noted that the technical solution of this computing device and the technical solution of the above-described request processing method belong to the same concept. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the above-described request processing method.

[0174] An embodiment of this specification also provides a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the steps of the above-described request processing method.

[0175] The above is an illustrative scheme of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium and the technical solution of the above-described request processing method belong to the same concept. For details not described in detail in the technical solution of the storage medium, please refer to the description of the technical solution of the above-described request processing method.

[0176] An embodiment of this specification also provides a computer program, wherein when the computer program is executed in a computer, it causes the computer to perform the steps of the above-described request processing method.

[0177] The above is an illustrative example of a computer program according to this embodiment. It should be noted that the technical solution of this computer program and the technical solution of the aforementioned request processing method belong to the same concept. Details not described in detail in the technical solution of the computer program can be found in the description of the technical solution of the aforementioned request processing method.

[0178] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0179] The computer instructions include computer program code, which may be in the form of source code, object code, executable file, or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording media, USB flash drive, portable hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium may be appropriately added to or subtracted according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media may not include electrical carrier signals and telecommunication signals.

[0180] 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 the embodiments in this specification are not limited to the described order of actions, because according to the embodiments in this specification, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in this specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the embodiments in this specification.

[0181] In the above embodiments, 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.

[0182] The preferred embodiments disclosed above are merely illustrative of this specification. The optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the embodiments described herein. These embodiments are selected and specifically described in this specification to better explain the principles and practical applications of the embodiments, thereby enabling those skilled in the art to better understand and utilize this specification. This specification is limited only by the claims and their full scope and equivalents.

Claims

1. A request processing method, comprising: Receive query requests submitted for the target database; Determine the query stage information corresponding to the query request, determine the initial rule set corresponding to the target resource group of the query request according to the preset mapping relationship between resource groups and rule sets, filter the rules in the initial rule set that match the life cycle corresponding to the query stage information, and construct the target rule set. The target resource group is the resource group specified for the query request, and the effective life cycle of the rules in the rule set is determined according to the attributes defined by the rules and the actions executed. Determine the target rule that matches the query request from the target rule set, and determine the query control strategy corresponding to the target rule; The query request is updated by executing the query control strategy, and the target database is accessed in response to the updated query request.

2. The method according to claim 1, further comprising: Determine the target resource group of the query request, and read the resource group identifier corresponding to the target resource group; Based on the resource group identifier, query the preset mapping relationship between the resource group and the rule set to obtain the rule set identifier; The target rule set is determined by identifying the rule set identifier in the rule storage space.

3. The method according to claim 1, wherein determining the target rule matching the query request in the target rule set comprises: Traverse the rules contained in the target rule set, and determine at least one request association rule that matches the query request based on the traversal results; Select the request association rule with the highest priority from the at least one request association rule as the target rule.

4. The method according to claim 3, wherein determining at least one request association rule matching the query request based on the traversal results includes: The execution information of the rules in the target rule set is determined based on the traversal results; The execution information of the rules in the target rule set is compared with the preset execution conditions; Based on the comparison results, the rule that meets the execution conditions is selected as at least one request association rule for matching the query request.

5. The method according to claim 1, wherein updating the query request by executing the query control strategy and accessing the target database in response to the updated query request includes: When the query control strategy is a query update strategy, determine the attribute information corresponding to the query request; The attribute information is updated to the target attribute information according to the query update strategy, and the query request is updated according to the target attribute information to obtain the target query request; Access the target database based on the target query request.

6. The method according to claim 1, after the step of determining the query control strategy corresponding to the target rule is executed, it further includes: When the query control policy is a query restriction policy, the query request is processed according to the query restriction policy; The processing result generates query feedback information, which serves as a response to the query request to access the target database.

7. The method according to any one of claims 1-6, further comprising, before executing the step of receiving a query request submitted to the target database: Receive rule change instructions carrying rule description information; Determine the metadata database associated with the target database, and write the rule description information into the metadata database; At the rule change node of the target database, the rule description information is read from the meta database; The rule description information is transformed according to a preset rule structure, and the mapping relationship between the resource group and the rule set is updated based on the transformation result.

8. The method according to claim 7, wherein converting the rule description information according to a preset rule structure and updating the mapping relationship between the resource group and the rule set based on the conversion result includes: Create a rule template based on a preset rule structure, and determine the rule structure dimension associated with the rule template; According to the rule structure dimension, extract rule sub-description information from the rule description information, and add the rule sub-description information to the rule template to obtain the rule to be written; Update the mapping relationship between the resource group and the rule set according to the rule to be written.

9. The method according to any one of claims 1-6, wherein after the step of receiving the query request submitted to the target database is executed, it further comprises: In response to information collection requests submitted to the indicator collection server, receive indicator information; Create a target query control strategy based on the aforementioned indicator information; The query request is updated by executing the target query control strategy, and the target database is accessed in response to the updated query request.

10. The method according to claim 8, wherein the rule structure dimension includes at least one of the following: Rule attribute dimension, rule state dimension, rule control dimension, rule time dimension; Accordingly, the rule description information includes at least one of the following: Rule attribute description information, rule status description information, rule control description information, and rule time description information.

11. A request processing apparatus, comprising: The receiving module is configured to receive query requests submitted to the target database; The determination module is configured to determine the query stage information corresponding to the query request, determine the initial rule set corresponding to the target resource group of the query request according to the preset mapping relationship between resource groups and rule sets, filter the rules in the initial rule set that match the lifecycle corresponding to the query stage information, and construct the target rule set. The target resource group is the resource group specified for the query request, and the effective lifecycle of the rules in the rule set is determined according to the attributes defined by the rules and the actions executed. The matching module is configured to determine the target rule that matches the query request in the target rule set, and to determine the query control strategy corresponding to the target rule; The update module is configured to update the query request by executing the query control strategy, and access the target database in response to the updated query request.

12. A computing device, comprising: Memory and processor; The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions, which, when executed by the processor, implement the steps of the method according to any one of claims 1 to 10.

13. A computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the steps of the method according to any one of claims 1 to 10.

Images