Options for Storing Connected Data - Graph Databases - page 21

the entire network is our friend: because of this, for many real-world use cases, we'd
likely trim the results, and the timings.
Both aggregate stores and relational databases perform poorly when we
move away from modestly sized set operations—operations that they
should both be good at. Things slow down when we try to mine path
information from the graph, as with the friends-of-friends example. We
don't mean to unduly beat up on either aggregate stores or relational
databases; they have a fine technology pedigree for the things they're
good at, but they fall short when managing connected data. Anything
more than a shallow traversal of immediate friends, or possibly friends-
of-friends, will be slow because of the number of index lookups in‐
volved. Graphs, on the other hand, use index-free adjacency to ensure
that traversing connected data is extremely rapid.
The social network example helps illustrate how different technologies deal with con‐
nected data, but is it a valid use case? Do we really need to find such remote “friends”?
Perhaps not. But substitute social networks for any other domain, and you'll see we
experience similar performance, modeling, and maintenance benefits. Whether music
or data center management, bio-informatics or football statistics, network sensors or
time-series of trades, graphs provide powerful insight into our data. Let's look, then, at
another contemporary application of graphs: recommending products based on a user's
purchase history and the histories of his friends, neighbors, and other people like him.
With this example, we'll bring together several independent facets of a user's lifestyle to
make accurate and profitable recommendations.
We'll start by modeling the purchase history of a user as connected data. In a graph, this
is as simple as linking the user to her orders, and linking orders together to provide a
purchase history, as shown in Figure 2-6 .
The graph shown in Figure 2-6 provides a great deal of insight into customer behavior.
We can see all the orders a user has PLACED , and we can easily reason about what each
order CONTAINS . So far so good. But on top of that, we've enriched the graph to support
well-known access patterns. For example, users often want to see their order history, so
we've added a linked list structure to the graph that allows us to find a user's most recent
order by following an outgoing MOST_RECENT relationship. We can then iterate through
the list, going further back in time, by following each PREVIOUS relationship. If we want
to move forward in time, we can follow each PREVIOUS relationship in the opposite
direction, or add a reciprocal NEXT relationship.