Databases Reference
In-Depth Information
London, which is in southeastern England, which, in turn, is in Great Britain. And
because UK postal codes are fine-grained, we can use that boundary to target people
with somewhat similar tastes.
Such pattern-matching queries are extremely difficult to write in SQL,
and laborious to write against aggregate stores, and in both cases they
tend to perform very poorly. Graph databases, on the other hand, are
optimized for precisely these types of traversals and pattern-matching
queries, providing in many cases millisecond responses. Moreover,
most graph databases provide a query language suited to expressing
graph constructs and graph queries. In the next chapter, we'll look at
Cypher, which is a pattern-matching language tuned to the way we tend
to describe graphs using diagrams.
We can use our example graph to make recommendations to the user, but we can also
use it to benefit the seller. For example, given certain buying patterns (products, cost of
typical order, and so on), we can establish whether a particular transaction is potentially
fraudulent. Patterns outside of the norm for a given user can easily be detected in a graph
and be flagged for further attention (using well-known similarity measures from the
graph data-mining literature), thus reducing the risk for the seller.
From the data practitioner's point of view, it's clear that the graph database is the best
technology for dealing with complex, semi-structured, densely connected data—that is,
with datasets so sophisticated they are unwieldy when treated in any form other than a
graph.
Summary
In this chapter we've seen how connectedness in relational databases and NOSQL data
stores requires developers to implement data processing in the application layer, and
contrasted that with graph databases, where connectedness is a first-class citizen. In the
next chapter we look in more detail at the topic of graph modeling.
