Cypher, Gremlin: Graph Query Language Paradigms

Graph Query Languages: Necessity and Evolution

Querying data where relationships are as significant as the entities themselves presents challenges for traditional database models. Relational databases excel at structured tables and predefined joins. However, retrieving data based on arbitrary-depth relationships, such as finding “friends of friends of friends”, requires multiple, self-joining SQL statements. These queries quickly become complex and inefficient as the path length increases.

Consider a simple social network. Finding all users within three steps of a given user in a relational model involves three self-joins on a friendship table. This approach scales poorly in terms of query readability and execution performance. Graph databases, in contrast, store relationships as first-class citizens. Each connection is an explicit edge, allowing direct traversal. This fundamental difference necessitates specialized query languages designed to navigate these connections efficiently and expressively.

Early graph database interactions often relied on imperative programming APIs. Developers would write code to explicitly traverse the graph step-by-step, fetching nodes and edges, then processing them in application logic. While flexible, this approach lacked declarative power and made complex graph patterns difficult to express concisely.

The need for a declarative query paradigm, akin to SQL for relational data, became clear. Users required languages that described what data to retrieve, not how to retrieve it. This shift led to the development of purpose-built graph query languages.

Cypher, originating with Neo4j, introduced a pattern-matching syntax designed for human readability, often resembling ASCII art representations of graphs. It focuses on describing graph patterns to find. Apache TinkerPop’s Gremlin evolved as a graph traversal language. It offers a functional, step-by-step approach where traversals are composed of chained operations. Gremlin is not tied to a single database and can be embedded in multiple host languages like Java, Python, and JavaScript.

These languages addressed the limitations of general-purpose query methods, providing native constructs for pathfinding, pattern matching, and neighborhood exploration within graph structures. Their development was crucial for making graph databases accessible and performant for complex interconnected data.

Cypher: Declarative Pattern Matching

Cypher is a declarative graph query language, focusing on describing the patterns of data to find or create, rather than specifying how to traverse the graph. Its syntax uses ASCII-art representations to visually map graph structures, making queries readable and intuitive. This approach allows the query optimizer to determine the most efficient execution plan.

To retrieve data, Cypher uses the MATCH clause to define the graph pattern. Nodes are represented by parentheses () and relationships by hyphens and arrows -[]->. For example, a node labeled Person is (p:Person), where p is an alias for the node.

MATCH (p:Person)
RETURN p.name, p.age
LIMIT 5;

This query finds up to five nodes with the Person label and returns their name and age properties. Properties are accessed using dot notation, nodeAlias.propertyName.

Relationships connect nodes and are defined within square brackets []. These relationships can have types, such as :WORKS_AT, and direction. For example, a pattern describing a Person working at a Company looks like this:

MATCH (p:Person)-[:WORKS_AT]->(c:Company)
RETURN p.name AS Employee, c.name AS Company
LIMIT 5;

Here, p is a Person node, c is a Company node, and the WORKS_AT relationship points from the Person to the Company. The AS keyword renames returned fields.

Filtering results uses the WHERE clause, which applies conditions to nodes, relationships, or their properties. This restricts the matched patterns before returning data.

MATCH (p:Person)-[:WORKS_AT]->(c:Company)
WHERE p.age > 30 AND c.industry = 'Tech'
RETURN p.name, c.name, c.industry;

This query finds people over 30 working in tech companies.

Cypher uses CREATE and MERGE for basic graph manipulation. The CREATE clause adds new nodes and relationships to the graph, defining their labels and properties.

CREATE (p:Project {name: 'Mars Colony', status: 'planning'})
RETURN p;

MERGE ensures a pattern exists in the graph. If the pattern is not found, MERGE creates it. If it exists, MERGE matches it without creating duplicates. This is useful for idempotent operations.

MERGE (s:Station {name: 'ISS'})
ON CREATE SET s.launched = 1998
RETURN s;

This ensures an ISS station node exists. If created, its launched property is set to 1998.

Gremlin: Traversal Building Blocks

Gremlin is an imperative, domain-specific language for graph traversal. It constructs a traversal as a sequence of discrete steps, each operating on the elements emitted by the previous step. This sequential execution defines a path through the graph, transforming data at each stage.

All Gremlin traversals begin with a traversal source, typically g. This source provides initial steps like V() to select all vertices or E() for all edges. Subsequent steps filter, navigate, or transform the elements passed from the preceding step.

Consider a simple graph with person vertices, each having a name property, and KNOWS edges. To find the names of individuals Alice knows, the traversal starts by locating Alice’s vertex.

g.V().has('person', 'name', 'Alice')

This step filters the initial set of all vertices (g.V()) to find the specific person vertex named ‘Alice’. The output of this step is a single vertex.

To navigate from Alice to the people she knows, the out() step is appended. This step traverses outgoing edges of the specified label.

g.V().has('person', 'name', 'Alice').out('KNOWS')

The out('KNOWS') step emits all vertices connected to Alice via an outgoing KNOWS edge. If Alice knows Bob, this step emits Bob’s vertex.

Finally, to retrieve only the names of these connected individuals, the values() step projects specific property values. This traversal emits the name property for each vertex found. If Alice knows Bob, the output is Bob. Each step in the Gremlin query operates on the stream of elements produced by the previous step, building a precise path and transforming the data as needed.

g.V().has('person', 'name', 'Alice').out('KNOWS').values('name')

Bob

Cypher vs Gremlin: Real-world Scenarios

Choosing between Cypher and Gremlin for a graph querying task depends on the query’s complexity, the data model, and the desired interaction paradigm. Cypher excels in declarative pattern matching, while Gremlin offers imperative, programmatic traversal control.

Consider the task of finding friends of friends within a social network graph. In Cypher, this is expressed as a direct pattern:

MATCH (p1:Person)-[:FRIEND_OF]->(p2:Person)-[:FRIEND_OF]->(p3:Person)
WHERE p1.name = 'Alice' AND p1 <> p3
RETURN p3.name AS FriendOfFriend

This query describes the desired graph structure directly. The graph database engine interprets the pattern and finds all matching paths. This approach prioritizes readability for common graph patterns.

Gremlin approaches the same task as a series of steps, traversing the graph element by element from a starting point:

g.V().has('Person', 'name', 'Alice').out('FRIEND_OF').out('FRIEND_OF').dedup().values('name')

Gremlin’s imperative style provides precise control over each traversal step. This makes it suitable for highly dynamic queries or when integrating graph traversals directly into application logic using a host language like Java or Python.

For more intricate subgraph pattern matching, such as identifying a specific chain of events or relationships, Cypher’s MATCH clause remains highly expressive. For instance, finding people who rated a movie that a friend also rated:

MATCH (p1:Person)-[:FRIEND_OF]->(p2:Person),
      (p1)-[:RATED]->(m:Movie)<-[:RATED]-(p2)
WHERE p1.name = 'Bob'
RETURN p1.name, m.title, p2.name

This query clearly outlines the two distinct paths and their shared movie node. Cypher’s strength lies in its ability to visually represent these complex relationships within the query itself.

Gremlin handles similar complex patterns by chaining multiple traversal steps and filters. While it can achieve the same result, the query often becomes longer and requires a deeper understanding of the traversal state at each step.

Cypher is often preferred for ad-hoc data exploration and when the query patterns are well-defined and known beforehand. Its declarative nature simplifies expressing common graph patterns. Gremlin, conversely, is powerful when queries need to be constructed programmatically, or when the traversal logic is highly conditional and depends on runtime data. Its step-by-step execution offers finer control, which is beneficial for complex algorithms or when integrating with existing codebases. The tradeoff is that Cypher’s declarative simplicity for patterns loses the fine-grained control over traversal execution that Gremlin offers.

Graph Query Optimization: Common Pitfalls

Inefficient graph queries can quickly exhaust system resources, leading to slow response times. Performance bottlenecks often stem from predictable patterns that expand the search space unnecessarily or process too much data. Understanding these patterns is key to designing efficient queries.

Deep graph traversals are computationally expensive. Each additional hop in a path query can multiply the number of nodes and relationships considered, especially in dense graphs. Queries that seek paths of indefinite length, such as MATCH p = (a)-[*]->(b), can cause the query planner to explore vast portions of the graph. Specifying a maximum path length, for example MATCH p = (a)-[*1..5]->(b), limits the search scope and improves performance.

Filtering nodes or relationships based on unindexed properties forces the database to scan all relevant elements. For instance, a query like MATCH (n:User) WHERE n.email = 'user@example.com' will scan every User node if no index exists on the email property. This becomes a full table scan in relational terms. Define property indexes on fields used in WHERE clauses or as starting points for traversals.

CREATE INDEX FOR (u:User) ON (u.email);

Applying filters late in a query’s execution also degrades performance. For example, matching all posts by all users, then filtering those users or posts, processes a larger intermediate result set. Instead, apply filters as early as possible within the graph pattern. MATCH (u:User {status: 'active'})-[:POSTED]->(p:Post) WHERE p.views > 1000 is more efficient than MATCH (u:User)-[:POSTED]->(p:Post) WHERE u.status = 'active' AND p.views > 1000 because the u.status filter is applied directly to the User node during pattern matching, reducing the number of paths considered from the start.

Over-fetching data is another common issue. Returning entire node or relationship objects when only specific properties are needed transfers unnecessary data over the network and consumes more memory. Instead of RETURN n, project only the required fields: RETURN n.id, n.username. This reduces serialization overhead.

To diagnose query performance, use the database’s execution plan tools. Cypher databases provide EXPLAIN and PROFILE to visualize the query plan and identify expensive operations. Gremlin users can use explain() or profile() on their traversals to understand step costs. These tools pinpoint exactly where a query spends its time.

Query Language Practice: Hands-on Challenges

Applying graph query languages requires practical construction of query patterns. These challenges use a small movie graph to demonstrate common query tasks in both Cypher and Gremlin. The graph contains Person and Movie nodes. Person nodes have a name property. Movie nodes have title and releaseYear properties. Relationships include ACTED_IN (from Person to Movie, with role property) and REVIEWED (from Person to Movie, with rating property).

Challenge 1: Find all movies a specific person acted in.

Given a person’s name, retrieve the titles of all movies they have an ACTED_IN relationship with.

Cypher Solution:

MATCH (p:Person {name: 'Tom Hanks'})-[:ACTED_IN]->(m:Movie)
RETURN m.title

Output:

m.title
"Forrest Gump"
"Cast Away"

Gremlin Solution:

g.V().has('Person', 'name', 'Tom Hanks').out('ACTED_IN').values('title')

Output:

==>Forrest Gump
==>Cast Away

Cypher uses pattern matching to locate the Person node by name, then traverses the ACTED_IN relationship to Movie nodes. Gremlin starts by finding the Person vertex, then uses the out() step to traverse outgoing ACTED_IN edges, and values() to extract the movie titles. Both queries filter by a specific person’s name property to begin their traversal or pattern match.

Challenge 2: Identify people who acted in a movie and also reviewed that same movie.

Locate individuals who both acted in a particular movie and provided a review for it. Return the person’s name and the movie title.

Cypher Solution:

MATCH (p:Person)-[:ACTED_IN]->(m:Movie)<-[:REVIEWED]-(p)
RETURN p.name, m.title

Output:

p.name      m.title
"Jerry"     "The Matrix"

Gremlin Solution:

g.V().hasLabel('Person').as('p').out('ACTED_IN').as('m').in('REVIEWED').where(eq('p')).select('p', 'm').by('name').by('title')

Output:

==>[p:Jerry,m:The Matrix]

The Cypher query forms a triangular pattern where a Person node connects to a Movie node via ACTED_IN and the same Person node connects to the same Movie node via REVIEWED. Gremlin’s approach involves marking the Person vertex (as('p')) and Movie vertex (as('m')) during traversal. The where(eq('p')) step ensures the vertex reached by in('REVIEWED') is the same Person vertex marked earlier, establishing the common actor-reviewer.