As more and more businesses wake up to the opportunity buried in their connected data, interest in graph databases has sky rocketed.
The availability of an efficient way to store and query connected data has made graph databases a viable option for a range of tasks that would previously have required massive computational resource.
As with all great things, however, there is a limitation to what they can do.
Graph databases, whilst highly optimized for connections, are generally not good for documents. A deployment requiring both would normally need some kind of integration (e.g. Neo4j with MongoDB).
On the other hand, relational and document stores are great for documents, but fairly awful with connected data. The workaround here is a painful combination of foreign keys and expensive join operations.
One potential solution to these woes is OrientDB.
Describing itself as “the first multi-model open source NoSQL DBMS”, OrientDB has full native graph capabilities, but also features you would normally only find in document databases. In theory, it can replace products in Graph, Document, Key/Value, or Object categories.
Like other graph databases, OrientDB stores data as nodes and edges. Data can be stored with or without a schema (or with a partial schema) and relationships can be traversed at lightning speed. However it can also embed documents, meaning they can effectively be stored, not just connected.
Download our Getting Started Guide for step-by-step instructions on hooking KeyLines up to your OrientDB database.
Getting Started Guide Contents
Getting started with KeyLines
Example: An OrientDB / KeyLines demo