Database Reference
In-Depth Information
Graph databases
Last but not least, and of course the subject of most of this topic, are the graph-oriented
databases. They are often also categorized in the NOSQL category, but as you will
see later, are inherently very different. This is not in the least the case because the
task-orientation that graph databases are aiming to resolve has everything to do with
graphs and graph theory that we discussed in
Chapter 1
,
Graphs and Graph Theory - an
Introduction
. Graph databases such as Neo4j aim to provide its users with a better
way to manage the complexity of the dense network of the data structure at hand.
Implementations of this model are not limited to Neo4j, of course. Other closed and
opensourcesolutionssuchasAllegrograph,Dex,FlockDB,IniniteGraph,OrientDB,
and Sones are examples of implementations at various maturity levels.
So, now that we understand the different types of NOSQL databases, it would
probablybeusefultoprovidesomegeneralclassiicationofthisbroadcategory
of database management systems, in terms of their key characteristics. In order to
do that, I am going to use a mental framework that I owe to Martin Fowler (from
his topic
NOSQL Distilled
) and Alistair Jones (in one of his many great talks on this
subject). The reason for doing so is that both of these gentlemen and me share the
viewpoint that NOSQL essentially falls into two categories, on two sides of the
relational crossroads:
• On one side of the crossroads are the aggregate stores. These are the
Key-Value-, Column-Family-, and Document-oriented databases, as
they all share a number of characteristics:
° They all have a fundamental data model that is based around
a single, rich structure of closely-related data. In the field of
software engineering called domain driven design, professionals
often refer to this as an "aggregate", hence the reference to the fact
that these NOSQL databases are all aggregate-oriented database
management systems.
° They are clearly optimized for use cases in which the read patterns
align closely with the write patterns. What you read is what you
have written. Any other use case, where you would potentially like
to combine different types of data that you had previously written
inseparatekey-valuepairs/documents/rows,wouldrequire
some kind of application-level processing, possibly in batch if at
some serious scale.
