Databases Reference
In-Depth Information
The Traversal Framework is both more loosely coupled than the Core API (because it
allows the developer to declare informational goals), and less verbose, and as a result a
query written using the Traversal Framework typically requires less developer effort
than the equivalent written using the Core API. Because it is a general-purpose frame‐
work, however, the Traversal Framework tends to perform marginally less well than a
well-written Core API query.
If we find ourselves in the unusual situation of coding with the Core API or Traversal
Framework (and thus eschewing Cypher and its affordances), it's because we are work‐
ing on an edge case where we need to finely craft an algorithm that cannot be expressed
effectively using Cypher's pattern matching. Choosing between the Core API and the
Traversal Framework is a matter of deciding whether the higher abstraction/lower cou‐
pling of the Traversal Framework is sufficient, or whether the close-to-the-metal/higher
coupling of the Core API is in fact necessary for implementing an algorithm correctly
and in accordance with our performance requirements.
This concludes our brief survey of graph programming APIs, using the native Neo4j
APIs as an example. We've seen how these APIs reflect the structures used in the lower
levels of the Neo4j stack, and how this alignment permits for idiomatic and rapid graph
traversals.
It's not enough for a database to be fast, however; it must also be dependable. This brings
us to a discussion of the nonfunctional characteristics of graph databases.
Nonfunctional Characteristics
At this point we've understood what it means to construct a native graph database, and
have seen how some of these graph-native capabilities are implemented, using Neo4j as
our example. But to be considered
dependable
, any data storage technology must pro‐
vide some level of guarantee as to the durability and accessibility of the stored data.
2
One common measure by which relational databases are traditionally evaluated is the
number of transactions per second they can process. In the relational world, it is as‐
sumed that these transactions uphold the ACID properties (even in the presence of
failures) such that data is consistent and recoverable. For nonstop processing and man‐
aging of large volumes, a relational database is expected to scale so that many instances
are available to process queries and updates, with the loss of an individual instance not
unduly affecting the running of the cluster as a whole.
At a high level at least, much the same applies to graph databases: they need to guarantee
consistency, recover gracefully from crashes, and prevent data corruption; further, they
2. The formal definition of dependability is the “trustworthiness of a computing system, which allows reliance
