Relational Databases deal poorly with relationships
Do you deal with complex queries that involve many joins (anywhere up from four)?
Do you try to find unknown paths through the data?
Do you have a model that evolves frequently?
At Vadis Technologies, our data scientists often face this kind of challenges.
In partnership with Intys Data, we have been investigating graph databases to
- gain in performance
- work agile
- get a richer view of the 300M companies and 200M peoplewe analyze
If you either work with highly connected data (social networks), recommendations (e-commerce), or pathfinding (how do I know you), then you will like our findings.
Do not get me wrong. Relational databases are great. But only for a limited number of tables, and when a rigid structure is not an issue. Here is an illustration from Max De Marzi.
A graph is a set of nodes, with relationships that connect them A graphDB is a database with:
- An explicit graph structure;
- Nodes that know each of their adjacent nodes;
- An index for lookups;
- Local steps (hops) whose cost remains constant as the number of nodes increases.
If you are used to SQL:
- Rows in tables become nodes;
- Foreign keys become relationships;
- Link tables become relationships (possibly with properties);
- Artificial constructs (extra primary and foreign keys for example) are no longer necessary.
GraphDBs are used in many other cases Here is a non-exhaustive list of graphDBs use cases
- Recommendation engine
- Network and IT Operations
- Search engine
- Master Data Management
- Identity and access management (internal and external)
- Machine learning and analytics
- Social networks
- Privacy and risk compliances
- Email targeting
- Knowledge Graph (for asset management, content management, inventory, workflows, cataloging..)