This site is not optimized for Internet Explorer 9 and lower. Please choose another browser or upgrade your existing browser in order get the best experience of this website.

Getting Ready for Neo4j 3.0

Neo4j 3.0 on GraphGridAs we’ve been deploying and testing the Neo4j 3.0 Milestone releases on GraphGrid we’ve been excited for some of the shiny new features and also taking note of the operational differences that we’ll need account for in preparation for supporting Neo4j 3.0.

Neo4j is the most popular option in today’s graph database space with its native graph reliability, performance and expressive querying language, Cypher, and Neo4j 3.0 takes strides in continuing the trend in being both enterprise ready and more developer friendly with your preferred language.

Neo4j 3.0 Feature Highlights

Some of the features in Neo4j 3.0 that we’re enjoying are the following in no particular order:

The upgrade to Lucene 5 comes with many performance improvements and other improvements made to the Lucene library since version 3 that was previously being used by Neo4j. Lucene is a high-performance, full-featured text search engine library written entirely in Java that Neo4j uses for some indexing operations so this brings some nice improvements to the indexing management and performance within Neo4j.
The introduction of a uniformed language driver, called Bolt, that greatly improves performance and capability of the language drivers that communicate with the Neo4j
graph database completely remotely.

Complex graph update operations using MERGE are probably our most used Cypher operations for loading data into Neo4j and keeping it updated constantly during various ETL processes when integrating Neo4j with existing data sources. This makes the Cypher improvements to the cost-based planner to supper update operations including MERGE very exciting.

Stored procedures are a great step in providing more flexibility to Cypher to call existing operations right on the database as an alternative to a completely separate REST endpoint exposed by an unmanaged extension. These are nice because they’ll support languages other than Java such as Javascript. There are also some useful built in procedures available by default:

  • sys.db.labels, returns all labels that are in use in the database
  • sys.db.relationshipTypes, returns all relationship types that are in use in the database
  • sys.db.propertyKeys, returns all property keys that in the database
  • sys.db.procedures, returns all procedures that are in the database

A new record format (Neo4j Enterprise only) with higher ID limits, which increases the logical limits well beyond any realistic concerns of maxing out the numbers of nodes and relationships stored.

Neo4j 3.0 Deployment Changes Thus Far

Most of the changes so far in the milestones haven’t been major on the deployment and operations side, but there are more coming. Some of the main ones we’ve seen so far are the following:

  • Jars are now lib instead of a split between lib and system/lib.
  • Location of database directories now changed to data/databases from data.
  • merged files.neo4j.properties configuration and neo4j-server properties into neo4j.conf
  • console.log is now called neo4j.log
  • messages.log is now called debug.log
  • queries.log is now called query.log

If you’d like to try out an upgrade of your graph in preparation for the 3.0 release let us know and we can get you up and running today to try out the migration.