Database Reference
In-Depth Information
Another reason you might consider moving to a graph database is to avoid the half-measures and workarounds
you must use to make your model fit within a relational database. A join table is created in order to have metadata that
provides properties about relationships between two tables. When a similar relationship needs to be created among
other tables, yet another join table must be created. Even if it has the same properties as the first join table, it must be
created in order to ensure the integrity of the relationships. A certain type of relationship—such as “LIKES”—can exist
among more than just two types of nodes. In fact, the relationship type could be applied to all types of nodes.
Another reason to favor graph databases over relational database is to avoid what might be referred to as
“join hell.” The joins required to connect two tables are often trivial, but those types of joins provide the least
expressive data. When the application requires data that connects several tables, it is then that expense of joins begins
to manifest itself in both the complexity and as well as diminished performance. In addition, the nature and depth of
the query would need to be known ahead of time, or the query would need to be dynamically generated.
Despite the differences between graph and relational databases, there are a few similarities. A significant
similarity is that both can achieve what is known as
ACID compliance. ACID
—Atomicity, Consistency, Isolation and
Durability—is a set of principles guaranteeing that transactions completed by the database are processed reliably.
In Neo4j, the Enterprise edition is fully ACID in high-availability clustering, whereas the Community edition is
eventually consistent
.
NoSQL and Neo4j
Graph databases are not the only alternative or complementary solutions to the shortcomings of relational databases.
Although the first use of the term
NoSQL
dates from the late 1990s, it was only toward the end of the 2000s that NoSQL
options became more focused and could be set into one of four different sectors or families:
key-value
,
column-family
,
document,
and
graph
databases.
3
Another group is the multimodel category, which includes combinations of concepts
and features from at least two of the four main groups.
■
Contrary to the assumption in some quarters,
NoSQL
does not stand for “no to sQL.” the proper sense of the
acronym is “not only sQL”—referring to alternatives to the relational database.
Note
Key-value stores represent data by storing large sets of values, with each value based on a key. This simple data
structure allows related applications to store its data in a schema-less way. The column-family database, modeled
after Google's BigTable, can be described simply as rows of objects that contain columns of related data. As with
key-value stores, column-family databases also have key values pairs that represent a row. Document databases
represent a collection of "documents"; each one has its own collection of keys and values. In some ways, documents
contained within a document database are like rows in relational database. In addition, querying against a unique id
or key is a typical method used to retrieve a document.
The first big difference between graph databases and other NoSQL categories is the data model. Each type of
node can have any number of properties. In addition, those properties can be changed over time, which provides a
model that does not require a schema. This schema-less nature is certainly not unique in the NoSQL world, but when
you consider that nodes can have arbitrary relationships that do not need to be determined ahead of time or carefully
modeled in after an initial release, the difference between graphs and other NoSQL options begins to take shape.
When you couple that with the fact that arbitrary relationships can also have any number of their own configurable
properties, the difference is even clearer. Finally, because graphs can be quickly adapted to changes in business
needs, especially in making connections between data, organizations are enabled to ask the right questions from the
data as the needs arise, and those questions do not have to be precisely identified prior to data capture.
3
