Skip to content

Db v4 schema layer#2658

Open
arienandalibi wants to merge 37 commits into
db_v4from
db_v4_schema_layer
Open

Db v4 schema layer#2658
arienandalibi wants to merge 37 commits into
db_v4from
db_v4_schema_layer

Conversation

@arienandalibi

Copy link
Copy Markdown
Collaborator

What changes were proposed in this pull request?

Adding a bitset (Vec) to keep track of which properties exist in which layers. Use this to optimize iterators (especially relevant when using disk storage). Also optimized the generation of schemas (node schema, edge schema, ...) by iterating edges only once and implementing a cache for already generated schemas.

Why are the changes needed?

Optimizations can be made to improve UI experience and disk accesses.

Does this PR introduce any user-facing change? If yes is this documented?

It shouldn't

How was this patch tested?

Will need to be tested using the UI

Are there any further changes required?

There shouldn't be

…global property id i corresponding to the segment. Persisted to disk. In-memory part grows incrementally.
…ow) of properties present in each (segment, layer) to efficiently retrieve the lists of relevant properties. We union over all segments in the storage. We also filter out props/metadata that aren't present now instead of all globally registered properties.
… for properties and one for metadata in Meta. Wired it in so that layers where we know the property isn't present are skipped.
…und in this layer. Added these for the node storage and edge storage. Skip layers in tprop_iter_layers, which is used in time semantics.
…es. These were used to track property presence per-(segment, layer) on disk and in-memory. Now, we only keep track of property presence per layer. We skip layers where we know the property was added, but that's it.
… previous layer property schemas (property presence bitsets) to avoid work. All of it was redundant and didn't save anything. Removed functions that pass these `LayerPropSchema`s around.
…pe, dst_node_type). Introduce limits for max number of edges/values in properties and edges.
# Conflicts:
#	raphtory-storage/src/graph/nodes/node_storage_ops.rs
#	raphtory/src/db/graph/views/filter/model/degree_filter.rs
…g all properties. As soon as a property key has more than ENUM_BOUNDARY values, we skip property value collection.
…ies and metadata. This is held by GraphWithVectors(Inner). It gets passed to GqlGraph for base/unfiltered (e.g. materialized) graphs, which passes them to EdgeSchema by Arc.
…String, String) type alias. This allows us to pass references to the key easily. Faster on cache lookup
# Conflicts:
#	raphtory-storage/src/graph/nodes/node_storage_ops.rs
# Conflicts:
#	raphtory-graphql/src/data.rs
#	raphtory-graphql/src/graph.rs
#	raphtory-storage/src/graph/nodes/node_storage_ops.rs
…es and metadata per layer. We use the maintained property presence bitsets to do this
… rid of NodeSchemaKey. Wire the cache through in the schemas.

@github-actions github-actions Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Performance Alert ⚠️

Possible performance regression was detected for benchmark 'Rust Benchmark'.
Benchmark result of this commit is worse than the previous benchmark result exceeding threshold 2.

Benchmark suite Current: aee77a1 Previous: 9823ef7 Ratio
lotr_graph/num_edges 4 ns/iter (± 0) 0 ns/iter (± 0) +∞
lotr_graph/num_nodes 4 ns/iter (± 0) 1 ns/iter (± 0) 4
lotr_graph/graph_latest 3 ns/iter (± 0) 0 ns/iter (± 0) +∞
lotr_graph_materialise/materialize 7800402 ns/iter (± 38373) 1564816 ns/iter (± 35303) 4.98
lotr_graph_window_100/num_nodes 13 ns/iter (± 0) 5 ns/iter (± 0) 2.60
lotr_graph_window_100_materialise/materialize 7870030 ns/iter (± 41252) 1669150 ns/iter (± 10700) 4.71
lotr_graph_window_10/has_node_existing 141 ns/iter (± 9) 62 ns/iter (± 11) 2.27
lotr_graph_window_10_materialise/materialize 3289025 ns/iter (± 8541) 971980 ns/iter (± 4278) 3.38
lotr_graph_subgraph_10pc_materialise/materialize 2068910 ns/iter (± 15530) 334634 ns/iter (± 1287) 6.18
lotr_graph_subgraph_10pc_windowed/has_node_existing 145 ns/iter (± 13) 62 ns/iter (± 14) 2.34
lotr_graph_subgraph_10pc_windowed_materialise/materialize 1242704 ns/iter (± 13349) 230399 ns/iter (± 2617) 5.39
lotr_graph_window_50_layered/num_edges_temporal 145693 ns/iter (± 2293) 70121 ns/iter (± 7586) 2.08
lotr_graph_window_50_layered/has_node_existing 374 ns/iter (± 20) 129 ns/iter (± 12) 2.90
lotr_graph_window_50_layered/graph_latest 86635 ns/iter (± 1638) 36649 ns/iter (± 916) 2.36
lotr_graph_window_50_layered_materialise/materialize 28506457 ns/iter (± 75868) 3488825 ns/iter (± 24948) 8.17
lotr_graph_persistent_window_50_layered/num_edges_temporal 585645 ns/iter (± 28120) 192686 ns/iter (± 1569) 3.04
lotr_graph_persistent_window_50_layered/has_node_existing 417 ns/iter (± 363) 174 ns/iter (± 83) 2.40
lotr_graph_persistent_window_50_layered/graph_latest 121050 ns/iter (± 1109) 57549 ns/iter (± 4809) 2.10
lotr_graph_persistent_window_50_layered_materialise/materialize 48760506 ns/iter (± 83599) 5298035 ns/iter (± 147912) 9.20

This comment was automatically generated by workflow using github-action-benchmark.

@arienandalibi arienandalibi marked this pull request as ready for review July 8, 2026 08:15
@fabubaker fabubaker self-requested a review July 8, 2026 16:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant