Ontdek zelf welke inzichten graph databases kunnen verschaffen. In tegenstelling tot andere databases komen relaties in graph databases op de allereerste plaats. Wij bij know.bi dragen deze filosofie graag uit naar onze klanten. Vul het onderstaande formulier in, of bel ons, indien je graag de mogelijkheden onderzoekt in een op jouw maat gemaakte demo.
Nu we de basisbegrippen van graphs overlopen hebben kunnen we bekijken hoe dit zich vertaalt naar graph databases.
Er zijn een aantal graph implementaties die we in wat detail zullen bekijken, maar het is van belang te weten dat dit geen volledige lijst is. Er zijn andere implementaties, sommige databases hebben graph functionaliteit die bovenop de relationele engine gebouwd is etc. Het is vooral van belang te onthouden dat de populariteit van graph databases momenteel door het dak gaat.
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, ...
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
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 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
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:
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.
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.
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.
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.
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:
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.
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.
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:
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:
In vergelijking met relationeel modelleren is het modelleren voor een graph databases (bijna) een fluitje van een cent:
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:
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 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:
Een voorbeeld van een Cypher query:
Deze query zoekt:
The basis Cypher taal kan uitgebreid worden met plugins. Twee plugins die honderden nuttige procedures en functies toevoegen zijn:
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:
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:
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: