OrientDB officially supports TinkerPop 3
Today I’m glad to announce that the OrientDB Team has started supporting officially the TinkerPop 3 standard in the “develop” branch, namely OrientDB v3.0.
Michael Pollmeier (@mpollmeier), the author of the already excellent OrientDB-Gremlin driver, transferred it under the OrientDB umbrella:
Together with Michael, also Marvin Froeder (@velo) joined the team as committer of the project. They will work, together with the OrientDB team, to make this driver ready for OrientDB v3.0. From the OrientDB side, the owner of this project is Enrico Risa (@maggiolo00).
Guys, we’re looking for new contributors. The roadmap is still open. So far the most important things are:
– Better support for indexes
– Usage of the new GraphAPI in the OrientDB core 3.0
– Better coverage of TinkerPop 3 features
By transferring the original project the entire history and issues are preserved. if you are already using it, please reset the master source of the git repository to it.
Founder & CEO
TinkerPop Blueprints standard doesn’t define a proper “Factory” to get graph instances. For this reason OrientDB users that wanted to use a pool of instances had to mix 2 different API: Graph and Document one. Example:
ODatabaseDocumentPool pool = new ODatabaseDocumentPool(“plocal:/temp/mydb”);
OrientGraph g = new OrientGraph(pool.acquire());
NOTE: You could also use a OGraphDatabase instance in place of ODatabaseDocumentPool, but this API has been deprecated since a long time and will be removed in v1.7.
Now everything is simpler, thanks to the new OrientGraphFactory class to manage graphs in easy way (Issue #1971). These the main features:
– by default acts as a factory by creating new database instances every time
– can be configured to work as a pool, by recycling database instances
– if the database doesn’t exist, it’s created automatically (but in “remote” mode)
– returns transactional and non-transactional instances
This is the basic way to create the factory, by using the default “admin” user (with “admin” password by default):
OrientGraphFactory factory = new OrientGraphFactory(“plocal:/temp/mydb”);
But you can also pass user and password:
OrientGraphFactory factory = new OrientGraphFactory(“plocal:/temp/mydb”, “jayminer”, “amigarocks”);
To work with a recyclable pool of instances with minimum 1, maximum 10 instances:
OrientGraphFactory factory = new OrientGraphFactory(“plocal:/temp/mydb”).setupPool(1, 10);
Once the factory is configured you can get a Graph instance to start working. OrientGraphFactory has 2 methods to retrieve a Transactional and Non-Transactional instance:
OrientGraph txGraph = factory.getTx();
OrientGraphNoTx noTxGraph = factory.getNoTx();
Or again you can configure in the factory the instances you want and use the get() method everytime:
OrientGraphNoTx noTxGraph = (OrientGraphNoTx) factory.get();
Once finished to free all the resources (in case of pool usage), call the close():
London, April 4th 2013
After about one month spent on development and test the NuvolaBase team has released the new GraphDB Engine!
The new Engine uses some novel techniques based on the idea of a dynamic Graph that change shape at run-time based on the settings and content. The new Engine is much faster than before and needs less space in memory and disk. Below the main improvements:
- avoid creation of edges as document if haven’t properties. With Graphs wit no properties on edges this can save more than 50% of space on disk and therefore memory with more chances to have a big part of database in cache. Furthermore this speed up traversal too because requires one record load less. As soon as the first property is set the edge is converted transparently
- Vertex “in” and “out” fields aren’t defined in the schema anymore because can be of different types and change at run-time adapting to the content:
- no connection = null (no space taken)
- 1 connection = store as LINK (few bytes)
- >1 connections = use the Set of LINKS (using the MVRBTreeRIDSet class)
- binding of Blueprints “label” concept to OrientDB sub-classes. If you create an edge with label “friend”, then the edge sub-type “friend” will be used (created by the engine transparently). This means:
- 1 field less in document (the field “label”) and therefore less space and the ability to use the technique 1 (see above)
- edges are stored on different files at file system level because are used different clusters
- better partitioning against multiple disks (and in the future more parallelism)
- direct queries like “select from friend” rather than “select from E” and then filtering the result-set looking for the edge with the wanted label property
- multiple properties for edges of different labels. Not anymore a “in” and “out” in Vertex but “out_friend” to store all the outgoing edges of class “friend”. This means faster traversal of edges giving one or multiple labels avoiding to scan the entire Set of edges to find the right one
- with such dynamic Graph in future we could support also HyperGraph in a flash
Such new Engine needed new API or a radical change to the current Raw API breaking the compatibility with the past. Well, we decided to change strategy by re-implementing the Blueprints
Graph layer as new GraphDB Engine. So the new GraphDB Engine IS the OrientDB’s Blueprints
Why? Mainly because:
- Blueprints is the de facto standard for Graph Databases made by TinkerPop team
- TinkerPop team is amazing with a lot of technologies built on top of Blueprints layer
- Latest release of Blueprints added some new features to allow the implementations to use the underlying engine in more powerful way
- Blueprints API and all the TinkerPop stack is very well documented with a lot of examples and a new Book that is coming
The new GraphDB engine depends on OrientDB 1.4.0-SNAPSHOT, so we can’t push it to TinkerPop repository because no SNAPSHOT are allowed as dependencies. As soon as we release OrientDB 1.4 we’re going to merge it with official TinkerPop Blueprint’s repository.
Starting from OrientDB 1.4 the GraphDB API to use are the Blueprints. Period. I’m sure this will make happy some users because Raw API are horrible and you’ve to work at document level using the OGraphDatabase class for any operations against vertices and edges (not really Object Oriented).
Waiting for the official release you can enjoy by cloning and start using the new GraphDB Engine from the master branch of NuvolaBase’s Blueprints fork: https://github.com/nuvolabase/blueprints
. It passes all the Blueprints Test Cases.
To open databases created with previous releases uses:
OrientGraph graph = new OrientGraph(“local:/temp/mydb”);
In the next days will be released a new tool to convert the databases to the new format.
CEO at NuvolaBase.com
the Company behind OrientDB
Follow me on http://twitter.com/lgarulli