Databases Reference
In-Depth Information
The Holy Grail of Graph Scalability
The eventual aim of most graph databases is to be able to partition a graph across many
machines without application-level intervention so that access to the graph can be scaled
horizontally. In the general case this is known to be an NP Hard problem, and thus
impractical to solve. This manifests itself in graph databases as unpredictable query
times as a result of traversals unexpectedly jumping between machines over a relatively
slow network. However, there is innovation happening in this space, with triple stores
able to scale horizontally very well (at the expense of latency); some nonnative graph
stores piggy-backing onto other databases (like Twitter's FlockDB, which runs atop
MySQL); and Neo4j's own horizontally scalable solution. This is certainly an exciting
time to be in the data space.
Summary
In this chapter we've shown how property graphs are an excellent choice for pragmatic
data modeling. We've explored the architecture of a graph database, with particular
reference to the architecture of Neo4j, and discussed the nonfunctional characteristics
of graph database implementations and what it means for them to be dependable.
