Databases Reference
In-Depth Information
so should create sensible sentences. For our data center example, we can read off sen‐
tences like “Load balancer 1 fronts the App, which consists of App Instance 1, 2, and 3,
and the Database, which resides on Database Machine 1 and Database Machine 2,” and
“Blade 3 runs VM 3, which hosts App Instance 3.” If reading the graph in this way makes
sense, we can be reasonably confident it is faithful to the domain.
To further increase our confidence, we also need to consider the queries we'll run on
the graph. Here we adopt a
design for queryability
mindset. To validate that the graph
supports the kinds of queries we expect to run on it, we must describe those queries.
This requires us to understand our end users' goals; that is, the use cases to which the
graph is to be applied. In our data center scenario, for example, one of our use cases
involves end users reporting that an application or service is unresponsive. To help these
users, we must identify the cause of the unresponsiveness and then resolve it. To de‐
termine what might have gone wrong we need to identify what's on the path between
the user and the application, and also what the application depends on to deliver func‐
tionality to the user. Given a particular graph representation of the data center domain,
if we can craft a Cypher query that addresses this use case, we can be even more certain
that the graph meets the needs of our domain.
Continuing with our example use case, let's assume that we can update the graph from
our regular network monitoring tools, thereby providing us with a near real-time view
of the state of the network. With a large physical network, we might use
Complex Event
Processing (CEP)
to process streams of low-level network events, updating the graph
only when the CEP solution raises a significant domain event. When a user reports a
problem, we can limit the physical fault-finding to problematic network elements be‐
tween the user and the application and the application and its dependencies. In our
graph we can find the faulty equipment with the following query:
START
user=
node
:users(name =
'User 3'
)
MATCH
(user)-[*1..5]-(asset)
WHERE
asset.status! =
'down'
RETURN DISTINCT
asset
The
MATCH
clause here describes a
variable length path
between one and five relationships
long. The relationships are unnamed and undirected (there's no colon and label between
the square brackets, and no greater-than or less-than sign to indicate direction). This
allows us to match paths such as:
(user)-[:USER_OF]->(app)
(user)-[:USER_OF]->(app)-[:USES]->(database)
(user)-[:USER_OF]->(app)-[:USES]->(database)-[:SLAVE_OF]->(another-database)
(user)-[:USER_OF]->(app)-[:RUNS_ON]->(vm)
(user)-[:USER_OF]->(app)-[:RUNS_ON]->(vm)-[:HOSTED_BY]->(server)
(user)-[:USER_OF]->(app)-[:RUNS_ON]->(vm)-[:HOSTED_BY]->(server)-[:
IN
]->(rack)
(user)-[:USER_OF]->(app)-[:RUNS_ON]->(vm)-[:HOSTED_BY]->(server)-[:
IN
]->(rack)
<-[:
IN
]-(load-balancer)
