Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

 

No More Joins - SilverStripe and OrientDB

There has been something of a database renaissance in recent years, as big data requirements...

Tagged OrientDB, database

Comments 2

by Frank Mullenger

Posted 20 December 2013

Read post

OrientDBThere has been something of a database renaissance in recent years, as big data requirements have emerged so have non-relational databases and terms such as "NoSQL", "document" and "graph" scatter the landscape.

Earlier this year we decided to invest some time into researching an exciting and innovative database that combines all three terms into an open source product that is currently used in production by large companies and startups alike - OrientDB. Our aim was to swap the relational database that is conventionally used for SilverStripe projects with OrientDB using SilverStripe's existing API as much as possible.

What is OrientDB?

OrientDB started as an ODBMS (Object Database Management System) in 1999, today it has evolved to become a document based graph database however many core Object Oriented principles such as classes, properties and inheritance are still prevalent.

The inherent support for Object Orientation lessens the impedance mismatch between code and database, the result is that manipulating the database feels very natural for developers familiar with OO. For instance instead of tables and attributes OrientDB uses classes and properties to structure the data.

Another interesting aspect of OrientDB is that data is stored in documents, these consist of POJOs (Plain Old Javascript Objects). This diverts from the familiar territory of relational databases where explicitly defining the database schema is part of the routine (/dev/build), with OrientDB the schema does not need to be defined however it can be if required.

Why use OrientDB?

There are numerous reasons to use OrientDB, performance is not least among them.

OrientDB does away with the concept of a join table, one of the most significant bottle necks in relational databases. Similarly the native support for inheritance in OrientDB is useful particularly for SilverStripe as we can use this concept to avoid joining tables to mimic class inheritance. OrientDB was designed with performance in mind, as it mentions on the project README "A single server does the work of about 125 servers running MySQL".

OrientDB is also open source and favourably licensed with the Apache 2 license which essentially means the software is free for any usage. Combined with the active community and exceptional documentation OrientDB is an excellent proposition.

SilverStripe and OrientDB

Our approach to this project was to use Anton Terekhov's excellent PHP driver for OrientDB. Using Anton's work we could concentrate on leveraging some of the idiosyncrasies of OrientDB, two of the more interesting and useful concepts being inheritance and referenced relationships.

Inheritance

The concept of class inheritance is no doubt familiar to every SilverStripe developer. As many relational databases such as MySQL do not have native support for inheritance this concept is approximated by joining normalised tables which together have all the attributes necessary to build a subclass object. As projects grow and the number of classes increase this can obviously lead to performance issues.

With OrientDB we can neatly avoid this issue using built in inheritance when defining our schema, this means all we need to do is query a single table/class without any "JOIN" operations and all the necessary data will be returned.

Relations

Relations such as has_one, has_many and many_many can be represented using OrientDB's referenced or embedded relationships. Relationships in OrientDB establish a physical connection between documents and can be traversed very quickly and intuitively.

A join table concept is replaced with a LinkSet for instance, each end of the relationship maintains LinkSets which together replace the join table. Using this approach we can query for relations using OrientDB's "traverse" command. This is something of a paradigm change for the existing API which extensively uses "JOIN".

Outcomes

The project is currently a work in progress. Concepts such as using LinkSet relations and inheritance have been implemented and the results of these changes on the number and speed of queries can be seen using the PerformanceController which is included in the project.

Going forward we believe this work could give rise to a number of interesting integrations between SilverStripe and OrientDB where components of a project may require features that OrientDB has to offer.

Further details can be found in the project documentation or this short presentation.

Frank MullengerFrank has been developing with SilverStripe for several years and this year joined the SilverStripe team in Auckland. He maintains a number of SilverStripe modules including an ecommerce module known as SwipeStripe. You can find more of his work on Github or the occasional blog post.