Database Reference
In-Depth Information
appeal and ease of use and understanding (aimed at developers and operational staff alike)
has made it a very compelling part of Neo4j's product surface. At present, Cypher can't
match the performance of the core API in most cases. In Neo4j 1.x, Cypher binds to the
Core and Traversal APIs (so it can never do any better than those APIs), but in the future
(especially from Neo4j 2.0 onward) Cypher will bind lower in the stack to a sympathetic
API that will support query optimization and other runtime efficiencies. Although Cypher
can't match the Core API today for performance, there's no reason to think it won't be on
par, or even outperform the Core API in the future—time will tell.
11.2. Neo4j High Availability (HA)
The Enterprise edition of Neo4j comes with a Neo4j HA component that provides the abil-
ity for Neo4j to run in a clustered setup, allowing you to distribute your database across
multiplemachines.Neo4jmakesuseofamaster-slavereplicationarchitectureand,broadly
speaking, provides support for two key features: resilience and fault tolerance in the event
of hardware failure, and the ability to scale Neo4j for read-intensive scenarios.
HA versus clustering
You'll often hear the terms HA and cluster used interchangeably when referring to a mul-
timachine setup within Neo4j. In essence, these are referring to the same concepts but with
different names.
Resilience and fault tolerance refer to the ability of Neo4j to continue functioning and
serving clients even in the presence of network disruptions or hardware failures. If one of
themachines inyourcluster blowsup,oralinktoyournetworkdies,Neo4jshouldbeable
to continue without a total loss of service.
Besides being able to handle hardware failure scenarios reliably, the master-slave archi-
tecture has the added benefit of providing a way to scale Neo4j horizontally for read-
mostly scenarios. In this context, read-mostly scenarios can refer to applications with high
throughput requirements where there's a need, or desire, to scale reads horizontally across
multiple slave instances. It's additionally used to support caching sharding (discussed in
section 11.2.4
)
, which enables Neo4j to handle a larger read load than could otherwise be
handled by a single Neo4j instance.
