OrientDB 1.5 has been released. This document graph database is open source, and the improvements to the new version include a new paginated local storage engine.

OrientDB isn’t a straight graph database; it has a hybrid model with elements taken from document database and object database worlds. It can make use of schemas or be used without a schema, and it supports traditional database features such as ACID transactions and SQL queries.  You can also use JSON for importing and exporting documents.  OrientDB  is written in Java, and the claims for its performance are impressive, with an ability to store up to 150,000 records per second on common hardware.  As OrientDB uses the Apache2 License, it’s free for any usage, even commercial.

OrientDB started life as an object oriented database called Orient ODBMS back in 1998, but since then it has been totally rewritten in Java in the form of a Document database and Version 1.0 was released in May 2012. The object database facilities are still there as a wrapper built on top of the Document database that transparently maps OrientDB document records to POJOs (plain old Java objects).

Graph databases store their data using a technique called index-free adjacency. Essentially, this means a data element has pointers to other data elements it’s related to, each of which also has pointers to the elements that data element is related to. 

Typical uses for graph databases include social networks, recommendation engines and networked systems. If you want to carry out queries such as ‘show me the friends of friends of person x’, graph databases run much faster than relational databases once the query depth rises. In one benchmark of this type of query, the graph database was 150 times faster than the relational query at query depth three. With a query depth of four, the graph database was over 1,000 times faster.

The changes to OrientDB start with the paginated local storage engine. This is persistent like the local store, but stores information in different way. Records are stored in cluster files, and the store is more durable than Local thanks to an append-on-write mode. It no longer uses memory mapping (MMAP) so the behavior is more ‘predictable’, and it supports better concurrency on parallel transactions.

Other improvements include a new Hash index type with better performance on lookups.  There’s also a new “transactional” SQL command that you can use to execute commands inside a transaction. This is claimed to be useful for ensuring the “create edge” SQL command works correctly and prevents the graph from becoming corrupted.