ONgDB Feature Highlights

ONgDB Deployment Changes Thus Far

As we’ve been getting ready for ONgGDB by deploying and testing the ONgDB Milestone releases on GraphGrid Cloud 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 the latest ONgDB release.

Open Native Graph Database (ONgDB) is the most popular fully open source option in today’s graph database space with its native graph reliability, performance and expressive querying language, Geequel, and ONgDB takes strides in continuing the trend in being both enterprise ready and more developer friendly with your preferred language.

Some of the features in ONgDB 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 ONgDB. Lucene is a high-performance, full-featured text search engine library written entirely in Java that ONgDB uses for some indexing operations so this brings some nice improvements to the indexing management and performance within ONgDB.
The introduction of a uniformed language driver, called Bolt, that greatly improves performance and capability of the language drivers that communicate with the ONgDB
graph database completely remotely.

Complex graph update operations using MERGE are probably our most used Geequel operations for loading data into ONgDB and keeping it updated constantly during various ETL processes when integrating ONgDB with existing data sources. This makes the Geequel 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 Geequel 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 with higher ID limits, which increases the logical limits well beyond any realistic concerns of maxing out the numbers of nodes and relationships stored.

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.ongdb.properties configuration and ongdb-server properties into ongdb.conf
• console.log is now called ongdb.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.