cdegroc
cdegroc
Explore posts from servers
JJanusGraph
Created by cdegroc on 6/11/2024 in #questions
Potentially useless allocations when checking a field cardinality
No description
2 replies
JJanusGraph
Created by cdegroc on 2/20/2024 in #questions
Concurrent updates during a REINDEX
👋🏻 Hello. I was reading JanusGraph documentation on reindexing (https://docs.janusgraph.org/schema/index-management/index-reindexing/) which says
JanusGraph can begin writing incremental index updates right after an index is defined. However, before the index is complete and usable, JanusGraph must also take a one-time read pass over all existing graph elements associated with the newly indexed schema type(s). Once this reindexing job has completed, the index is fully populated and ready to be used. The index must then be enabled to be used during query processing.
which made me wonder how JanusGraph handles incremental updates happening concurrently to a REINDEX. For instance, if we consider a slow reindexing process (e.g. done through the ManagementSystem interface) that can take several hours, how are concurrent additions/updates/deletions of vertices/edges/properties handled? Won't they just be overwritten by the reindexing process that could be based on old data? Any thought / pointer to code would be greatly appreciated. Thanks!
16 replies
JJanusGraph
Created by cdegroc on 1/12/2024 in #questions
TreeStep and MultiQuery support
On JanusGraph 1.0, a traversal like g.V().has(...).out(...).has(...).out(...).has(...) nicely leverages the MultiQuery optimisation and returns results in acceptable time. However, as soon as we add a tree() step, as in g.V().has(...).out(...).has(...).out(...).has(...).tree(), all MultiQuery optimisations are disabled and the traversal time increases drastically. Based on the following code, I think this applies to all Steps with PATH requirement (e.g. PathStep, TreeStep): https://github.com/JanusGraph/janusgraph/blob/v1.0/janusgraph-core/src/main/java/org/janusgraph/graphdb/tinkerpop/optimize/JanusGraphTraversalUtil.java#L393 Could a knowledgeable person chime in and explain if disabling MultiQuery is a hard requirement by design (e.g. the traverser's history needs to be kept and MultiQuery does not allow that), if it's just that the optimisation was not implemented for this step or if this can be changed easily (as in just removing that condition), or if there could be other approaches to get a subgraph/tree that wouldn't have such limitation? Thanks!
10 replies