Query processing method and device based on cache pre-verification and electronic equipment

Abstract

The embodiment of the invention discloses a query processing method and device based on cache pre-verification and electronic equipment. A specific embodiment of the method comprises the following steps: in response to the detection that a monitoring index reaches a preset threshold value, executing cache verification operation on acquired query request information; analyzing query parameter information corresponding to the query request information; generating a cache index key based on the query parameter information; based on the cache index key, searching the query result cache index table to obtain an index result; in response to the index result, representing that the cache is hit, and performing validity verification on the cache index key to obtain a verification result; in response to verification result representation passing, a cache query result is generated according to the index result, and the cache query result is sent to the corresponding client terminal; the monitoring index is updated, and the cache verification operation is forbidden in response to the situation that the monitoring index does not reach the preset threshold value. According to the embodiment, the technical effect of reducing calculation overhead is achieved.

Description

Technical Field

[0001] The embodiments of this disclosure relate to the field of computer technology, and more specifically to a query processing method, apparatus, and electronic device based on cache pre-validation. Background Technology

[0002] In modern database systems, especially distributed analytical databases, cloud-native databases, and database products that need to support complex permissions, external tables, views, and nondeterministic functions, query result caching is one of the key technologies for improving throughput and reducing response latency. Currently, the common approach to implementing query result caching is as follows: the user submits a query request; the database executes a structured query statement (SQL statement) parsing, semantic analysis, metadata binding, and generates and optimizes the query execution plan. Subsequently, the system determines whether a reusable query result cache exists based on the execution plan or the normalized structured query statement. If the cache is hit, the cached result is returned directly; if not, the complete query process is executed and a new query result cache is generated.

[0003] However, when using the above method to implement query result caching, the following technical problems often arise: Delayed cache validation leads to wasted computing resources. Existing solutions validate cache validity after SQL parsing, binding, and query optimization. Even if the query eventually hits the cache, the system must first complete the aforementioned series of computationally intensive operations. These pre-processing operations (especially parsing and optimization) consume significant amounts of CPU and memory resources, resulting in wasted computing resources.

[0004] The information disclosed in this background section is only intended to enhance the understanding of the background of the inventive concept, and therefore may contain information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0005] The summary portion of this disclosure is intended to provide a brief overview of the concepts, which will be described in detail in the detailed description portion. This summary portion is not intended to identify key or essential features of the claimed technical solutions, nor is it intended to limit the scope of the claimed technical solutions.

[0006] Some embodiments of this disclosure propose query processing methods, apparatuses, electronic devices, and computer-readable media based on cache pre-validation to address one or more of the technical problems mentioned in the background section above.

[0007] In a first aspect, some embodiments of this disclosure provide a query processing method based on cache pre-validation. The method includes: in response to detecting that a monitoring indicator representing the repetition rate of a query request reaches a preset threshold, performing a cache validation operation on the acquired query request information: parsing query parameter information corresponding to the query request information; generating a cache index key based on the query parameter information and a predefined anti-collision algorithm; searching a query result cache index table based on the cache index key to obtain an index result; in response to the index result indicating a cache hit, performing multi-dimensional cache validity validation on the cache index key to obtain a validation result; in response to the validation result indicating a pass, generating a cache query result based on the index result, and sending the cache query result to the corresponding client terminal; in response to the index result indicating a cache miss, clearing the index result, and performing a query result generation operation.

[0008] Secondly, some embodiments of this disclosure provide a query processing apparatus based on cache pre-verification. The apparatus includes: a detection unit configured to, in response to detecting that a monitoring indicator representing the repetition rate of a query request reaches a preset threshold, perform a cache verification operation on the acquired query request information: parsing query parameter information corresponding to the query request information; generating a cache index key based on the query parameter information and a predefined anti-collision algorithm; searching a query result cache index table based on the cache index key to obtain an index result; in response to the index result indicating a cache hit, performing multi-dimensional cache validity verification on the cache index key to obtain a verification result; in response to the verification result indicating a pass, generating a cache query result based on the index result, and sending the cache query result to the corresponding client terminal; and a clearing unit configured to, in response to the index result indicating a cache miss, clear the index result and perform a query result generation operation.

[0009] Thirdly, some embodiments of this disclosure provide an electronic device, including: one or more processors; and a storage device having one or more programs stored thereon, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the method described in any implementation of the first aspect above.

[0010] Fourthly, some embodiments of this disclosure provide a computer-readable medium having a computer program stored thereon, wherein the program, when executed by a processor, implements the method described in any of the implementations of the first aspect above.

[0011] The above embodiments of this disclosure have the following beneficial effects: By using the cache pre-verification-based query processing method of some embodiments of this disclosure, the cache verification timing is advanced to before the SQL parsing stage, and combined with a multi-dimensional verification mechanism and adaptive decision-making methods, the computational overhead is reduced. Specifically, the reason for the waste of computational resources is that the delayed cache verification timing leads to the waste of computational resources. Existing solutions place the verification of cache validity after the SQL parsing, binding, and query optimization processes. Even if the query eventually hits the cache, the system must first complete the aforementioned series of computationally intensive operations. These pre-operations (especially parsing and optimization) consume a large amount of CPU and memory resources, resulting in a waste of computational resources. Based on this, the cache pre-verification-based query processing method of some embodiments of this disclosure firstly performs a cache verification operation on the acquired query request information in response to the detection that the monitoring indicator representing the repetition of the query request reaches a preset threshold. Thus, a fast verification channel can be intelligently activated in the scenario most suitable for enabling cache acceleration. The cache verification operation includes: firstly, parsing the query parameter information corresponding to the query request information. Thus, key parameters used to uniquely identify the query semantics and context can be extracted. Second, based on the aforementioned query parameter information and a predefined anti-collision algorithm, a cache index key is generated. This allows for the creation of a unique identifier for quickly locating cached items. Third, based on the cache index key, the query result cache index table is searched to obtain the index result. This allows for determining the existence of reusable cache results with minimal overhead. Fourth, in response to the index result indicating a cache hit, the cache index key undergoes multi-dimensional cache validity verification to obtain a verification result. This allows confirming the validity of the cached result while ensuring its correctness and security. Fifth, in response to the verification result indicating a successful cache hit, cached query results are generated based on the index result and sent to the corresponding client terminal. This avoids expensive computational overhead such as SQL parsing and optimization, enabling rapid return of query results. Finally, in response to the index result indicating a cache miss, the index result is cleared, and the query result generation operation is performed. This automatically closes the fast channel when the query pattern is no longer suitable for caching, avoiding unnecessary verification overhead. This implementation achieves the technical effect of reducing computational overhead. Attached Figure Description

[0012] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and elements are not necessarily drawn to scale.

[0013] Figure 1 This is a flowchart of some embodiments of the query processing method based on cache pre-validation disclosed herein; Figure 2 This is a schematic diagram of the structure of some embodiments of the query processing apparatus based on cache pre-verification according to the present disclosure; Figure 3 This is a schematic diagram of the structure of an electronic device suitable for implementing some embodiments of the present disclosure. Detailed Implementation

[0014] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0015] It should also be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings. Unless otherwise specified, the embodiments and features described in this disclosure can be combined with each other.

[0016] It should be noted that the concepts of "first" and "second" mentioned in this disclosure are used only to distinguish different devices, modules or units, and are not used to limit the order of functions performed by these devices, modules or units or their interdependencies.

[0017] It should be noted that the terms "a" and "a plurality of" used in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0018] The names of messages or information exchanged between multiple devices in the embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.

[0019] This disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0020] Figure 1 A flow 100 of some embodiments of a cache-prevalidation-based query processing method according to the present disclosure is shown. This cache-prevalidation-based query processing method includes the following steps: Step 101: In response to the detection that the monitoring indicator representing the repetition of query requests has reached a preset threshold, perform a cache verification operation on the obtained query request information.

[0021] In some embodiments, the execution entity (e.g., a server) of the query processing method based on cache pre-validation can perform cache validation on the acquired query request information in response to detecting that a monitoring metric characterizing query request duplication has reached a preset threshold. The preset threshold can be a frequency threshold for query texts with the same hash value appearing within a preset time window (e.g., 1 minute). For example, the preset threshold could be 10 times per second. Query request duplication can be the number of times the same or similar structured query statements appear within a certain period (e.g., the most recent 1 minute). The monitoring metric can be a value obtained by the execution entity using a monitoring agent (e.g., Prometheus Node Exporter) and a streaming statistics engine (e.g., Apache Flink) to monitor query request duplication in real time. As an example, if the monitoring metric does not reach the preset threshold, indicating a large number of non-duplicate queries, enabling the cache validation operation in this case will result in low returns or even performance degradation due to increased index lookup overhead. The query request information can be an SQL query statement.

[0022] Step 1011: Parse the query parameter information corresponding to the query request information.

[0023] In some embodiments, the execution entity can parse the query parameter information corresponding to the query request information. The query parameter information may include a structured query statement (SQL statement), the target user identity, the target directory (Catalog), and the target database (Database).

[0024] In practice, the aforementioned execution entity can use communication protocols (such as MySQL's binary protocol, PostgreSQL's text protocol, and JDBC / ODBC driver protocol) to parse the query parameter information corresponding to the above query request information.

[0025] Step 1012: Generate a cache index key based on the query parameter information and a predefined anti-collision algorithm.

[0026] In some embodiments, the aforementioned execution entity may generate a cache index key based on query parameter information and a predefined anti-collision algorithm.

[0027] In practice, the aforementioned execution entity can generate a cache index key based on the above query parameter information and a predefined anti-collision algorithm through the following sub-steps: Sub-step one involves normalizing the structured query statement to obtain normalized query text. In practice, the execution entity can use an SQL parsing library (such as Druid SQL Parser) to normalize the structured query statement and obtain normalized query text. This normalization process may include, but is not limited to: whitespace normalization (e.g., replacing consecutive whitespace characters with single spaces), and comment removal (e.g., deleting -- and / ). / Note), keyword consistency (convert keywords to uppercase, such as change select to SELECT).

[0028] Sub-step two involves combining the standardized query text with the target user identity, target directory, and target database to obtain combined information. In practice, the executing entity can concatenate the standardized query text with the target user identity, target directory, and target database in a preset order to form a string as combined information. For example, the combined information could be [standardized query text, target user identity, target directory, target database].

[0029] Sub-step three involves generating a cache index key based on a predefined anti-collision algorithm and the aforementioned combined information. In practice, the execution entity can use a predefined anti-collision algorithm to map the combined information to generate the cache index key. This predefined anti-collision algorithm can be an algorithm that possesses collision resistance (the probability of different inputs mapping to the same output is 2^(n / 2), where n is the length), used to convert the combined information into a fixed-length identifier (cache index key).

[0030] Step 1013: Based on the cached index key, search the cached index table of the query results to obtain the index results.

[0031] In some embodiments, the execution entity can search the query result cache index table based on the cache index key to obtain the index result. The query result cache index table can be a key-value mapping table storing the mapping relationship between cache index keys and cache result metadata. The cache result metadata can be pointer data pointing to the storage location of the query result in memory (or disk). The index result can be a result identifier representing the cache hit status. It can include cache hit or cache miss. As an example, in response to the existence of a cache index key in the query result cache index table and the associated cache result metadata (a pointer to the actual cache result), the index result can be a cache hit; in response to the absence of a cache index key in the query result cache index table, the index result can be a cache miss.

[0032] Step 1014: In response to the index result indicating a cache hit, perform multi-dimensional cache validity verification on the cache index key to obtain the verification result.

[0033] In some embodiments, the execution entity may perform multi-dimensional cache validity verification on the cached index key in response to the index result indicating a cache hit, and obtain a verification result. The verification result can be used to indicate whether the verification passed or failed. The multi-dimensional cache validity verification may include table structure version verification, data version verification, view definition verification, permission rule verification, security rule verification, user variable verification, session variable verification, and external data source verification. If each of the above multi-dimensional cache validity verification checks indicates successful verification, the verification result can indicate that the verification passed. The table structure version verification can be used to verify whether the table structure involved in the cached index key has changed. For example, if the hash signature of the current table structure does not match the signature at the time of caching, it indicates that the table structure has changed (e.g., a field has been added), and the verification fails. The data version verification can be used to verify whether the table data version involved in the cached index key has changed. For example, if the table data version recorded in the cached index key is inconsistent with the table data version of that record in the current database, the verification fails. The view definition verification can be used to verify whether the view definition involved in the cached index key is consistent with the one at the time of caching. For example, querying the INFORMATION_SCHEMA.VIEWS table in the database retrieves the view definition for the aforementioned cached index key. If the view definition for the cached index key is inconsistent with the view definition stored during caching (e.g., changes in SQL query logic), the validation fails. The aforementioned permission rule validation can be used to verify whether the current user's access permissions to the data objects involved in the aforementioned cached index key have changed. For example, the cached result requires the user to have "report:view" permissions. If the user's "report:view" permissions are revoked by the administrator, the validation fails. The aforementioned security rule validation can be used to verify whether row-level security rules and column-level data masking rules have changed. For example, if the aforementioned row-level security rules (RLS) and the aforementioned column-level data masking rules (Dynamic DataMasking, DDM) have changed (e.g., rules have been updated), the validation fails. The aforementioned user variable validation can be used to verify whether the current value of user-defined variables used in the query is consistent with that used during caching. For example, if the user-defined variables used in the query are different from the user-defined variables used when the cache was generated, the validation fails. The session variable validation described above can be used to verify whether session-level system variables (such as timezone) affecting query results have changed. For example, the validation will fail if the session-level system variables are inconsistent with those stored in the cache. The external data source validation described above can be used to verify whether the external data source connection configuration involved in the query has changed.For example, if a query depends on an external data source (such as a table accessed via a database link, or an API that returns JSON), and the "last modified time" timestamp or hash value of the aforementioned external data source is inconsistent with the timestamp or hash value stored in the cache, the verification fails.

[0034] Step 1015: In response to the verification result indicating that the verification has passed, generate cached query results based on the index results, and send the cached query results to the corresponding client terminal.

[0035] In some embodiments, the aforementioned execution entity may, in response to the verification result indicating that the verification has passed, generate query results based on the index results and send the query results to the corresponding client terminal.

[0036] In practice, the aforementioned execution entity can, in response to the verification result indicating that the above verification result has passed, retrieve the cached query result from the cache storage according to the pointer or address to the actual cached result data structure corresponding to the above index result, and send the cached query result to the client terminal corresponding to the above query request information.

[0037] In addressing the technical challenges of the aforementioned background technologies, the application scenario—a real-time large-scale data monitoring system (such as a large-scale vehicle networking platform or transaction system)—often presents the following technical issues: In online transaction processing with extremely high concurrency and highly random query patterns, it is necessary to perform "generate cache key" and "query cache index" operations for each query (regardless of whether it hits). Under massive random queries, the vast majority of searches are invalid, and the accumulated CPU overhead of these operations, along with the memory consumption of the cache index itself, leads to redundant computation and response latency. Considering the following requirements of this application scenario—adaptability to high-concurrency tasks and adaptability to highly random tasks—we have decided to adopt the following solution: In some alternative implementations of certain embodiments, the execution entity may further perform a cache verification operation on the acquired query request information in response to detecting that a monitoring indicator characterizing the repetition rate of query requests has reached a preset threshold: The first step involves obtaining query request information for the target database system when the number of concurrent connections exceeds a preset concurrency threshold and the global cache miss rate is lower than a performance benefit threshold. The system concurrent connections can be the number of active client sessions maintained by the database server per unit of time. The preset concurrency threshold can be a configurable value (e.g., 70% or 90% of the maximum allowed connections by the database server). The global cache miss rate can be the percentage of query requests that attempt cache validation but ultimately fail to hit the cache or fail validation despite hitting it. The performance benefit threshold can be a preset miss rate threshold (e.g., 30%).

[0038] The second step is to extract features from the query request information to obtain an initial feature vector. In practice, the execution entity can use a query optimizer to extract features from the query request information and obtain the initial feature vector. This query optimizer can be a rule-based optimizer, such as the parser in Apache Calcite or ANTLR.

[0039] The third step is to standardize the initial feature vector to obtain the query feature vector. This standardization can be Z-score standardization. The query feature vector can include: query text length, query structure complexity, historical execution frequency, historical cache hit rate, and corresponding data table change frequency. For example, the query feature vector could be: [Query text length: 150, Query structure complexity: 0.85, Historical execution frequency: 10 times / minute, Historical cache hit rate: 70%, Data table change frequency: 1 time / hour].

[0040] The fourth step involves inputting the aforementioned query feature vector into a preset adaptive decision model to obtain an initial decision score. This preset adaptive decision model can be a model that takes the aforementioned query feature vector (numerical vector) as input and the aforementioned initial decision score (floating-point number) as output. The preset adaptive decision model may include: a feature processing layer (composed of a fully connected layer and an activation function (such as ReLU), which takes the query feature vector as input and outputs a high-level feature vector), a core decision layer (a Gradient Boosting Decision Tree (GBDT) model, which takes the aforementioned high-level feature vector as input and outputs a logistic regression value), and an output layer (a Sigmoid or Softmax function, which takes the aforementioned logistic regression value as input and outputs a floating-point number between 0 and 1).

[0041] The fifth step involves applying a sliding window average to the initial decision scores to obtain the final decision score. In practice, the executing entity can use the Exponential Weighted Moving Average (EWMA) algorithm to apply this sliding window average to the initial decision scores to suppress noise and obtain the final decision score. The decision score can be a floating-point number between 0 and 1, used to quantify the predicted benefit probability of performing a cache validation operation on the current query request. A higher decision score indicates a greater performance improvement (such as reduced latency and CPU overhead) that the model predicts can be achieved by performing a cache validation operation on the query.

[0042] Step 6: Based on historical decision results and actual execution performance data, incrementally train the aforementioned pre-defined adaptive decision model. In practice, the executing entity can use the stochastic gradient descent (SGD) method, taking the aforementioned historical decision results and actual execution performance data as input, to incrementally train the aforementioned pre-defined adaptive decision model. The aforementioned historical decision results can be a dataset of decisions made regarding historical query requests (i.e., "enable cache verification" or "disable cache verification"). The aforementioned actual execution performance data can be response latency data collected after the query is actually executed.

[0043] Step 7: Update the preset thresholds based on the global cache hit rate and average query latency. In practice, the execution entity can use a PID controller to update the preset thresholds using the global cache hit rate and average query latency as constraints. The global cache hit rate can be the proportion of queries that successfully hit the cache within a preset time period (e.g., within the last 5 minutes from the current time). The average query latency can be the average of the processing times for all queries.

[0044] Step 8: In response to the decision score reaching the preset threshold, perform the cache verification operation.

[0045] The first to eighth steps and related content described above, as an inventive point of this disclosure, solve the technical problem that "in online transaction processing with extremely high concurrency and highly random query patterns, it is necessary to perform the operations of 'generating cache keys' and 'querying cache indexes' for each query (regardless of whether it hits). Under massive random queries, most searches are invalid, and the accumulated CPU overhead of these operations and the memory occupation of the cache index itself lead to redundant calculations and response delays." The factors leading to redundant calculations and response delays are often as follows: In online transaction processing with extremely high concurrency and highly random query patterns, it is necessary to perform the operations of "generating cache keys" and "querying cache indexes" for each query (regardless of whether it hits). Under massive random queries, most searches are invalid, and the accumulated CPU overhead of these operations and the memory occupation of the cache index itself lead to redundant calculations and response delays. Solving these factors can reduce redundant calculations and response delays. To achieve this effect, firstly, query request information for the target database system is obtained. This provides a raw and comprehensive data foundation for subsequent intelligent decision-making, ensuring the integrity of the decision-making basis. Second, in response to the system's concurrent connection count exceeding a preset concurrency threshold and the global cache miss rate being lower than the performance gain threshold, feature extraction is performed on the aforementioned query request information to obtain an initial feature vector. This transforms unstructured query requests into structured, machine-understandable feature data, providing standardized input for model prediction. Third, the initial feature vector is standardized to obtain a query feature vector. This eliminates the differences in dimensions and numerical ranges between different feature dimensions. Fourth, the query feature vector is input into a preset adaptive decision model to obtain an initial decision score. This allows for a quantitative assessment of the expected benefit of enabling cache validation for the current query based on the machine learning model's learning of historical patterns. Fifth, the initial decision score is averaged using a sliding window to obtain a final decision score. This more accurately reflects the latest system load changes while smoothing out short-term fluctuations. Sixth, the preset adaptive decision model is incrementally trained based on historical decision results and actual execution performance data. This enables the decision model to continuously learn from actual system operation feedback, adapt to load changes, and continuously optimize decision accuracy. Seventh, the preset thresholds are updated based on the global cache hit rate and average query latency. Therefore, the stringency of decisions can be dynamically adjusted from the perspective of overall system performance. Caching can be used more aggressively to reduce latency under high system load, while a more conservative approach can be taken to avoid additional overhead when cache efficiency is low, achieving optimal global performance. Eighth, in response to the decision score reaching the preset threshold, the cache verification operation is executed. This translates intelligent decision-making into practical action, activating the cache acceleration path only when the predicted benefits outweigh the costs, generating query results and sending them to the corresponding client terminals. This effectively utilizes cache resources and avoids performance degradation.Ultimately, it can reduce redundant calculations and response latency in various complex and highly random scenarios.

[0046] Step 102: In response to the index result indicating a cache miss, clear the index result and perform the query result generation operation.

[0047] In some embodiments, the execution entity may, in response to the index result indicating a cache miss, clear the index result and perform a query result generation operation.

[0048] In some optional implementations of certain embodiments, the execution entity may, in response to the index result indicating a cache miss, clear the index result and perform a query result generation operation through the following steps: The first step is to clear the index results in response to the cache miss.

[0049] The second step is to parse the query parameter information to obtain a parse tree. In practice, the execution entity can use a parser generator (such as ANTLR (Another Tool for Language Recognition)) to parse the structured query statement in the query parameter information to obtain a parse tree. This parse tree can be a tree-like data structure that reflects the syntactic structure of the SQL statement.

[0050] The third step involves performing semantic analysis on the parse tree and binding it to metadata in the system directory to obtain a bound parse tree. In practice, the execution entity performs semantic analysis on the parse tree and binds abstract identifiers (such as table names and column names) in the parse tree to metadata in the database system directory to obtain a bound parse tree. The semantic analysis may include existence verification, accessibility verification, and type compatibility verification. Existence verification can check whether the database objects referenced in the query request actually exist. For example, SELECT... The `employees` table in `FROM employees` is registered in the system directory. The accessibility validation mentioned above can check if the target user has permission to access the referenced database object. For example, does the user have SELECT privileges on the `employees` table? The type compatibility validation mentioned above can check if the data types in the operation match. For example, in the condition `WHERE age='twenty-five'`, check if the `age` column (usually a numeric type) is compatible with the string 'twenty-five'.

[0051] The fourth step involves generating a set of query plans based on the aforementioned binding parse tree and query optimizer, and determining the target query plan based on the cost model and the set of query plans. In practice, the execution entity can use the aforementioned query optimizer to analyze the aforementioned binding parse tree to determine at least one query plan as part of the query plan set. Then, based on the cost model, the cost of the set of query plans is determined to identify the target query plan. The cost model can be a mathematical model based on database system statistics (such as table size, index selectivity, and data distribution histograms) to quantitatively evaluate the consumption of system resources (such as CPU, memory, and I / O subsystems) by different query plans, such as Oracle's cost model or PostgreSQL's cost model. The query plan can include selecting a data access path (full table scan or index scan), determining a join algorithm (hash join, nested loop join, sort-merge join), and deciding on sorting and aggregation rules (memory sorting or disk sorting). The cost determination can include determining I / O costs (number of disk pages to be read), CPU costs, memory costs, and network costs (data transfer overhead).

[0052] The fifth step is to execute the target query plan described above to generate query results and send these results to the corresponding client terminals. In practice, the executing entity can use a query execution engine to execute the target query plan, generate query results, and send these results to the corresponding client terminals. For example, the query execution engine could be the query execution engine of MySQL, PostgreSQL, or SQL Server.

[0053] Optionally, the aforementioned implementing entity may also perform the following steps: The first step is to locate the target cache item in the query result cache index table based on the above cache index key, in response to the above verification result not passing.

[0054] In some embodiments, the execution entity may, in response to the failure of the verification result, locate the target cache item in the query result cache index table according to the cache index key.

[0055] In practice, the aforementioned execution entity can respond to the failure of the aforementioned verification result representation by locating the target cache item in the aforementioned query result cache index table using a hash table lookup algorithm and the aforementioned cache index key.

[0056] The second step is to mark the target cache item as unavailable and confirm the cache expiration timestamp.

[0057] In some embodiments, the execution entity may mark the target cached item as unavailable and confirm the cache expiration timestamp. As an example, the cache expiration timestamp may be Expires: Thu, 31 Dec 2025 23:59:59 GMT.

[0058] The third step is to release the storage space occupied by the aforementioned target cache items.

[0059] In some embodiments, the execution entity may release the storage space occupied by the target cache item.

[0060] The fourth step is to generate a cache invalidation event notification based on the hash value corresponding to the cache index key and the cache invalidation timestamp.

[0061] In some embodiments, the execution entity may generate a cache invalidation event notification based on the hash value corresponding to the cache index key and the cache invalidation timestamp. The cache invalidation event notification may be a message object, including eventId (a unique identifier for the event), cacheKey (the hash value corresponding to the invalidated cache index key), expirationTimestamp (cache invalidation timestamp), and action (event type, such as "CACHE_INVALIDATION").

[0062] Fifth, write the above cache invalidation event notification to the system log.

[0063] In some embodiments, the aforementioned executing entity may write the cache invalidation event notification to the system log. The system log may include cache statistics.

[0064] Step 6: Update the cache statistics in the system logs mentioned above.

[0065] In some embodiments, the aforementioned execution entity may update cache statistics in the aforementioned system log. These cache statistics include: a global cache miss rate and an expiration counter. The global cache miss rate may be the percentage of all query requests that failed cache validation out of the total number of query requests. The expiration counter may be a cumulative counter used to count the number of times different expiration reasons occurred.

[0066] Step 7: Perform the query result generation operation to generate query results and send the query results to the corresponding client terminal.

[0067] In some embodiments, the aforementioned execution entity may perform a query result generation operation to generate query results and send the query results to the corresponding client terminal.

[0068] In practice, firstly, the aforementioned executing entity can execute steps two through five of step "102" to generate query results and send the query results to the corresponding client terminal.

[0069] In addressing the technical challenges mentioned above, the application scenario—network traffic anomaly monitoring (or real-time fraud transaction monitoring)—often presents the following challenges: In stream processing scenarios (such as Apache Flink and Kafka Streams), data is constantly changing, lacking a stable state for caching. Cached items expire as soon as they are stored, and frequent cache invalidation and rebuilding lead to computational redundancy, further causing response latency. Considering the following requirements for this application scenario: efficient memory management, low-latency update mechanism, and strong consistency, we have decided to adopt the following solution: After step 102 above, the executing entity may also perform the following steps: The first step, in response to the detection that the data inflow rate exceeds a preset threshold within a preset sliding time window, decomposes the historical streaming query request set into multiple query sub-expressions, resulting in a query sub-expression set. In practice, the execution entity can use the query optimizer to analyze recurring computational patterns in the historical streaming query request set to obtain the query sub-expression set. The historical streaming query request set can be a collection of previously executed query requests running in streaming mode. For example, the query sub-expression set may include, but is not limited to: filtering conditions (e.g., WHERE status='ACTIVE'), join operations (e.g., joining the orders table with the customers table), or aggregation operations (e.g., SUM(sales_amount)). The data inflow rate can be the number of new data records arriving at the data source per unit time or the data volume (e.g., records / second or MB / second). The preset sliding time window can be a continuously moving time interval (e.g., the most recent 60 seconds). The preset threshold can be a critical value for the data inflow rate pre-set based on system processing capacity and business needs (e.g., 10,000 records / second).

[0070] The second step is to determine the materialization priority of each query subexpression in the aforementioned query subexpression set, thus obtaining a set of materialization priorities. In practice, the executing entity can determine the access frequency of each query subexpression in the aforementioned query subexpression set within the aforementioned preset sliding time window, using this as the materialization priority, thus obtaining a set of materialization priorities. The materialization priority can be the access frequency within the aforementioned preset sliding time window.

[0071] The third step involves constructing an initial materialized view for each query sub-expression in the aforementioned query sub-expression set, based on the aforementioned materialized priority set, thus obtaining an initial materialized view set. In practice, the execution entity can sort the aforementioned query sub-expression set in descending order based on the aforementioned materialized priority set to obtain a sequence of query sub-expressions. Next, a priority scheduling algorithm and a distributed snapshot algorithm are used to obtain snapshot data of the aforementioned historical streaming query request set at time point T. Then, each query sub-expression in the aforementioned query sub-expression set is executed on the aforementioned snapshot data to obtain an execution result set. Finally, the execution result set is stored in columnar format to obtain the initial materialized view set. As an example, the aforementioned priority scheduling algorithm can be Weighted Fair Queuing (WFQ). The aforementioned distributed snapshot algorithm can be the Chandy-Lamport algorithm.

[0072] The fourth step is to establish a subscription relationship between the data stream source and the initial materialized view set. In practice, the execution entity can use a publish-subscribe system to establish this relationship. For example, the publish-subscribe system could be Apache Kafka.

[0073] Fifth, based on the data change events from the data source and the subscription relationships described above, perform incremental updates on the initial materialized view set and bind a version number to it to obtain the materialized view set. In practice, the executing entity can use the database's built-in engine (database built-in triggers or the materialized view log (MLog)) to obtain the data change events from the data source to perform incremental updates on the initial materialized view set and bind a version number to it to obtain the materialized view set.

[0074] Step 6: Obtain the access frequency and computational cost of the aforementioned materialized view set. Based on these factors, determine the benefit value of each materialized view in the set, resulting in a benefit value set. The computational cost can be the maintenance cost of monitoring the materialized views, including: storage cost (the number of bytes of disk or memory occupied by the materialized view), update cost (the CPU time (milliseconds) and I / O operations required for incremental updates to the materialized view), and memory cost (the amount of working memory (bytes) used when querying the materialized view). The benefit value can be determined using the following formula: Benefit Value = Access Frequency / Computational Cost.

[0075] Step 7: In response to the fact that the benefit value in the aforementioned benefit value set is lower than the elimination threshold, the storage resources occupied by the corresponding materialized view are released. The aforementioned elimination threshold can be a dynamically adjusted critical value, for example, it can be the 25th percentile of the aforementioned benefit value set.

[0076] Step 8: In response to receiving a streaming query request, based on the aforementioned materialized view set, the streaming query request is rewritten into a streaming query plan, and a version number consistency check is performed on the streaming query plan to obtain the version check result. In practice, the execution entity can use the query optimizer to identify the query subexpressions included in the streaming query request and match and transform them with the aforementioned materialized view set to obtain a streaming query plan. Then, a version number consistency check is performed on the streaming query plan to obtain the version check result. The version number consistency check can verify whether the corresponding materialized views in the aforementioned materialized view set were generated based on the same logical point in time. As an example, a correlated subquery in the aforementioned streaming query request (such as SELECT c1, (SELECT avg(c2) FROM t2 WHERE t2.c2 = t1.c2) FROM t1) can be converted into an equivalent JOIN operation. SELECT SUM(sales) FROM orders is rewritten to directly read the result from the sales_sum materialized view in the aforementioned materialized view set.

[0077] Step nine: In response to the version verification result indicating version number consistency, the system generates query results based on the materialized view set and sends these results to the corresponding client terminal. In practice, the execution entity may, in response to the version verification result indicating version number consistency, extract data from the materialized view corresponding to the materialized view set to generate query results, and then use a database connection protocol (such as MySQL's binary protocol) to send these query results to the client terminal corresponding to the query request information.

[0078] The first to ninth steps and related content described above, as an inventive point of this disclosure, solve the technical problem that "in stream processing scenarios (such as Apache Flink and Kafka Streams), data is constantly changing, and there is no 'stable' state to cache. Cache items expire as soon as they are stored, and frequent cache invalidation and rebuilding lead to computational redundancy, further resulting in response latency." The factors leading to computational redundancy and response latency are often as follows: In stream processing scenarios (such as Apache Flink and Kafka Streams), data is constantly changing, and there is no "stable" state to cache. Cache items expire as soon as they are stored, and frequent cache invalidation and rebuilding lead to computational redundancy, further resulting in response latency. If these factors are resolved, the effects of reducing computational redundancy and response latency can be achieved. To achieve this effect, firstly, in response to detecting that the data inflow rate exceeds a preset rate threshold within a preset sliding time window, the historical streaming query request set is decomposed into multiple query sub-expressions to obtain a set of query sub-expressions. This allows for the identification and abstraction of reusable computational patterns in streaming queries, breaking down complex query logic into smaller, more manageable, and optimizable basic computational units, laying the foundation for subsequent materialized view construction. Second, the materialization priority of each query sub-expression in the aforementioned query sub-expression set is determined, resulting in a materialization priority set. This allows for determining the construction order of materialized views under limited computational and storage resource constraints, avoiding the average allocation and waste of resources. Third, based on the aforementioned materialization priority set, initial materialized views are constructed for each query sub-expression in the aforementioned query sub-expression set, resulting in an initial materialized view set. This allows for the physical storage and materialization of frequently used computational logic results, transforming expensive real-time computation into fast pre-computation result access, providing a preliminary foundation for performance acceleration in streaming queries. Fourth, a subscription relationship is established between the data stream source and the aforementioned materialized view set. This allows for the establishment of a real-time, automated data change notification channel from the data source to the materialized views. Fifth, based on the data change events corresponding to the aforementioned data flow sources and the aforementioned subscription relationships, the initial materialized view set is incrementally updated, and a version number is bound to the initial materialized view set to obtain the materialized view set. This allows for maintaining the data freshness of the materialized views with extremely low overhead, avoiding the expensive cost of a full reconstruction. Simultaneously, the version number accurately marks the data status of the materialized views at different points in time, providing a basis for query consistency. Sixth, the access frequency and computational cost corresponding to the aforementioned materialized view set are obtained, and based on these access frequencies and computational costs, the benefit value of each materialized view in the set is determined, resulting in a benefit value set. This allows for the establishment of a quantitative and objective performance benefit evaluation indicator for each materialized view, transforming the management of materialized views from a static, experience-driven model to a dynamic, data-driven model.Seventh, in response to the benefit value set falling below the elimination threshold, the storage resources occupied by the corresponding materialized view are released. This allows for the timely cleanup of invalid or inefficient materialized views whose maintenance costs outweigh their query acceleration benefits, enabling the recycling of storage resources and preventing system resources from being occupied by gradually expired caches. Eighth, in response to receiving a streaming query request, based on the aforementioned materialized view set, the streaming query request is rewritten into a streaming query plan, and a version number consistency check is performed on the streaming query plan to obtain the version check result. This ensures that the query can maximize the use of existing materialized views to accelerate execution, and the consistency check guarantees that the query result is based on a logically consistent data snapshot, avoiding errors caused by misaligned data timestamps. Ninth, in response to the version check result indicating version number consistency, query results are generated based on the aforementioned materialized view set, and the query results are sent to the corresponding client terminal. This avoids scanning large amounts of raw data and complex calculations, achieving rapid query result response. Ultimately, this achieves the effect of reducing computational redundancy and response latency in stream processing scenarios.

[0079] The above embodiments of this disclosure have the following beneficial effects: By using the cache pre-verification-based query processing method of some embodiments of this disclosure, the cache verification timing is advanced to before the SQL parsing stage, and combined with a multi-dimensional verification mechanism and adaptive decision-making methods, the computational overhead is reduced. Specifically, the reason for the waste of computational resources is that the delayed cache verification timing leads to the waste of computational resources. Existing solutions place the verification of cache validity after the SQL parsing, binding, and query optimization processes. Even if the query eventually hits the cache, the system must first complete the aforementioned series of computationally intensive operations. These pre-operations (especially parsing and optimization) consume a large amount of CPU and memory resources, resulting in a waste of computational resources. Based on this, the cache pre-verification-based query processing method of some embodiments of this disclosure firstly performs a cache verification operation on the acquired query request information in response to the detection that the monitoring indicator representing the repetition of the query request reaches a preset threshold. Thus, a fast verification channel can be intelligently activated in the scenario most suitable for enabling cache acceleration. The cache verification operation includes: firstly, parsing the query parameter information corresponding to the query request information. Thus, key parameters used to uniquely identify the query semantics and context can be extracted. Second, based on the aforementioned query parameter information and a predefined anti-collision algorithm, a cache index key is generated. This allows for the creation of a unique identifier for quickly locating cached items. Third, based on the cache index key, the query result cache index table is searched to obtain the index result. This allows for determining the existence of reusable cache results with minimal overhead. Fourth, in response to the index result indicating a cache hit, the cache index key undergoes multi-dimensional cache validity verification to obtain a verification result. This allows confirming the validity of the cached result while ensuring its correctness and security. Fifth, in response to the verification result indicating a successful cache hit, cached query results are generated based on the index result and sent to the corresponding client terminal. This avoids expensive computational overhead such as SQL parsing and optimization, enabling rapid return of query results. Finally, in response to the index result indicating a cache miss, the index result is cleared, and the query result generation operation is performed. This automatically closes the fast channel when the query pattern is no longer suitable for caching, avoiding unnecessary verification overhead. This implementation achieves the technical effect of reducing computational overhead.

[0080] Continue to refer to Figure 2 As a response to the above Figure 1 The present disclosure provides some embodiments of a query processing apparatus based on cache pre-validation, which are similar to the implementation of the method shown. Figure 1 Corresponding to the method embodiments shown, the device can be specifically applied to various electronic devices.

[0081] like Figure 2 As shown, a query processing apparatus 200 based on cache pre-verification in some embodiments includes a detection unit 201 and a clearing unit 202. The detection unit 201 is configured to perform a cache verification operation on the acquired query request information in response to a monitoring indicator representing the repetition rate of query requests reaching a preset threshold: parsing the query parameter information corresponding to the query request information; generating a cache index key based on the query parameter information and a predefined anti-collision algorithm; searching the query result cache index table based on the cache index key to obtain an index result; performing multi-dimensional cache validity verification on the cache index key in response to the index result indicating a cache hit, obtaining a verification result; generating a cache query result based on the index result in response to the verification result indicating a pass, and sending the cache query result to the corresponding client terminal; the clearing unit 202 is configured to clear the index result in response to the index result indicating a cache miss, and perform a query result generation operation.

[0082] It is understandable that the units described in the device 200 are related to the reference. Figure 1 The steps in the described method correspond to each other. Therefore, the operations, features, and beneficial effects described above for the method also apply to the device 200 and the units contained therein, and will not be repeated here.

[0083] The following is for reference. Figure 3 It shows a schematic diagram of the structure of an electronic device 300 suitable for implementing some embodiments of the present disclosure. Figure 3 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments of this disclosure.

[0084] like Figure 3 As shown, the electronic device 300 may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) 301, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 302 or a program loaded from a storage device 308 into a random access memory (RAM) 303. The RAM 303 also stores various programs and data required for the operation of the electronic device 300. The processing unit 301, ROM 302, and RAM 303 are interconnected via a bus 304. An input / output (I / O) interface 305 is also connected to the bus 304.

[0085] Typically, the following devices can be connected to I / O interface 305: input devices 306 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 307 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 308 including, for example, magnetic tapes, hard disks, etc.; and communication devices 309. Communication device 309 allows electronic device 300 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 3 An electronic device 300 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively. Figure 3 Each box shown can represent a device or multiple devices as needed.

[0086] In particular, according to some embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, some embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication device 309, or installed from storage device 308, or installed from ROM 302. When the computer program is executed by processing device 301, it performs the functions defined in the methods of some embodiments of this disclosure.

[0087] It should be noted that, in some embodiments of this disclosure, the computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium may be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In some embodiments of this disclosure, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In some embodiments of this disclosure, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0088] In some implementations, clients and servers can communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol) and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet of Things), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future-developed networks.

[0089] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device. The aforementioned computer-readable medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to: upon detecting that a monitoring indicator representing the repetition rate of a query request reaches a preset threshold, perform a cache verification operation on the acquired query request information: parse the query parameter information corresponding to the query request information; generate a cache index key based on the query parameter information and a predefined anti-collision algorithm; search the query result cache index table based on the cache index key to obtain an index result; upon the index result indicating a cache hit, perform multi-dimensional cache validity verification on the cache index key to obtain a verification result; upon the verification result indicating a pass, generate a cached query result based on the index result and send the cached query result to the corresponding client terminal; upon the index result indicating a cache miss, clear the index result and perform a query result generation operation.

[0090] Computer program code for performing operations of some embodiments of this disclosure can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0091] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0092] The units described in some embodiments of this disclosure can be implemented in software or in hardware. The described units can also be housed in a processor; for example, a processor may be described as including a detection unit and a clearing unit. The names of these units do not necessarily limit the unit itself; for example, a clearing unit may also be described as "a unit that, in response to the index result indicating a cache miss, clears the index result and performs a query result generation operation."

[0093] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), and so on.

[0094] The above description is merely a selection of preferred embodiments of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in the embodiments of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described inventive concept. For example, technical solutions formed by substituting the above-described features with (but not limited to) technical features with similar functions disclosed in the embodiments of this disclosure.

Claims

1. A query processing method based on cache pre-validation, comprising: In response to the detection that a monitoring metric characterizing the repetition rate of query requests has reached a preset threshold, a cache verification operation is performed on the acquired query request information: Parse the query parameter information corresponding to the query request information; Based on the query parameter information and the predefined anti-collision algorithm, a cache index key is generated; Based on the cached index key, the query result cached index table is searched to obtain the index result; In response to the index result indicating a cache hit, the cache index key is subjected to multi-dimensional cache validity verification to obtain the verification result; In response to the verification result indicating that the verification is successful, a cached query result is generated based on the index result, and the cached query result is sent to the corresponding client terminal. In response to the index result indicating a cache miss, the index result is cleared, and a query result generation operation is performed.

2. The method according to claim 1, wherein, The response to the index result indicating a cache miss, clearing the index result, and performing a query result generation operation includes: In response to the index result indicating a cache miss, the index result is cleared; The query parameter information is parsed to obtain a parse tree; Semantic analysis is performed on the parse tree, and the parse tree is bound to metadata in the database system directory to obtain a bound parse tree; Based on the binding parse tree and the query optimizer, a set of query plans is generated, and based on the cost model and the set of query plans, a target query plan is determined; The target query plan is executed to generate query results and send the query results to the corresponding client terminal.

3. The method according to claim 1, wherein, The preset threshold is the frequency threshold of query texts with the same hash value appearing within a preset time window.

4. The method according to claim 1, wherein, The query parameter information includes a structured query statement, the target user's identity, the target directory, and the target database. Based on the query parameter information, a cache index key is generated, including: The structured query statement is normalized to obtain normalized query text; The standardized query text is combined with the target user identity, the target directory, and the target database to obtain combined information; A cache index key is generated based on a predefined anti-collision algorithm and the combined information.

5. The method according to claim 1, wherein, The multi-dimensional cache validity verification includes: table structure version verification, data version verification, view definition verification, permission rule verification, security rule verification, user variable verification, session variable verification, and external data source verification.

6. The method according to claim 1, wherein, The method further includes: In response to the verification result indicating failure, the target cache item is located in the query result cache index table according to the cache index key; Mark the target cache item as unavailable and confirm the cache expiration timestamp; Release the storage space occupied by the target cache item; Generate a cache invalidation event notification based on the hash value corresponding to the cache index key and the cache invalidation timestamp; Write the cache invalidation event notification to the system log; In the system log, update the cache statistics information, which includes: global cache miss rate and miss counter; Perform the query result generation operation to generate query results and send the query results to the corresponding client terminal.

7. A query processing apparatus based on cache pre-validation, comprising: The detection unit is configured to perform cache verification operations on the acquired query request information in response to the detection that a monitoring indicator characterizing the repetition of query requests has reached a preset threshold. Parse the query parameter information corresponding to the query request information; Based on the query parameter information and the predefined anti-collision algorithm, a cache index key is generated; Based on the cached index key, the query result cached index table is searched to obtain the index result; In response to the index result indicating a cache hit, the cache index key is subjected to multi-dimensional cache validity verification to obtain the verification result; In response to the verification result indicating that the verification is successful, a cached query result is generated based on the index result, and the cached query result is sent to the corresponding client terminal. The clearing unit is configured to clear the index results and perform a query result generation operation in response to the index result indicating a cache miss.

8. An electronic device, comprising: One or more processors; A storage device on which one or more programs are stored; When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1 to 6.

9. A computer-readable medium having a computer program stored thereon, wherein, When the program is executed by the processor, it implements the method as described in any one of claims 1 to 6.

Images