Databases Reference
In-Depth Information
chosen; in this section, we'll describe some of the architectural choices, and the corre‐
sponding application architectures, available to us when using Neo4j.
Embedded Versus Server
Most databases today run as a server that is accessed through a client library. Neo4j is
somewhat unusual in that it can be run in embedded as well as server mode—in fact,
going back nearly ten years, its origins are as an embedded graph database.
An embedded database is not the same as an in-memory database. An
embedded instance of Neo4j still makes all data durable on disk. Later,
in
“Testing” on page 82
, we'll discuss
ImpermanentGraphDatabase
, which
is an in-memory version of Neo4j designed for testing purposes.
Embedded Neo4j
In embedded mode, Neo4j runs in the same process as our application. Embedded Neo4j
is ideal for hardware devices, desktop applications, and for incorporating in our own
application servers. Some of the advantages of embedded mode include:
Low latency
Because our application speaks directly to the database, there's no network
overhead.
Choice of APIs
We have access to the full range of APIs for creating and querying data: the Core
API, traversal framework, and the Cypher query language.
Explicit transactions
Using the Core API, we can control the transactional life cycle, executing an arbi‐
trarily complex sequence of commands against the database in the context of a
single transaction. The Java APIs also expose the transaction life cycle, enabling us
to plug in
custom transaction event handlers
that execute additional logic with each
transaction.
Named indexes
Embedded mode gives us full control over the creation and management of named
indexes. This functionality is also available through the web-based REST interface;
it is not, however, available in Cypher.
When running in embedded mode, however, we should bear in mind the following:
JVM only
Neo4j is a JVM-based database. Many of its APIs are, therefore, accessible only from
a JVM-based language.
