Graph database query acceleration method and system

Abstract

The invention discloses a graph database query acceleration method and system. The method comprises the following steps: constructing panoramic query observation data through non-intrusive log interception and structured processing; the query statement is analyzed into an abstract syntax tree, semantic normalization processing is carried out, and a unique hash value is generated; predicting a hotspot query template and high-frequency parameters thereof based on a popularity value score model, and asynchronously preloading a result to a cache; dynamically calculating adaptive survival time for each cache item according to the data change frequency and the access popularity; and constructing a multi-level cache architecture comprising a local cache, a distributed cache and a database built-in cache, and performing intelligent routing and collaborative backfilling based on a hash value. According to the method, intelligent and transparent acceleration of graph database query is realized, the query performance is remarkably improved, the database load is reduced, and the problems of redundancy, high cold start delay and difficulty in balancing cache consistency caused by grammar difference in traditional cache are solved.

Description

Technical Field

[0001] This invention relates to the field of database performance optimization technology, specifically to a method and system for accelerating graph database queries. Background Technology

[0002] Graph databases are widely used in social networks, knowledge graphs, recommender systems, and financial risk control due to their inherent advantages in representing and processing complex relationships. However, with the increasing volume of data and query complexity, graph databases face significant performance challenges, especially the requirement for low latency under high concurrency.

[0003] Traditional query optimization techniques, such as indexing and query plan optimization, have been applied at the graph database level. However, at the application layer, common caching strategies (such as caching based on raw query strings) have significant drawbacks: First, graph query languages ​​(such as nGQL and Cypher) are flexible, and queries with the same semantics may differ in syntax such as capitalization, spaces, variable aliases, and condition order, causing traditional caches to fail to recognize their semantic similarity, resulting in cache redundancy and low hit rates. Second, caching suffers from the cold start problem, where the first query request still needs to access the underlying database, failing to meet the needs of extremely low-latency scenarios. Third, static cache expiration strategies struggle to balance data freshness and cache utilization, easily leading to dirty reads for frequently changing data and premature expiration for stable data. Finally, a single-level cache cannot simultaneously meet the requirements of extreme speed, large capacity, and global consistency.

[0004] Therefore, there is an urgent need for a systematic solution that can understand query semantics, proactively predict hotspots, intelligently manage lifecycles, and coordinate multi-level caching resources to achieve deep and transparent acceleration of graph database queries. Summary of the Invention

[0005] To address the aforementioned issues, this invention provides a method and system for accelerating graph database queries. This method solves the cache redundancy problem through semantic normalization, addresses the cold start problem through predictive preloading, balances performance and consistency through adaptive lifecycle management, and maximizes system efficiency through multi-level caching collaboration.

[0006] To achieve the above objective, a method for accelerating graph database queries based on semantic awareness and multi-level caching collaboration is provided. The specific technical solution is as follows: S1. Collect log data from graph database queries and process it into a structured query log dataset; S2. Parse and semantically normalize the query statements in the structured dataset to generate parameterized query patterns, calculate their unique semantic identifiers, and build and maintain a knowledge base. S3. Based on the historical execution information in the knowledge base, identify the query template and parameter combination that meet the preset conditions, and actively load the query results into the cache system; S4. Based on the graph data update status associated with the cache item and the access status of the cache item, dynamically adjust the retention strategy of the cache item in the cache system; S5. Configure a caching system with at least two layers and define the routing rules for query requests in the caching system and the data synchronization mechanism between different caching layers.

[0007] Preferably, step S2 includes: Parse the query statement into an abstract syntax tree; Perform at least one semantically preserving transformation operation on the abstract syntax tree, the transformation operation being selected from: identifier format standardization, conditional reordering based on logical commutative law, normalization of user variable names to system variable names, and replacement of constants with parameter placeholders; Based on the transformed abstract syntax tree, a parameterized query template is generated; The parameterized query template is calculated to generate its unique identifier.

[0008] Preferably, the construction and maintenance of the knowledge base in step 2 includes: Using the unique identifier as the primary key, the statistical information of the query template is recorded in the knowledge base. The statistical information includes: cumulative execution count, average execution time, historical execution timestamp sequence, parameter value sequence used, and result set size. When the query template is executed again, the statistical information of the corresponding record in the knowledge base is updated.

[0009] Preferably, step 3 includes: Based on the statistical information, calculate the popularity score for each query template; For each query template, analyze its historical parameter value sequence to determine the frequently occurring parameter values; Based on the popularity score and the frequency of parameter values, calculate the comprehensive priority score of the query template and the specific parameter value combination; Combinations whose overall priority scores exceed the threshold are identified as targets to be actively loaded.

[0010] Preferably, the formula for calculating the popularity score S of the query template is: S = F × W(t) × T × (1 / R), Where F is the number of executions within the preset time window, W(t) is the time decay weight based on the most recent access time, T is the average execution time, and R is the average result set size.

[0011] Preferably, the formula for calculating the overall priority score P is: P = S × R_penalty × P_freq. Where R_penalty is the ranking penalty coefficient calculated based on the position of the query template in the popularity sorted list, and P_freq is the frequency ratio of the high-frequency parameter value in the historical parameters of the query template.

[0012] Preferably, the dynamic adjustment strategy for cached item retention includes: Monitor data change events in the graph database, count the number of times the data related to the cached item changes per unit time, and obtain the data change frequency factor Vf; The access frequency factor Hf is obtained by counting the number of times the cached item is accessed per unit time. The dynamic lifetime of the cached item is calculated according to the formula Retention Time TTL = T_base × (1 - Vf) × (1 + Hf), where T_base is the base lifetime value.

[0013] Preferably, the caching system includes at least: The first caching layer is a memory cache deployed locally on the application. The second caching layer is a distributed shared cache independent of the application. The routing rule is as follows: the query request first accesses the first cache layer; if it misses, it accesses the second cache layer; if it still misses, it queries the graph database. The data synchronization mechanism is as follows: when a query result is hit in the second cache layer, the result is asynchronously written to the first cache layer; when a query result is obtained from the graph database, the result is synchronously written to the second cache layer and the first cache layer corresponding to the application that initiated the query.

[0014] An electronic device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that the processor executes the program to implement a graph database query performance optimization method.

[0015] A system for implementing a graph database query performance optimization method, the system comprising: The log collection and processing module is used to collect and structure graph database query logs. The semantic analysis and knowledge base management module is used to parse and normalize query statements, generate semantic identifiers, and build and maintain a knowledge base that records query pattern characteristics. A hotspot prediction and preloading engine is used to perform popularity modeling and priority calculation based on a knowledge base, and to execute preloading tasks asynchronously; The dynamic cache lifecycle management module is used to monitor data changes and access frequency, and dynamically calculate and adjust the lifecycle of cached data. A multi-level cache coordinator is used to manage architectures containing at least two levels of cache and to perform corresponding routing and data synchronization operations.

[0016] The beneficial effects of this invention are as follows: 1. High-hit-rate semantic caching: Through semantic parsing and normalization, queries with different forms but the same semantics are mapped to a unique cache key, which completely solves the cache redundancy problem caused by syntactic differences and greatly improves the cache hit rate.

[0017] 2. Proactive service and zero cold start: Based on the quantitative model, hot queries are predicted and preloaded asynchronously, so that hot data is ready before the first user request arrives, eliminating the high latency caused by cache cold start.

[0018] 3. Refined lifecycle management: The TTL is dynamically adjusted based on the frequency of data changes and access popularity, achieving an intelligent balance between performance (long cache) and data consistency (short cache), improving the utilization efficiency of cache space and data freshness.

[0019] 4. Highly efficient and collaborative caching architecture: The three-level collaboration of local caching (high speed), distributed caching (capacity and sharing), and database built-in caching (semantic fallback), combined with intelligent routing and backfilling strategies, achieves the lowest access latency and the highest throughput overall, while reducing database load. Attached Figure Description

[0020] Figure 1 This is a schematic diagram of the method flow of the present invention.

[0021] Figure 2 This is a schematic diagram of the system structure of the present invention. Detailed Implementation

[0022] The technical solutions in the embodiments of the present invention are clearly and completely described in the following description. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0023] In the description of the embodiments of the present invention, it should be noted that the indicated orientation or positional relationship is based on the orientation or positional relationship shown in the accompanying drawings, or the orientation or positional relationship in which the product of the invention is conventionally placed during use, or the orientation or positional relationship in which those skilled in the art conventionally understand it during use. This is only for the convenience of describing the present invention and simplifying the description, and is not intended to indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, it should not be construed as a limitation of the present invention. Furthermore, the terms "first" and "second" are only used to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0024] In the description of the embodiments of the present invention, it should also be noted that, unless otherwise explicitly specified and limited, the terms "set" and "connection" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a direct connection or an indirect connection through an intermediate medium. Those skilled in the art can understand the specific meaning of the above terms in the present invention based on the specific circumstances. Example

[0025] Embodiment 1 of the present invention discloses a method for accelerating graph database queries, such as... Figure 1 As shown, the specific method is as follows: S1. Collect log data from graph database queries and process it into a structured query log dataset.

[0026] Through comprehensive and efficient data collection, a true and reliable data foundation is built for all subsequent analysis and decision-making. Specifically, this includes: S11. Employ technologies such as Spring AOP to inject aspects into the call chain between the application and the graph database (such as Nebula Graph), capturing complete context information of each query request without loss, including the original nGQL statement, execution timestamp, execution duration, and execution status (success / failure).

[0027] S12. Using log processing engines (such as Logstash) to process log data from message queues, the raw text-formatted logs are parsed into structured JSON objects with fixed fields using predefined parsing rules (such as Grok pattern). These fields include: nGQL (query statement), timestamp, duration, status, and resultSize. Finally, this structured data is indexed and stored in an Elasticsearch cluster, forming a query log dataset {Qt}=[{nGQL,timestamp,duration,status,resultSize}] that can be used for subsequent analysis.

[0028] The aforementioned log data suffers from redundancy due to syntactic differences. Therefore, through deep parsing and normalization, the essential semantics of the query are extracted, laying the foundation for building a semantic cache with a high hit rate.

[0029] S2. Semantic analysis and normalization to build a knowledge base.

[0030] Queries with the same semantic meaning may have subtle differences in capitalization, spaces, variable aliases, and condition order when written. Traditional caching mechanisms based on the original query string will treat MATCH (u:User) and MATCH (p:User) as two completely different queries, resulting in a large amount of semantically repetitive data being stored in the cache, inefficient use of cache space, and a low hit rate.

[0031] This step aims to eliminate grammatical differences and extract the semantic essence.

[0032] S21. Batch Processing: To avoid impacting online services with real-time processing, set up a scheduled task (executed every 5 minutes) to extract recent (e.g., the past hour) execution logs from Elasticsearch for batch analysis.

[0033] S22. Parsing and Normalization: For each extracted query (e.g., MATCH (u:User)-[:FOLLOWS]->(f:User) WHERE u.name == “Alice” RETURN f), the nGQL parser converts it into an Abstract Syntax Tree (AST). Then, normalization is performed on the AST: Identifier standardization: Convert all labels, attributes, and relation types to lowercase (User -> user, FOLLOWS -> follows).

[0034] Variable alias elimination: Replaces user-defined variables (such as u, f) with standardized placeholders (such as $1, $2).

[0035] Constant parameterization: Replace literal values ​​(such as "Alice") in the WHERE condition with generic parameter placeholders.

[0036] Condition reordering: If WHERE contains multiple conditions connected by AND, they are reordered according to the lexicographical order of the attribute names.

[0037] After the above processing, the example query is normalized to a parameterized query template: `match ($1:user)-[:follows]->($2:user) where $1.name == ? return $2`. Even if another query `MATCH (p:User)-[:FOLLOWS]->(q:User) WHERE p.name = “Alice” RETURN q`, it will still result in the exact same template after normalization.

[0038] S23. Serialize the normalized query template string and calculate its SHA-256 hash value to obtain a 64-bit hexadecimal string (such as 8f3a9b...), which is the unique semantic identifier of the query template.

[0039] S24. Building and updating the knowledge base: Design and create a dedicated knowledge base in the relational database MySQL, establishing the table `query_pattern_knowledge` with the primary key `hash` (a semantic identifier). This table stores statistical metrics for the query templates, including the following core fields: `hash` (hash value (unique semantic identifier), primary key), `parameterized_template` (normalized query template), `total_executions` (total execution count), `average_duration` (average execution time), `timestamps` (timestamps for each execution), `parameters` (query parameters), and `resultSize` (result set size).

[0040] After processing a query, attempt to insert or update a record using the query's hash value as the primary key: If it is a new hash, insert a new record, recording information such as the template, parameters for the first execution, and execution time.

[0041] If the hash already exists, update the statistics for that record: increment total_executions by 1; recalculate average_duration; append the timestamp of this execution and the specific parameter values ​​used to the timestamps and parameters fields respectively; and update the result_size statistics.

[0042] The output of this step is an evolving knowledge base. It categorizes the chaotic raw queries into a limited number of meaningful query templates and assigns a unique semantic identifier to each template. All semantically identical query requests, regardless of their apparent form, will be located at the same cache key, thus completely eliminating cache redundancy caused by syntax differences and greatly improving cache space utilization and hit rate.

[0043] S3, Hotspot Prediction and Asynchronous Preloading A knowledge base built on S2 is used to predict and preheat data.

[0044] S31. Calculate the query template popularity score (S): Scan the knowledge base at regular intervals (e.g., every 15 minutes) and calculate the composite popularity value score for each query template. The formula is: S = F × W(t) × T × (1 / R).

[0045] F: Total number of times this template was executed in the past 2 hours (filtered from timestamps).

[0046] W(t): Time decay weight. Executions within the last 30 minutes are counted as 1.0, 30-60 minutes as 0.7, 60-120 minutes as 0.3, and those more than 2 hours ago are not counted.

[0047] T: The average execution time of this template (average_duration). The longer the execution time, the greater the benefit of caching.

[0048] R: Average result set size (KB). The larger the result set, the more cache space it occupies, so the reciprocal is used to represent the penalty. Using the reciprocal as a penalty guides the system to prioritize warming up "small but valuable" data, thus optimizing cache space usage.

[0049] S32. Identifying High-Frequency Parameters and Calculating Overall Priority: For the top N query templates (e.g., Top 20) with high popularity scores S, analyze the historical parameters recorded in their parameters field. Identify parameter values ​​whose frequency exceeds a certain percentage (e.g., 5%), and define them as "high-frequency parameters" of that template. Calculate the overall priority score P = S × R_penalty × P_freq for the "template-parameter" combination. Where R_penalty is the penalty coefficient based on template popularity ranking (the higher the ranking, the closer the coefficient is to 1), and P_freq is the historical frequency of the parameter. This mechanism ensures that preloaded resources are always allocated to the most popular and most likely to be requested immediately.

[0050] S33, Decision and Preloading: Set a threshold (e.g., P > 500 and S > 1000). "Template-high-frequency parameter" combinations that reach the threshold (e.g., template 8f3a9b… + parameter "Alice") are identified as preloading targets. This involves replacing the placeholders "?" in the parameterized template with the specific parameter "Alice," restoring it to an executable nGQL statement, and then placing this query task into the RabbitMQ asynchronous task queue.

[0051] S34. Asynchronous Execution: The background worker thread consumes the preloaded tasks in the queue, executes the query, and stores the obtained result set in the Redis distributed cache (as an L2 cache) with "8f3a9b…::Alice" as the key. At this point, although the user has not yet requested the data, the hot data "user Alice's followed list" is already ready in the cache.

[0052] S4, Adaptive Cache Lifecycle Management For each cached data item (e.g., "8f3a9b…::Alice"), its expiration time is dynamically managed. Setting a fixed Time-to-Live (TTL) for cached items is a crude management approach. For frequently changing data, an excessively long TTL can lead to dirty reads; for stable but frequently accessed data, an excessively short TTL can cause premature cache expiration, resulting in cache penetration and increasing database load. This "one-size-fits-all" strategy cannot adapt to the dynamic nature of data.

[0053] S41, Monitoring Factor: Change Frequency Factor (Vf): Monitors the change log of the Nebula Graph graph database (or via triggers). A "change event" is recorded and a counter increments whenever a vertex or edge associated with a cached item is updated or deleted. The number of changes C_current over the past hour is counted, and Vf = min(1, C_current / C_max), where C_max is the set maximum change threshold (e.g., 100 changes / hour).

[0054] Access popularity factor (Hf): Counts the number of times the cache item has been accessed in the L1 or L2 cache, A_current (in the past 1 hour). Calculate Hf = min(1, A_current / A_max), where A_max is the set maximum access threshold (e.g., 1000 times / hour).

[0055] S42. Dynamically calculate the expiration time TTL: Use the formula TTL = Base_TTL × (1 - Vf) × (1 +Hf). Where Base_TTL is the preset base lifetime (e.g., 10 minutes).

[0056] If the data is stable (small Vf) and popular (large Hf), the TTL will be significantly extended (e.g., >10 minutes).

[0057] If the data is volatile (Vf is large) or unpopular (Hf is small), the TTL will be shortened (e.g., <10 minutes, or even close to 0).

[0058] S43. Periodic Adjustment: Periodically (e.g., every minute) scan cache items, recalculate and update their TTL based on the latest Vf and Hf, and adjust the lifespan of each cached data item according to the expiration time TTL (i.e., delete items that have exceeded the expiration time TTL).

[0059] S5, multi-level caching collaboration and intelligent routing Local memory caching is the fastest, but has limited capacity and cannot be shared across multiple application instances; distributed caching has large capacity and can be shared, but network access introduces latency; database built-in caching is deeply coupled with the engine, but its policies are opaque. No single layer can simultaneously meet all needs. Therefore, a multi-level caching system is needed.

[0060] S51 Multi-level Cache At least include the second-level cache pyramid: L1 (Local Application Cache): Based on high-performance local memory caching (such as Caffeine), it provides nanosecond-level response and solves the problem of repeated access to extremely hot data within a single instance, but data silos exist.

[0061] L2 (Distributed Shared Cache): Based on Redis cluster, it provides millisecond-level response and large capacity, stores globally hot data, enables cross-instance sharing, and is the main carrier layer for preloading.

[0062] L3 (Graph Database Built-in Cache): Utilizes the caching mechanism of graph databases such as Nebula Graph as the underlying layer for semantic awareness.

[0063] When a user initiates a query request (such as looking up Alice's following list): S52. Application Layer Interception and Normalization: When a request is intercepted by AOP, the query statement is immediately subjected to the real-time normalization process described in S2 to obtain the semantic identifier 8f3a9b… and the parameter “Alice”, which are then concatenated into the cache key “8f3a9b…::Alice”.

[0064] S53, Intelligent Router Query: Level 1: First, query the Caffeine cache in the application server's local memory. If a match is found, return the result directly with extremely low latency (nanoseconds).

[0065] Level 2: If L1 cache misses, query the Redis cluster using the same cache key. If a match is found, while returning the result to the user, trigger an asynchronous task to asynchronously populate the result back into the current server's L1 cache for subsequent local requests to use quickly.

[0066] Level 3: If the L2 query still fails to hit (indicating it's not a preloaded hotspot or has expired), the query will be pushed down to the graph database. First, the graph database's built-in cache is used (if supported). If the built-in cache also fails to hit, a disk query is finally executed.

[0067] Once the query finally retrieves the results from the database, a synchronous write operation is performed: a. Synchronously write the result to Redis (key: "cache:8f3a9b...::Alice"), along with the currently calculated dynamic TTL.

[0068] b. Synchronously write the results to the Caffeine cache of the server where the current request thread resides.

[0069] This mechanism ensures data collaboration and eventual consistency across multiple cache levels, leveraging the extreme speed of L1 cache while achieving capacity sharing and avoiding cold starts through L2 cache, thereby reducing database load. Example

[0070] This embodiment provides a graph database query acceleration system that implements the above method. This system can be deployed as a standalone middleware service or integrated into an application framework. For example... Figure 2As shown, the system includes: The log collection and processing module is used to collect and structure graph database query logs. The semantic analysis and knowledge base management module is used to parse and normalize query statements, generate semantic identifiers, and build and maintain a knowledge base that records query pattern characteristics. A hotspot prediction and preloading engine is used to perform popularity modeling and priority calculation based on a knowledge base, and to execute preloading tasks asynchronously; The dynamic cache lifecycle management module is used to monitor data changes and access frequency, and dynamically calculate and adjust the lifecycle of cached data. A multi-level cache coordinator is used to manage architectures containing at least two levels of cache and to perform corresponding routing and data synchronization operations.

[0071] The modules communicate and work together through an internal bus or message queue.

[0072] This approach systematically addresses three objectives that are difficult to optimize simultaneously in a single caching system: access speed, data capacity, and shared consistency. Through an intelligent routing and data backfilling strategy, it ensures that user query requests are automatically guided to the most appropriate cache level for processing, thereby achieving the lowest overall access latency and the highest system throughput.

[0073] This invention is not limited to the specific embodiments described above. The invention extends to any new feature or combination disclosed in this specification, as well as any new method or process step or combination disclosed herein.

Claims

1. A method for accelerating graph database queries, characterized in that, include: S1. Collect log data from graph database queries and process it into a structured query log dataset; S2. Parse and semantically normalize the query statements in the structured dataset to generate parameterized query patterns, calculate their unique semantic identifiers, and build and maintain a knowledge base. S3. Based on the historical execution information in the knowledge base, identify the query template and parameter combination that meet the preset conditions, and actively load the query results into the cache system; S4. Based on the graph data update status associated with the cache item and the access status of the cache item, dynamically adjust the retention strategy of the cache item in the cache system; S5. Configure a caching system with at least two layers and define the routing rules for query requests in the caching system and the data synchronization mechanism between different caching layers.

2. The method according to claim 1, characterized in that, Step S2 includes: Parse the query statement into an abstract syntax tree; Perform at least one semantically preserving transformation operation on the abstract syntax tree, the transformation operation being selected from: identifier format standardization, conditional reordering based on logical commutative law, normalization of user variable names to system variable names, and replacement of constants with parameter placeholders; Based on the transformed abstract syntax tree, a parameterized query template is generated; The parameterized query template is calculated to generate its unique identifier.

3. The method according to claim 1, characterized in that, Step 2, which involves building and maintaining the knowledge base, includes: Using the unique identifier as the primary key, the statistical information of the query template is recorded in the knowledge base. The statistical information includes: cumulative execution count, average execution time, historical execution timestamp sequence, parameter value sequence used, and result set size. When the query template is executed again, the statistical information of the corresponding record in the knowledge base is updated.

4. The method according to claim 1, characterized in that, Step 3 includes: Based on the statistical information, calculate the popularity score for each query template; For each query template, analyze its historical parameter value sequence to determine the frequently occurring parameter values; Based on the popularity score and the frequency of parameter values, calculate the comprehensive priority score of the query template and the specific parameter value combination; Combinations whose overall priority scores exceed the threshold are identified as targets to be actively loaded.

5. The method according to claim 4, characterized in that, The formula for calculating the popularity score S of the query template is: S = F × W(t) × T × (1 / R), Where F is the number of executions within the preset time window, W(t) is the time decay weight based on the most recent access time, T is the average execution time, and R is the average result set size.

6. The method according to claim 4 or 5, characterized in that, The formula for calculating the overall priority score P is: P = S × R_penalty × P_freq. Where R_penalty is the ranking penalty coefficient calculated based on the position of the query template in the popularity sorted list, and P_freq is the frequency ratio of the high-frequency parameter value in the historical parameters of the query template.

7. The method according to claim 1, characterized in that, The dynamic adjustment of cache item retention strategy in step S4 includes: Monitor data change events in the graph database, count the number of times the data related to the cached item changes per unit time, and obtain the data change frequency factor Vf; The access frequency factor Hf is obtained by counting the number of times the cached item is accessed per unit time. The dynamic lifetime of the cached item is calculated according to the formula Retention Time TTL = T_base × (1 - Vf) × (1 + Hf), where T_base is the base lifetime value.

8. The method according to claim 1, characterized in that, The caching system described in step S5 includes at least: The first caching layer is a memory cache deployed locally on the application. The second caching layer is a distributed shared cache independent of the application. The routing rule is as follows: the query request first accesses the first cache layer; if it misses, it accesses the second cache layer; if it still misses, it queries the graph database. The data synchronization mechanism is as follows: when a query result is hit in the second cache layer, the result is asynchronously written to the first cache layer; when a query result is obtained from the graph database, the result is synchronously written to the second cache layer and the first cache layer corresponding to the application that initiated the query.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the graph database query acceleration method as described in any one of claims 1 to 8.

10. A graph database query acceleration system, characterized in that, The system for implementing the method as described in any one of claims 1 to 8 comprises: The log collection and processing module is used to collect and structure graph database query logs. The semantic analysis and knowledge base management module is used to parse and normalize query statements, generate semantic identifiers, and build and maintain a knowledge base that records query pattern characteristics. A hotspot prediction and preloading engine is used to perform popularity modeling and priority calculation based on a knowledge base, and to execute preloading tasks asynchronously; The dynamic cache lifecycle management module is used to monitor data changes and access frequency, and dynamically calculate and adjust the lifecycle of cached data. A multi-level cache coordinator is used to manage architectures containing at least two levels of cache and to perform corresponding routing and data synchronization operations.

Images