I have a question about the use of relationship indexes in Neo4j.
Are these indexes used when iterating over the relationships of a specific Node? Or are they only used when querying for a specific relationship type and property across the database?
For example, if I'm creating a movie database and I have genre supernodes, will I be able to find that genre node first, then leverage property indexes on the relationships connected to that genre node to avoid iterating across every relationship connected to that node?
Let's say I'm looking for movie's of the action genre that were released in the last month. I will have a RANGE property index of "date_released" on all of the relationships connecting movies to this node.
Or, if this is not possible, will the query planner automatically use the property index to find the specified relationship type first, then iterate across those relationships with the valid property and find the ones connected to the desired genre?
If my question needs clarification, please let me know!
For additional context, I'm trying to decide what database best suits the needs for the application I'm working on building. I like the interconnectedness of graphs over SQL or Document databases, but my main concern is the potential inevitability of supernodes in my application. I want to make sure I can still achieve the desired functionality in my application without being hampered by supernodes. Scalability is a central concern for me. So far the other databases I'm looking into are Mongo and CockroachDB.
Thanks for replying! That doesn't actually answer my question.
I understand that we can first find relationships using relationship imdexes, then find nodes.
What I'm curious about is whether or not we can use relationship indexes when we find a node first.
Let's say I find a genre node first, then want to query across its relationships that were created in the past week. Will I have to iterate across all its relqtionships? Or will neo4j use relationship indexes for this portion of the query as well?
My concern pertains to supernodes and traversal time complexity. If finding a node and then querying across it's relationships does not use indexes and is strictly O(n) - iterating across a linked list - that will affect my data model and query design.
Core Answer: Rel-indexes are not used when expanding relationships from a node.
if you have supernodes you might need to refactor your model, e.g. elevate-rel-properties to rel-type or introduce intermediate tree-structures.
Do you really have per-issues with supernodes? or is this just a concern?
Avoid traversing over supernodes rather check "against" them.
In principle you can store the start (or end-node id) on the relationship with it's properties like timestamp and index both in the rel-index and then use it to lookup globally, based on source id and and timestamp.
But that then a hack that defeats the graph purpose.