Per Manier van Data Opslag

• Native Graph Storage: dit type van graph databases werd vanaf de basis gebouwd om met graphs te werken (bv. Neo4j, TigerGraph)
• Relationele Opslag: data wordt bewaard in een relationeel(achtig) model, en wordt in runtime (bij uitvoering van een query) vertaald naar een graph (bv. GraphX). 
• Key-Value Opslag: vergelijkbaar met de graphs met relationele opslag, met dat verschil dat hier een key-value of andere NoSQL database als onderliggende laag voor data-opslag gebruikt wordt (bv. JanusGraph). 

Per Data Model

Labeled Property Graphs

In een labeled property graph wordt data georganiseerd als nodes en relationships, waarbij beide "properties" (of eigenschappen, key-value pairs) kunnen bevatten. 

Nodes kunnen getagd met een aantal (0 of meer) labels om verschillende rollen in een graph of bedrijfsdomein aan te duiden. 

Relaties bieden een (optionele) richting (zie ook “Graph Theory”), en qua naam semantisch relevante verbinding tussen twee nodes. Net als nodes kunnen relaties eigenschappen (properties) hebben. De eigenschappen van een relatie kunnen een gewicht of kost aan een relatie toevoegen. Wanneer we bijvoorbeeld de kortste route tussen twee nodes proberen te vinden kan het efficiënter zijn om een pad te volgen dat langs 3 relaties (bv. elk met een korte tussenliggende afstand) tegenover een enkele kostelijke relatie (bv. over lange afstand). Hoewel relaties altijd aangemaakt worden met een richting, kan deze genegeerd worden bij het doorlopen van de graph.

Voorbeelden van labeled property graphs zijn Neo4J, AWS Neptune, ...

Hypergraph

Een relatie in een hypergraph kan een willekeurig aantal nodes verbinden. Dit model is bij uitstek geschikt voor het voorstellen van data met een groot aantal "many-to-many" relaties. Hypergraphs kunnen steeds gemodelleerd worden als labeled property graphs, het omgekeerde is niet altijd mogelijk.    

Een voorbeeld van een hypergraph is HypergraphDB

Triple Store (RDF)

Een triple store of RDF (Resource Description Framework) bewaart data punten als triples. Een triple (bv. “Bob is 35”, “Bob kent John”) bestaat uit

• een subject (onderwerp) is het voorwerp of concept waarover de triple information biedt: “Bob”
• het predicate beschrijft wat het object over het subject vertelt: “is” of “kent”
• het object (voorwerp): “35” of “John”

Een triple kan vergeleken worden met een node in een labeled property graph. Relaties in een triple store worden gedefinieerd als ‘Arcs’, waarbij een triple als subject (start node), een triple voor het object (end node) en een "arc" of type relatie voor het predicate. 

Aangezien arcs logisch gelinkte triples of nodes aanmaken worden triple stores als graph databases beschouwd. Aangezien hun architectuur eerder gericht is op individuele triples dan op de graph als geheel zijn ze niet in dezelfde mate geschikt voor het snel doorlopen van graphs als native graph databases, in het bijzonder property graphs. 

Voorbeelden van Triple Stores zijn AWS Neptune, AllegroGraph, Stardog

Ontdek meer

Hoe verschillen Graph databases van Relationele databases?

Relationele database bewaren gegevens in tabellen. Deze tabellen bestaan uit een sterk gestructureerde en vooraf gedefinieerde set kolommen, met onder meer vast bepaalde data types. 

Relaties worden bepaald als een combinatie van kolommen die dienst doen als de unieke identificatie van een rij in een tabel (de primary keys) and referenties naar vergelijkbare unieke rij-sleutels in andere tabellen (foreign keys). 

Relaties in een relationele database worden niet in de database bewaard, maar worden in runtime opgebouwd (door het gebruik van JOIN-statements in queries).  

Doordat relaties niet bewaard worden objecten in de database kan er geen bijkomende meta-informatie aan een relatie gekoppeld worden. 

Daarbovenop is het bepalen van relaties in runtime (tijdens het uitvoeren van queries) erg duur, wat het werken met sterk geconnecteerde data bemoeilijkt. 

In het kort zijn de beperkingen van relationele databases bij sterk geconnecteerde data de volgende: 

• Starheid: de vastbepaalde structuur van relationele database tabellen maakt het lastig om snel te schakelen in de huidige agile omgevingen, waarbij snelle en frequente wijzigingen als vanzelfsprekend beschouwd worden. 
• geen concept van "relaties": in een sterk verbonden wereld is informatie ivm relaties tussen data punten vaak belangrijker dan de data zelf. Relationele database werden niet ontworpen om deze informatie over relaties op te slaan. 
• Performantie wordt snel problematisch bij het werken met sterk geconnecteerde gegevens. Grote aantallen (self) joins dwingen de performantie van relationele databases al snel op de knieën en zijn 1 van de oorzaken van wat bekend is als “SQL Strain” (de "remmende factor" van SQL).

Analyse van Sociale Netwerken

Moderne social networken laten mensen to om te communiceren en informatie te delen met andere leden van wereldwijde netwerken. Deze networken kunnen gaan van intense interacties met een beperkt aantal dichte vrienden tot onderdeel uitmaken van een groter netwerk (of “community”). 

Analyse van sociale networken (of Social Network Analysis, SNA) richt zich op deze relaties, en tracht uit te zoeken hoe de manier waarop individuen interageren met anderen hun gedrag en beslissingen beïnvloedt.

Social networken, zeker wanneer ze bestaan uit duizenden individuen en miljoenen interacties (relaties),  worden vrij snel erg complex. Het analyseren van deze gigantische hoeveelheden data vereist modellen die het netwerk vereenvoudigen en terzelfdertijd representatief blijven. 

Fraude Detectie

Of je fraude met credit cards, ecommerce, verzekeringen of andere types fraude wil onderzoeken, frauduleus gedrag wordt al snel erg complex.  

In een graph database zoals Neo4j worden  transacties bewaard in een graph waar gerelatedeerde data-gebieden met elkaar verbonden worden. Dit maakt het eenvoudig deze relaties in real-time te doorlopen en frauduleuze patronen snel op te sporen. 

Geo

Erg veel geografische en navigatie-gerelateerde problemen werken van nature perfect op graphs. Het vinden van de best route van punt A naar punt B is een kwestie van vinden van het kortste pad binnen een netwerk (graph) van punten op die weg. Op een vergelijkbare manier is het vinden van lokaties dicht bij een bepaald punt een kwestie van het vinden van alle nodes binnen een bepaalde afstand van node A.  

Recommendation engines

Real-time recommendation engines (aanbevelingen) zijn de sleutel tot success voor online winkels. Om relevante real-time aanbevelingen te kunnen maken is de mogelijkheid om product, klant, inventaris, leverancier, logistiek en zelfs sociale data (sentiment analysis) met elkaar in verband te brengen. Meer zelfs, een real-time recommendation engine  moet steeds en onmiddellijk nieuwe interesses tijdens het bezoek van klanten kunnen oppikken en integreren, iets wat met batch processing quasi onmogelijk te realiseren is. Het koppelen van deze real-time informatie aan historische gegevens is triviaal voor een graph database.

Graph databases verslaan met gemak hun relationele en NoSQL collega's voor het verbinden van grote hoeveelheden klant- en product-data (en geconnecteerde data in het algemeen) om inzichten te verkrijgen in de noden van klanten, product trends etc.

Authorizaties en Toegangscontrole

Traditioneel gezien wordt informatie over (groepen van) mensen en resources (bestanden, systemen, producten, legale documenten, …) en toegang tot deze mensen en resources bewaard in directory services (e.g. Active Directory). Naarmate deze hierarchische systemen groeien beginnen ze te worstelen met een aantal problemen: 

• Diep intergeconnecteerde gegevens met betrekking tot identiteit en toegang tot data 
• Productiviteit en klantentevredenheid (performantie)
• Dynamische structuur

Met een graph engine die deze complexe netwerken van relaties in milliseconden kan doorlopen, toegang tot resources kan analyseren, en bv dubbele rollen kan identificeren worden deze taken bijna triviaal.  

Master Data Management

Het up to date en consistent houden van operationele data vraagt een beheer dat de volledige organisatie overspant. Dit vereist het opzetten van een centrale zone waar master data over klanten, producten, processen etc beheerd wordt.  

Niet enkel moet er betekenis gegeven worden aan deze gegevens in verspreide systemen, in een veelheid aan formaten, locaties en sterk wisselende kwaliteit, nog belangrijker is een goede koppeling van deze gegevens en een goed begrip van de onderlinge relaties. 

Lineage, Auditing, Impact Analyse

Het overzicht behouden van hoe verschillende infrastructuur componenten en systemen in grote en complexe organisaties zoals we die vandaag kennen is een hele uitdaging met relationele databases. 

Aangezien alle (virtuele) hardware infrastructuur, software servers, applicaties, data flows en acties van gebruikers met elkaar verbonden zijn vormen ze in principe al een graph die uitermate geschikt is om in een graph database opgeslagen en beheerd te worden. 

Een aantal resultaten van mogelijke queries kunnen dan zijn: 

• Lineage: Ik heb dit inkomend data punt "A". Wat gebeurt er verder met dit data object? Waar komt het uiteindelijk terecht? Wie wijzigt het, en op welk punt? 
• Impact Analyse: wat is de impact wanneer ik kolom x in tabel y in database z aanpas? Welke gebruikers verder in mijn organisatie zullen impact van deze wijziging ondervinden? 
• Auditing: wat zijn mijn populairste dashboards? Wat zijn mijn populairste rapporten? Welke data wordt door niemand ooit gebruikt?

Monitoring van netwerken en infrastructuur 

Netwerk en IT infrastructuur wordt al snel moeilijk te beheren, wat eerder vroeg dan laat vraagt om het opstellen van een  Configuration Management DataBase (CMDB). Waar relationele databases al snel beginnen te worstelen met het beheren van grote hoeveelheden verbonden systemen is dit opnieuw een use case waar graph sytemen in uitblinken. 

Een graph database laat niet alleen toe om je volledig infrastructuur op te slaan en te beheren, het maakt het ook eenvoudig om te verbinden met een groot aanbod aan monitoring tools en op die manier belangrijke inzichten te verschaffen in de complexe relaties tussen het functioneren van netwerken of volledige data centers. Van het beheren van de afhankelijkheden tussen systemen tot het geautomatiseerd monitoren van microservices, de mogelijkheden voor graphs in netwerken en IT operations zijn eindeloos.

De meeste mensen die betrokken zijn in het ontwerpen of modelleren van relationele database schema's ervaren dat proces als lastig of zelfs ronduit pijnlijk. Een aantal elementen die die indruk voeden zijn:  

• Het model van de "echte wereld" moet gekoppeld worden aan een technisch ontwerp. Een groot aantal beslissingen (bv. normalisatie, dedupliceren van data, bepalen van sleutelvelden, data types, etc) moeten enkel en alleen om technische redenen gemaakt worden, zodat het "echte wereld" model gekoppeld kan worden aan de technische beperkingen die door de database opgelegd worden. 
• Vooruit denken is moeilijk maar onvermijdelijk. Van zodra een database schema aangemaakt en gevuld is met data worden wijzigingen lastig en duur. Wijzigingen aan het schema moeten gemaakt worden met voorwaartse en achterwaartse compatibiliteit in het achterhoofd, de wijzigingen zelf zijn vaak lastig en traag door te voeren. 

In vergelijking met relationeel modelleren is het modelleren voor een graph databases (bijna) een fluitje van een cent: 

• Mensen denken in termen van objecten (nodes) en wat die objecten verbindt (relationships). We denken uit onszelf al bijna in graphs. Dit maakt graph modelling uitermate geschikt om op een  whiteboard uit te tekenen. Een conceptueel ontwerp van een system vereist niet langer een technische vertaling om binnen het schema van een relationele database te passen, maar kan bijna onmiddellijk op de graph database toegepast worden. 
• Aangezien er geen nood is aan een vast bepaald database schema kunnen graph models eenvoudig aangepast en uitgebreid worden naar veranderende vereisten.De oorspronkelijke nodes en relaties blijven bestaan en compatibel, terwijl nieuwe functionaliteit een bijgewerkt of aangepast data model kan gebruiken. Het graph database model evolueert bijna moeiteloos mee met de voortdurend wijzigende realiteit van uw bedrijf. 

SPARQL

SPARQL (uitgeproken als “Sparkel”) is een recursief acroniem voor “SPARQL Protocol and RDF Query Language”, en is een query taal voor RDF (een semantische database query taal) die gegevens in het Resource Description Framework (RDF) formaat kan bevragen. 

SPARQL queries bestaan in 4 verschillende vormen: 

• SELECT queries worden gebruikt om gegevens uit een SPARQL endpoint (database) op te halen. De resultaten worden in een tabulair formaat aangeleverd.
• CONSTRUCT queries worden gebruikt om informatie uit een SPARQL endpoint op te halen. Het resultaat wordt aangeleverd als geldige RDF waarmee onmiddellijk nieuwe triples gecreëerd kunnen worden.
• ASK queries worden gebruikt om eenvoudige True/False resultaten uit een SPARQL endpoint op te halen.
• DESCRIBE queries worden gebruikt om een RDF graph uit een SPARQL endpoint op te halen. Op basis van de inhoud van de resulterend graph kan de database beheerder bepalen wat nuttige informatie is.

Voorbeeld van een (SELECT) query:

Deze query voegt alle triples met eenzelfde subject samen,waarbij het type predicate, "a",  een person is (foaf:Person), en deze persoon 1 of meerdere namen (foaf:name) en mailboxes (foaf:mbox) heeft.

Cypher

Cypher is Neo4j’s graph query taal die gebruikers toelaat informatie naar de graph database te schrijven of er uit op te halen. Cypher is een beschrijvende, door SQL geïnspireerd taal voor het beschrijven van visuele patronen in graphs door middel van  ASCII-Art syntax.

Net zoals andere query talen bevat Cypher een heel aantal kernwoorden voor het bevragen en filteren van patronen, en voor het formatteren van de terug te leveren resultaten. Een aantal van de meest gebruikte kernwoorden zijn: MATCH, WHERE, en RETURN. Deze werken iets anders dan SELECT en WHERE in SQL, maar worden voor vergelijkbare doelen gebruikt.

De belangrijkste kernwoorden om te vermelden zijn: 

• MATCH wordt gebruikt voor het beschrijven van patronen voor het zoeken van nodes, relaties, of de combinatie van nodes en relaties. 
• WHERE wordt gebruikt om bijkomende beperkingen en filters toe te passen op de gezochte nodes en relaties, of om ongewenste patronen uit te sluiten.
• RETURN formatteert en organiseert de te tonen resultaten: welke properties getoond moeten worden, aggregaties, sortering etc.

Een voorbeeld van een Cypher query:

Deze query zoekt: 

• (nicole:Actor {name: 'Nicole Kidman'}): alle nodes met een “Actor” label, met een filter op de property “name” voor alle acteurs die “Nicole Kidman” heten. Deze nodes krijgen de alias “nicole” 
• (movie:Movie): alle nodes met een label “Movie”, krijgen een alias “movie”
• [:ACTED_IN]: voor beide lijsten van nodes zoals eerder bepaald worden alles nodes opgezocht waarvoor een “ACTED_IN” relatie bestaat. 
• voor alle gevonden nodes worden de nodes met een alias “movie” door de database aangeleverd. 

The basis Cypher taal kan uitgebreid worden met plugins. Twee plugins die honderden nuttige procedures en functies toevoegen zijn: 

• APOC (Awesome Procedures On Cypher): een zeer uitgebreide bibliotheek van bijkomende functionaliteit 
• Algo: Graph algorithmes (zie "Graph Analytics and Algorithms")

GQL

Standaarden zijn belangrijk om fragmentatie te vermijden in de sterk groeiende wereld van  labeled property graphs. Dit resulteerde in het ontstaan van GQL (Graph Query Language). In juni 2019 startte ISO/IEC’s Joint Technical Committee 1 (verantwoordelijk voor IT standaarden) het verkiezingsproces voor GQL. Als eerste nieuwe ISO/IEC’s standaard sinds SQL is het belang van GQL een niet te onderschatten stap in het proces naar verdere maturiteit voor graph databases!

GQL is opgebouwd door de sterke punten van 3 graph query talen te combineren: 

• Cypher (Neo4j, openCypher community)
• PGQL (Oracle)
• G-CORE: een query taal gebaseerd op een onderzoeksprojecpt van het  Linked Data Benchmark Council,  waar onderzoekers met wereldnaam en -faam uit Nederland, Duitsland, Chili, de VS en technische medewerkers van SAP, Oracle, Capsenta en Neo4j aan meegewerkt hebben. 

Door deze combinatie van de sterke punten van de leidende graph query talen in de graph industry is GQL bedoeld om de ‘SQL for graphs’ te worden. Het ISO/IEC wil hiermee fragmentatie vermijden en de volledige graph industrie een stevige stimulans geven. 

Laat ons even in iets meer detail kijken naar de opties die markleider Neo4j aanbiedt: 

• Load CSV: import van vooraf gemodeleerde data (voor nodes en relaties) in je graph door middel van Cypher of de neo4j-admin command line tool
• APOC: Neo4j’s APOC (Awesome Procedures On Cypher), is een bibliotheek van uitbreidingen op de core van de Cypher taal die (onder meer) complexe operaties en transformaties tijdens het laden van data mogelijk maakt (bv. apoc.load.json, apoc.load.jdbc om data van JSON bestanden en relationele databases te laden) 
• Neo4j’s ETL Tool ondersteunt een aantal import scenario's om data naar Neo4j te laden. Hoewel nuttig voor projecten op kleinere schaal loop je al snel tegen de beperkingen van de Neo4j ETL tool wanneer de problemen wat groter of complexer worden. 
• Custom code door middel van drivers: er bestaan drivers voor .Net, Javascript, Java, Go, Python en andere talen. Als drivers voor een specifieke programmeertaal worden de beperkingen bepaald door de programmeertaal zelf, wat in de praktijk uiterst beperkt is. Met grote flexibiliteit komt een grote verantwoordelijkheid (en veel werk), dus deze piste is vooral interessant wanneer zeer specifieke taken uitgevoerd dienen te worden.
• Kettle/Hop: het open source Kettle data engineering platform, ook (vroeger?) gekend als Pentaho Data Integration biedt een rijke set aan integraties met Neo4j. Er zijn visuele mogelijkheden om data te lezen vanuit Cyper queries, om data naar nodes en relaties of rechtstreeks naar een (in Kettle te modelleren) graph te laden. De ontwikkeling van Project Hop (gestart als nieuwe incarnatie van Kettle, maar snel evoluerend tot veel meer dan dat) wordt gesponsored en ondersteund door Neo4j en beschouwt Neo4j over de volledige lijn als "eersterangsburger". 

Ook hier ligt Neo4j behoorlijk ver voor op de rest van de markt. Een aantal van de  types algoritmes die vanuit de algo-bibliotheek ondersteund worden zijn: 

• Path finding: het zoeken van het kortste pad tussen nodes, of het vinden en evalueren van de beschikbaarheid en kwaliteit van routes
• Centrality: bepaal het belang van bepaalde nodes in een network
• Community Detection: bepaal hoe een groep nodes geclustered of gepartitioneerd is, met hun neiging een sterkere groep te worden of net uit elkaar te vallen
• Similarity: bepalen van de gelijkaardigheid van nodes
• Labs: het Neo4j labs team experimenteert constant met en werkt constant aan algoritmes die momenteel nog niet klaar zijn voor productie of "prime time".