Introduction

The advent of NoSQL databases has lead many application developers, designers, and architects to apply the most appropriate means of data storage to each specific aspect of their systems, and this may involve implementing multiple types of Database and integrating them into a single solution. The result is a polyglot solution.

Designing and implementing a polyglot system is not a straightforward task and there are a number of questions that need to be addressed including:

• How can you implement a uniform data access strategy that is independent of the different databases? The business logic of an application should not be dependent on the physical structure of the data that it processes as this can introduce dependencies between the business logic and the databases. This issue is especially important of your data is spread across different types of database, where a single business method might retrieve data from a variety of data stores.
• How can you make the best use of different databases to match the business requirements of your applications? This is the driving force behind building polyglot solutions.
  • If your applications need to store and retrieve structured data very quickly you might consider using a document database
  • If you need to perform more complex analyses on the same data then a column-family database might be more appropriate
  • If you need to track and manage complex relationships between business objects, then a graph database could provide the features that you require
• Some of the challenges to address are:
  • Maintaining consistency across different databases
  • Increased application complexity
  • Increased deployment complexity
  • Training for developers and operational staff

Why OrientDB?

OrientDB is a tool capable of defining, persisting, retrieving and traversing information. It can play as a

Document DB

Similar to MongoDB or Couchbase, OrientDB can store documents and can take an arbitrary Document (e.g., a JSON document) and store it. After it has been stored we can query it using path expressions, as we would expect from any document database.

Graph DB

Similar to famous Neo4j and Titan, handling relationships are responsibilities of graph databases. Graph databases typically implement the relationships as first class citizens called edges that connect vertices. A vertex, in most graph databases, is a simple cluster of name-value pairs. Is it possible to make each document in the document database as a vertex? OrientDB has done exactly that. Instead of each node being a flat set of properties, it can be a complete document with nested properties.

Object DB

Another interesting feature that OrientDB offers is the object-oriented implementation under the document DB: with OrientDB we are able to define a hierarchy between tables (they are called “classes”) and thus being able to take advantage of inheritance.

OrientDB allows us to define classes that the objects (vertices or documents) must conform to but does not enforce us to do so. OrientDB can run in strict schema mode (all objects are typed and must conform to the class definitions), in a hybrid mode (all objects must AT LEAST conform to the rules of the classes but may add any other properties not specified in the classes) or in schema-less mode.

Use Case

OrientDB being both Document and Graph database, it’s very obvious to use such multi-model NOSQL data store to address the below use cases that would otherwise end us up dealing with two NOSQL databases with all the challenges mentioned in the previous section.

Use Case 1

An application stores detailed information about each employee as a collection of documents in a document database, and maintain the information about the managers that they report to as a graph in a graph database. In this way, the data for each employee can be as complicated as the document database will allow, and the graph database only needs to hold the essential details of each employee needed to perform the various graph-oriented queries required by the application

Use Case 2

Wanderu provides the ability for consumers to search for bus and train tickets, with journeys combining legs from multiple different transportation companies. The route data is stored in JSON, making a document storage engine a great solution for their route leg data storage. However, they also needed to be able to find the optimal path from origin to destination. This is perfect for a graph database as they can understand the data relationships between different transit route legs.

Conclusion

• The power of a Distributed Graph Database engine with the flexibility of a Document Database all in one product. That is OrientDB.
• With OrientDB, ACID transactions are distributed across servers.
• HTTP Rest + JSON API, Multi-Master Replication, user and roles security, embedded & server deployment, data sharding, and SQL support are some of the key capabilities of OrientDB.

References

• OrientDB: http://www.orientdb.com/
• OrientDB vs Neo4j: http://www.slideshare.net/kwoxer/orientdb-vs-neo4j-and-an-introduction-to-nosql-databases
• OrientDB vs MongoDB:  http://www.slideshare.net/StefanoCampese/mongodb-vs-orientdb
• Getting Started: http://orientdb.com/getting-started/