There are a large number of Neo4j core optimizations planned.
After six milestones, Neo4j 1.4 is now GA, with a list of new features, including a new query language, an auto-indexing framework, and a paging mechanism for traversers. We speak to the co-founder of Neo4j, Peter Neubauer, on some of the new features in this latest release.
JAXenter: Neo4j 1.4 is now generally available with support for the Cypher language. What does Cypher add, for Neo4j users?
Peter Neubauer: It allows for expressive and efficient querying of the graph store without having to write Java Neo4j traversers in code.
Cypher is designed to be a humane query language, suitable for both developers and – importantly, we think – operations professionals who want to make ad-hoc queries on the database. Its constructs are based on English prose and neat iconography, which helps to make it – somewhat – self-explanatory.
Cypher is inspired by a number of different approaches and builds upon established practices for expressive querying. Most of the keywords like WHERE and ORDER BY are inspired by SQL. Pattern matching borrows expression approaches from SPARQL. Regular expression matching is implemented using the Scala programming language.
Cypher is a declarative language. It focuses on the clarity of expressing what to retrieve from a graph, not how to do it, in contrast to imperative languages like Java and Scala, and scripting languages like Groovy (Gremlin) or Ruby (JRuby Neo4j bindings). This makes the concern of how to optimize queries in implementation detail not exposed to the user.
JAXenter: What does the new auto-indexing framework add, on top of the existing index framework?
Peter: With auto-indexing, indexes can be configured once, and then listen to transactions and changes in the database. This saves the overhead of including index updates explicitly into mutating transactions, and the overhead to remove and update indexes as part of your domain code.
Auto-indexing is not replacing manual control, so that for non-trivial scenarios like conditional and complex rules for indexing, or complex indexing values you still can use the full atomic index API.
JAXenter: How has the REST API developed, in this release?
Peter: Mostly, the concept of paging has been added to the traversal methods, and a batch-mode for REST operations has been introduced, where all listed REST operations are executed in the same transaction. This mitigates two of the major shortcomings of REST as a concept – statefulness and transaction support.
Also, new plugins for Gremlin and Cypher are now part of the standard Neo4j Server distribution, largely eliminating the need to write Java Plugins to achieve custom functionality and good performance. They let you execute scripting code on the server, and return collections of the normal REST collections of Nodes, Relationships and Paths, or primitives like Strings.
JAXenter: What are the next steps, for the Neo4j project?
Peter: For the next versions, we are working on
developing Cypher into a full Graph Query Language. Also, there are
a large number of Neo4j core optimizations planned to improve
caching, high-load performance and resilience to the JVM Garbage
Collector in high load scenarios as Neo4j is increasingly being
used in large, mission critical projects. Also, we want to add
better remoting than REST via binary protocols. We are looking to
database store optimizations regarding storage
volume, compression and encryption. Also, the enterprise features like replication, failover and distribution are seeing big improvements based on the feedback from users. But in the end, our roadmap is a balance of features from our great community, and of the requirements of our customers. We are working in a time-boxed manner, so it is very hard to exactly say what features will make it for 1.5.
Further out, we are really looking forward to get started with graph distribution and integration with other NoSQL and relational for Neo4j 2.0.