Graph databases are NoSQL databases which use the graph data model comprised of vertices, which is an entity such as a person, place, object or relevant piece of data and edges, which represent the relationship between two nodes.
Graph databases are particularly helpful because they highlight the links and relationships between relevant data similarly to how we do so ourselves.
Even though graph databases are awesome, they’re not enough on their own.
Advanced second-generation NoSQL products like OrientDB are the future. The modern multi-model database provides more functionality and flexibility while being powerful enough to replace traditional DBMSs.
As part of Apache’s TinkerPop API, Gremlin is the open source standard language for graph databases. It creates a shared set of basic interfaces to abstract the graph, vertex, edge and property concepts.
Both OrientDB Community and OrientDB Enterprise editions are compatible with TinkerPop.
As an official OrientDB partner, TinkerPop and OrientDB staff worked together to build the OrientDB implementation of Blueprints.
Not only is SQL more readable and concise than most mapreduce scripts, we believe you shouldn’t have to learn a new query language in order to utilize graphs.
With an SQL-based query language extended to support trees and graphs, OrientDB makes moving to the NoSQL world familiar to those coming to it for the first time.
The custom Java Database Connectivity (JDBC) driver for OrientDB enables applications to connect to remote servers using the standard and consolidated way of interacting with databases in the Java world. Simply add a dependency inside your project and you are ready to connect.
Our JDBC driver is compatible with most tools that support the standard. Take a look at our integrations for a complete list of compatible tools and drivers.
Unlike relational databases, a graph database doesn’t utilize foreign keys or JOIN operations. Instead, all relationships are natively stored within vertices (as documents in OrientDB). This results in deep traversal capabilities, increased flexibility and enhanced agility.
Native graph databases are equipped to easily accommodate rapidly scaling data—something particularly useful as organizations generate more and more data each day.
Modern day applications—like recommendation engines, social media, fraud detection, forensic analysis and medical research platforms—all use graphs to process highly connected data.
Native graph databases that apply index-free adjacency report reduced latency in create, read, update and delete (CRUD) operations.
OrientDB connects documents using fast, direct links from the graph database world.
Aside from incorporating multiple data models within their core engine, true multi-model databases are those which not only make use of several models, but also:
The overall strategy of multi-model databases is to act as drop-in replacements for relational, graph or document databases. However, multi-model databases can also work alongside them to synchronize data first. Real-world scenarios rarely present opportunities to simply substitute databases; these changes occur gradually. Multi-model databases acknowledge these challenges and help make that process easier. As a result, inefficient systems can be gradually removed without compromising the data integrity of production environments.
Multi-model databases such as OrientDB allow for relational and other graph data to be either synchronized or migrated into them. Although it supports embedding documents, the ability to connect them removes duplicate information—making data processing that much more efficient.
Systems such as OrientDB exploit the advantages of graph databases but add transactional complexity, query optimization, SQL familiarity and the data integrity needed to run stable, secure environments and process massive data sets quickly.
Though graph databases allow for large amounts of highly connected data to be retrieved quickly, most production environments are comprised of multiple systems. These systems lack common standards, making data synchronization costly and inefficient.
This causes most popular graph databases (such as Neo4j*) to be utilized as stores for large data sets and adds another layer of complexity to administration. Production environments generally utilize graph databases solely to resolve complex relationships, with remaining data still residing on other databases. For example. while graph databases might store recommendations for an application, financial data is still stored in relational database and product data is typically stored in a document database.
Multi-model databases, on the other hand, allow all data to be stored in a single system. Not only does this optimize performance, it also reduces licensing and operational costs.
OrientDB eliminates the need for multiple systems.
Polyglot persistence requires multiple systems, which hurts performance and increases costs.
By exploiting multiple data models and integrating multiple systems, OrientDB optimizes graph data. The platform, which combines spatial awareness and graph data, enables applications to harness graph database speeds with transactional data for many modern-day use cases.
OrientDB can be used as a single system. But it’s also equipped to make integration with multiple systems easier. As a result, production environments aren’t impacted while enterprises transition to modern-day applications.
True multi-model databases like OrientDB also eliminate restrictions imposed by data models and database vendors by harnessing graph data relationships with document metadata for better RAM use and improved caching. What’s more, OrientDB’s Reactive Model optimizes resources by pushing query results when changes occur—instead of regularly polling the database to spot changes.
When compared to Neo4j’s* graph database, an independent benchmark by the Tokyo Institute of Technology* and IBM Research*shows that OrientDB is 10x faster on graph operations among all workloads.
OrientDB is fully customizable; users decide which constraints are set and when to enforce schemas. Lacking schema restrictions, database managers and developers can choose schema-full, schema-less or schema-mixed modes.
By combining the power of graphs with the flexibility of documents, multi-model databases such as OrientDB are suitable for virtually any use case. Some of the uses include:]
For additional use cases, take a look at our case studies, use cases and success stories to find out more about specific OrientDB applications and how multi-model databases are being used for everything from traffic management to forensic analysis to fraud prevention.
"OrientDB saved us countless time in providing critical features for our platform that more traditional database technologies do not deliver. It did so in a well-designed, easy-to-integrate approach.”
—Jim Marino, architect and technology strategist at Massiv.io
If you are currently using a relational database and are interested in converting your data to a graph, try out OrientDB Teleporter, which was built to make the migration as easy as possible. Start your free 45-day OrientDB Enterprise trial today and begin synchronizing all your relational data with a few clicks.