A method and system for dynamic graph storage and snapshot access based on cumulative version blocks

Abstract

The application discloses a dynamic graph storage and snapshot access method and system based on a cumulative version block, and belongs to the technical field of graph storage. In order to solve the technical problems that when graph data continuously receives transaction updates and graph analysis tasks concurrently access different snapshots, current adjacent data is mixed with historical version data, snapshot reading depends on an edge-by-edge version chain, and historical version transaction-by-transaction publishing leads to high coordination overhead, the current edge state, the historical edge version not yet published and the historical edge version already published are stored separately, the historical edge version with the same version time under the same source vertex is organized into a cumulative version block according to the creation time and is published according to the update batch; when reading, the cumulative version block is filtered according to the target snapshot time, and the visible edge version is determined, so that the out-edge set of the source vertex is obtained. The application can maintain the continuity of the current adjacent scanning, reduce edge-by-edge version access and scattered memory access, and reduce the coordination overhead of historical version publishing and recycling.

Description

Technical Field

[0001] This invention relates to a dynamic graph storage and snapshot access method and system based on cumulative version blocks, belonging to the field of graph storage technology. Background Technology

[0002] A graph is a data representation consisting of vertices and edges, where vertices represent entities and edges represent the relationships between entities. Graph data can describe user relationships in social networks, transaction relationships in financial systems, user-content relationships in recommendation systems, and device communication relationships in cybersecurity systems. In these applications, graph data is typically constantly changing, such as adding user relationships, deleting broken connections, modifying transaction relationships, or updating edge attribute values. Simultaneously, the system needs to perform graph analysis tasks such as breadth-first search, single-source shortest path, connected component analysis, community detection, and PageRank during the continuous updating of the graph data.

[0003] Dynamic graphs can take on different states at different times. The insertion, deletion, or attribute modification of edges causes the graph to transition from one state to another; the graph states at each point in time can be represented as graph snapshots. Graph analysis tasks may start at different times and require continuous access to the graph state at the start of the task during execution. Therefore, in addition to receiving graph updates, graph storage systems also need to save or restore graph snapshots at different times.

[0004] like Figure 1 As shown, outgoing edges of the same vertex can be modified at different times, forming corresponding graph snapshots at different timestamps. For continuously running graph analysis tasks, even if the system has received new edge updates, earlier read tasks may still need to access the edge states before the updates. Therefore, dynamic graph storage involves not only storing the current graph state but also organizing and accessing historical edge states.

[0005] Adjacency lists and compressed sparse rows are two common data structures in graph data storage. An adjacency list maintains a neighbor list for each vertex, storing edges originating from that vertex or identifiers of target vertices. When reading the neighborhood of a vertex, the corresponding neighbor list is first located based on the vertex index, and then the edges within it are accessed sequentially. Because the neighbor lists of different vertices are independent, adjacency lists facilitate data partitioning by vertex and also allow for insertion, deletion, and resizing operations on edges of individual vertices. Neighbor lists can be implemented using data structures such as arrays, linked lists, skip lists, trees, or block arrays, allowing for the selection of appropriate internal organization methods based on query and update requirements.

[0006] Compressed Sparse Row (CSR) uses vertex offset arrays and contiguous edge arrays to represent graph data. The vertex offset array records the start and end positions of each vertex's adjacency data within the edge array, with neighbors of the same vertex stored contiguously. When querying the neighbors of a vertex, the corresponding data range can be directly determined through the offset array. Because the edges of multiple vertices are stored in a contiguous storage region, CSR features a compact storage structure, continuous adjacency scanning process, and fewer extra pointers. It is suitable for graph analysis tasks that require repeated traversal of adjacency data and facilitates the division of scanning tasks among multiple computation threads based on vertex or edge ranges.

[0007] like Figure 2 As shown, adjacency lists store the neighbors of each vertex separately and locate the neighbor list using vertex indices; CSRs, on the other hand, divide the adjacency range of each vertex in a continuous edge array using an offset array. Both structures support accessing adjacency data by vertex, but their physical organization differs. Adjacency lists allow the neighbor list of each vertex to be adjusted relatively independently, making them suitable for graph data with local updates; CSRs can continuously store edges with less auxiliary information, making them suitable for large-scale adjacency scans on stable graph snapshots. In continuous update scenarios, adjacency list-based storage structures need to handle neighbor list expansion, data scattering, and index maintenance, while CSRs need to handle data movement caused by insertions or deletions, free space reservation, or batch reorganization.

[0008] To provide consistent graph snapshots as graph updates continue to occur, existing dynamic graph storage systems typically employ transaction processing and multi-version concurrency control (MPV). Transaction processing is used to execute updates to a set of related edges as a whole, preventing read tasks from observing intermediate states where only partial updates have been completed. MPV preserves the old edge state as an edge is updated and creates a new version for the updated edge. Each version record carries corresponding time information, and read tasks select the visible version based on their own snapshot time, enabling update transactions and graph analysis tasks to run concurrently.

[0009] A storage system that simultaneously supports graph update transactions, consistent snapshot readings, and graph analysis tasks can be called a transactional graph storage system. Such systems typically consist of two parts: a vertex index and an edge storage. The vertex index maps external vertex identifiers to internal identifiers and locates the adjacency data of the corresponding vertex; the edge storage stores the current adjacency data and historical edge versions generated by multi-version concurrency control.

[0010] like Figure 3 As shown, depending on whether the current adjacent data and historical version data are stored in the same physical container, existing transactional graph storage methods can be divided into coupled edge version storage and decoupled edge version storage.

[0011] Coupled edge version storage stores the current edge state and historical update records in a common data area. Zhu et al. proposed the LiveGraph system (see ZHU X, FENG G, SERAFINI M, et al. LiveGraph: A Transactional Graph Storage System with Purely Sequential Adjacency ListScans[J]. Proceedings of the VLDB Endowment, 2020, 13(7): 1020-1034.), which maintains vertex adjacency data in append log form and determines whether a record is visible to the target snapshot by timestamp. Zhou et al. proposed the GTX system (see ZHOU L, RAYHAN Y, XING L, AREF W G. GTX: A Write-Optimized Latch-free Graph Data System with Transactional Support[J]. Proceedings of the ACM on Management of Data, 2025, 3(3): 1-27.), which uses incremental records and incremental chain organization graph updates and combines indexes to speed up single edge location. The system described above receives new edge states through append-only records, which can reduce data movement during update writes. However, the current version and historical versions may coexist within the incremental record area.

[0012] Decoupled edge version storage organizes current adjacency data and historical version data separately. De Leo et al. proposed the Teseo system (see DE LEO D, BONCZ P. Teseo and the Analysis of StructuralDynamic Graphs[J]. Proceedings of the VLDB Endowment, 2021, 14(6): 1053-1066.), which uses a sparse array with gaps and a multi-level tree structure to store dynamic graph data. Fuchs et al. proposed the Sortledton data structure (see FUCHS P, GICEVA J, MARGAN D. Sortledton: AUniversal, Transactional Graph Data Structure[J]. Proceedings of the VLDB Endowment, 2022, 15(6): 1173-1186.), which maintains an adjacency set consisting of multiple ordered edge blocks for each vertex and uses a skip list to connect the corresponding data blocks. Hao et al. proposed the RapidStore system (see HAO C, SU J, SUN S, et al. RapidStore: An Efficient Dynamic Graph Storage System for Concurrent Queries[J]. Proceedings of the VLDB Endowment, 2025, 18(10): 3587-3600.), which separates graph data from version data and adopts a subgraph-oriented concurrency control and version management approach. The system stores the current edge state in an adjacency query-oriented structure and transfers the old state replaced by the new version to an independent historical version region, enabling the current adjacency structure and the historical version structure to be organized separately.

[0013] The existing systems described above employ different adjacency data structures and historical version organization methods. CSR (Continuous Relationship Streaming) emphasizes contiguous storage and adjacency scanning, while adjacency lists emphasize independent data organization by vertex. Coupled version storage focuses on receiving updates through append records, while decoupled version storage allows the current adjacency structure and historical version structure to be organized separately. In transactional graph storage, the system needs to handle edge updates, current adjacency scanning, and historical snapshot access simultaneously. Therefore, it is also necessary to determine the connection methods between historical versions, the method for determining version visibility, and the timing of publishing committed updates to read tasks.

[0014] The shortcomings of existing technology: 1. Existing coupled edge version storage methods store current adjacency data and historical version records in the same physical storage area. When an edge is inserted, deleted, or modified, the system typically appends the new edge state to the existing storage area as an incremental record or log record, instead of immediately removing expired records. This approach reduces data movement caused by update operations, but as updates continue, the storage area of ​​the same vertex will simultaneously contain currently valid records, historical records, and records not visible to the target snapshot. When a graph analysis task scans the vertex neighbor list, it needs to read and check these records, and then filter edges visible under the target snapshot based on timestamps or transaction states, resulting in the actual amount of data read being greater than the amount of data obtained. The interleaving of historical records and current adjacency data also reduces the continuity of adjacency scanning, making it difficult to maintain the sequential scanning advantages of continuous adjacency arrays or CSR-type structures.

[0015] 2. While existing decoupled edge version storage separates current adjacency data from historical version data, historical versions are typically organized into version chains from newest to oldest for each edge. When reading an earlier graph snapshot, the system first checks the current edge record in the main adjacency structure; if the current record is later than the target snapshot time, it needs to access earlier historical records sequentially along the version chain corresponding to that edge until a version with a valid time range that includes the target snapshot time is found. In continuously updated graphs, an edge may form multiple historical versions, and multiple graph analysis tasks may also maintain different snapshot times. In this case, the read task needs to perform version chain access for multiple edges in the neighbor list and repeatedly read newer versions that are not visible to the target snapshot. Since the historical records of each edge are usually scattered in different memory locations, this process results in pointer jumps, random memory accesses, and repeated visibility checks.

[0016] 3. Existing multi-version graph storage methods suffer from fine-grained version release and historical reclamation. If a single transaction or edge update is used as the unit for version creation, release, and reclamation, the system needs to frequently generate timestamps, modify shared transaction states, organize historical records, and notify read tasks of visibility when there are many small transactions. If the current adjacency data and historical version data are organized immediately after each transaction commit, the update thread will bear a significant amount of sorting, data movement, and synchronization operations. If historical versions are processed with a delay, additional determination is needed to determine when committed updates can be safely accessed by read tasks. Long-running graph analysis tasks also retain earlier snapshots, preventing the system from immediately deleting old versions; when multiple analysis tasks retain different snapshots, the system needs to determine which versions may still be readable. In storage methods based on single-edge version chains, the release and reclamation of historical versions often require processing along multiple version chains separately, increasing metadata access and synchronization overhead. Summary of the Invention

[0017] The purpose of this invention is to propose a dynamic graph storage and snapshot access method and system based on cumulative version blocks, in order to solve the technical problems of mixed current adjacency data and historical version data, snapshot reading relying on edge-by-edge version chains, and high coordination overhead caused by historical version publishing per transaction when graph data continuously receives transaction updates and graph analysis tasks concurrently access different snapshots. The invention aims to maintain the continuity of current adjacency scanning, support consistent snapshot access, and reduce the overhead of historical version reading, publishing, and recycling.

[0018] To achieve the above objectives, the present invention adopts the following technical solution.

[0019] A dynamic graph storage and snapshot access method based on cumulative version blocks includes the following steps: The received graph update transactions are allocated to update batches, the primary adjacency structure is updated according to the graph update transactions, and the resulting historical edge versions are written into temporary version blocks. When the update batch meets the release conditions, the historical edge versions in the temporary version block are organized into a cumulative version block according to the source vertex and version time; Set the cumulative version block to an immutable state, connect the cumulative version block to the cumulative version block chain of the corresponding source vertex according to the version time identifier, and update the published visible boundary of the corresponding update batch; Based on the snapshot read request including the source vertex identifier and the target snapshot time, access the main adjacency structure of the corresponding source vertex, and determine the candidate cumulative version block from the cumulative version block chain of the corresponding source vertex according to the target snapshot time; The edge versions visible at the target snapshot time are determined from the main adjacency structure and the candidate cumulative version block, and the outgoing edge set of the source vertex at the target snapshot time is obtained.

[0020] Furthermore, the primary adjacency structure is updated according to the graph update transaction, and the resulting historical edge versions are written to a temporary version block, including: Update the main adjacency structure of the transaction location source vertex and the state of the edge to be updated according to the graph; Update the state of the edge to be updated according to the update type, and determine the state of the replaced or deleted edge as the historical edge version; The updated edge state is written to the main adjacency structure, and the historical edge version is written to the temporary version block.

[0021] Furthermore, the state of the edge to be updated is updated according to the update type, and the state of the replaced or deleted edge is determined as a historical edge version, including: When the update type is edge insertion, a new edge state is generated according to the graph update transaction; When the update type is edge modification, a new edge state is generated according to the graph update transaction to replace the edge state to be updated, and the edge state to be updated is determined as a historical edge version. When the update type is edge deletion, the edge state to be updated is removed or the edge state to be updated is set to deletion, and the edge state to be updated before deletion is determined as a historical edge version.

[0022] Furthermore, the primary adjacency structure is updated according to the graph update transaction, and the resulting historical edge versions are written to a temporary version block, including: The edge update record generated by the graph update transaction is appended to the write buffer of the main adjacency structure; When the write buffer meets the merging condition, the edge update record in the write buffer is merged with the ordered edge array of the main adjacency structure according to the target vertex identifier, and a historical edge version is generated according to the state of the replaced or deleted edge. Update the ordered edge array based on the merge result, and write the historical edge version into the temporary version block.

[0023] Furthermore, the received graph update transactions are assigned to update batches, including: Determine the currently open update batches and assign the received graph update transactions to the currently open update batches; When the currently open update batch meets the closing condition, the currently open update batch is set to a closed state, and the next open update batch is created; The graph update transactions received after the currently open update batch is closed will be allocated to the next open update batch.

[0024] Furthermore, when the currently open update batch meets the closing condition, the currently open update batch is set to a closed state, and the next open update batch is created, including: Sampling is performed on the edge updates in the currently open update batch, and the shared sampling count is updated when a sampling hit occurs. When the shared sampling count reaches the sampling quota, the update batch closure control is acquired, and it is confirmed that the currently open update batch has not been switched. Set the currently open update batch to a closed state, create the next open update batch, and reset the shared sampling count.

[0025] Furthermore, when the currently open update batch meets the closure condition, the currently open update batch is set to a closed state, and the next open update batch is created, including: Obtain at least one batch status data from the currently open update batch: update quantity, transaction quantity, duration, and temporary version block space occupied; The batch status data is compared with the corresponding closure threshold to determine whether the currently open update batch meets the closure conditions. When the closure condition is met, the currently open update batch is set to a closed state, and the next open update batch is created.

[0026] Further, determining that the update batch meets the release conditions includes: After the update batch is closed, stop allocating new graph update transactions to the update batch; Check whether all graph update transactions assigned to the update batch have been committed or terminated; The update batch is determined to meet the release conditions when all graph update transactions assigned to the update batch have been committed or terminated.

[0027] Further, detecting whether all graph update transactions allocated to the update batch have been committed or terminated includes: Retrieve the update batch identifier, access mode, and activity status recorded in the activity slots of each worker thread; Based on the update batch identifier, the access mode, and the activity status, determine whether there are any graph update transactions that are still accessing the update batch; If there are no graph update transactions still accessing the update batch, it is determined that all graph update transactions assigned to the update batch have been committed or terminated.

[0028] Furthermore, the historical edge versions in the temporary version block are organized into cumulative version blocks according to the source vertex and version time, including: Obtain the valid historical edge versions belonging to the update batch from the temporary version block, and group the valid historical edge versions according to the source vertex and version time; Sort the valid historical edge versions of each group according to their creation time; The sorted groups of valid historical edge versions are stored consecutively to obtain the corresponding cumulative version blocks.

[0029] Furthermore, the sorted groups of valid historical edge versions are stored consecutively to obtain the corresponding cumulative version blocks, including: Generate a block header based on the source vertex, version time, and number of records corresponding to each group of valid historical edge versions, and allocate a record area for each group of valid historical edge versions. Each group of valid historical edge versions is continuously written into the corresponding record area, and the record area is associated with the corresponding block header to obtain the cumulative version block.

[0030] Further, the accumulated version block is set to an immutable state, and the accumulated version block is connected to the accumulated version block chain of the corresponding source vertex according to the version time identifier, and the published visible boundary of the corresponding update batch is updated, including: The cumulative version blocks to be released are determined according to the order of the update batches, and the cumulative version blocks to be released are set to an immutable state. Establish a temporal sequence association between the cumulative version block to be released and adjacent cumulative version blocks in the cumulative version block chain of the corresponding source vertex, based on the version time identifier; After the cumulative version block to be released is connected, the released visible boundaries are updated in the order of the update batches.

[0031] Furthermore, update the published visibility boundaries of the corresponding update batch, including: Before the update batch is released, the updated state generated by the update batch is stored in the write buffer of the main adjacency structure; When the update batch is released, the updated state is incorporated into the main adjacency structure, and the cumulative version block corresponding to the update batch is connected to the cumulative version block chain; After the update is completed and the cumulative version block is released, update the published visibility boundary of the update batch.

[0032] Furthermore, update the published visibility boundaries of the corresponding update batch, including: When a graph update transaction is committed, a commit sequence number within the batch is assigned to the graph update transaction, and a version time identifier is determined based on the update batch identifier and the commit sequence number within the batch. The creation time of the updated edge state and the expiration time of the replaced or deleted edge state are determined according to the version time identifier, and the updated edge state is written into the main adjacency structure. When the update batch is released, the corresponding cumulative version block is connected to the cumulative version block chain, and the released visible boundary is updated according to the version time identifier.

[0033] Further, based on the target snapshot time, candidate cumulative version blocks are determined from the cumulative version block chain of the corresponding source vertex, including: Obtain the version time identifier of each cumulative version block in the cumulative version block chain; Compare the version time identifier of each cumulative version block with the target snapshot time, and exclude cumulative version blocks that have expired before the target snapshot time; The accumulator blocks that were not excluded are identified as candidate accumulator blocks.

[0034] Further, the version time identifier of each cumulative version block is compared with the target snapshot time, and cumulative version blocks that have expired before the target snapshot time are excluded, including: Compare the update batch identifier in the version timestamp with the update batch identifier in the target snapshot time; When the version time identifier corresponds to the same update batch as the target snapshot time, the commit sequence number within the batch in the version time identifier is compared with the commit sequence number within the batch in the target snapshot time; Based on the comparison between the update batch identifier and the commit sequence number within the batch, determine whether the corresponding cumulative version block has expired before the target snapshot time.

[0035] Further, based on the snapshot read request including the source vertex identifier and the target snapshot time, the primary adjacency structure of the corresponding source vertex is accessed, and candidate cumulative version blocks are determined from the cumulative version block chain of the corresponding source vertex according to the target snapshot time, including: The concurrent read protection of the corresponding source vertex is obtained based on the source vertex identifier; Under the concurrent read protection, obtain the main adjacency structure, the stable entry point of the cumulative version block chain, and the published visible boundary; Release the concurrent read protection after obtaining the stable entry point and the published visible boundary; Based on the target snapshot time and the published visible boundary, the candidate cumulative version block is determined from the cumulative version block chain pointed to by the stable entry.

[0036] Further, the edge versions visible at the target snapshot time are determined from the main adjacency structure and the candidate cumulative version block, resulting in the set of outgoing edges from the source vertex at the target snapshot time, including: The current visible edge state is determined from the main adjacency structure based on the target snapshot time; Scan the historical edge versions in the candidate cumulative version block according to the creation time, and determine the visible historical edge versions based on the creation time and expiration time; By merging the visible current edge state and the visible historical edge version according to the logical edge, the set of outgoing edges of the source vertex at the target snapshot time is obtained.

[0037] Further, the historical edge versions in the candidate cumulative version block are scanned according to their creation time, and the visible historical edge versions are determined based on their creation time and expiration time, including: The creation and expiration times of historical side versions in the candidate cumulative version block are compared with the target snapshot time in chronological order of creation time. When a historical edge version whose creation time is no earlier than the target snapshot time is detected, the scanning of the current candidate cumulative version block is stopped; The historical edge versions that meet the conditions of having a creation time earlier than the target snapshot time and an expiration time no earlier than the target snapshot time before the scanning stops are determined as the visible historical edge versions.

[0038] Further, the edge versions visible at the target snapshot time are determined from the main adjacency structure and the candidate cumulative version block, resulting in the set of outgoing edges from the source vertex at the target snapshot time, including: Scan the current edge state in the main adjacency structure in the order of the target vertex identifiers; When the current edge state does not meet the target snapshot time, locate the historical edge version of the same logical edge from the candidate cumulative version block according to the predecessor version reference of the current edge state; The visible edge version is determined from the historical edge version based on the target snapshot time, and the outgoing edge set of the source vertex at the target snapshot time is generated in the order of the target vertex identifiers.

[0039] A dynamic graph storage and snapshot access system based on cumulative version blocks, comprising: The update transaction processing module is used to allocate the received graph update transactions to update batches, update the main adjacency structure according to the graph update transactions, and write the generated historical edge versions into a temporary version block. The version block construction module is used to organize the historical edge versions in the temporary version block into a cumulative version block according to the source vertex and version time when the update batch meets the release conditions; The background publishing module is used to set the cumulative version block to an immutable state, connect the cumulative version block to the cumulative version block chain of the corresponding source vertex according to the version time identifier, and update the published visible boundary of the corresponding update batch. The snapshot reading module is used to access the main adjacency structure of the corresponding source vertex according to the snapshot reading request including the source vertex identifier and the target snapshot time, and determine the candidate cumulative version block from the cumulative version block chain of the corresponding source vertex according to the target snapshot time. The outgoing edge set generation module is used to determine the edge versions visible at the target snapshot time from the main adjacency structure and the candidate cumulative version block, and obtain the outgoing edge set of the source vertex at the target snapshot time.

[0040] The present invention has achieved the following beneficial effects.

[0041] 1. This invention stores the current edge state, unpublished historical edge versions, and published historical edge versions in the main adjacency structure, temporary version block, and cumulative version block chain, respectively. The current edge state is continuously saved and organized through an ordered edge array, and recent edge updates are received through a write buffer. This eliminates the need for the current adjacency scan to access a large number of historical edge versions and invalid edge states simultaneously, thereby reducing the reading of version metadata and invalid data and maintaining the continuous storage and sequential access of the source vertex outgoing edge set.

[0042] 2. This invention centrally stores multiple historical edge versions with the same expiration time or the same update batch identifier under the same source vertex in a continuous cumulative version block, and arranges the historical edge versions in the block according to the creation time. At the same time, it retains the inheritance relationship between different versions of the same logical edge through predecessor version references. This changes the physical structure of organizing historical versions in a scattered manner based on logical edges, which can reduce version pointer jumps and scattered memory accesses, and take into account both continuous snapshot scanning and the location of historical versions of specified logical edges.

[0043] 3. In the snapshot reading process, the present invention first performs block-level visibility judgment based on the version time identifier of the cumulative version block, and excludes the cumulative version blocks that cannot contain visible edge versions under the target snapshot time. Then, it continuously scans the candidate cumulative version blocks in the order of creation time, and stops scanning when the subsequent historical edge versions do not meet the visibility conditions. This can reduce the access to the edge version chain, the check of invisible versions one by one, and the access to invalid records in the candidate cumulative version blocks.

[0044] 4. This invention divides multiple graph update transactions into update batches, allowing each update batch to sequentially experience open, closed, committed, and published states. Historical edge versions generated by the graph update transactions are first appended to temporary version blocks, and then immutable cumulative version blocks are constructed and published in batches according to the update batch order. Update batch closure can be triggered by sampling counts, and the completion status of graph update transactions can be asynchronously detected through worker thread activity slots, thereby reducing the need for historical version organization during each edge update or transaction commit and frequent coordination of shared update batch states.

[0045] 5. This invention employs a dual-granularity timestamp consisting of an update batch identifier and a commit sequence number within the batch. While maintaining the construction and publication of cumulative version blocks according to update batches, it distinguishes the commit order of different graph update transactions within the same update batch. Furthermore, it protects the main adjacency structure, temporary version blocks, and cumulative version block chain entry points through vertex-level concurrency control, enabling read tasks to access the immutable cumulative version blocks pointed to by stable entry points. When historical edge versions are no longer accessed by active snapshots and there are no valid predecessor versions referencing them, they are reclaimed on a per-cumulative version block basis. This ensures snapshot visibility and reduces the overhead of metadata access and structural modification during the historical data reclamation process. Attached Figure Description

[0046] Figure 1 This is a schematic diagram illustrating the changes in snapshot data at different timestamps. Figure 2 This is a schematic diagram of the adjacency list and CSR structure; Figure 3 A schematic diagram of transactional graph storage abstraction and edge version storage method; Figure 4 This is a flowchart of a dynamic graph storage and snapshot access method based on cumulative version blocks in an embodiment. Figure 5 A comparison diagram of data organization and reading methods between traditional edge version chains and cumulative version blocks; Figure 6 This is a diagram illustrating the period state transition and sequential release process. Detailed Implementation

[0047] To make the various technical features, advantages, or effects of the present invention more apparent and understandable, detailed descriptions are provided below through embodiments.

[0048] This invention provides a method for dynamic graph storage and snapshot access based on cumulative version blocks, such as... Figure 4 As shown, this method uses the set of outgoing edges of the source vertex as the management object, and organizes the current edge state, the unpublished historical edge version, and the published historical edge version in the main adjacency structure, the temporary version block, and the cumulative version block chain, respectively.

[0049] The operational basis of this method includes vertex indexes, a main adjacency structure, temporary version blocks, and a cumulative version block chain. Vertex indexes are used to locate the storage entry of the corresponding vertex based on the external vertex identifier; the main adjacency structure is used to store the state of currently valid or currently published outgoing edges and serves as the entry point for reading the outgoing edge set; temporary version blocks are used to temporarily store historical edge versions generated by graph update transactions but not yet published; and the cumulative version block chain is used to store historical edge versions that have been published according to version time.

[0050] The current edge state and historical edge versions are stored separately. When an edge is modified, deleted, or replaced by a new edge state, the edge state before the replacement or deletion forms the historical edge version. A historical edge version includes at least the source vertex identifier, target vertex identifier, edge attribute value, creation time, expiration time, and a reference to the predecessor version. The creation time represents the logical time when the edge state became valid, and the expiration time represents the logical time when the edge state was subsequently updated or deleted. If the target snapshot time is later than the creation time but not later than the expiration time, the historical edge version is visible at the target snapshot time.

[0051] The predecessor version reference is used to locate the previous historical edge version of the same logical edge. The predecessor version reference can include the identifier and position within the cumulative version block where the previous historical edge version resides, or it can use an address or index that can locate the previous historical edge version. Published cumulative version blocks are immutable structures; subsequently generated historical edge versions are written to temporary version blocks, and new cumulative version blocks are formed when the corresponding update batch is released.

[0052] Step S1: Assign the received graph update transactions to the update batch, update the primary adjacency structure according to the graph update transactions, and write the generated historical edge versions into the temporary version block.

[0053] Specifically, an update batch is the unit of organization for graph update transactions, and each update batch has a unique update batch identifier. Update batches have sequential states: open, closed, committed, and published. An open state indicates that the update batch can receive new graph update transactions; a closed state indicates that the update batch has stopped receiving new graph update transactions, but graph update transactions already assigned to this batch can still be executed; a committed state indicates that all graph update transactions within this update batch have been committed or terminated; and a published state indicates that the updates generated by this update batch have been processed and can be read by snapshots.

[0054] In an optional embodiment of the present invention, step S1, which updates the primary adjacency structure according to the graph update transaction and writes the generated historical edge version into a temporary version block, may include: Step S11: Update the main adjacency structure of the source vertex of the transaction location and the state of the edge to be updated according to the graph.

[0055] Specifically, the main adjacency structure of the source vertex can be located using the vertex index based on the source vertex identifier, and the state of the edge to be updated can be located based on the target vertex identifier. When setting concurrency control on a vertex-by-vertex basis, write access permissions for the source vertex are acquired before accessing the main adjacency structure and temporary version blocks. When a graph update transaction involves multiple vertices, write access permissions for each vertex can be acquired in the order of their internal identifiers; if acquiring write access permissions fails, the acquired write access permissions are released and the transaction is retried. The graph update transaction is terminated after a preset number of retries is reached.

[0056] Step S12: Update the state of the edge to be updated according to the update type, and determine the state of the replaced or deleted edge as the historical edge version.

[0057] In an optional embodiment of the present invention, step S12 may include: Step S121: When the update type is edge insertion, generate a new edge state according to the graph update transaction.

[0058] Specifically, the new edge state can include the target vertex identifier, edge attribute value, creation time, expiration time, record status, and predecessor version reference. If the newly inserted edge does not have a corresponding historical edge version to replace, no such historical edge version is generated.

[0059] Step S122: When the update type is edge modification, generate a new edge state according to the graph update transaction to replace the edge state to be updated, and determine the edge state to be updated as the historical edge version.

[0060] Specifically, the new edge state inherits the version relationship of the same logical edge, the state of the replaced edge to be updated records the corresponding expiration time, and is associated with the previous historical edge version of the same logical edge through the predecessor version reference.

[0061] Step S123: When the update type is edge deletion, remove the state of the edge to be updated or set the state of the edge to be updated to deletion, and determine the state of the edge to be updated before deletion as the historical edge version.

[0062] Specifically, the expiration time of the edge state to be updated before deletion is recorded. The main adjacency structure may choose not to save the current edge state of the deleted edge, or it may retain the corresponding deletion state.

[0063] Step S13: Write the updated edge state into the main adjacency structure and write the historical edge version into the temporary version block.

[0064] Specifically, the temporary version block receives historical edge versions in the order they are written, does not require sorting of historical edge versions when the graph update transaction is committed, and does not modify the already published cumulative version block in place.

[0065] In an optional embodiment of the present invention, when a graph update transaction terminates, the temporary update record generated by the graph update transaction is deleted, or the temporary update record is set to an invalid state so that it is ignored when constructing the cumulative version block. If the updated edge state has already been written to the main adjacency structure, the edge state before the update can be restored based on the old edge state or reversal information after obtaining write access permissions for the corresponding vertex.

[0066] In an optional embodiment of the present invention, step S1, which updates the primary adjacency structure according to the graph update transaction and writes the generated historical edge version into a temporary version block, may include: Step S11: Append the edge update record generated by the graph update transaction to the write buffer of the primary adjacency structure.

[0067] Specifically, the primary adjacency structure may include an ordered edge array and a write buffer. The edge states in the ordered edge array are arranged and stored contiguously according to the target vertex identifier. The write buffer appends, modifies, and deletes edges in the order they are written, without requiring the order of the target vertex identifiers to be maintained for each write. The write buffer can be a fixed-length array, an expandable array, or a segmented buffer.

[0068] Step S12: When the write buffer meets the merging condition, merge the edge update records in the write buffer with the ordered edge array of the main adjacency structure according to the target vertex identifier, and generate historical edge versions according to the state of the replaced or deleted edges.

[0069] Specifically, the merging criteria can be determined based on the number of records in the write buffer, the space occupied, the write duration, the number of graph update transactions, the update batch status, or the background load. During merging, edge states unaffected by edge update records are retained; newly inserted edge states are inserted at the corresponding positions according to the target vertex identifier; modified edge states are replaced by new edge states, and the edge states before replacement are identified as historical edge versions; deleted edge states are not written to the merged ordered edge array, or are written to the merged ordered edge array in a deleted state.

[0070] Step S13: Update the ordered edge array according to the merging result and write the historical edge version into the temporary version block.

[0071] Specifically, after merging, the original structure is replaced with the merged ordered edge array or the corresponding array entry, and the write buffer is cleared or reinitialized. The main adjacency structure can also use a segmented ordered array, skip list, tree structure, dynamic CSR, or compressed adjacency array, as long as it can support continuous access to the outgoing edge set and the location of the specified edge state.

[0072] In an optional embodiment of the present invention, the step S1 of allocating the received graph update transactions to update batches may include: Step S11: Determine the currently open update batches and assign the received graph update transactions to the currently open update batches.

[0073] Specifically, at the start of a graph update transaction, the corresponding update batch identifier, write access mode, and activity status are recorded in the activity slot of the worker thread executing the graph update transaction, and the currently open update batches are checked again to see if they have changed. If the currently open update batches have changed, the update batch corresponding to the graph update transaction is redefined.

[0074] Step S12: When the currently open update batch meets the closing conditions, set the currently open update batch to a closed state and create the next open update batch.

[0075] In an optional embodiment of the present invention, step S12 may include: Step S121: Sample the edge updates in the currently open update batch and update the shared sampling count when the sampling hits.

[0076] Specifically, let the target update quantity of the update batch be N, and the sampling quota be h. The sampling probability is determined based on the ratio of the sampling quota h to the target update quantity N. When a graph update transaction performs an edge update, the shared sampling count is updated only when the edge update is sampled and hit. Here, N represents the target update quantity that triggers the closure of the update batch; h represents the sampling count threshold that triggers the closure of the update batch.

[0077] Step S122: When the shared sampling count reaches the sampling quota, obtain the closed control of the update batch and confirm that the currently open update batch has not been switched.

[0078] Specifically, the worker thread that triggers the update batch closure acquires the update batch closure lock and checks the currently open update batch identifier. If other worker threads have already completed the update batch switch, they abandon the current closure operation.

[0079] Step S123: Set the currently open update batch to a closed state, create the next open update batch, and reset the shared sampling count.

[0080] Specifically, after the update batch switch is completed, the next open update batch will receive subsequent graph update transactions, and the graph update transactions that have been assigned to the original update batch will continue to be executed.

[0081] In another alternative embodiment, the sampling count can be obtained by using thread-local counting, fragment counters, approximate counters, or periodic statistics, and the updated batch closure is triggered based on the obtained count results.

[0082] In another optional embodiment of the present invention, step S12 may include: Step S121: Obtain at least one batch status data from the following: update quantity, transaction quantity, duration, and temporary version block space occupied by the currently open update batch.

[0083] Step S122: Compare the batch status data with the corresponding closure threshold to determine whether the currently open update batch meets the closure conditions.

[0084] Specifically, a single batch state data can be used to determine the closure condition, or multiple batch state data can be used in combination to determine the closure condition.

[0085] Step S123: When the closure condition is met, set the currently open update batch to a closed state and create the next open update batch.

[0086] Step S13: Distribute the graph update transactions received after the currently open update batch is closed to the next open update batch.

[0087] Specifically, such as Figure 6 As shown, once the original update batch enters a closed state, it will no longer receive new graph update transactions. Graph update transactions that have already been assigned to the original update batch will continue to be executed, and subsequent graph update transactions will be assigned to the next open update batch.

[0088] Step S2: When the update batch meets the release conditions, organize the historical edge versions in the temporary version block into a cumulative version block according to the source vertex and version time.

[0089] Specifically, version time is used to determine the batch organization scope and time order to which historical edge versions belong. Version time can be an expiration time, update batch identifier, transaction batch identifier, commit batch identifier, or other monotonically increasing logical time. Historical edge versions with the same version time under the same source vertex are organized in the same cumulative version block.

[0090] In an optional embodiment of the present invention, determining that the update batch meets the release conditions in step S2 may include: Step S21: After the update batch is closed, stop allocating new graph update transactions to the update batch.

[0091] Step S22: Check whether all graph update transactions assigned to the update batch have been committed or terminated.

[0092] In an optional embodiment of the present invention, step S22 may include: Step S221: Obtain the update batch identifier, access mode, and activity status recorded in the activity slot of each worker thread.

[0093] Specifically, after a graph update transaction is committed or terminated, the activity state in the corresponding worker thread's activity slot is cleared.

[0094] Step S222: Based on the update batch identifier, access mode, and activity status, determine whether there are any graph update transactions that are still accessing the update batch.

[0095] Specifically, the active slots of each worker thread are periodically scanned, and the update batch identifier and write access mode recorded in the active slot are used to determine whether the corresponding worker thread is still executing the graph update transaction belonging to that update batch.

[0096] Step S223: If there are no graph update transactions still accessing the update batch, determine that all graph update transactions assigned to the update batch have been committed or terminated.

[0097] In another alternative embodiment, it can be determined whether all graph update transactions assigned to the update batch have been committed or terminated based on the transaction registry, reference count, active transaction list, or commit queue.

[0098] Step S23: When all graph update transactions assigned to the update batch have been committed or terminated, determine that the update batch meets the release conditions.

[0099] Specifically, update batches are released sequentially according to the time sequence corresponding to their update batch identifiers, with later update batches not being released before earlier update batches.

[0100] In an optional embodiment of the present invention, step S2, which organizes the historical edge versions in the temporary version block into a cumulative version block according to the source vertex and version time, may include: Step S21: Obtain the valid historical edge versions belonging to the update batch from the temporary version block, and group the valid historical edge versions according to the source vertex and version time.

[0101] Specifically, temporary update records that are deleted or set to an invalid state when a graph update transaction terminates are not included in the grouping. When an update batch involves multiple source vertices, historical edge versions are grouped separately for each source vertex; if a source vertex does not generate a historical edge version in the update batch, an empty cumulative version block is not created for that source vertex.

[0102] Step S22: Sort the valid historical edge versions of each group according to their creation time.

[0103] Specifically, historical side versions within the same cumulative version block have the same or similar expiration times and are arranged in chronological order of creation time. For example... Figure 5 As shown, historical versions of different logical edges can be arranged in contiguous storage areas based on the same version time.

[0104] Step S23: Store the sorted groups of valid historical edge versions consecutively to obtain the corresponding cumulative version blocks.

[0105] In an optional embodiment of the present invention, step S23 may include: Step S231: Generate a block header based on the source vertex, version time, and number of records corresponding to each group of valid historical edge versions, and allocate a record area for each group of valid historical edge versions.

[0106] Specifically, the block header can record the source vertex identifier, block time identifier, number of records in the block, record region address, and link information of adjacent cumulative version blocks.

[0107] Step S232: Write each group of valid historical edge versions continuously into the corresponding record area, and associate the record area with the corresponding block header to obtain the cumulative version block.

[0108] Specifically, cumulative version blocks can use contiguous arrays, fixed-size pages, variable-size pages, or segmented contiguous storage areas to store historical edge versions. Cumulative version blocks can also set record offset tables, time range indexes, or block header metadata to locate records within the block or determine the time range corresponding to records within the block.

[0109] Specifically, when writing historical edge versions to the record area, a predecessor version reference is set according to the version relationship of the same logical edge. The predecessor version reference can point to the cumulative version block where the previous historical edge version is located and its position within the block, or it can point to an address or index that can locate the previous historical edge version.

[0110] In an optional embodiment of the present invention, the sorting of valid historical edge versions and the construction of the cumulative version block content can be performed without occupying the write access permissions of the corresponding vertex, and the write access permissions of the corresponding vertex can be obtained when switching the cumulative version block chain entry and updating the visible state.

[0111] Step S3: Set the cumulative version block to an immutable state, connect the cumulative version block to the cumulative version block chain of the corresponding source vertex according to the version time identifier, and update the published visible boundary of the corresponding update batch.

[0112] Specifically, multiple cumulative version blocks corresponding to the same source vertex are formed in chronological order according to their version time identifiers. Cumulative version blocks closer to the entry point of the cumulative version block chain correspond to newer time ranges, while those farther from the entry point correspond to earlier time ranges. Once a cumulative version block is published, it is not modified in place.

[0113] In an optional embodiment of the present invention, step S3 may include: Step S31: Determine the cumulative version blocks to be released according to the order of update batches, and set the cumulative version blocks to be released to an immutable state.

[0114] Step S32: Establish a time sequence association between the cumulative version block to be released and the adjacent cumulative version blocks in the cumulative version block chain of the corresponding source vertex according to the version time identifier.

[0115] Specifically, the cumulative version block chain can be implemented using a linked list, a contiguous array of pointers, a segmented array, or a block directory, and the corresponding cumulative version block can be accessed based on the version time identifier.

[0116] Step S33: After the cumulative version block to be released is connected, update the released visible boundaries in the order of update batches.

[0117] Specifically, the published visible boundary represents the range of consecutive update batches that can be reliably accessed by snapshot readings. After an update batch completes the cumulative version block connection and publishes the corresponding current edge state, it updates to the visible boundary corresponding to that update batch.

[0118] In an optional embodiment of the present invention, the earliest snapshot time of the active read task can be recorded, and the safe reclamation boundary of the accumulator block can be determined accordingly. When an accumulator block is no longer accessible to the active read task, and there is no predecessor version reference that needs to reference the historical side version in the accumulator block, the accumulator block is removed from the accumulator block chain and the corresponding storage space is released.

[0119] Specifically, update batch protection, reference counting, dangerous pointers, or delayed reclamation queues can be used to delay the release of accumulated version blocks that have been stably accessed by read tasks but have not yet been fully accessed. When historical side versions are stored contiguously according to accumulated version blocks, historical data reclamation is performed on a unit basis of accumulated version blocks.

[0120] In an optional embodiment of the present invention, step S3, updating the published visibility boundary of the corresponding update batch, may include: Step S31: Before the update batch is released, the updated state generated by the update batch is saved in the write buffer of the main adjacency structure.

[0121] Specifically, in the update batch-level visibility mode, graph update transactions in the same update batch share the release time of the corresponding update batch, and the updated state does not enter the visibility range of ordinary snapshot reading before the update batch is released.

[0122] Step S32: When the update batch is released, the updated state is incorporated into the main adjacency structure, and the cumulative version block corresponding to the update batch is connected to the cumulative version block chain.

[0123] Step S33: After updating the status and cumulative version block, update the published visible boundary of the update batch.

[0124] Specifically, the updated status and historical versions within the same update batch share a common release boundary.

[0125] In another optional embodiment of the present invention, updating the published visibility boundary of the corresponding update batch in step S3 may include: Step S31: When a graph update transaction is committed, a commit sequence number within the batch is assigned to the graph update transaction, and the version time identifier is determined based on the update batch identifier and the commit sequence number within the batch.

[0126] Specifically, the version timestamp uses a dual-granularity timestamp consisting of an update batch identifier and a commit number within the batch. When comparing two dual-granularity timestamps, the update batch identifiers are compared first; if the update batch identifiers are the same, the commit numbers within the batch are compared next.

[0127] Step S32: Determine the creation time of the updated edge state and the expiration time of the replaced or deleted edge state according to the version time identifier, and write the updated edge state into the main adjacency structure.

[0128] Specifically, the commit time of a graph update transaction is represented by both the update batch identifier and the commit sequence number within the batch. The state of edges created by the graph update transaction is based on this commit time, while the state of edges that are replaced or deleted is based on this commit time.

[0129] Step S33: When updating the batch release, connect the corresponding cumulative version block to the cumulative version block chain, and update the released visible boundary according to the version time identifier.

[0130] Specifically, using dual-granularity timestamps does not change the physical structure of the cumulative version blocks organized by update batches. Historical edge versions that fail in the same update batch under the same source vertex are still organized in the corresponding cumulative version blocks.

[0131] In another alternative embodiment, the version time identifier may be a combination of a globally incrementing timestamp, a batch identifier and a transaction sequence number, a hybrid logical clock, or other time representation methods that can compare creation time, expiration time, and target snapshot time.

[0132] Step S4: Based on the snapshot read request including the source vertex identifier and the target snapshot time, access the main adjacency structure of the corresponding source vertex, and determine the candidate cumulative version block from the cumulative version block chain of the corresponding source vertex according to the target snapshot time.

[0133] Specifically, snapshot reading is performed on a per-source vertex basis. Based on the source vertex identifier, the primary adjacency structure, temporary version blocks, and cumulative version block chain of the corresponding source vertex are located using the vertex index. Snapshot reading first accesses the current edge state in the primary adjacency structure, and then accesses the already published cumulative version blocks based on the target snapshot time.

[0134] In an optional embodiment of the present invention, step S4, which involves determining candidate cumulative version blocks from the cumulative version block chain of the corresponding source vertex based on the target snapshot time, may include: Step S41: Obtain the version time identifier of each cumulative version block in the cumulative version block chain.

[0135] Step S42: Compare the version time identifier of each cumulative version block with the target snapshot time, and exclude cumulative version blocks that have expired before the target snapshot time.

[0136] In an optional embodiment of the present invention, step S42 may include: Step S421: Compare the update batch identifier in the version time identifier with the update batch identifier in the target snapshot time.

[0137] Step S422: When the version time identifier and the target snapshot time correspond to the same update batch, compare the commit sequence number in the batch in the version time identifier with the commit sequence number in the batch in the target snapshot time.

[0138] Step S423: Based on the comparison result between the update batch identifier and the commit sequence number within the batch, determine whether the corresponding cumulative version block has expired before the target snapshot time.

[0139] Specifically, when the cumulative version block and the target snapshot time belong to different update batches, a block-level judgment is made based on the update batch identifier; when the cumulative version block and the target snapshot time belong to the same update batch, the historical side version in the cumulative version block is further judged based on the commit sequence number within the batch to determine whether it is visible under the target snapshot time.

[0140] Step S43: Identify the accumulator blocks that have not been excluded as candidate accumulator blocks.

[0141] Specifically, if all historical edge versions in a cumulative version block have expired before the target snapshot time, the entire cumulative version block is skipped; if a cumulative version block may contain historical edge versions visible at the target snapshot time, the cumulative version block is included in the candidate cumulative version block.

[0142] In an optional embodiment of the present invention, step S4 may include: Step S41: Obtain the concurrent read protection of the corresponding source vertex based on the source vertex identifier.

[0143] Specifically, concurrent read protection can employ vertex-level read-write locks, or it can employ optimistic locking, segmented locking, version verification, read replication update, or transaction write set verification mechanisms.

[0144] Step S42: Under concurrent read protection, obtain the main adjacency structure, the stable entry point of the cumulative version block chain, and the published visible boundary.

[0145] Specifically, it is also possible to obtain the stable entry and record status of temporary version blocks under concurrent read protection, so as to access historical side versions that have not yet been released but have been committed.

[0146] Step S43: After obtaining a stable entry point and a published visible boundary, release the concurrent read protection.

[0147] Specifically, for snapshot reads that only access published update batches, after obtaining a stable entry point to the cumulative version block chain, immutable cumulative version blocks can be accessed without continuously occupying concurrent read protection.

[0148] Step S44: Based on the target snapshot time and the published visible boundary, determine the candidate cumulative version block from the cumulative version block chain pointed to by the stable entry.

[0149] Specifically, when the target snapshot time is within the published visible boundary, block-level determination is performed based on the version time identifier of the cumulative version block. When the target snapshot time involves an update batch that has not yet been published, historical side versions already committed in the temporary version block are accessed under concurrent read protection.

[0150] Step S5: Determine the edge versions visible at the target snapshot time from the main adjacency structure and candidate cumulative version blocks to obtain the set of outgoing edges of the source vertex at the target snapshot time.

[0151] Specifically, the current edge state in the primary adjacency structure, the historical edge versions in the candidate cumulative version block, and the committed historical edge versions in the temporary version block when the target snapshot time involves an update batch that has not yet been released constitute the candidate edge versions for snapshot reading. Only one visible edge version is determined for the same logical edge at a target snapshot time.

[0152] In an optional embodiment of the present invention, step S5 may include: Step S51: Determine the visible current edge state from the main adjacency structure based on the target snapshot time.

[0153] Specifically, if the effective time range of the current edge state covers the target snapshot time, the current edge state is determined to be a visible current edge state; if the current edge state is created after the target snapshot time or does not meet the visibility conditions corresponding to the target snapshot time, the historical edge version continues to be accessed.

[0154] Step S52: Scan the historical edge versions in the candidate cumulative version block according to the creation time, and determine the visible historical edge versions based on the creation time and expiration time.

[0155] In an optional embodiment of the present invention, step S52 may include: Step S521: Compare the creation time and expiration time of the historical edge versions in the candidate cumulative version block with the target snapshot time in the order of creation time.

[0156] Step S522: When a historical edge version whose creation time is not earlier than the target snapshot time is detected, stop scanning the current candidate cumulative version block.

[0157] Specifically, when historical edge versions in the same candidate cumulative version block are arranged according to their creation time, historical edge versions whose creation time is no earlier than the target snapshot time and their subsequent historical edge versions do not meet the visibility conditions corresponding to the target snapshot time.

[0158] Step S523: The historical edge versions that meet the conditions of creation time earlier than the target snapshot time and expiration time not earlier than the target snapshot time before the scanning is stopped are identified as visible historical edge versions.

[0159] In an optional embodiment of the present invention, when the historical side versions in the temporary version block are appended in the order of writing and have not yet been sorted by creation time, the creation time, expiration time and target snapshot time of each historical side version already committed in the temporary version block are compared one by one, and the scanning is not stopped prematurely based on the creation time.

[0160] Step S53: Merge the visible current edge state and the visible historical edge version according to the logical edge to obtain the outgoing edge set of the source vertex at the target snapshot time.

[0161] Specifically, candidate edge versions can be merged based on the target vertex identifier or the logical identifier of the edge. For breadth-first search, PageRank, and connected component calculation tasks that do not require neighbor order, the main adjacency structure can be scanned first, followed by the candidate cumulative version block, and the resulting candidate edge versions can be merged.

[0162] In another optional embodiment of the present invention, step S5 may include: Step S51: Scan the current edge state in the main adjacency structure according to the order of the target vertex identifiers.

[0163] Specifically, when the main adjacency structure uses an ordered edge array, the order in which the current edge states are arranged in the ordered edge array is used as the reading order of the outgoing edge set.

[0164] Step S52: When the current edge state does not meet the target snapshot time, locate the historical edge version of the same logical edge from the candidate cumulative version block based on the predecessor version reference of the current edge state.

[0165] Specifically, based on the predecessor version reference, the previous historical edge version of the same logical edge is located sequentially until a historical edge version that meets the visibility condition corresponding to the target snapshot time is located, or it is determined that there is no historical edge version that meets the visibility condition.

[0166] Step S53: Determine the visible edge version from the historical edge version of the location based on the target snapshot time, and generate the outgoing edge set of the source vertex at the target snapshot time according to the order of the target vertex identifier.

[0167] Specifically, for a read task that requires returning neighbors in the order of the target vertex identifier, the current edge state in the main adjacency structure is used as the basis for the read order, and the current edge state that does not meet the target snapshot time is replaced with the version of the visible historical edge that has been located.

[0168] This invention also provides a dynamic graph storage and snapshot access system based on cumulative version blocks, used to execute the above method, including: The update transaction processing module is used to allocate the received graph update transactions to update batches, update the main adjacency structure according to the graph update transactions, and write the generated historical edge versions into a temporary version block. The version block construction module is used to organize the historical edge versions in the temporary version block into a cumulative version block according to the source vertex and version time when the update batch meets the release conditions; The background publishing module is used to set the cumulative version block to an immutable state, connect the cumulative version block to the cumulative version block chain of the corresponding source vertex according to the version time identifier, and update the published visible boundary of the corresponding update batch. The snapshot reading module is used to access the main adjacency structure of the corresponding source vertex according to the snapshot reading request including the source vertex identifier and the target snapshot time, and determine the candidate cumulative version block from the cumulative version block chain of the corresponding source vertex according to the target snapshot time. The outgoing edge set generation module is used to determine the edge versions visible at the target snapshot time from the main adjacency structure and the candidate cumulative version block, and obtain the outgoing edge set of the source vertex at the target snapshot time.

[0169] Although the present invention has been disclosed above with reference to embodiments, it is not intended to limit the present invention. Appropriate modifications or equivalent substitutions made by those skilled in the art to the technical solutions of the present invention should be covered within the protection scope of the present invention, which is defined by the claims.

Claims

1. A method for dynamic graph storage and snapshot access based on cumulative version blocks, characterized in that, Includes the following steps: The received graph update transactions are allocated to update batches, the primary adjacency structure is updated according to the graph update transactions, and the resulting historical edge versions are written into temporary version blocks. When the update batch meets the release conditions, the historical edge versions in the temporary version block are organized into a cumulative version block according to the source vertex and version time; Set the cumulative version block to an immutable state, connect the cumulative version block to the cumulative version block chain of the corresponding source vertex according to the version time identifier, and update the published visible boundary of the corresponding update batch; Based on the snapshot read request including the source vertex identifier and the target snapshot time, access the main adjacency structure of the corresponding source vertex, and determine the candidate cumulative version block from the cumulative version block chain of the corresponding source vertex according to the target snapshot time; The edge versions visible at the target snapshot time are determined from the main adjacency structure and the candidate cumulative version block, and the outgoing edge set of the source vertex at the target snapshot time is obtained.

2. The method as described in claim 1, characterized in that, The graph update transaction updates the primary adjacency structure and writes the resulting historical edge versions into a temporary version block, including: The edge update record generated by the graph update transaction is appended to the write buffer of the main adjacency structure; When the write buffer meets the merging condition, the edge update record in the write buffer is merged with the ordered edge array of the main adjacency structure according to the target vertex identifier, and a historical edge version is generated according to the state of the replaced or deleted edge. Update the ordered edge array based on the merge result, and write the historical edge version into the temporary version block.

3. The method as described in claim 1, characterized in that, Determining that the update batch meets the release conditions includes: After the update batch is closed, stop allocating new graph update transactions to the update batch; Check whether all graph update transactions assigned to the update batch have been committed or terminated; The update batch is determined to meet the release conditions when all graph update transactions assigned to the update batch have been committed or terminated.

4. The method as described in claim 3, characterized in that, Checking whether all graph update transactions assigned to the update batch have been committed or terminated includes: Retrieve the update batch identifier, access mode, and activity status recorded in the activity slots of each worker thread; Based on the update batch identifier, the access mode, and the activity status, determine whether there are any graph update transactions that are still accessing the update batch; If there are no graph update transactions still accessing the update batch, it is determined that all graph update transactions assigned to the update batch have been committed or terminated.

5. The method as described in claim 1, characterized in that, The historical edge versions in the temporary version block are organized into cumulative version blocks according to the source vertex and version time, including: Obtain the valid historical edge versions belonging to the update batch from the temporary version block, and group the valid historical edge versions according to the source vertex and version time; Sort the valid historical edge versions of each group according to their creation time; The sorted groups of valid historical edge versions are stored consecutively to obtain the corresponding cumulative version blocks.

6. The method as described in claim 1, characterized in that, Update the published visibility boundaries for the corresponding update batch, including: When a graph update transaction is committed, a commit sequence number within the batch is assigned to the graph update transaction, and a version time identifier is determined based on the update batch identifier and the commit sequence number within the batch. The creation time of the updated edge state and the expiration time of the replaced or deleted edge state are determined according to the version time identifier, and the updated edge state is written into the main adjacency structure. When the update batch is released, the corresponding cumulative version block is connected to the cumulative version block chain, and the released visible boundary is updated according to the version time identifier.

7. The method as described in claim 1, characterized in that, Based on the target snapshot time, candidate cumulative version blocks are determined from the cumulative version block chain of the corresponding source vertex, including: Obtain the version time identifier of each cumulative version block in the cumulative version block chain; Compare the version time identifier of each cumulative version block with the target snapshot time, and exclude cumulative version blocks that have expired before the target snapshot time; The accumulator blocks that were not excluded are identified as candidate accumulator blocks.

8. The method as described in claim 1, characterized in that, The edge versions visible at the target snapshot time are determined from the main adjacency structure and the candidate cumulative version block, resulting in the set of outgoing edges from the source vertex at the target snapshot time, including: The current visible edge state is determined from the main adjacency structure based on the target snapshot time; Scan the historical edge versions in the candidate cumulative version block according to the creation time, and determine the visible historical edge versions based on the creation time and expiration time; By merging the visible current edge state and the visible historical edge version according to the logical edge, the set of outgoing edges of the source vertex at the target snapshot time is obtained.

9. The method as described in claim 8, characterized in that, Scan the historical edge versions in the candidate cumulative version block according to their creation time, and determine the visible historical edge versions based on their creation time and expiration time, including: The creation and expiration times of historical side versions in the candidate cumulative version block are compared with the target snapshot time in chronological order of creation time. When a historical edge version whose creation time is no earlier than the target snapshot time is detected, the scanning of the current candidate cumulative version block is stopped; The historical edge versions that meet the conditions of having a creation time earlier than the target snapshot time and an expiration time no earlier than the target snapshot time before the scanning stops are determined as the visible historical edge versions.

10. A dynamic graph storage and snapshot access system based on cumulative version blocks, characterized in that, include: The update transaction processing module is used to allocate the received graph update transactions to update batches, update the main adjacency structure according to the graph update transactions, and write the generated historical edge versions into a temporary version block. The version block construction module is used to organize the historical edge versions in the temporary version block into a cumulative version block according to the source vertex and version time when the update batch meets the release conditions; The background publishing module is used to set the cumulative version block to an immutable state, connect the cumulative version block to the cumulative version block chain of the corresponding source vertex according to the version time identifier, and update the published visible boundary of the corresponding update batch. The snapshot reading module is used to access the main adjacency structure of the corresponding source vertex according to the snapshot reading request including the source vertex identifier and the target snapshot time, and determine the candidate cumulative version block from the cumulative version block chain of the corresponding source vertex according to the target snapshot time. The outgoing edge set generation module is used to determine the edge versions visible at the target snapshot time from the main adjacency structure and the candidate cumulative version block, and obtain the outgoing edge set of the source vertex at the target snapshot time.

Images