At the same time, well-established relational database management systems (RDBMS) like Oracle aren’t going anywhere soon. Oracle RDBMS is the backbone of millions of enterprise applications and can’t (or shouldn’t) be tossed aside lightly.
However, thanks to a polyglot persistence architecture, today’s data professionals can harness the power of both a graph database like Neo4j and the established reputation of Oracle RDBMS. Using each database technology according to its strengths has a number of advantages.
In this Neo4j and Oracle blog series, we’ll explore how these two database technologies work together in tandem to deliver the best bottom-line results for both enterprise architects and business teams alike. Last week, we defined and introduced both Neo4j and Oracle RDBMS.
This week, we’ll cover the advantages of using Neo4j and Oracle to work together.
Advantage #1: Your Oracle Investment Keeps Paying Off
There are several advantages to using Neo4j and Oracle RDBMS together, beginning with the simple fact that Oracle is a trusted and well-established technology. With so many enterprise applications running on Oracle, you shouldn’t throw away your existing investments in Oracle infrastructure, tools and training.
Fortunately, you don’t have to. All of your applications can continue to use Oracle RDBMS uninterrupted. By adding Neo4j to your arsenal, you lose nothing while gaining all the strategic capabilities of a graph database.
Advantage #2: You Use the Right Database for the Job
There are scenarios where using an RDBMS versus a graph database simply makes sense, and vice versa.
Oracle is great for tabular, structured data while unstructured, highly connected or very dynamic data such as hierarchies and networks can be moved out of Oracle and into Neo4j. This enables agility. When architected to coexist, application performance will improve since fast traversals can be done against the graph using Neo4j while transactional data can be retrieved from Oracle.
Graph databases and relational databases each address specific use cases. Neo4j, therefore, doesn’t compete with Oracle but coexists with it. Together, Neo4j and Oracle enable developers and architects to use the right type of database for the right use case.
Advantage #3: You Get Superior Query Performance for Connected Data
Using Neo4j and Oracle together also enables organizations to improve application performance by offloading queries that leverage connected data.
In an RDBMS, data relationship queries can be answered by creating JOINs between database tables. However, these operations are compute- and memory-intensive, and the performance impact increases as data volumes grow. A graph database can analyze complex, connected data much faster and persist that analysis for future reference.
Depth and density of connections and data volume impact query times significantly. With Neo4j, you can query data with a depth of millions or tens of millions of connections per second per computer core, which would be the equivalent in the relational database world of millions of JOIN operations per second per core, which is impossible. There’s a big difference in speed, and this difference amplifies the tighter your connections are and the more data you have.
The more data you have, the slower it becomes to relate data in other kinds of databases, including Oracle RDBMS. Using Neo4j, a shortest path query on data with tens of billions of nodes and relationships might take one or two milliseconds to run. The equivalent SQL query would run many thousands of times slower if an application was solely using an RDBMS such as Oracle.
Conclusion
With Neo4j you can use best-of-breed technology as your applications dictate – whether that be a graph database or an Oracle relational database. As the world’s first graph database built with native graph storage and processing, Neo4j delivers unparalleled performance even as your data grows.
In the following weeks, we’ll cover three different ways to use Neo4j alongside Oracle RDBMS, taking a closer look at the advantages and disadvantages of each from an architecture perspective.
Read the White Paper