Databases Reference
In-Depth Information
need to scale out to provide high availability, and scale up for performance. In the
following sections we'll explore what each of these requirements means for a graph
database architecture. Once again, we'll expand on certain points by delving into Neo4j's
architecture, as a means of providing concrete examples. It should be pointed out that
not all graph databases are fully ACID. It is important, therefore, to understand the
specifics of the transaction model of your chosen database. Neo4j's ACID transaction‐
ality shows the considerable levels of dependability that can be obtained from a graph
database—levels we are accustomed to obtaining from enterprise-class relational data‐
base management systems.
Transactions
Transactions have been a bedrock of dependable computing systems for decades. Al‐
though many NOSQL stores are not transactional, in part because there's an unvalidated
assumption that transactional systems scale less well, transactions remain a fundamental
abstraction for dependability in contemporary graph databases—including Neo4j.
(There is some truth to the claim that transactions limit scalability, insofar as distributed
two-phase commit can exhibit unavailability problems in pathological cases, but in
general the effect is much less marked than is often assumed.)
Transactions in Neo4j are semantically identical to traditional database transactions.
Writes occur within a transaction context, with write locks being taken for consistency
purposes on any nodes and relationships involved in the transaction. On successful
completion
of the transaction, changes are flushed to disk for durability, and the write
locks released. These actions maintain the atomicity guarantees of the transaction.
Should the transaction fail for some reason, the writes are discarded and the write locks
released, thereby maintaining the graph in its previous consistent state.
Should two or more transactions attempt to change the same graph elements concur‐
rently, Neo4j will detect a potential deadlock situation, and serialize the transactions.
Writes within a single transactional context will not be visible to other transactions,
thereby maintaining isolation.
How Transactions Are Implemented in Neo4j
The transaction implementation in Neo4j is conceptually straightforward. Each trans‐
action is represented as an in-memory object whose state represents writes to the da‐
tabase. This object is supported by a lock manager, which applies write locks to nodes
and relationships as they are created, updated, and deleted. On transaction rollback, the
transaction object is simply discarded and the write locks released, whereas on successful
completion the transaction is committed to disk.
Committing data to disk in Neo4j uses a
Write Ahead Log
, whereby changes are ap‐
pended as actionable entries in the active transaction log. On transaction
commit
