Adaptive triggering optimization method, device and equipment for reverse query of graph database and medium

Abstract

The application discloses a kind of graph database's backtracking query adaptive trigger optimization method, device, equipment and medium, relate to data processing technical field, method includes: relying on the system performance data of real-time monitoring and the graph data change log of graph database, after receiving backtracking query request, dynamically determine whether to trigger graph structure optimization process;After confirming triggering, adjust graph structure according to preset optimization strategy.The application can realize the automatic triggering and dynamic execution of graph structure optimization, ensure that system is always adapted to dynamically changing query mode and real-time data update scene.

Description

Technical Field

[0001] This invention relates to the field of data processing, and more specifically, to a method, apparatus, device, and medium for adaptive triggering optimization of backward query in graph databases. Background Technology

[0002] Graph databases, with their powerful ability to handle relationships, have become a core technology in fields such as knowledge graphs, social networks, and recommendation systems. Traditional graph database systems (such as Neo4j and RDF databases) typically rely on predefined indexing strategies, static query rewriting, and graph partitioning techniques to optimize query performance. In reverse query scenarios, the system deduces preceding relationships from the target node, often used for complex business operations such as task tracing and causal analysis.

[0003] Existing graph databases struggle to adapt to dynamic query scenarios when performing backward lookup queries, and are inefficient when handling complex backward lookup queries. Summary of the Invention

[0004] This invention provides a method, apparatus, device, and medium for adaptive triggering optimization of graph database backward query, which can realize automatic triggering and dynamic execution of graph structure optimization, so that the system can always adapt to dynamically changing query modes and real-time data update scenarios.

[0005] In a first aspect, the present invention provides an adaptive triggering optimization method for backward querying in graph databases, comprising:

[0006] Upon receiving a reverse query request, retrieve real-time system performance data and graph data change logs from the graph database;

[0007] Determine whether to trigger the graph structure optimization process based on system performance data and graph data change logs;

[0008] If the graph structure optimization is determined to be triggered, the graph structure is adjusted according to the preset optimization strategy.

[0009] In one alternative implementation of the first aspect, the system performance data includes query latency data and system resource data.

[0010] In an optional implementation of the first aspect, the step of determining whether to trigger the graph structure optimization process based on system performance data and graph data change logs includes:

[0011] Calculate the delay score for time t based on the query delay corresponding to the most recent completed reverse query before the time t when the current reverse query request is received;

[0012] Calculate the resource score for time t based on the real-time CPU utilization and real-time memory usage at time t.

[0013] The change score at time t is calculated based on the total number of changes to nodes and edges in the graph structure within a preset time window prior to time t.

[0014] The trigger score is calculated based on the delay score, resource score, and change score.

[0015] Based on the comparison between the trigger score and the preset trigger threshold, it is determined whether to trigger the graph structure optimization process.

[0016] In an optional implementation of the first aspect, the calculation of the trigger score based on the delay score, resource score, and change score includes:

[0017] The trigger score is obtained by performing a weighted summation of the delay score, resource score, and change score.

[0018] In an alternative implementation of the first aspect, the optimization strategy includes at least one optimization operation for the graph structure, and the type of optimization operation includes at least node merging and shortcut edge creation.

[0019] In an alternative implementation of the first aspect, the method further includes:

[0020] Each optimization operation in the optimization strategy is converted into a corresponding standardized scheduling task;

[0021] Based on the expected reduction in the back-query path length for each scheduled task's corresponding optimization operation, calculate the impact score for the corresponding scheduled task.

[0022] The complexity score of each scheduling task is determined based on the number of changes to nodes and edges involved in the optimization operations of each scheduling task.

[0023] Based on the historical query frequency of the backward query path associated with each optimization operation, the urgency score of the corresponding scheduling task is determined.

[0024] The priority score of each scheduling task is determined based on its impact score, complexity score, and urgency score.

[0025] In an optional implementation of the first aspect, determining the priority score of each scheduling task based on its impact score, complexity score, and urgency score includes:

[0026] The priority score of each scheduling task is obtained by weighted summation of its impact score, complexity score, and urgency score.

[0027] Secondly, the present invention provides an adaptive triggering optimization device for backward querying of graph databases, comprising:

[0028] The acquisition module is used to acquire real-time monitoring system performance data and graph data change logs in the graph database after receiving a backward query request;

[0029] The judgment module is used to determine whether to trigger the graph structure optimization process based on system performance data and graph data change logs;

[0030] The adjustment module is used to adjust the graph structure according to a preset optimization strategy when the graph structure optimization is determined to be triggered.

[0031] Thirdly, the present invention provides a computer device including a memory and a processor. The memory stores a computer program, and when the computer program is executed by the processor, the processor performs the steps of the graph database backward query adaptive triggering optimization method provided in the first aspect.

[0032] Fourthly, the present invention provides a computer-readable storage medium storing a computer program, which, when executed by a processor, causes the processor to perform the steps of the graph database backward query adaptive triggering optimization method provided in the first aspect.

[0033] The method, apparatus, device, and medium for adaptive triggering optimization of graph database backward queries provided by this invention have at least the following beneficial effects:

[0034] Based on real-time monitoring of system performance data and graph data change logs in the graph database, the system dynamically determines whether to trigger the graph structure optimization process upon receiving a backward query request. Once triggered, the graph structure is adjusted according to the preset optimization strategy, thereby achieving automatic triggering and dynamic execution of graph structure optimization and ensuring that the system always adapts to dynamically changing query patterns and real-time data update scenarios. Attached Figure Description

[0035] Figure 1 The structural diagram of the graph database backward query optimization system provided by this invention;

[0036] Figure 2 This is a topological diagram of the graph structure before adjustment provided by the present invention;

[0037] Figure 3 This is a schematic diagram of the topology after the graph structure adjustment provided by the present invention;

[0038] Figure 4 A schematic diagram illustrating the adaptive triggering optimization process for backward querying in a graph database, provided as an embodiment of the present invention;

[0039] Figure 5 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present invention. Detailed Implementation

[0040] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0041] Graph databases (such as Neo4j and RDF) are widely used in knowledge graphs, social networks, and recommender systems due to their advantage in handling complex relational data. Performance can be optimized through query rewriting, indexing, and partitioning, but these methods are typically based on static graph structures or predefined rules. Graph databases have the ability to generate nodes in reverse, but the backward reasoning of nodes and edges is mainly based on static graph structures or predefined rules, making it difficult to adapt to dynamic query patterns and data changes. Furthermore, backward reasoning in knowledge graphs and RDF databases for semantic reasoning also lacks a mechanism for dynamically adjusting the graph structure. As data scale and query complexity increase, traditional graph databases face performance bottlenecks.

[0042] Existing optimization techniques, such as Hypermode Query Optimization, Adaptive Partitioning (IEEE), and backward chaining, are used in knowledge graphs and semantic queries to deduce preconditions from the target, but they generate a large number of intermediate nodes, leading to the following technical problems:

[0043] (1) Traditional graph databases are inefficient when dealing with complex backward queries, especially in dynamic data environments.

[0044] (2) The reverse reasoning generates a large number of intermediate nodes, resulting in a long path and increased computation and storage overhead.

[0045] (3) Existing optimization methods (such as query rewriting and graph partitioning) are based on static structures and are difficult to adapt to changes in query patterns in real time.

[0046] (4) Lack of intelligent mechanisms to predict high-frequency query paths or optimize graph structures.

[0047] To address at least one of the aforementioned technical issues, this invention proposes a novel graph database feature—Dynamic Backward Chaining Optimization Extension (DBCOE)—aimed at improving the efficiency of backward chaining queries, particularly in complex project scenarios (such as project management and supply chain analysis). This feature significantly reduces query latency and resource consumption by optimizing the graph structure in real time, utilizing AI prediction and dynamic adjustments, thereby improving long-term performance.

[0048] The following section provides a detailed description of the graph database backward query optimization system proposed in this invention.

[0049] Please see Figure 1 The graph database backward query optimization system proposed in this invention includes:

[0050] The coordination module is used to coordinate the data flow and control flow between the graph structure optimization module, the optimization suggestion module, and the adaptive adjustment module, so as to drive each module to complete the graph structure optimization of the graph database based on the backward query request;

[0051] The adaptive adjustment module is used to generate a trigger signal when it is determined that the graph structure needs to be optimized based on real-time monitoring system performance data and graph data change logs.

[0052] The optimization suggestion module is used to respond to trigger signals, determine the critical path and critical nodes of the graph structure based on historical query logs, and generate optimization strategies for graph structure adjustment based on the critical path and critical nodes.

[0053] The adaptive adjustment module is also used to generate a scheduling scheme based on the optimization strategy. The scheduling scheme includes the priority of each scheduling task, and each scheduling task corresponds to an optimization operation of a graph structure.

[0054] The graph structure optimization module is used to perform at least one optimization operation among node merging, path merging, path parallelism, and shortcut edge creation in response to a scheduling scheme to reconstruct the graph structure.

[0055] Reverse query (or "backward search") refers to a query method in graph databases that starts from a target node and searches for or traces relationships in the reverse direction. This type of query does not rely on a pre-defined "starting point → ending point" unidirectional path, but rather traverses the graph structure backward according to business needs to discover hidden associations or verify causal relationships. For example, if the original relationship is A → B, a reverse query starts from B and finds which nodes point to B, or, given a node has a certain attribute, it traces back all its upstream dependent nodes.

[0056] Among them, the adaptive adjustment module, optimization suggestion module and graph structure optimization module mentioned above can be deployed in the system as plug-ins or extension modules, such as running as a Neo4j plug-in and integrating with existing graph databases.

[0057] The technical principles and specific implementation methods of the adaptive adjustment module are explained in detail below.

[0058] The Self-Adaptive Adjustment Mechanism (SAAM) module is responsible for real-time monitoring of system performance data and graph structure changes during backward lookup queries, automatically triggering graph structure optimization processes to ensure the system adapts to dynamic query patterns and data updates. This module optimizes query efficiency and resource utilization through a Performance-Triggered Optimization (PTO) algorithm combined with dynamic scheduling strategies, making it particularly suitable for complex project scenarios (such as scheduling dependency tracing in project management).

[0059] The system performance data includes query latency data and system resource data. Query latency data includes the query latency for a single reverse query. System resource data includes CPU and memory usage data.

[0060] Query latency is defined as the time difference between the start and end times of a single reverse query, measured in milliseconds (ms). For example, if a reverse query request is received at 10:00 and the response time and result display time are 10:02, the query latency is 2ms. This metric can be collected by the Prometheus monitoring module from the Neo4j server. The Neo4j server calculates the query latency of a single reverse query in real time and stores it in the Prometheus latency table TSDB. The Neo4j server can also push the real-time calculated query latency to the adaptive tuning module, or the adaptive tuning module can collect the query latency of a single reverse query in real time from the Prometheus TSDB.

[0061] In one alternative implementation, the adaptive adjustment module is specifically used to perform the following steps:

[0062] Obtain real-time system performance data and graph data change logs from the graph database;

[0063] Determine whether to trigger the graph structure optimization process based on system performance data and graph data change logs.

[0064] Given that the trigger graph structure is optimized, a trigger signal is generated.

[0065] Optionally, determining whether to trigger the graph structure optimization process based on system performance data and graph data change logs may include:

[0066] Calculate the delay score for time t based on the query delay corresponding to the most recent completed reverse query before the time t when the current reverse query request is received;

[0067] Calculate the resource score for time t based on the real-time CPU utilization and real-time memory usage at time t.

[0068] The change score for time t is calculated based on the total number of changes to nodes and edges in the graph structure within a preset time window (e.g., the past 60 seconds) prior to time t.

[0069] The trigger score is calculated based on the delay score, resource score, and change score.

[0070] Based on the comparison between the trigger score and the preset trigger threshold, it is determined whether the graph structure needs to be optimized.

[0071] Optionally, the delay score for time t is calculated based on the query delay corresponding to the most recent completed reverse query before time t, a preset target query delay benchmark, and the historical maximum query delay.

[0072] More specifically, the delay fraction of time t is calculated using the following formula. :

[0073] ,

[0074] Here, LatencyScore(t) ranges from [0,1], latency_ms(t) is the query latency of the most recent completed reverse query before time t (obtained from the latest record in Prometheus's TSDB), latency_baseline is the target query latency baseline, and max(latency_ms) is the historical maximum query latency. latency_baseline and max(latency_ms) are calculated using historical metrics and stored in memory, and are updated on a rolling basis at preset time intervals (e.g., hourly). max(latency_ms) is the maximum query latency within the most recent preset historical time period (e.g., the past 24 hours). latency_baseline is determined by statistically analyzing the 50th percentile (median) of all reverse query latencies within the preset historical time period to reflect the typical query latency level of the system under normal load. When latency_ms(t) exceeds latency_baseline, LatencyScore(t) is greater than 0, triggering a latency assessment.

[0075] Optionally, the resource score for time t is determined based on the real-time CPU utilization, historical CPU utilization, real-time memory usage, and historical memory usage at time t.

[0076] More specifically, the resource score for time t is calculated using the following formula. :

[0077] ,

[0078] ,

[0079] .

[0080] in, The range is [0,1], which is used to measure resource pressure and trigger optimization to reduce resource consumption. This represents the CPU usage score at time t, ranging from [0,1]. It measures the CPU load on the Neo4j server during queries and triggers optimizations to reduce resource pressure. CPU utilization at time t represents the percentage of CPU usage by the Neo4j server when executing reverse queries (unit: percentage, range [0,1]), reflecting the server's computational load. It is collected by Prometheus through Neo4j's monitoring endpoint, stored in TSDB, and transmitted to a memory buffer in real time. `max(cpu_usage)` is the historical maximum CPU utilization (unit: percentage). As an example, CPU utilization over the past 24 hours can be used for calculation, and it can be stored in a memory circular buffer. MemoryUsage(t) represents the memory usage score at time t, ranging from [0,1], used to measure the memory load of the Neo4j server during queries and trigger optimizations to reduce resource consumption. Memory_mb(t) represents the memory usage at time t, in megabytes (MB), indicating the memory usage of the Neo4j server during queries. It is collected by Prometheus from the Neo4j server's memory monitoring metrics, recording instantaneous memory usage. Max(memory_mb) is the maximum historical memory usage, in megabytes (MB), used to normalize memory_mb(t). It provides a normalization baseline to ensure that MemoryUsage(t) is within the range of [0,1]. It can be extracted from Prometheus's TSDB for the past 24 hours' memory_mb metrics and the maximum value is calculated.

[0081] Specifically, the change score for time t is determined based on the total number of changes to nodes and edges in the graph structure within a preset time window between times t and the total number of historical changes.

[0082] More specifically, the change score ChangeScore(t) for time t is calculated using the following formula:

[0083] ,

[0084] num_changes(t)=node_changes(t)+edge_changes(t),

[0085] ChangeScore(t) ranges from [0,1] and is based on the change rate of nodes and edges. It is used to measure changes in the graph structure and trigger optimization to adapt to new data. num_changes(t) represents the total number of node and edge changes in the graph structure adjustment within a preset time window before time t. node_changes(t) and edge_changes(t) represent the number of node changes (i.e., the number of nodes deleted or merged) and the number of edge changes (i.e., the number of all edges affected by the deleted or merged nodes) in the graph structure adjustment within the preset time window before time t, respectively. These can be obtained from the graph structure change log. max(num_changes) represents the maximum value of the total number of historical changes, in units of times, used to normalize num_changes(t). It provides a normalization benchmark to ensure that ChangeScore(t) is within the range of [0,1]. Its value can be determined by extracting the maximum value of num_changes(t) over 24 hours.

[0086] Optionally, the delay score, resource score, and change score can be weighted and summed to obtain the trigger score.

[0087] Specifically, the trigger score is calculated using the following formula. :

[0088] α, β, and γ are trigger weights, which are unitless and can be initially set to 0.5, 0.3, and 0.2, respectively. α, β, and γ are used to balance the impact of latency, resources, and changes to optimize trigger decisions. α, β, and γ are tuned through grid search and range [0.1, 0.9]. The trigger accuracy is based on the validation set, which is extracted from historical query logs, performance metrics, and change logs and stored in memory.

[0089] In the above scheme, unlike traditional static scheduling (such as timed optimization), this invention designs a multi-dimensional performance trigger condition (latency, resources, change rate) to execute the PTO algorithm for backward query, which adapts to backward query and data changes in real time.

[0090] When the adaptive adjustment module determines that the trigger score is greater than a preset trigger threshold (e.g., 0.7), it generates a trigger signal and sends it to the optimization suggestion module, or forwards it to the optimization suggestion module through the coordination module. This allows the optimization suggestion module to filter key nodes and key paths based on historical query logs and generate an optimization strategy. This optimization strategy includes at least one optimization operation for the graph structure, and the types of optimization operations include node fusion, path fusion, path parallelism, and shortcut edge creation. How the optimization suggestion module generates optimization strategies is described in detail below.

[0091] Specifically, the adaptive adjustment module transforms specific optimization operations in the optimization strategy (such as "merging node a and node b") into standardized scheduling tasks with a unified format and executable capability (i.e., the "merging node a and node b" scheduling task), ensuring that each optimization operation corresponds to a unique scheduling task.

[0092] Then, the adaptive adjustment module calculates the scheduling priority of each scheduling task based on real-time system performance data, that is, the execution order of each scheduling task.

[0093] Specifically, the adaptive adjustment module performs the following steps:

[0094] Based on the expected reduction in the back-query path length for each scheduled task's corresponding optimization operation, calculate the impact score for the corresponding scheduled task.

[0095] The complexity score of each scheduling task is determined based on the number of changes to nodes and edges involved in the optimization operations of each scheduling task.

[0096] Based on the historical access frequency of the reverse query path associated with each optimization operation, the urgency score of the corresponding scheduling task is determined.

[0097] The priority score of each scheduling task is determined based on its impact score, complexity score, and urgency score.

[0098] Among them, the higher the priority score of the scheduled task, the higher its execution priority.

[0099] Specifically, the impact score Impact(k) of the k-th scheduled task is calculated using the following formula:

[0100] .

[0101] Where Impact(k) ranges from [0,1], and est_reduction(k) represents the average length of the backward query path (in hops) expected to be reduced by the k-th scheduled task. Since an optimization operation (such as merging nodes) typically affects multiple backward query paths in the graph simultaneously, and the reduction in length for each path varies, est_reduction(k) uses the path access probability output by the QPP algorithm as the weight, and calculates a weighted average of the path length reductions for all affected paths, as shown in the following formula:

[0102] .

[0103] Among them, P k Let P(p) represent the set of all candidate paths affected by the nodes or edges involved in the k-th scheduling task (i.e., paths containing the operation objects of that scheduling task), and let L be the access probability of path p predicted by the QPP algorithm. before (p) represents the path length (number of hops) of path p before the optimization operation, L after (p) represents the path length (hop count) of path p after the simulated optimization operation. If a path is not affected by this operation, then L... before (p)=L after (p), its contribution to this path is 0. Figure 2 and Figure 3 For example, suppose the scheduling task is to merge nodes b and c, and the set of affected paths P k This includes all candidate paths in the graph that pass through either node b or node c. For the current backward query request "find the source node a of node e", the original backward query path e→d→b→c→a has a path length of 4. After the merge operation, the path length of the corresponding path e→b→d→a is 3, and the path length is reduced by 1 hop. If there are other paths in the graph that pass through nodes b or c, they are also included in the weighted calculation. max(est_reduction) represents the maximum value of est_reduction(k) among all historical scheduled tasks, stored in memory, and updated on a rolling basis at preset time intervals.

[0104] Specifically, the urgency score Urgency(k) of the k-th scheduled task is calculated using the following formula:

[0105] ,

[0106] Urgency(k) ranges from [0,1], representing the timeliness of scheduling and prioritizing tasks related to current high-frequency queries. query_freq(k) represents the access frequency (in times) of the query path associated with the optimization operation of the k-th scheduling task in the historical query log. For optimization operations involving a single node or edge, query_freq(k) is the total number of query paths passing through that node or edge in the historical query log; for operations involving multiple nodes (such as merging nodes b and c), query_freq(k) is the total number of query paths passing through all involved nodes in the historical query log, i.e., the number of historical query records containing both nodes b and c in the path, to accurately reflect the improvement of the optimization operation on actual high-frequency queries. max(query_freq) is the maximum access frequency of query paths involved in all historical optimization operations, such as the maximum value in the past 24 hours, used for normalization.

[0107] Specifically, the complexity score Complexity(k) of the k-th scheduled task is calculated using the following formula:

[0108] ,

[0109] est_cost(k)=c1×num_nodes(k)+c2×num_edges(k),

[0110] in, The value range is [0,1], representing the computational cost of executing the k-th scheduled task. Scheduling efficiency is optimized by reducing the priority of high-complexity scheduling. `est_cost(k)` is the computational cost of the k-th scheduled task (in milliseconds), estimated based on the scheduling type and the number of nodes / edges affected by the corresponding optimization operation. `c1` and `c2` are constants. `num_nodes(k)` is the number of nodes deleted or merged (i.e., eliminated from the graph structure) in the k-th scheduled task, and `num_edges(k)` is the total number of edges that need to be created, redirected, or deleted in the k-th scheduled task, including all incoming and outgoing edges of the eliminated nodes. Figure 2 and Figure 3Taking the graph structure as an example, in the optimization operation of "merging nodes b and c", node c is merged and eliminated, and num_nodes(k) = 1. The outgoing edge of node c "c→b" needs to be redirected to "b→d" (if node c has other outgoing edges, such as "c→g" and assuming there is an edge "c→f", then it needs to be redirected to "b→g"). If node c has incoming edges (such as "a→c"), they also need to be redirected to "a→b". num_edges(k) is the total number of edges that need to be changed. max(est_cost) is the maximum computational cost of all historical optimization operations, in milliseconds (ms), used to normalize est_cost(k), for example, the maximum computational cost of all optimization operations in the past 24 hours.

[0111] Specifically, the priority score P of the k-th scheduling task is obtained by weighted summing of its impact score, urgency score, and complexity score. task(k) That is:

[0112] ,

[0113] in, The range is [0,1]. w1, w2, and w3 are priority weights with no unit. As an example, the initial values ​​of w1, w2, and w3 are 0.5, 0.3, and 0.2, respectively. w1, w2, and w3 can be optimized through grid search, with a range of [0.1,0.9]. Based on the scheduling efficiency of the validation set, the validation set is extracted from historical scheduling execution records and stored in memory.

[0114] The technical principles and specific implementation methods of the optimization suggestion module are explained in detail below.

[0115] In one alternative implementation, the optimization suggestion module is specifically used for:

[0116] Obtain path access information for reverse queries from historical query logs;

[0117] Based on path access information and node association information of the graph structure, the critical paths and critical nodes of the graph structure are selected.

[0118] The reinforcement learning network predicts at least one final optimization operation for the current graph structure based on the output of the critical path and key nodes, and outputs an optimization strategy for graph structure adjustment based on the at least one final optimization operation.

[0119] Optionally, based on path access information and node association information of the graph structure, the key paths and key nodes of the graph structure can be filtered out, which may include:

[0120] By inputting the graph structure and path access information into the graph neural network, the access probability of each path and the access probability of each node can be obtained.

[0121] Based on the access probability of each path, at least one critical path is selected from all paths in the graph structure.

[0122] The access frequency of each node is calculated based on path access information;

[0123] The importance score of each node is determined based on the access probability and access frequency of each node.

[0124] Based on the importance score of each node, at least one key node is selected from all nodes.

[0125] Optionally, the graph neural network is an inductive graph neural network (GraphSampleandAggregate, GraphSAGE) based on sampling and aggregation.

[0126] Specifically, the optimization suggestion module uses the Query Pattern Prediction (QPP) algorithm to predict critical paths and key nodes based on neural networks, including the following steps:

[0127] The graph structure is input into an inductive graph neural network based on sampling and aggregation. The inductive graph neural network extracts the embedding vectors of each node and each path in the graph structure based on the sampling and neighborhood feature aggregation mechanism of the graph topology. The embedding vector is used to characterize the topological association features of the nodes in the graph structure.

[0128] Feature extraction is performed on path access information to obtain the feature vector and access frequency of each path;

[0129] The embedding vectors of each node, the feature vectors of each path, and the access frequency of each path are input into the feedforward artificial neural network model. Based on the feature fusion and nonlinear mapping mechanism of the fully connected layer, the feedforward artificial neural network model fuses the heterogeneous features of the node embedding vectors, the path feature vectors, and the access frequency, and outputs the access probability of each path and the access frequency of each node.

[0130] More specifically, the graph structure is input into GraphSAGE, which performs embedding processing on the nodes in the graph structure to obtain the node embedding vectors, which have a dimension of 128. Finally, the node embedding matrix is ​​output, which is [n, 128], where n is the number of nodes.

[0131] Furthermore, based on historical query logs, each query path is obtained. Then, the attributes (weight, type) of each edge e in each query path are one-hot encoded to generate a 64-dimensional edge attribute vector V(e) of type float32. Then, average pooling is performed on the attribute vector V(e) of all edges in the path to obtain the feature vector of the path, with the formula as follows:

[0132] ,

[0133] in, Representing a path The feature vector is 64-dimensional and of type float32, representing the contextual information of the path (such as edge weights and type). E(p) represents the path. The set of all edges contained, where |E(p)| is the path. The number of edges in the middle.

[0134] Specifically, the feedforward artificial neural network model uses a multilayer perceptron (MLP), and its algorithm formula is as follows:

[0135] ,

[0136] .

[0137] The parameters in the formula above are defined as follows:

[0138] E(s) and E(t) represent the embedding vectors of nodes s and t, respectively. Each vector has 128 dimensions and is of type float32. They are used to capture the semantic and topological information of nodes in the graph structure.

[0139] Representing a path eigenvectors.

[0140] For path The access frequency is represented by 1-dimensional float32 data, reflecting the historical access frequency of the path and enhancing prediction accuracy.

[0141] frequency ) is the path The number of times it appears in the historical query log.

[0142] `max(frequency)` represents the maximum number of occurrences of all query paths in the historical query log.

[0143] W1: The first layer weight matrix of the MLP, with dimensions [385, 128] (where 385 is the total input dimension and 128 is the number of hidden layer neurons), obtained through supervised learning training.

[0144] W2: The second layer weight matrix of the MLP, with dimensions [128,1] (where 128 is the hidden layer output dimension and 1 is the single-value prediction output), obtained through supervised learning training.

[0145] b: Bias vector, 1×1 (float32 type), obtained during training.

[0146] ReLU: Activation function, its mathematical expression is f(x)=max(0,x) (positive input, output x, negative input, output 0).

[0147] σ: Sigmoid activation function, with the formula σ(x)=1 / (1+e−x), is used to normalize the output to a probability value in the interval [0,1].

[0148] The model uses the cross-entropy loss function and iteratively optimizes W1, W2, and b through supervised learning until the predicted access probability converges.

[0149] After obtaining the path access probability and node access probability through MLP, the importance of a node can be calculated based on these probabilities using the following formula:

[0150] ,

[0151] in, Let $n$ represent the importance score of node $n$, ranging from $[0, ∞)$, used to identify key nodes. Nodes with higher importance scores have higher execution priority. $Freq(p)$ is the normalized access frequency of path $p$, ranging from $[0, 1]$. Equivalent. In node importance calculation, the contribution of high-frequency paths to node scores is enhanced to ensure that key nodes reflect the actual usage patterns of reverse queries. P(p) is the predicted probability of path p, ranging from [0,1], which is equivalent to , which is the general representation of the path in the formula. The set of paths containing node n is used to calculate node importance, with a limited range for accumulation.

[0152] After calculating the importance of each node and the access probability of each path, the nodes are sorted from largest to smallest according to their importance, and the paths are sorted from largest to smallest according to their access probability. The top p nodes are selected as critical nodes, and the top q paths are selected as critical paths, where p and q are positive integers and can be the same or different.

[0153] The optimization suggestion module also generates graph structure adjustment strategies based on the key nodes and key paths output by the QPP algorithm and real-time monitoring system performance data to optimize long-term query performance.

[0154] In this invention, the Structure Adjustment Optimization (SAO) algorithm is used to generate a graph structure adjustment strategy.

[0155] Specifically, the structural adjustment optimization algorithm may include the following steps:

[0156] The state transition model predicts the next graph structure state obtained after executing at least one candidate optimization operation based on the critical path and key nodes. Based on the topological features of each next graph structure state, the multi-dimensional performance indicators corresponding to the reverse query of the graph structure after the execution of the corresponding candidate optimization operation are predicted.

[0157] By using the reward function and action selection strategy of reinforcement learning, the final optimization operation is determined based on the multi-dimensional performance indicators of all candidate optimization operations.

[0158] Optionally, based on the topological features of each next graph structure state, predict the multi-dimensional performance metrics corresponding to the reverse query of the graph structure after the execution of the corresponding candidate optimization operation, including:

[0159] Perform the calculation of performance metrics for at least two of the following dimensions:

[0160] Calculation of the average path length reduction ratio: Compare the path features of the original graph structure state with the corresponding next graph structure state, and statistically analyze the change in average path length before and after performing candidate optimization operations to obtain the average path length reduction ratio.

[0161] Calculation of graph structure stability: Count the number of node changes and edge changes between the original graph structure state and the corresponding next graph structure state, and obtain the graph structure stability based on the number of node changes and edge changes;

[0162] Query latency / memory usage calculation: The candidate optimization operation is simulated by a state transition model to construct the next graph structure state. Then, the query performance prediction model is used to predict the query latency and memory usage corresponding to the reverse query performed by the graph database in this state based on the topological features of the next graph structure state.

[0163] The state transition model generates the next graph structure state after the optimization operation in memory without actually writing it to the graph database by virtually inferring the candidate optimization operation on the current graph structure (e.g., simulating merging nodes i and j and updating the node set, edge set, and their relationships). The query performance prediction model is a supervised learning model (e.g., gradient boosting tree) trained on historical data. Its input is the topological feature vector of the next graph structure state (including average path length, number of nodes, number of edges, graph density, in-degree and out-degree of the target node, etc.), and its output is the predicted query latency (ms) and memory usage (MB). This prediction model uses historical graph structure snapshots and corresponding measured query performance metrics as training samples, is trained offline, deployed in memory, and performs online inference during each candidate operation evaluation.

[0164] Optionally, the final optimization operation is determined based on the multi-dimensional performance metrics of all candidate optimization operations using the reward function and action selection policy of reinforcement learning, and an optimization policy for the output graph structure is then established based on the final optimization operation, including:

[0165] By employing a reward function and action selection strategy derived from reinforcement learning, the final optimization operation is determined based on multi-dimensional performance metrics of all candidate optimization operations. Furthermore, a graph structure optimization strategy is output based on the final optimization operation, including:

[0166] The calculated multi-dimensional performance metrics are substituted into the reward function to determine the reward value for each candidate optimization operation.

[0167] The candidate optimization operation with the highest reward value is selected as the final optimization operation.

[0168] Specifically, the core logic of DQN (Deep Q-Network) is: learning state s → action a → next state s' → reward. The mapping relationship is used to optimize the value function Q(s,a) to select the optimal action. In this invention, the state transition model is defined as responsible for the topological derivation of "s→s′" in DQN and is the carrier for generating the next state s′.

[0169] In this invention, state s includes the topological features (node / edge distribution) and real-time performance metrics (query latency, memory usage) of the current graph structure.

[0170] The set of actions for 'a' is {merge_nodes(node_i, node_j), add_shortcut(source, target, weight), no_action}, corresponding to the optimization operation types of node merging, shortcut edge creation, and no action, respectively, used to modify the graph structure. Specifically, the action `merge_nodes(node_i, node_j)` merges nodes i and j, the action `add_shortcut(source, target, weight)` creates a shortcut edge between the source and target nodes and sets the weight of the created shortcut edge, and `no_action` indicates that no optimization operation is performed.

[0171] award The combined benefits of merging latency, memory usage, path simplification, and stability are calculated using the following formula:

[0172] .

[0173] The parameters in the formula are defined as follows:

[0174] The normalized query latency of time t, ranging from [0,1], is used to penalize high latency to optimize query speed. Its calculation formula is as follows: ,in, The data is obtained from the Prometheus monitoring system, normalized, and stored in a circular buffer in memory. max(latency_ms) is the maximum value of historical query latency.

[0175] MemoryUsage(t): Normalized memory usage over time t, in the range [0,1]. The calculation logic is the same as that of Latency(t).

[0176] PathReduction(t): The percentage reduction in the average path length of the backward query after performing candidate optimization operations, ranging from [0,1]. The calculation formula is... Where L(p_before) is the length of the relevant backward query path before the action is executed, and L(p_after) is the length of the corresponding path after the action is executed. The definition of "relevant path" is: if the merge operation between node h and node i is executed, then all backward query paths containing node h or node i are associated.

[0177] Stability(t): The structural stability score of the graph, ranging from [0,1]. A higher score indicates smaller structural changes and stronger stability. The calculation formula is as follows: , where num_changes(a) is the sum of the number of nodes that need to be deleted or merged and the number of edges that need to be created, redirected or deleted when performing action a, and is named the total number of node and edge changes; max(num_changes) is the maximum value of the total number of node and edge changes within the historical time period.

[0178] α, β, δ, and ϵ are reward weights (unitless), with initial values ​​of 0.4, 0.3, 0.2, and 0.1 respectively, used to balance latency, memory usage, path simplification benefits, and structural stability. Optimization is achieved through a grid search method within the range [0.1, 0.9], using iterative optimization based on the mean reward from the validation set (extracted from historical query logs and performance metrics, and stored in memory).

[0179] The value function is used to calculate the expected cumulative reward of action 'a' in state 's', guiding action selection and determining whether to perform graph structure adjustments (such as merging nodes or adding edges). Its formula is: ,in, This is the discount factor.

[0180] In the above scheme, this scheme deeply integrates the backward access frequency characteristics into the path / node importance prediction logic, and constructs a multi-dimensional index based on query latency, memory usage, path simplification, graph structure stability and other indicators to evaluate the performance of graph structure optimization, thereby achieving a dynamic balance between the benefits and costs of graph structure optimization operations, and ultimately achieving the dual goals of improving query performance and ensuring graph structure stability.

[0181] It's important to note that the SAO algorithm selects a single optimal optimization action each time through DQN and executes it iteratively. Its output is a graph structure optimization strategy (i.e., determining which optimization operations to execute). The critical nodes and critical paths predicted by QPP provide a candidate action space for DQN, not all of which are tasks that need to be executed synchronously. The scheduling priority calculation of the PTO algorithm is applied after the SAO output. Its purpose is to dynamically determine the execution order and timing of multiple determined scheduling tasks based on the current real-time system load (CPU, memory, query latency) and the impact of each task on the current query. Therefore, SAO is responsible for the quality decision of the optimization strategy, while PTO is responsible for the timing management of the execution schedule. The two have different functions but cooperate with each other.

[0182] The technical principles and specific implementation methods of the dynamic graph structure optimization module are introduced below.

[0183] Among them, the Dynamic Graph Structure Optimization Module (DGSOM) is the core component for backward chaining optimization of graph databases. As an extension function of existing graph databases (such as Neo4j), it reduces query complexity and latency through node fusion, parallel path identification, and shortcut edge creation.

[0184] In this invention, the dynamic graph structure optimization module performs graph structure operations in two triggering modes: the first is graph structure adjustment triggered by the optimization strategy output by the optimization suggestion module (defined as "performance adaptive triggering mode"), and the second is real-time optimization automatically triggered when receiving a backward query request (defined as "normal mode").

[0185] In normal mode, when DGSOM intercepts a backward query request, it autonomously calculates node similarity, path independence, and path frequency based on historical query logs, completing node fusion, parallel path grouping, and shortcut edge creation. In performance adaptive trigger mode, DGSOM receives a scheduling scheme from the adaptive tuning module, eliminating the need to repeatedly calculate node and path priority (this task is already handled by the optimization suggestion module), and directly executes optimization operations according to the scheduling task list and priority order. The two modes are functionally independent and are suitable for real-time query optimization and system-level proactive tuning scenarios, respectively.

[0186] The specific implementation method of the performance adaptive triggering mode is described below.

[0187] After the adaptive adjustment module outputs a scheduling scheme containing a list of scheduled tasks and the priority of each scheduled task, it is transmitted to the graph structure optimization module through the coordination module. The dynamic graph structure optimization module responds to the scheduling scheme and executes each scheduled task in sequence according to its priority.

[0188] The following describes the specific implementation of the conventional mode. In the conventional mode, the dynamic graph structure optimization module executes the dynamic node fusion and path optimization method of the graph database. This method includes:

[0189] D10 receives the backward query request and determines the graph structure associated with the target node based on the backward query request.

[0190] Specifically, the system receives a backward query request submitted by the user, intercepts and parses the request. This request contains a target node identifier. Based on this identifier, the system extracts the target node's attribute data from the graph database and retrieves the entire subgraph structure associated with the target node as the current graph structure. Simultaneously, the system obtains the contextual constraints accompanying the query, such as attribute filtering or path length limits, for constraint judgment in subsequent optimization processes. This ensures that optimization operations are based on accurate query intent and the current data state.

[0191] It's important to note that the target node in the backward query request does not represent the entire project entity, but rather a specific milestone node in the graph database (e.g., a node indicating "Project X is completed"), identified by a unique node ID. Since the project itself consists of multiple task nodes interconnected via dependency edges, forming a network graph, the system starts with the target node ID and recursively retrieves all upstream task nodes and dependent edges directly or indirectly associated with the target node by traversing all its incoming edges in reverse (i.e., along the opposite direction of the edge). This constructs a complete subgraph structure associated with the backward query request, which serves as the current graph structure for subsequent optimization operations. As an example, assuming node e is the node indicating "Project X is completed," and the backward query request is "find the source node of the node indicating 'Project X is completed'," the final result would be as follows: Figure 2 The aforementioned structural diagram.

[0192] D20 identifies and merges nodes with similar functions in the graph structure based on node access information in historical query logs.

[0193] Specifically, the system retrieves the historical query logs of the current graph structure, which record the access frequency of each node and each query path. Then, it calculates multidimensional similarity based on the access frequency of nodes and their attribute information.

[0194] Specifically, the similarity score for each pair of nodes is calculated using the Node Similarity Detection and Fusion (NSDF) algorithm. The range includes [0,1]:

[0195] .

[0196] in, Represents embedding similarity, where and It is a 128-dimensional node embedding vector generated by a graph neural network. Represents attribute similarity, where, and It is the collection of node attributes. Represents frequency similarity, where and This is the node access frequency statistically analyzed from historical query logs. The initial values ​​of the weighting coefficients α, β, and γ are preferably 0.5, 0.3, and 0.2, respectively, but can be adjusted according to actual needs in practical applications.

[0197] Specifically, the formula for calculating embedding similarity is as follows:

[0198] .

[0199] in, Represents a node Embedded vector, Represents a node The embedding vectors are generated by a graph neural network (GNN) with a dimension of 128 (float32).

[0200] The formula for calculating attribute similarity is as follows:

[0201] .

[0202] in, Represents a node The set of attributes, Represents a node The attribute set is in key-value pair form. Attribute similarity quantifies the degree of overlap by calculating the ratio of the intersection to the union of the two attribute sets.

[0203] The formula for calculating frequency similarity is as follows:

[0204]

[0205] in, Represents a node Access frequency, Represents a node The access frequency is calculated from the query log statistics.

[0206] If the similarity score of a pair of nodes If the value exceeds a preset threshold θ (e.g., 0.85, which can be adjusted according to actual needs in practical applications), it is determined to be functionally similar. Subsequently, the system will select one of the nodes (e.g., ) merged into another node ( ), the specific operations include: Redirect all incoming and outgoing edges to Then, the attribute sets of both are merged, and finally the node is deleted from the gallery. This reduces the overall size of the graph.

[0207] D30, in the analysis of multiple candidate paths for backward query, detects node and edge conflicts between paths in real time, and groups and parallelizes independent paths without conflicts based on the conflict detection results.

[0208] Specifically, the system intercepts Neo4j's query execution requests, calls Neo4j's EXPLAIN interface to obtain the execution plan tree for the current reverse query, and parses all candidate traversal paths that meet the query conditions from the execution plan tree, forming a candidate path set P={p1,p2,...,pk}. Each candidate path corresponds to a feasible path generated by the Neo4j executor during the reverse graph traversal. The system parses each path pi, generates a node set V(pi) and an edge set E(pi), and outputs a path metadata list [{path_id,nodes,edges}]. Furthermore, it can further analyze the overlap relationships between these paths, specifically by calculating the intersection of the path node set and edge set.

[0209] Meanwhile, the system combines query logs to analyze the historical access frequency statistics of the paths; in addition, the system also extracts the length information (i.e., hop count) of each path, thus providing a data foundation for subsequent node fusion, parallelization, and quick edge generation.

[0210] Optionally, extract the node set and edge set of each path from the candidate path set; calculate the intersection of the node set and the intersection of the edge set of different paths, and mark the paths with empty node set intersection and edge set intersection as independent paths; based on the marking results of independent paths, use a graph coloring algorithm to divide all independent paths into multiple independent path groups; assign each independent path group to different execution threads for parallel querying.

[0211] In the reverse query, paths that share no nodes or edges with each other (called independent paths) are identified. Independent paths are allocated to multi-threaded or distributed scheduling to accelerate query execution. Parallel query results are merged to ensure output consistency with serial queries. Parallelization reduces query latency and optimizes CPU and memory usage. Specifically, the system executes the Parallel Path Detection (PPD) algorithm. First, the node set V(pi) and edge set E(pi) for each path pi are extracted from the candidate path set P. Then, the independence judgment formula is used... Analyze each pair of paths:

[0212] .

[0213] Here, V(pi) represents the node set of path pi, containing the node_id of all nodes in the path, used to detect node conflicts between paths. Specifically, all n_i.node_ids are extracted from the path list [(n_1,e_1,n_2),...] and stored as the set {node_id_1,node_id_2,...}. E(pi) represents the edge set of path pi, containing the edge_id of all edges in the path, used to detect edge conflicts between paths; and all e_i.edge_ids are extracted from the path list and stored as the set {edge_id_1,edge_id_2,...}.

[0214] If V(pi)∩V(pj)=∅ and E(pi)∩E(pj)=∅, then Pind=1, indicating that the two paths are independent and conflict-free, and can be executed in parallel; otherwise, Pind=0, and needs to be processed serially.

[0215] Specifically, the system intercepts Neo4j query execution requests, calls Neo4j's EXPLAIN interface to obtain the execution plan tree of the current backward query, and parses all candidate traversal paths that meet the query conditions from the execution plan tree, forming a candidate path set P={p1,p2,...,pk}. For example, based on... Figure 2 Given the graph structure, the candidate paths corresponding to the query request "find the source node of the completed node of project X" are: (1) e→d→b→c→a; (2) e→f→c→a.

[0216] Each candidate path corresponds to a feasible path generated by the Neo4j executor during the reverse graph traversal. The system parses each path pi, generates a node set V(pi) and an edge set E(pi), and outputs a list of path metadata [{path_id,nodes,edges}].

[0217] Based on the path metadata list, for each pair of paths (pi, pj), calculate Pind(pi, pj) using Python's set intersection operation. Output the independence matrix ind_matrix[i, j], with values ​​of 0 or 1. Further, based on the independence matrix, use a greedy graph coloring algorithm (GreedyGraphColoring, GGC) to group the paths, ensuring that paths within the same group are independent. Using NetworkX's greedy_color function, treat paths as nodes in a graph and independence as edges, outputting a group list [{group_id, [path_id_1, path_id_2, ...]}]. Based on the group list, assign each group of paths to a thread pool, executing them using Python's concurrent.futures.ThreadPoolExecutor. Each thread calls Neo4j's CypherAPI to execute a subquery (e.g., MATCH(n)-[r]->(m)WHEREEn.node_id=$start_id), outputting a thread result list [{path_id, result}]. Merge the results, remove duplicate nodes / paths, and format them as Neo4j standard output. Use Python's dictionary to remove duplicates, where n is the number of results. Output the final query results (JSON format).

[0218] D40 dynamically creates weighted shortcut edges between the endpoints of preset high-frequency long paths based on the path access frequency and path length recorded in the historical query log, in order to optimize subsequent query paths.

[0219] The system executes the Shortcut Edge Generation (SEG) algorithm.

[0220] First, the access frequency of each reverse path p is calculated from the historical query logs. Filter out access frequencies exceeding a preset threshold φ (e.g., 100; in practical applications, this can be adjusted according to actual needs) and path lengths. Paths with more than 2 hops are identified as high-frequency long paths.

[0221] For each high-frequency, long path, the system creates a new shortcut edge between its start and end nodes. Specifically, the weight of the new edge is calculated using the following formula. :

[0222] .

[0223] in, This indicates the access frequency of path p, calculated from historical query logs. This represents the length (number of hops) of path p. This represents the sum of the weights of all existing edges on the path (obtained from the edge attributes, with a default weight of 1).

[0224] The system uses Cypher statements (such as CREATE) to add new edges with calculated weights as shortcut edges to the graph database, thereby reducing the number of traversal hops when querying the same path in subsequent queries.

[0225] After completing a series of dynamic optimization operations, including node merging, parallel path grouping, and shortcut edge creation, the system generates an optimized graph structure containing elements such as merged nodes and newly added shortcut edges. Based on this optimized structure, the system reconstructs the execution plan for this reverse query and ultimately executes the plan to retrieve and output a result set that meets the query conditions, thereby simultaneously achieving adaptive optimization of the graph structure and improving query efficiency in a single query.

[0226] Optionally, after the dynamic optimization operation is executed, the response to the reverse query request is completed based on the optimized graph structure. Specifically, after completing node fusion, parallel path grouping, and shortcut edge creation, an optimized graph structure containing optimized nodes is generated; the execution plan for executing the reverse query is reconstructed based on the optimized graph structure; and based on the reconstructed execution plan, the result set that meets the query conditions is retrieved and output.

[0227] The coordination module manages the data flow and control flow between modules, ensuring real-time optimization of backward queries. Through dynamic task pipelines, it achieves adaptive collaboration between modules, optimizing the performance and resource utilization of backward queries, which is superior to static workflows (such as fixed-sequence execution).

[0228] It should be noted that the optimization suggestion module in this paper, also known as the Adaptive Dynamic Optimization Engine (ADOE), is responsible for generating optimization strategy suggestions for graph structure adjustment based on historical query logs and graph structure data using QPP and SAO algorithms before task scheduling and execution. Its output serves as the input for task generation and is a preliminary step in the scheduling process; it does not participate in the execution of the scheduled tasks. The coordination module manages the data flow and control flow between modules, ensuring real-time optimization of backward lookup queries.

[0229] The specific implementation method of the coordination module is described below.

[0230] The coordination module manages the data flow and control flow between modules, ensuring real-time optimization of backward queries. Through dynamic task pipelines, it achieves adaptive collaboration between modules, optimizing the performance and resource utilization of backward queries, which is superior to static workflows (such as fixed-sequence execution).

[0231] Specifically, the collaboration module calculates the execution priority of each task using the following formula:

[0232] .

[0233] Where Texec(t) ranges from [0,∞), is unitless, and represents the total weighted priority of all scheduled tasks to be executed at time t, used to reflect the overall scheduling load of the current system. When T... exec (t) When the preset load threshold is exceeded, the coordination module can delay the execution of low-priority tasks to ensure timely response of high-priority tasks. The execution order of each scheduled task is determined by its own priority score P. task (k) is determined by arranging from high to low. P task (k) represents the priority score of the k-th scheduled task, derived from the PTO algorithm. W module (k) represents the module affiliation weight of the k-th scheduling task, ranging from [0,1], with no unit. Since all scheduling tasks (i.e., graph structure optimization operations such as node fusion, path parallelism, and shortcut edge creation) are executed by the Graph Structure Optimization Module (DGSOM), the W of all current scheduling tasks... module (k) are all taken as 1.0. K t This represents the set of scheduled tasks to be executed at time t, extracted from the task priority list output by the PTO algorithm.

[0234] It should be noted that the above formulas are all dimensionless calculations. The formulas are derived from software simulations based on a large amount of collected data to obtain the most recent real-world results. The preset parameters in the formulas are set by those skilled in the art according to the actual situation.

[0235] Please see Figure 4 The present invention also provides an adaptive triggering optimization method for backward querying in graph databases, comprising:

[0236] C10, upon receiving a reverse query request, retrieves real-time system performance data and graph data change logs from the graph database.

[0237] C20 determines whether to trigger the graph structure optimization process based on system performance data and graph data change logs.

[0238] C30, when it is determined that the graph structure optimization is triggered, adjusts the graph structure according to the preset optimization strategy.

[0239] It should be noted that the specific implementation methods of each of the above steps can be found in the description of the corresponding modules in the embodiment of the graph database reverse query optimization system above.

[0240] Accordingly, the present invention also provides another adaptive triggering optimization device for backward querying of graph databases, comprising:

[0241] The acquisition module is used to acquire real-time monitoring system performance data and graph data change logs in the graph database after receiving a backward query request;

[0242] The judgment module is used to determine whether to trigger the graph structure optimization process based on system performance data and graph data change logs;

[0243] The optimization module is used to adjust the graph structure according to a preset optimization strategy when the graph structure optimization is triggered.

[0244] It should be noted that the device provided in the above embodiments is only an example of the division of the above functional modules. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the computer device can be divided into different functional modules to complete all or part of the functions described above.

[0245] Figure 5 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present invention. For example, as shown... Figure 5 As shown, the computer device 30 includes: a memory 31, a processor 32, and a computer program 33 stored in the memory 31 and running on the processor 32, wherein when the processor 32 executes the computer program 33, the computer device can execute the aforementioned graph database backward query adaptive triggering optimization method.

[0246] Furthermore, embodiments of the present invention also protect a computer processing device, which may include a memory and a processor, wherein the memory stores executable program code, and the processor is used to call and execute the executable program code to execute the graph database backward query adaptive triggering optimization method provided in the embodiments of the present invention.

[0247] In this embodiment of the invention, the computer processing device can be divided into functional modules according to the above method example. For example, each module can correspond to a separate function, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware. It should be noted that the module division in this embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0248] It should be understood that the computer processing device provided in this embodiment of the invention is used to execute the above-described graph database backward query adaptive triggering optimization method, and thus can achieve the same effect as the above implementation method.

[0249] When using integrated units, the computer processing device may include a processing module and a storage module. When applied to an object, the processing module can be used to control and manage the operation of the object. The storage module can be used to support the execution of program code by the object. The processing module may be a processor or a controller, which can implement or execute various exemplary logic blocks, modules, and circuits as described in this disclosure. The processor may also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of Digital Signal Processing (DSP) and a microprocessor, etc., and the storage module may be a memory.

[0250] In addition, the computer processing device provided in the embodiments of the present invention may specifically be a chip, component or module. The chip may include a connected processor and a memory. The memory is used to store instructions. When the processor calls and executes the instructions, the chip can execute a dynamic node fusion and path optimization method for a graph database provided in the above embodiments.

[0251] This invention also provides a computer-readable storage medium storing computer program code. When the computer program code is run on a computer, the computer executes the aforementioned method steps to implement the graph database backward query adaptive triggering optimization method provided in the above embodiments.

[0252] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for adaptive triggering optimization of backward query in graph databases, characterized in that, include: Upon receiving a reverse query request, retrieve real-time system performance data and graph data change logs from the graph database; Determine whether to trigger the graph structure optimization process based on system performance data and graph data change logs; Once the graph structure optimization is determined, the graph structure is adjusted according to the preset optimization strategy.

2. The graph database backward query adaptive triggering optimization method as described in claim 1, characterized in that, The system performance data includes query latency data and system resource data.

3. The graph database backward query adaptive triggering optimization method as described in claim 2, characterized in that, The process of determining whether to trigger the graph structure optimization procedure based on system performance data and graph data change logs includes: Calculate the delay score for time t based on the query delay corresponding to the most recent completed reverse query before the time t when the current reverse query request is received; Calculate the resource score for time t based on the real-time CPU utilization and real-time memory usage at time t. The change score at time t is calculated based on the total number of changes to nodes and edges in the graph structure within a preset time window prior to time t. The trigger score is calculated based on the delay score, resource score, and change score. Based on the comparison between the trigger score and the preset trigger threshold, it is determined whether to trigger the graph structure optimization process.

4. The graph database backward query adaptive triggering optimization method as described in claim 3, characterized in that, The calculation of the trigger score based on latency score, resource score, and change score includes: The trigger score is obtained by performing a weighted summation of the delay score, resource score, and change score.

5. The adaptive triggering optimization method for backward querying of graph databases as described in claim 1, characterized in that, The optimization strategy includes at least one optimization operation for the graph structure, and the type of optimization operation includes at least node merging and shortcut edge creation.

6. The adaptive triggering optimization method for backward querying of graph databases as described in claim 1, characterized in that, The method further includes: Each optimization operation in the optimization strategy is converted into a corresponding standardized scheduling task; Based on the expected reduction in the back-query path length for each scheduled task's corresponding optimization operation, calculate the impact score for the corresponding scheduled task. The complexity score of each scheduling task is determined based on the number of changes to nodes and edges involved in the optimization operations of each scheduling task. Based on the historical query frequency of the backward query path associated with each optimization operation, the urgency score of the corresponding scheduling task is determined. The priority score of each scheduling task is determined based on its impact score, complexity score, and urgency score.

7. The graph database backward query adaptive triggering optimization method as described in claim 6, characterized in that, The determination of the priority score for each scheduling task based on its impact score, complexity score, and urgency score includes: The priority score of each scheduling task is obtained by weighted summation of its impact score, complexity score, and urgency score.

8. A backward query adaptive triggering optimization device for graph databases, characterized in that, include: The acquisition module is used to acquire real-time monitoring system performance data and graph data change logs in the graph database after receiving a backward query request; The judgment module is used to determine whether to trigger the graph structure optimization process based on system performance data and graph data change logs; The adjustment module is used to adjust the graph structure according to a preset optimization strategy when the graph structure optimization is determined to be triggered.

9. A computer device, characterized in that, The computer device includes a memory and a processor. The memory stores a computer program, which, when executed by the processor, causes the processor to perform the steps of the graph database backward query adaptive triggering optimization method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The system stores a computer program that, when executed by a processor, causes the processor to perform the steps of the graph database backward query adaptive triggering optimization method as described in any one of claims 1 to 7.

Images