Imagine you are an army mechanic, and you are deployed with resupplying resources days away. A truck breaks down and needs to be fixed using only the parts at hand. You need to fix the problem, but also want to continue the mission as seamlessly as possible. What do you do?
To address the problem’s competing priorities – expediency and mission – you may choose to cannibalize a replacement part from the lowest-priority system deployed with you. To do that, you need to know what parts are broken, and what other parts are on every other vehicle on the road with you at the time. And since time is a factor, you probably want the biggest single replacement part, whether it’s an engine block, a housing, or a piston, that can make the truck functional again.
This is exactly the sort of data problem that becomes a headache with traditional relational databases. Understanding which parts intersect with other parts (which may also intersect with larger components), and knowledge of which of these components are in the field on an array of systems requires so much specific knowledge of the problem that just diagnosing it could take hours, if not days. How can you to model these parameters generally, and quickly surface dozens of eligible replacement options?
Enter graph databases.
Graph databases focus on the relationships between things. In this example, the relationship is simply “FITS ON”. If a part fits on another part, the graph draws a connection between the two parts. If a part fits on a component made of multiple parts, the part is connected to the component with the same type of relationship. If a component fits onto a system such as a vehicle, the component and the vehicle again share a FITS ON relationship. Listing out the options for vehicles to choose from is a simple task of querying the database for any system that has the component or part that requires replacement.
Example set of nodes and relationships using Neo4j.
Relationships are stored in a graph database when they are created, so there is no need to create foreign keys and re-index multiple times in order to chase the parts, components, and systems across separate tables. And since they index only once, finding those relationships in graph databases can be done in constant time, rather than in log time, which Army logistics officers report as a significant boost in performance over RDMS solutions for the same problem.
But graph databases can also refer to relationships that are current, rather than static. If a vehicle is deployed with a given battalion, then its system node could also be connected via an “IS DEPLOYED WITH” relationship to the battalion node. The relationship between those systems and the battalions can also carry a property describing the system’s criticality to the mission.
If your use case is similar to the any of these listed below, graph database solutions might be right for you:
- The most critical insights are about the relationships between objects tracked in a database, rather than the properties inherent in those objects
- Your data relationships aren’t strictly hierarchical, and those relationships may loop back on one another
- Data updates frequently, with relationships that are also subject to change
Need someone to get you up and running with graph databases? Excella’s data and analytics group would be happy to answer your questions, feel free to contact us.