By Gabe Stanek & Stefan Kolmar, Neo4j Field Engineering Team | January 31, 2017
There are many use cases and scenarios where it makes sense to use Oracle RDBMS in tandem with the Neo4j graph database, whether you’re migrating a subset of data or constantly syncing both graph and relational datasets.
However, sometimes circumstances dictate that the best decision for your data is to migrate it fully into Neo4j.
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. In previous weeks, we defined and introduced both Neo4j and Oracle RDBMS; we covered 3 advantages of using Neo4j with Oracle; we explored how to migrate or sync a subset of your data between them; and we discussed how to fully sync your relational and graph data.
This week, we’ll cover when (and when not) it makes sense to fully migrate all of your relational data from Oracle RDBMS into Neo4j.
Migrating Your Relational Data into Neo4j
In some cases, an existing application may be hitting its architectural and performance limits. Often, this means you are faced with developing a new application. If the data in question is highly connected, it may make sense to use Neo4j rather than Oracle RDBMS as the sole database store, and in that case you would migrate all the data to Neo4j.
There are several scenarios where it may indeed make sense to do a rip and replace for a particular application. If business users are complaining about prohibitively slow application performance, for example, then you may want to consider moving entirely to Neo4j since doing so can greatly improve query times.
Similarly, if most of the queries in an application are joining varying sets and depths of data in real time, where the sets cannot be easily predicted or pre-computed, then the data would be much more efficiently handled in Neo4j. Finally, you may choose to do a rip and replace if your queries have become exceedingly complex and it’s taking too long to train new staff members on them. With a graph database, connected data queries are much simpler and easy enough for even beginners to grasp with minimal training.
Replacing Oracle RDBMS with Neo4j is similar to migrating a subset of data, only you’re migrating all of the data. The migration also involves editing the application code that interacts with the database and rewriting those queries.
Case Study: Schleich
A number of companies have moved traditional systems, like supply chain management, to Neo4j. Schleich GmbH, one of the largest toy companies in Germany, found that its RDBMS-powered product data management (PDM) solution wasn’t delivering the flexibility, performance and operational efficiency their supply chain required. Schleich decided to create its next generation PDM system in Neo4j.
Within six months, the company’s technology partner, Structr, had migrated all the data from the previous PDM system into the company’s open source graph application program, which leverages Neo4j. Traceability and compliance across the entire value chain are key aspects of the toy industry, and the new PDM system meets all of these requirements, including allowing third parties to gain visibility where needed. The graph-based PDM system is being integrated with SAP and introduced into key areas of the company.
Case Study: Billes
Another use case where migrating all the data into Neo4j made sense involved integrating numerous systems from acquired companies into a single application. Billes, a printing house in business since 1939, together with its technology partner NetConsult, built a system for planning, ordering, shipping and billing based on Neo4j. A variety of mergers and acquisitions had led to a patchwork of tools and parallel IT systems. Relevant portions of all of these systems were integrated seamlessly into the Neo4j-based system, which is called Poff.
Because Neo4j has a flexible data model that can be changed at any time, system integration efforts were greatly reduced. In total, about 40 external systems receive orders and process them through Poff. The success and ease of administration of the system have enabled the company to add new business areas, including online orders from consumers.
This is the end of the Oracle RDBMS + Neo4j blog series. We hope this series has been helpful to you in discovering how these two database platforms can work side by side at your enterprise. If you’re new to the series, catch up with the first post here on the definition of both platforms: Neo4j and Oracle RDBMS.
Read the White Paper
About the Author
Gabe Stanek & Stefan Kolmar, Neo4j Field Engineering Team
Gabe Stanek is VP of the Global Field Engineering organization on the Neo4j team. He has spent his entire career focused on helping people and companies achieve success with technology and realizing value out of technical investments. At Neo4j, he enjoys the opportunity to help guide the team committed to this same success.
Stefan Kolmar is the Director of Field Engineering for the EMEA region. He has been in Technical Pre-sales roles for more than 15 years, working for companies such as Tandem, Compaq and Portal Software with specific emphasis on database technologies. More recently, he took on lead Pre-Sales and Consulting roles in the DACH region for TimesTen (in-memory relational database). After TimesTen was acquired by Oracle (2006), Stefan grew to lead the entire European Oracle ISV/OEM Pre-Sales team as the Director of Sales Consulting.
From the CEO
Have a Graph Question?
Reach out and connect with the Neo4j staff.Stackoverflow
Share your Graph Story?
Email us: email@example.com