Practice graph query patterns vocabulary: traversal queries, subgraph matching, path expressions, I/O bound graph queries, and Cypher vs. Gremlin performance characteristics.
0 / 10 completed
1 / 10
What is a 'traversal query' in graph database terminology?
A traversal query navigates the graph by following edges from node to node. It is the fundamental graph operation — unlike SQL table scans, traversals follow relationship pointers, making them fast for connected data but sensitive to graph depth.
2 / 10
A query is described as 'I/O bound on the graph.' What does this mean?
An I/O-bound graph query spends most of its time reading data from storage rather than computing. Deep traversals or queries touching large disconnected subgraphs are prone to this — graph databases optimize for this by keeping frequently traversed nodes in memory.
3 / 10
What is 'subgraph matching' in a graph query context?
Subgraph matching (or graph pattern matching) finds all subgraphs within a larger graph that are isomorphic to a query pattern. It is computationally expensive (NP-complete in general) but central to applications like fraud detection and chemistry informatics.
4 / 10
In Cypher (Neo4j's query language), how is a path expression typically written?
Cypher uses ASCII-art path notation: (a)-[:KNOWS*1..3]->(b) means 'find nodes a and b connected by 1 to 3 directed KNOWS edges'. This declarative syntax makes Cypher readable and expressive for graph pattern matching.
5 / 10
What is a key practical difference between Cypher and Gremlin for graph queries?
Cypher (Neo4j) is declarative: you describe the graph pattern you want and the engine finds it. Gremlin (Apache TinkerPop) is imperative/functional: you chain traversal steps. Both are powerful but favor different styles — Cypher is often more readable, Gremlin is more portable.
6 / 10
Review Comment: 'This query is inefficient. It's performing a full graph scan instead of using an index to narrow down the results.' What does this comment most likely imply regarding the graph query's design?
This comment highlights a common performance issue in graph databases: full scans. Indexing allows the database to quickly locate relevant nodes without examining every single one. Misinterpreting this suggests the query isn't leveraging available indexing strategies, which is a key factor impacting query efficiency. The incorrect options propose changes that don't directly address the root cause of the inefficiency.
7 / 10
Slack Message: 'Just ran this Cypher query against our customer network and it's taking a *really* long time! I suspect we need to rethink the path expression.' Which aspect of the query is most likely causing the performance bottleneck?
Complex path expressions – especially those involving multiple hops and diverse relationship types – can significantly impact query performance. The database engine must evaluate numerous possible paths to satisfy the query's conditions. While CPU usage or concurrency *could* contribute, the core problem is frequently the complexity of the graph traversal itself. The MATCH clause keywords are less likely to be a primary bottleneck in this scenario.
8 / 10
PR Description: 'Implemented subgraph matching for the 'fraud detection' use case. The query now focuses solely on transactions involving high-value accounts and suspicious IP addresses, dramatically reducing scan times.' What is the primary benefit of using 'subgraph matching' in this context?
Subgraph matching drastically reduces query execution time by filtering the graph to only include nodes and relationships that are pertinent to the specific use case. This targeted approach avoids unnecessary traversal of the entire graph, which is crucial for performance-sensitive operations like fraud detection. The other options describe unrelated functionalities of graph databases.
9 / 10
Standup Update: 'I'm working on optimizing the query for identifying connected components in our social network. We're using a recursive Cypher pattern to traverse relationships.' What is the *most* likely reason for employing a recursive pattern here?
Recursive patterns in Cypher (and other graph languages) are essential when dealing with graphs where the depth or number of hops between nodes is unknown or variable. A fixed-depth path expression would quickly become inadequate as it struggles to represent arbitrarily complex connection structures. The options present alternatives that don't address this core challenge.
10 / 10
API Response (Graph Database): 'Query: MATCH (p:Person)-[:KNOWS]->(f:Film) WHERE p.age > 30 AND f.rating >= 7. Result Set Size: 12'. Considering this API response, what does the result set size *primarily* indicate about the query's outcome?
The result set size directly reflects the *number* of nodes that satisfy all conditions specified in the query's WHERE clause. In this case, it represents the count of individuals (p) who meet both criteria: they are over 30 and know a film with a rating of at least 7. Understanding this is critical for evaluating query performance and optimizing filtering logic.
What will I practise in "Graph Query Patterns Vocabulary Quiz"?
Practice graph query patterns vocabulary: traversal queries, subgraph matching, path expressions, I/O bound graph queries, and Cypher vs. Gremlin performance characteristics.
How many exercises are in this module?
This module has 10 multiple-choice exercises, each with instant feedback and a full explanation of the correct answer.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
Do I need to create an account to do these exercises?
No account is required. Just click an option to answer — your score for this session is tracked automatically in the progress bar above.
What happens if I choose the wrong answer?
You'll immediately see which answer was correct, plus a full explanation covering the vocabulary and reasoning behind it — mistakes are where most of the learning happens.
Can I retry the exercises if I want a higher score?
Yes — use the "Try again" button on the results screen to reset and go through all the questions again.
Is my progress saved if I close the page?
No. Progress is tracked only for your current visit; reloading or leaving the page resets the counter. This keeps the exercise simple and account-free.
Where can I find more Knowledge Graph Vocabulary exercises?
Browse the full Knowledge Graph Vocabulary hub for related drills, or check the "Next up" link below to continue with a connected topic.
How is this different from reading an article on the same topic?
Articles explain vocabulary and concepts in prose; this exercise tests and reinforces that vocabulary through active recall with immediate feedback — the two work best together.
Who writes these exercises?
Every exercise is written by the CoderSlingo team, drawing on real workplace English used in IT roles, then reviewed for accuracy and clarity.