I am busy with " Graph Data Modeling Fundamentals" and was wondering why use labels to shorten data being queried and not just match a "relationship" or in plain words: Why does a match have to go through nodes and can't go through "relationships" directly?
Can you show an example query or statement to clarify what you are looking at, and what you would like to do differently?
The more context the better.
Well, you can actually query for a relationship(s) by type or property
Match (n)-[r:HAS_EVENT{status:active}]-(m)
//do something or return stuff.
Creating an index on relationship type HAS_NEXT and property status will sped up the query.
Labels are used for classifying entities for searching and filtering during traversals or pattern matching. They have efficiency benefits over using properties based on how the data is organized in the database. Also, creating an index is done for a specific label and one or more properties.
Thanks for the responses @andrew_bowman and @glilienfield
As mentioned, I am working through the GraphAcademy training and as I am working through it, I have questions that come up, when I read statements like "Shouldn't have more than four labels" and "It is faster to MATCH if you use a label".
It then occured to me that if the noun is a Person, then the relationship e.g. "Directed" is actually the verb of the label (Director), which theoretically could mean that any relationship with a Person could be automatically seen as a label and it would be more efficient (I think) to search via "relationships", than adding labels every time.
Is my thinking wrong?
I could be wrong, or misunderstand your question, but you limit your query based on what you're trying to discover. I often want to find whatever edges connect to a given vertex label. If you know you only want to see a given edge label, then you can specify, of course.
If it makes sense to you to do a relationship type scan instead of starting with a label scan, you can certainly do that.
You would need to have a relationship type lookup index created first (there is only 0 or 1 of these, and if created it supports all relationship type scans):
After ensuring a relationship type lookup index is created, it is possible for the planner to plan a RelationshipTypeScan when solving a MATCH. But if you want to nudge the planner into using the scan when it otherwise isn't planning it (it may be favoring a different means of lookup), you can provide it a hint which may prompt it into using it:
And of course if you have a property you want to consider in addition to the type, then what you're really after is a relationship index lookup. After ensuring the supporting index is created, then you can hint for usage of that index, if the planner isn't using it already:
Thanks @andrew_bowman I believe you answered my question. I just wanted to know if you can search via relation. I am still learning the fundamentals and I am assuming that the training is either "outdated" or just "keeping it simple" and "matching by relation" is more of an "advanced topic".
It may help to understand more of what you are trying to do.
MATCH patterns with relationships (whether using the relationship type or not, and using a relationship's properties or not) is always possible. In most cases, you will have already matched to various nodes in the graph, and by expanding relationships the planner and executor continue to fulfill the patterns you've requested in your match.
When it comes down to matching to anchoring elements (the first elements you find in your graph), for finding relationships first, instead of finding nodes first and expanding to the connected relationships, that is what relationship type scans and relationship index lookups are for.
A relationship type index (whether through our native indexes or fulltext indexes) require the relationship type to be present, and for at least one relationship property to be present, and for an index to already be created on the relationship's type and the property you are trying to use for lookup. You can use an index hint to nudge the planner to plan it, providing all the elements just mentioned are present to allow the relationship index usage. You would see a relationship index seek in the EXPLAIN plan of the query.
If you don't have the conditions in place for a relationship index lookup, but you want to start with looking at all relationships of the given type, then that would use a relationship type scan (but only if a relationship lookup index is present, as it is that which allows relationship type scans in the first place). You would see a Relationship by type scan in the EXPLAIN plan for the query.
They may be a bit more advanced, given that for most use cases you are typically looking to start with a node in your pattern, instead of looking up (or scanning) relationships regardless of the nodes they connect to. Some use cases, however, can benefit from looking up the relationship first, when there is not enough information to use indexes or label scans to find a starting node in the pattern.
If there is still confusion, then we would want to understand more about what you mean by "searching via relationship" (with examples) and how that differs from the relationship type scan and relationship index lookups we've been discussing so far.
1 Like