Graph database-oriented path prefix shared storage method

Abstract

The application discloses a path prefix shared storage method for a graph database, and comprises the following steps: collecting path query related data in the graph database; generating a path prefix candidate set; calculating the sharing benefit score of each candidate prefix to determine a to-be-shared prefix; constructing a path prefix shared storage unit; establishing a path prefix shared index; splitting a complete path into a shared prefix reference and a differential suffix segment; identifying a reusable path prefix shared storage unit based on the path prefix shared index, reading the path prefix shared storage unit after version checking and time validity checking, and continuing to expand a subsequent path from an end node, combining the shared prefix segment and the subsequent expansion segment to generate a complete query result. The path prefix shared storage method for the graph database reduces the repeated adjacent expansion of high-frequency multi-hop paths by constructing reusable path prefix shared storage units and splitting a complete path into a shared prefix reference and a differential suffix segment.

Description

Technical Field

[0001] This invention belongs to the field of graph database technology, and specifically relates to a path prefix shared storage method for graph databases. Background Technology

[0002] Graph databases are widely used in scenarios such as financial risk control, transaction anti-fraud, knowledge graphs, recommendation systems, social networks, device relationship analysis, supply chain tracking, and cybersecurity. Unlike traditional relational databases, graph databases represent entities and their relationships using nodes and edges, and the query process typically relies on adjacency traversal and multi-hop paths.

[0003] In practical applications, graph databases frequently perform path queries of the following types: account transfer path queries in financial risk control, fund flow tracking in transaction networks, entity relationship reasoning in knowledge graphs, user-product-behavior path queries in recommendation systems, device-account-IP-location association queries in device graphs, and subject-event-object link backtracking queries in auditing scenarios. These queries typically exhibit significant path pattern repetition. For example, in financial risk control scenarios, many queries may use Account A-Transfer-Account B-Bound Device C as the first two or three hops as the path prefix, and then continue to expand different relationships in subsequent hops.

[0004] Existing graph databases typically improve path query efficiency using the following methods: adjacency list or edge indexing, which creates outgoing edges, incoming edges, or relation type indexes for each vertex, and expands the query hop by hop from the starting point; path indexing, which creates indexes for some commonly used path patterns to quickly locate candidate edges or candidate nodes that satisfy the path pattern; query result caching, which caches historical query results and returns the cached results directly when the same query occurs again; execution plan optimization, which selects an appropriate path expansion order based on edge type selectivity, filtering conditions, statistical information, etc.; and materialized path, which pre-computes some fixed path results and saves the complete path or path endpoint results in advance.

[0005] While the above solutions can improve graph query efficiency to some extent, they still have the following drawbacks: Ordinary adjacency indexes cannot avoid repeated prefix expansion. When a large number of multi-hop queries share the same first few hops, the system still needs to access the adjacency table hop by hop from the starting point. Even if subsequent queries share the same path prefix as the previous query, the prefix edge sequence cannot be directly reused at the storage layer. Ordinary path indexes are biased towards location, not storage reuse. Existing path indexes are typically used to quickly find candidate nodes, candidate edges, or path results based on path patterns. Their core is index location, but they lack a mechanism to encapsulate the edge sequence in high-frequency common path prefixes into a shared storage unit and allow multiple path queries, multiple path patterns, and multiple path results to reference the same prefix edge sequence. Query result caching is too coarse-grained. Query result caching typically caches the complete query result. When query start point, end point, filter conditions, hop count range, or return value are not cached, the caching becomes too coarse-grained. When fields change slightly, the cache hit rate drops significantly. Many queries, although their complete results differ, share the same prefixes in the first few hops, and ordinary result caches cannot reuse these common parts. Materializing complete paths incurs high storage overhead. If complete multi-hop paths are directly materialized, a large number of identical prefix edge sequences will be stored repeatedly between different paths. During execution, prefix sharing lacks a persistent storage structure. Some query executors can reuse intermediate results during a single query execution, but this reuse is usually limited to the current execution plan or the current operator's lifecycle and cannot form a long-term shared storage unit for high-frequency path patterns. Updating and maintaining consistency of path prefixes is difficult. Graph data is dynamically changing, and edges may be added, deleted, have updated attributes, or have changed validity periods. Without version control and expiration mechanisms for shared path prefix units, shared prefixes may expire, be repeatedly referenced, or be inconsistent with the underlying edge state.

[0006] Therefore, a path prefix shared storage method for graph databases is needed. This method identifies common prefix edge sequences in high-frequency multi-hop paths at the storage layer, constructs them into reusable, referable, updatable, and invalidable shared storage units, and integrates them with the path query execution process to reduce repeated path expansion and improve multi-hop query performance. Summary of the Invention

[0007] This invention provides a path prefix shared storage method for graph databases to solve the aforementioned technical problems, specifically adopting the following technical solution: A path prefix shared storage method for graph databases includes the following steps: Collect path query related data from the graph database, including query mode information, path expansion information, edge access information, and path prefix candidate information; A sliding window analysis is performed on the collected path query results to generate a candidate set of path prefixes; Calculate the sharing benefit score for each candidate prefix. When the sharing benefit score is greater than the sharing threshold and the length of the candidate prefix is ​​not less than the minimum length threshold, the corresponding candidate prefix is ​​determined as the prefix to be shared. Construct a path prefix shared storage unit for the prefix to be shared; Establish a path prefix shared index, which includes a prefix key index, a path pattern to prefix unit mapping table, a prefix reference table, and a prefix end extension table; The complete path is split into a shared prefix reference and a differential suffix segment. The shared prefix reference points to the shared storage unit of the path prefix, and the differential suffix segment contains a suffix edge sequence and a suffix version vector. During path query, the reusable path prefix shared storage unit is identified based on the path prefix shared index. After version verification and time validity verification, the path prefix shared storage unit is read, and the subsequent path is expanded from the end node. The shared prefix segment is combined with the subsequent expanded segment to generate a complete query result. Version consistency maintenance is performed on the shared storage unit for the path prefix. The validity of the shared prefix is ​​determined by comparing the edge version vector with the current underlying edge version, and the corresponding state update process is performed according to the edge change type.

[0008] Furthermore, the sliding window analysis of the collected path query results includes: Extract the length of each path as l The prefix edge sequence, where 1≤ l ≤Lmax, where Lmax represents the maximum prefix length allowed to establish shared memory units; Prefixes with the same initial constraint, the same relation type sequence, the same direction constraint, the same filtering condition summary, and the same edge sequence are grouped into the same candidate prefix.

[0009] Furthermore, the shared revenue score PSS(C) j Calculated as follows: PSS(C j )=a1·norm(Hit(C j ))+a2·norm(Reuse(C j ))+a3·norm(CostSave(C j ))+a4·norm(Stability(C j ))-a5·norm(UpdateCost(C j ))-a6·norm(StorageOverhead(C j )) Among them, C jIndicates the candidate prefix, Hit(C) j) Reuse(C) represents the number of times a candidate prefix is ​​hit within the statistics window. j The ) represents the number of candidate prefixes reused in different query patterns. CostSave(C j The value () represents the expected savings in adjacency unrolling cost from reusing the prefix. Stability(C) j The prefix indicates the stability of the edges involved within the statistical window. `UpdateCost(C)` represents the degree of stability of the edges involved within the statistical window. j ) represents the update cost required to maintain this prefix, StorageOverhead(C j ) represents the additional metadata and storage overhead brought about by establishing a shared storage unit, a1 to a6 are weight parameters, and norm() represents the normalization function.

[0010] Furthermore, the adjacency unrolling cost savings (CostSave(C...)) j ) is represented as: CostSave(C j =ExpandCost(C j )×(Hit(C j )-1) Among them, ExpandCost(C j Hit(C) represents the average cost required to re-expand the prefix from the original adjacency list each time. j )-1 indicates the number of times the element can be reused after the first expansion.

[0011] Furthermore, the stability level Stability(C) j ) is represented as: Stability(C j =1-ChangeRate(C j ) Among them, ChangeRate(C j The prefix indicates the frequency of edge additions, deletions, attribute changes, or valid status changes.

[0012] Furthermore, the path prefix shared storage unit includes a prefix identifier, an edge sequence reference, an edge version vector, a relation type sequence, a direction sequence, a filter condition summary, a prefix length, a path state summary, a reference count, a valid time range, a storage location, an update status, and an invalidation status; The path state summary includes the prefix end node set, the prefix cumulative edge attribute summary, the prefix cumulative risk score, the prefix path length, whether the prefix passes through hotspot nodes, whether the prefix crosses partitions, and whether the prefix meets the time validity constraint.

[0013] Furthermore, reusing the path prefix shared storage unit during path lookup includes: Parse the query statement and extract the starting point, relation type sequence, direction, hop count range, filter conditions, and time window; Generate a query path pattern summary; Candidate shared prefixes are found in the prefix key index and path pattern to the prefix unit mapping table; Perform version verification, time validity verification, and filter condition compatibility verification on candidate shared prefixes; After the verification is successful, the path prefix shared storage unit is read directly, and the subsequent path is continued to be expanded from the end node; The shared prefix segment is combined with the subsequent expanded segment to generate a complete query result, and the hit count, citation count, and popularity score of the shared prefix are updated.

[0014] Furthermore, the version consistency maintenance includes: Maintain the edge version vector VV(PSU) of the shared prefix unit = <ver(e1),ver(e2),...,ver(e l )>, where ver(ei) represents the version number of the i-th edge, l Indicates the prefix length; When querying, read the current underlying edge version VVcurrent= <vercurrent(e1),vercurrent(e2),...,vercurrent(e l )>; If VV(PSU) = VVcurrent, then the shared prefix is ​​valid; If the condition is not met, then perform the following processing based on the edge change type: When non-critical fields of edge attributes change, update the attribute summary and version vector of the shared cell; When a key field of an edge attribute changes, the shared cell is marked as partially invalid and the filter condition summary is recalculated. When an edge is deleted or becomes invalid, the shared prefix unit is marked as invalid and the associated path references are reduced; When a new edge is added to form a better shared prefix, the candidate prefix analysis process is restarted. When the prefix terminal node undergoes expansion changes, update the prefix terminal expansion table.

[0015] Furthermore, the path prefix shared storage method for graph databases also includes dynamically adjusting the path prefix shared storage units.

[0016] Furthermore, the dynamic adjustment includes: For shared prefix replacement, the replacement score of the shared memory unit of the path prefix is ​​calculated according to the following formula:

[0017] Where IdleTime represents idle time, UpdateCost represents maintenance cost, StorageOverhead represents storage overhead, UpdateFreq represents update frequency, HitCount represents the number of hits, ReferenceCount represents the reference count, and β1 to β6 are weight parameters; If the elimination score is greater than the elimination threshold, the corresponding path prefix shared storage unit is added to the elimination candidate queue. For the path prefix shared storage unit added to the elimination candidate queue, its current reference status and version status are checked. If it is not currently referenced by the query task being executed and there are no incomplete suffix segment dependencies, the elimination operation is performed. Shared prefix merging: When multiple shared prefixes have the same starting point, the same relation type sequence, and the same first few edges, they are merged into a shorter shared prefix unit, and the difference part is saved as a suffix segment; Shared prefix splitting involves splitting a shared prefix into a stable prefix segment and a failed suffix segment when the latter half of the prefix frequently fails while the former half remains stable. This preserves the stable prefix and reduces maintenance costs.

[0018] The advantage of this invention lies in the path prefix shared storage method for graph databases provided. By constructing reusable path prefix shared storage units in the storage layer, the complete path is split into shared prefix references and differential suffix segments, reducing the repeated adjacency expansion of high-frequency multi-hop paths, reducing storage bloat, and achieving deep linkage between storage optimization and query execution.

[0019] The advantages of this invention also lie in the path prefix sharing storage method for graph databases provided. Through a six-dimensional weighted normalized sharing benefit scoring model, the sharing value of candidate prefixes is scientifically quantified, taking into account both benefits and costs, popularity and stability. This enables the system to select high-value prefixes, avoid low-cost-performance prefixes, and improve the accuracy of sharing decisions.

[0020] The advantages of this invention also lie in the path prefix shared storage method for graph databases, the edge version vector comparison and differential change processing mechanism, and the fine-grained maintenance strategy for five edge change types. In dynamic graph data environments, it maximizes the preservation of reusable shared prefixes, significantly improving the survival rate and long-term reliability of shared storage units. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 This is a schematic diagram of the path prefix shared storage method for graph databases proposed in this application. Detailed Implementation

[0023] Embodiments of the present invention are described in detail below. Examples of these embodiments are illustrated in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain the present invention, and should not be construed as limiting the present invention.

[0024] In the description of this application, it should be noted that, unless otherwise specified and limited, the terms "installation", "connection" and "linkage" should be interpreted broadly, and can refer to mechanical or electrical connections, or internal connections between two components, or direct connections. "Up", "down", "left", "right", etc., are only used to indicate relative positional relationships. When the absolute position of the described object changes, the relative positional relationship may change.

[0025] like Figure 1The following is a method for shared storage of path prefixes for graph databases according to this application, comprising the following steps: S1: Collect path query-related data from the graph database, including query pattern information, path expansion information, edge access information, and path prefix candidate information; S2: Perform sliding window analysis on the collected path query results to generate a path prefix candidate set; S3: Calculate the sharing benefit score for each candidate prefix. When the sharing benefit score is greater than the sharing threshold and the candidate prefix length is not less than the minimum length threshold, the corresponding candidate prefix is ​​determined as the prefix to be shared; S4: Construct a path prefix shared storage unit for the prefixes to be shared; S5: Establish a path prefix shared index, which includes a prefix key index and a path pattern to prefix unit. The system includes a mapping table, a prefix reference table, and a prefix end expansion table; S6: The complete path is split into a shared prefix reference and a differing suffix segment. The shared prefix reference points to the shared storage unit of the path prefix, and the differing suffix segment contains the suffix edge sequence and the suffix version vector; S7: During path querying, reusable shared storage units of the path prefix are identified based on the shared index of the path prefix. After version verification and time validity verification, the shared storage unit of the path prefix is ​​read, and the subsequent path is expanded from the end node. The shared prefix segment is combined with the subsequent expanded segment to generate a complete query result; S8: Version consistency is maintained for the shared storage unit of the path prefix. The validity of the shared prefix is ​​determined by comparing the edge version vector with the current underlying edge version, and the corresponding state update processing is performed according to the edge change type. This invention introduces a path prefix shared storage unit in the graph database storage layer, enabling the identification, encapsulation, reuse, and consistency maintenance of common prefix edge sequences in high-frequency multi-hop paths. This solves the problems in existing technologies, such as the repeated expansion of common prefix edge sequences in high-frequency multi-hop path queries, ordinary path indexes only being able to locate but not reduce the repeated storage of prefix edge sequences, storage expansion caused by complete path materialization, excessively coarse query result caching granularity with low hit rate, difficulty in maintaining consistency of path prefix shared units in dynamic graph data, and the disconnect between storage optimization and query execution.Compared to existing adjacency lists or edge indexes, this invention eliminates the need to re-expand the same prefix from the original adjacency list each time, significantly reducing redundant adjacency scans and path expansion. Compared to ordinary path indexes, this invention encapsulates the edge sequences in high-frequency common path prefixes into shared storage units that can be referenced by multiple path results and query patterns, achieving storage layer reuse rather than just location. Compared to query result caching, this invention uses path prefixes as the reuse granularity rather than the complete query result, greatly improving reusability between different queries. Compared to materialized complete paths, this invention avoids storage bloat caused by repeatedly storing the same prefix edge sequences between different paths through a shared prefix reference and differential suffix segment splitting mechanism. Through edge version vectors, valid time ranges, and failure status mechanisms, this invention can maintain the consistency of shared prefixes when edges are updated, deleted, or their attributes change, supporting dynamic graph data scenarios. Through the linkage between the path prefix shared index and the query execution process, this invention achieves synergy between storage layer optimization and query layer optimization, improving the overall performance of multi-hop path queries in graph databases. The following details the above steps.

[0026] For step S1: Collect path query related data from the graph database. The path query related data includes query mode information, path expansion information, edge access information, and path prefix candidate information.

[0027] During the execution of graph database queries, the system tracks and records the entire process of each path query, collecting path query behavior and path expansion data from the graph database.

[0028] Specifically, the query pattern information includes the query statement, starting node type, starting node identifier, relation type sequence, path hop count range, direction constraints, node label constraints, edge attribute filtering conditions, time window conditions, and returned fields. Path expansion information includes the set of edges visited at each hop, the set of candidate nodes generated at each hop, the number of candidate edges at each hop, the number of edges retained after filtering at each hop, the number of complete paths, path expansion time, cross-partition access counts, and storage block read counts. Edge access information includes edge ID, edge type, edge start and end points, edge attribute version, the number of times the edge is hit by the path query, the hop number at which the edge is hit, and the partition and storage block to which the edge belongs. Path prefix candidate information includes the first hop edge sequence, the first 2 hop edge sequence, the first 3 hop edge sequence, the first k hop edge sequence, the prefix end node, the path pattern corresponding to the prefix, and the number of times the prefix is ​​reused in different queries. By collecting the above multi-dimensional path query-related data, the system provides a complete data foundation for subsequent identification of high-frequency common path prefixes.

[0029] Among them, the path prefix refers to the continuous edge sequence formed from a certain starting node or set of starting nodes according to the specified relationship type, direction and filtering conditions.

[0030] For example, the path is: v0 - e1:TRANSFER ->v1 -e2:BIND_DEVICE ->v2 -e3:LOGIN_IP ->v3 Its path prefix of length 2 is: Prefix_2 = [e1, e2] A path prefix of length 3 is: Prefix_3 = [e1, e2, e3] For step S2: Perform sliding window analysis on the collected path query results to generate a candidate set of path prefixes.

[0031] The system performs sliding window analysis on the path query result set P={p1,p2,...,pn} collected in step one, and performs analysis on each path pi=<v0,e1,v1,e2,v2,...,em,vm> Extract its length as l Prefix(pi, l )= <e1,e2,...,e l >, among which l The range of values ​​for is 1≤ l ≤Lmax, where Lmax represents the maximum prefix length allowed to establish shared storage units. The system groups prefixes with the same initial constraints, the same relation type sequence, the same direction constraints, the same filtering condition summary, and the same edge sequence into the same candidate prefix, generating a candidate prefix set.

[0032] Candidate prefixes can be represented as:

[0033] in: `prefix_key` represents the unique identifier of the candidate prefix; `edge_sequence` represents the sequence of edge IDs in the candidate prefix; `start_vertex` represents the starting point of the prefix; `end_vertex` represents the ending node of the prefix; `relation_sequence` represents the sequence of relation types; `filter_signature` represents the summary of the filtering conditions; `hit_count` represents the number of times the prefix is ​​hit; `query_pattern_set` represents the set of query patterns that hit the prefix; `last_hit_time` represents the time of the most recent hit.

[0034] Each candidate prefix record contains information such as its prefix key, edge sequence, starting node, ending node, relation type sequence, filter condition summary, hit count, query pattern set, and most recent hit time, providing candidate objects for subsequent shared benefit evaluation.

[0035] A sliding window analysis was performed on the collected path query results, and the length of each path was extracted. l The prefix edge sequence, where the prefix length is... l The prefix length is set between 1 and Lmax, where Lmax represents the maximum prefix length allowed by the system to establish shared storage units. This upper limit can be configured based on system storage resources and query characteristics. After extracting the prefix edge sequence, the system merges prefixes according to multiple consistency conditions: the same starting constraint ensures that the prefixes originate from the same starting point or set of starting points; the same relation type sequence ensures that the relation type of each hop in the prefix is ​​consistent; the same direction constraint ensures that the direction of each hop edge is consistent; the same filter condition summary ensures that the filter conditions satisfied when the prefix is ​​valid are consistent; and the edge sequence consistency ensures that the edge ID sequence in the prefix is ​​exactly the same. Only prefixes that simultaneously meet the above five conditions are merged into the same candidate prefix, thereby ensuring the accuracy and reusability of the candidate prefixes. By performing sliding window analysis on the path query results and merging candidate prefixes based on multiple consistency conditions, this invention can accurately identify path prefixes that truly have common characteristics, avoiding incorrect merging of unreusable prefixes due to different starting points, different relation types, or different filter conditions. Setting the maximum prefix length Lmax can effectively control system overhead and prevent the storage units from becoming too specific due to excessively long prefixes, thus reducing the reusability rate. This constraint makes the candidate prefix generation process more precise and controllable, providing high-quality candidate objects for subsequent shared revenue scoring and shared storage unit construction, and improving the overall efficiency and accuracy of path prefix shared storage.

[0036] For step S3: Calculate the shared revenue score for each candidate prefix. When the shared revenue score is greater than the shared threshold and the length of the candidate prefix is ​​not less than the minimum length threshold, the corresponding candidate prefix is ​​determined as the prefix to be shared.

[0037] In the embodiments of this application, the shared revenue score PSS(C) j Calculated as follows: PSS(C j )=a1·norm(Hit(C j ))+a2·norm(Reuse(C j ))+a3·norm(CostSave(C j ))+a4·norm(Stability(C j ))-a5·norm(UpdateCost(C j ))-a6·norm(StorageOverhead(C j )) Among them, C j Indicates the candidate prefix, Hit(C) j)Reuse(C) represents the number of times a candidate prefix is ​​hit within the statistics window. j The ) represents the number of candidate prefixes reused in different query patterns. CostSave(C j The value () represents the expected savings in adjacency unrolling cost from reusing the prefix. Stability(C) j The prefix indicates the stability of the edges involved within the statistical window. `UpdateCost(C)` represents the degree of stability of the edges involved within the statistical window. j ) represents the update cost required to maintain this prefix, StorageOverhead(C j ) represents the additional metadata and storage overhead brought about by establishing a shared storage unit, a1 to a6 are weight parameters, and norm() represents the normalization function.

[0038] This scoring model employs a six-dimensional weighted normalization method, comprehensively considering six factors: hit frequency of candidate prefixes, reuse breadth, cost savings, stability, update overhead, and storage overhead. The number of hits (Hit(C)) is the key factor. j This reflects the usage frequency of candidate prefixes within the statistical window; the reuse count (C) reflects the number of reuses. j This reflects the breadth of the prefix shared by different query patterns; adjacency expansion saves cost (CostSave(C)). j Quantization reuse of this prefix saves computational resources compared to repeated expansion; Stability (C j The prefix's edge data is measured by its reliability within the statistical window; UpdateCost(Cj) assesses the overhead required to maintain the prefix; StorageOverhead(Cj) measures the reliability of the prefix's edge data within the statistical window; UpdateCost(Cj) evaluates the overhead required to maintain the prefix; StorageOverhead(Cj) measures the reliability of the prefix's edge data within the statistical window. j This invention measures the additional metadata and storage burden brought about by establishing shared storage units. Six dimensions are weighted using parameters a1 to a6, and the difference in units is eliminated using the normalization function norm(), making each dimension comparable. Through a six-dimensional weighted normalized shared benefit scoring model, this invention can scientifically quantify the shared value of each candidate prefix, avoiding the bias caused by making decisions based on a single indicator (such as the number of hits). This scoring model takes into account both benefits and costs, popularity and stability, enabling the system to select truly valuable prefixes worth building shared storage units, while avoiding low-cost-performance prefixes that, although frequently hit, are updated too frequently, have excessively high maintenance costs, or excessive storage overhead. The configurability of the weight parameters allows the system to flexibly adjust the scoring strategy according to different business scenarios, improving the adaptability and practicality of the method.

[0039] In the embodiments of this application, adjacent expansion cost savings (CostSave(C)) are achieved. j ) is represented as: CostSave(C j=ExpandCost(C j )×(Hit(C j )-1) Among them, ExpandCost(C j Hit(C) represents the average cost required to re-expand the prefix from the original adjacency list each time. j )-1 indicates the number of times the element can be reused after the first expansion.

[0040] Further limits the cost savings from adjacency rollout (CostSave(C)). j The specific calculation method for this cost is as follows: The cost is obtained by multiplying two parts: ExpandCost(C... j Hit(C) represents the average cost required to re-expand the prefix from the original adjacency list each time. This cost can be comprehensively evaluated by statistically analyzing the number of storage block reads, cross-partition accesses, and computation time during the historical expansion process; j )-1 represents the number of times the prefix can be reused after the initial expansion, i.e., the total number of hits minus the initial expansion operation. The product of the two is the total adjacency expansion cost expected to be saved by reusing the prefix. This formula reflects the core economic logic of shared storage: building a shared storage unit only has practical value when the number of reuses is sufficient and the cost savings per reuse are large enough. By quantifying the cost savings of adjacency expansion as the product of the average expansion cost and the number of reusable prefixes, this invention provides a clear calculation basis and interpretability for the cost savings dimension in the shared storage benefit score. This formula directly reflects the core value source of shared storage—the computational resource savings brought about by avoiding repeated expansions of the same prefix, enabling the system to prioritize the construction of shared units using prefixes with high single expansion costs and high reuse counts. Simultaneously, Hit(C) is used... j )-1 instead of Hit(C j As the number of reuses, it accurately depicts the objective fact that the first use is inevitable and the shared value is reflected in subsequent reuses, making the scoring results more reasonable.

[0041] In the embodiments of this application, the stability level (C) j ) is represented as: Stability(C j =1-ChangeRate(C j ) Among them, ChangeRate(C j The prefix indicates the frequency of edge additions, deletions, attribute changes, or valid status changes.

[0042] The stability level (C) is further defined. jThe specific calculation method for stability is as follows: stability is calculated by subtracting the change rate (ChangeRate(C)) from 1. j The change rate ChangeRate(C) is obtained from this. j The change rate indicates the frequency of edge additions, deletions, attribute changes, or valid state changes within the prefix. A higher change rate indicates lower stability, meaning the edge data involved in the prefix changes more frequently within the statistical window, making it unsuitable as a long-term shared storage unit. Conversely, a lower change rate indicates higher stability, meaning the edge data involved in the prefix is ​​more stable and more suitable for constructing a shared storage unit. This indicator evaluates the sharing suitability of candidate prefixes from the perspective of data dynamism, complementing popularity indicators such as hit count. By introducing a stability index, this invention can effectively identify and avoid prefixes that, although currently frequently hit, have drastically changing underlying edge data, preventing repeated failures and reconstructions of shared storage units due to frequent edge data changes, thereby saving maintenance costs and extending the effective lifespan of shared storage units. The simple linear relationship between stability and change rate makes the calculation process efficient and intuitive, facilitating rapid evaluation during system runtime. This index ensures that the system prioritizes sharing stable prefixes, significantly improving the reliability and durability of path prefix shared storage units in real-world dynamic graph data environments.

[0043] For step S4: construct the path prefix shared storage unit for the shared prefix.

[0044] For a shared prefix that meets the conditions, the system constructs a path prefix shared storage unit (PSU).

[0045] A path prefix shared memory unit includes at least the following:

[0046] Wherein, `prefix_id` represents the unique identifier of the shared prefix unit; `prefix_key` represents the key generated from the start point, relation sequence, direction sequence, filter condition summary, and edge sequence summary; `start_vertex` represents the start point of the shared prefix; `end_vertex` represents the end node of the shared prefix; `edge_sequence_ref` represents the reference or compressed storage address of the prefix edge sequence; `edge_version_vector` represents the version vector corresponding to each edge in the prefix; `relation_sequence` represents the type of each hop relation in the prefix; `direction_sequence` represents the direction of each hop edge; `filter_signature` represents the filter condition summary satisfied when the prefix is ​​valid; `prefix_length` represents the number of hops in the prefix; `path_state_summary` represents the prefix path state summary; `reference_count` represents the number of times the shared unit is referenced by path results, path patterns, or query plans; `valid_time_range` represents the applicable time range of the prefix; `storage_location` represents the physical storage location of the shared unit; `update_state` indicates whether the shared unit is currently in a normal, updating, or pending repair state; and `expire_state` indicates whether the shared unit is valid, partially invalid, or completely invalid.

[0047] The `path_state_summary` includes: a set of prefix terminal nodes; a summary of cumulative edge attributes of the prefix; a cumulative risk score of the prefix; the length of the prefix path; whether the prefix passes through hotspot nodes; whether the prefix crosses partitions; and whether the prefix meets time validity constraints. The path state summary is a crucial component of the shared storage unit for path prefixes, recording multi-dimensional state information of the prefix path, including: a set of prefix terminal nodes, recording all terminal nodes reachable by the prefix; a summary of cumulative edge attributes of the prefix, aggregating the attribute information of each edge in the prefix; a cumulative risk score of the prefix, used for risk quantification in scenarios such as financial risk control; the length of the prefix path, recording the number of hops in the prefix; whether the prefix passes through hotspot nodes, indicating whether the prefix involves nodes with extremely high access frequency; whether the prefix crosses partitions, indicating whether the edges of the prefix are distributed across different storage partitions; and whether the prefix meets time validity constraints, indicating whether the prefix is ​​valid within a specified time range. By embedding multi-dimensional path state summaries in the shared storage unit for path prefixes, this invention enables the query executor to quickly obtain key feature information of the prefix when reusing shared prefixes, thereby making more accurate query optimization decisions.

[0048] For step S5: Establish a path prefix shared index, which includes a prefix key index, a path pattern to prefix unit mapping table, a prefix reference table, and a prefix end extension table.

[0049] The system establishes a shared index for the path prefix shared storage unit. The purpose of this index is not to simply find the path, but to locate the reusable shared prefix storage unit.

[0050] The path prefix shared index consists of four parts: a prefix key index, which uses a hash function to generate prefix keys from the starting range, relation type sequence, direction sequence, filter condition summary, prefix length, and edge sequence summary, establishing a mapping from prefix keys to prefix identifiers; a path pattern to prefix unit mapping table, recording which prefix shared units can be reused for a certain type of query pattern; a prefix reference table, recording which path results, query patterns, or execution plans reference the shared prefix; and a prefix end extension table, recording the prefix end node, subsequent relation candidates, next storage location, and extension statistics, used to continue expanding the subsequent path from the prefix end node after a query hits the shared prefix.

[0051] For step S6: split the complete path into a shared prefix reference and a differing suffix segment. The shared prefix reference points to the shared storage unit of the path prefix, and the differing suffix segment contains the suffix edge sequence and the suffix version vector.

[0052] When the system needs to store or reuse a complete multi-hop path, it no longer repeatedly saves the complete path edge sequence. Instead, it splits the path into two parts: a shared prefix reference and a differing suffix segment. The shared prefix reference points to an established shared storage unit for the path prefix. The differing suffix segment contains a suffix identifier, an associated prefix identifier, a suffix edge sequence, a suffix start node, a suffix end node, a suffix filtering condition summary, and a suffix version vector. The suffix start node is usually the end node of the shared prefix. Through this splitting mechanism, when multiple paths share the same prefix, the common prefix is ​​stored only once. The complete path is generated by combining the shared prefix reference and the differing suffix segment, thus avoiding the storage bloat problem caused by materializing the complete path.

[0053] For step S7: During path query, reusable path prefix shared storage units are identified based on the path prefix shared index. After version verification and time validity verification, the path prefix shared storage units are read, and the subsequent path is expanded from the end node. The shared prefix segment is combined with the subsequent expanded segment to generate a complete query result.

[0054] In embodiments of this application, reusing the path prefix shared storage unit during path lookup includes: Parse the query statement and extract the starting point, relation type sequence, direction, hop count range, filter conditions, and time window.

[0055] Generate a summary of the query path pattern.

[0056] Candidate shared prefixes are found by mapping the prefix key index and path pattern to the prefix unit table.

[0057] The candidate shared prefixes are validated for version, time validity, and compatibility of filtering conditions.

[0058] After successful verification, the path prefix shared storage unit is read directly, and the subsequent path is expanded from the end node.

[0059] The shared prefix segment is combined with the subsequent expanded segment to generate a complete query result, and the hit count, citation count, and popularity score of the shared prefix are updated.

[0060] When the graph database receives a path query request, the system parses the query statement to extract the starting point, relation type sequence, direction, hop count range, filtering conditions, and time window, generating a query path pattern signature. Based on the prefix key index and path pattern, it searches the prefix unit mapping table for candidate shared prefixes, performing version verification, time validity verification, and filtering condition compatibility verification on the candidate shared prefixes. If the verification passes, it directly reads the shared storage unit of the path prefix, continues to expand the remaining path pattern from its end node, combines the shared prefix segment with the subsequent expanded segments to generate a complete query result, and updates the hit count, reference count, and popularity score of the shared prefix.

[0061] Through a standardized query reuse execution process, this invention achieves closed-loop management of path prefix shared storage units, from identification and verification to reuse and feedback. Multiple verification mechanisms ensure the correctness and consistency of query results, preventing erroneous results due to changes in underlying data or mismatched query conditions. The end-node expansion mechanism enables seamless connection between the shared prefix and subsequent paths, maintaining the continuity of query execution. Real-time updates of hit counts, citation counts, and popularity scores allow the system to dynamically track the usage status of shared units, providing data support for subsequent dynamic adjustments and elimination decisions. This constraint deeply couples storage layer optimization with the query execution process, maximizing the query acceleration effect of path prefix shared storage.

[0062] For step S8: maintain version consistency of the path prefix shared storage unit, determine the validity of the shared prefix by comparing the edge version vector with the current underlying edge version, and perform the corresponding state update processing according to the edge change type.

[0063] Since edge data in the graph database may be added, deleted, have attributes updated, or have changes in validity, the system establishes a version consistency mechanism for the shared storage unit of path prefixes.

[0064] Each shared prefix unit maintains an edge version vector: VV(PSU)= <ver(e1),ver(e2),...,ver(e l )> Where ver(ei) represents the version number of the i-th edge. l Indicates the prefix length.

[0065] Read the current underlying edge version during the query: VV_current= <ver_current(e1),ver_current(e2),...,ver_current(e l )> If VV(PSU) = VV_current, the shared prefix remains valid and can be reused directly; otherwise, differential processing is performed based on the edge change type. When non-critical fields of edge attributes change, update the attribute summary and version vector of the shared cell; When a key field of an edge attribute changes, the shared cell is marked as partially invalid and the filter condition summary is recalculated. When an edge is deleted or becomes invalid, the shared prefix unit is marked as invalid and related path references are reduced; When a new edge forms a better shared prefix, the candidate prefix analysis process is re-entered. When the prefix terminal node undergoes expansion changes, the prefix terminal expansion table is updated to ensure that subsequent queries can continue from the correct terminal node.

[0066] By employing edge version vector comparison and differentiated change handling mechanisms, this invention achieves efficient maintenance of shared prefix consistency in dynamic graph data environments. The version vector mechanism tracks the state changes of multiple edges in a lightweight manner, avoiding the high overhead of full data scanning. The differentiated handling strategy for five change types enables the system to take the most economical maintenance measures based on the degree of change impact, rather than indiscriminately invalidating all shared prefixes, significantly improving the survival rate and reusability of shared storage units in dynamic data environments. This limitation allows the invention to adapt to the continuous dynamic changes in graph data, ensuring the long-term effectiveness and reliability of the path prefix shared storage method.

[0067] In embodiments of this application, the path prefix shared storage method for graph databases further includes dynamically adjusting the path prefix shared storage units.

[0068] In the embodiments of this application, dynamic adjustment includes: 1. Shared prefix replacement. The replacement score of the shared memory unit of the path prefix is ​​calculated using the following formula:

[0069] Where IdleTime represents idle time, UpdateCost represents maintenance cost, StorageOverhead represents storage overhead, UpdateFreq represents update frequency, HitCount represents hit count, ReferenceCount represents reference count, and β1 to β6 are weight parameters.

[0070] Among them, IdleTime, UpdateCost, StorageOverhead, and UpdateFreq are positively correlated with eviction propensity, that is, the longer the idle time, the higher the maintenance cost, the greater the storage overhead, or the higher the update frequency, the higher the eviction score; HitCount and ReferenceCount are negatively correlated with eviction propensity, that is, the higher the hit count or the higher the reference count, the lower the eviction score.

[0071] After calculating the elimination score, the system compares the elimination score with the elimination threshold. When the elimination score is greater than the elimination threshold, the corresponding path prefix shared storage unit is added to the elimination candidate queue. For the path prefix shared storage unit added to the elimination candidate queue, the system further checks its current reference status and version status. If it is not currently referenced by an executing query task and has no incomplete suffix segment dependencies, the system performs an elimination operation, deletes or reclaims the path prefix shared storage unit, and synchronously updates the prefix key index, path pattern to prefix unit mapping table, prefix reference table, and prefix end extension table.

[0072] 2. Shared prefix merging. When multiple shared prefixes have the same starting point, the same relation type sequence, and the same first few edges, they are merged into a shorter shared prefix unit, and the differences are saved as a suffix segment.

[0073] 3. Shared prefix splitting. When the latter half of a shared prefix frequently fails while the former half remains stable, it is split into a stable prefix segment and a failed suffix segment, preserving the stable prefix and reducing maintenance costs.

[0074] The elimination mechanism comprehensively evaluates six dimensions—idle time, maintenance cost, storage overhead, update frequency, hit count, and reference count—by calculating the EliminateScore (PSU). Elimination is performed when the score exceeds a threshold. The merging mechanism identifies multiple shared prefixes with the same starting point, the same relation type sequence, and the same first few edges. It extracts their common parts into shorter shared prefix units, saving the differing parts as suffix segments. The splitting mechanism identifies shared prefixes where the latter half frequently fails while the former half remains stable. It splits these into stable prefix segments and failed suffix segments, retaining the stable parts and reducing maintenance costs. These three operations work together to form a dynamic optimization system for the entire lifecycle of shared storage units. By introducing these three dynamic adjustment mechanisms—elimination, merging, and splitting—this invention enables path prefix shared storage units to adaptively optimize based on actual usage and data change trends, avoiding the system burden caused by the unlimited growth of shared storage units. The elimination mechanism promptly cleans up low-value units, releasing storage resources; the merging mechanism reduces redundant storage and improves sharing granularity; and the splitting mechanism isolates failed parts and protects stable parts. The three mechanisms work together to enable the system to maintain the high quality and high efficiency of the shared storage unit set during long-term operation, realize the sustainable operation and self-optimization of the path prefix shared storage method, and significantly improve the long-term stability and resource utilization efficiency of the system.

[0075] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the above embodiments do not limit the present invention in any way, and all technical solutions obtained by equivalent substitution or equivalent transformation fall within the protection scope of the present invention.

Claims

1. A path prefix shared storage method for graph databases, characterized in that, Includes the following steps: Collect path query related data from the graph database, including query mode information, path expansion information, edge access information, and path prefix candidate information; A sliding window analysis is performed on the collected path query results to generate a candidate set of path prefixes; Calculate the sharing benefit score for each candidate prefix. When the sharing benefit score is greater than the sharing threshold and the length of the candidate prefix is ​​not less than the minimum length threshold, the corresponding candidate prefix is ​​determined as the prefix to be shared. Construct a path prefix shared storage unit for the prefix to be shared; Establish a path prefix shared index, which includes a prefix key index, a path pattern to prefix unit mapping table, a prefix reference table, and a prefix end extension table; The complete path is split into a shared prefix reference and a differential suffix segment. The shared prefix reference points to the shared storage unit of the path prefix, and the differential suffix segment contains a suffix edge sequence and a suffix version vector. During path query, the reusable path prefix shared storage unit is identified based on the path prefix shared index. After version verification and time validity verification, the path prefix shared storage unit is read, and the subsequent path is expanded from the end node. The shared prefix segment is combined with the subsequent expanded segment to generate a complete query result. Version consistency maintenance is performed on the path prefix shared storage unit. The validity of the shared prefix is ​​determined by comparing the edge version vector with the current underlying edge version, and the corresponding state update process is performed according to the edge change type. The shared revenue score PSS(C) j Calculated as follows: PSS(C j )=a1·norm(Hit(C j ))+a2·norm(Reuse(C j ))+a3·norm(CostSave(C j ))+a4·norm(Stability(C j ))-a5·norm(UpdateCost(C j ))-a6·norm(StorageOverhead(C j )) Among them, C j Indicates the candidate prefix, Hit(C) j) Reuse(C) represents the number of times a candidate prefix is ​​hit within the statistics window. j The ) represents the number of candidate prefixes reused in different query patterns. CostSave(C j The value () represents the expected savings in adjacency unrolling cost from reusing the prefix. Stability(C) j The prefix indicates the stability of the edges involved within the statistical window. `UpdateCost(C)` represents the degree of stability of the edges involved within the statistical window. j ) represents the update cost required to maintain this prefix, StorageOverhead(C j The symbol represents the additional metadata and storage overhead incurred by establishing a shared storage unit, a1 to a6 are weight parameters, and norm() represents the normalization function; The adjacency expansion cost savings CostSave(C j ) is represented as: CostSave(C j )=ExpandCost(C j )×(Hit(C j )-1) Among them, ExpandCost(C j Hit(C) represents the average cost required to re-expand the prefix from the original adjacency list each time. j )-1 indicates the number of times the device can be reused after the initial expansion; The stability level Stability(C) j ) is represented as: Stability(C j )=1-ChangeRate(C j ) Among them, ChangeRate(C j The prefix indicates the frequency of edge additions, deletions, attribute changes, or valid status changes.

2. The path prefix shared storage method for graph databases according to claim 1, characterized in that, The sliding window analysis of the collected path query results includes: For each path, extract a prefix edge sequence of length l, where 1≤l≤Lmax, and Lmax represents the maximum prefix length allowed to establish a shared memory unit; Prefixes with the same initial constraint, the same relation type sequence, the same direction constraint, the same filtering condition summary, and the same edge sequence are grouped into the same candidate prefix.

3. The path prefix shared storage method for graph databases according to claim 1, characterized in that, The path prefix shared storage unit includes a prefix identifier, edge sequence reference, edge version vector, relation type sequence, direction sequence, filter condition summary, prefix length, path status summary, reference count, valid time range, storage location, update status, and invalidation status. The path state summary includes the prefix end node set, the prefix cumulative edge attribute summary, the prefix cumulative risk score, the prefix path length, whether the prefix passes through hotspot nodes, whether the prefix crosses partitions, and whether the prefix meets the time validity constraint.

4. The path prefix shared storage method for graph databases according to claim 1, characterized in that, Reusing the shared storage unit for path prefixes during path lookup includes: Parse the query statement and extract the starting point, relation type sequence, direction, hop count range, filter conditions, and time window; Generate a query path pattern summary; Candidate shared prefixes are found in the prefix key index and path pattern to the prefix unit mapping table; Perform version verification, time validity verification, and filter condition compatibility verification on candidate shared prefixes; After the verification is successful, the path prefix shared storage unit is read directly, and the subsequent path is continued to be expanded from the end node; The shared prefix segment is combined with the subsequent expanded segment to generate a complete query result, and the hit count, citation count, and popularity score of the shared prefix are updated.

5. The path prefix shared storage method for graph databases according to claim 1, characterized in that, The version consistency maintenance includes: Maintain the edge version vector VV(PSU) of the shared prefix unit =<ver(e1),ver(e2),...,ver(el)> , where ver(ei) represents the version number of the i-th edge, and l represents the prefix length; When querying, read the current underlying edge version VVcurrent=<vercurrent(e1),vercurrent(e2),...,vercurrent(el)> ; If VV(PSU) = VVcurrent, then the shared prefix is ​​valid; If the condition is not met, then perform the following processing based on the edge change type: When non-critical fields of edge attributes change, update the attribute summary and version vector of the shared cell; When a key field of an edge attribute changes, the shared cell is marked as partially invalid and the filter condition summary is recalculated. When an edge is deleted or becomes invalid, the shared prefix unit is marked as invalid and the related path references are reduced; When a new edge is added to form a better shared prefix, the candidate prefix analysis process is restarted. When the prefix terminal node undergoes expansion changes, update the prefix terminal expansion table.

6. The path prefix shared storage method for graph databases according to claim 1, characterized in that, The path prefix shared storage method for graph databases also includes dynamically adjusting the path prefix shared storage units.

7. The path prefix shared storage method for graph databases according to claim 6, characterized in that, The dynamic adjustment includes: For shared prefix replacement, the replacement score of the shared memory unit of the path prefix is ​​calculated according to the following formula: EliminateScore(PSU)=β1·norm(IdleTime)+β2·norm(UpdateCost)+β3·norm(StorageOverhead)+β4·norm(UpdateFreq)-β5·norm(HitCount)-β6·norm(ReferenceCount) Where IdleTime represents idle time, UpdateCost represents maintenance cost, StorageOverhead represents storage overhead, UpdateFreq represents update frequency, HitCount represents the number of hits, ReferenceCount represents the reference count, and β1 to β6 are weight parameters; If the elimination score is greater than the elimination threshold, the corresponding path prefix shared storage unit is added to the elimination candidate queue. For the path prefix shared storage unit added to the elimination candidate queue, its current reference status and version status are checked. If it is not currently referenced by the query task being executed and there are no incomplete suffix segment dependencies, the elimination operation is performed. Shared prefix merging: When multiple shared prefixes have the same starting point, the same relation type sequence, and the same first few edges, they are merged into a shorter shared prefix unit, and the difference part is saved as a suffix segment; Shared prefix splitting involves splitting a shared prefix into a stable prefix segment and a failed suffix segment when the latter half of the prefix frequently fails while the former half remains stable. This preserves the stable prefix and reduces maintenance costs.

Images