Nøgleværdi, dokumentorienteret, kolonnefamilie, graf, relationel ... I dag ser vi ud til at have så mange slags databaser, som der er slags data. Selvom dette kan gøre valg af en database sværere, gør det valg afret database lettere. Det kræver selvfølgelig, at du laver dit hjemmearbejde. Du har lært dine databaser at kende.
En af de mindst forståede typer af databaser derude er grafdatabasen. Designet til at arbejde med stærkt sammenkoblede data, kan en grafdatabase beskrives som mere ”relationel” end en relationsdatabase. Grafdatabaser skinner, når målet er at indfange komplekse forhold i store informationsbånd.
Her er et nærmere kig på, hvad grafdatabaser er, hvorfor de ikke er i modsætning til andre databaser, og hvilke slags dataproblemer de er bygget til at løse.
Grafdatabase vs. relationsdatabase
I en traditionel relations- eller SQL-database er dataene organiseret i tabeller. Hver tabel registrerer data i et specifikt format med et fast antal kolonner, hver kolonne med sin egen datatype (heltal, tid / dato, friformstekst osv.).
Denne model fungerer bedst, når du primært beskæftiger dig med data fra en enkelt tabel. Det fungerer heller ikke så dårligt, når du samler data, der er gemt på tværs af flere tabeller. Men denne adfærd har nogle bemærkelsesværdige grænser.
Overvej en musikdatabase med album, bands, labels og kunstnere. Hvis du vil rapportere alle de kunstnere, der blev vist på det her album af at band udgivet den Disse etiketter - fire forskellige tabeller - du skal eksplicit beskrive disse forhold. Med en relationsdatabase opnår du dette ved hjælp af nye datakolonner (for en-til-en eller en-til-mange relationer) eller nye tabeller (for mange-til-mange relationer).
Dette er praktisk, så længe du administrerer et beskedent antal forhold. Hvis du har at gøre med millioner eller endda milliarder af forhold - for eksempel venner af venners venner - skaleres disse forespørgsler ikke godt.
Kort sagt, hvisforhold mellem data, ikke selve dataene, er dit største problem, så er en anden slags database - en grafdatabase - i orden.
Grafdatabasefunktioner
Udtrykket "graf" kommer fra brugen af ordet i matematik. Der bruges det til at beskrive en samling noder (eller hjørner), der hver indeholder information (ejendomme), og med mærkede forhold (eller kanter) mellem noderne.
Et socialt netværk er et godt eksempel på en graf. Folk i netværket ville være knudepunkterne, hver persons attributter (såsom navn, alder osv.) Ville være egenskaber, og linjerne, der forbinder folket (med etiketter som "ven" eller "mor" eller " supervisor ”) angiver deres forhold.
I en konventionel database kan forespørgsler om relationer tage lang tid at behandle. Dette skyldes, at relationer implementeres med fremmede nøgler og forespørges ved at slutte sig til tabeller. Som enhver SQL DBA kan fortælle dig, er det dyrt at udføre sammenføjninger, især når du skal sortere et stort antal objekter - eller, værre, når du skal deltage i flere tabeller for at udføre de slags indirekte (f.eks. "Ven af en ven") forespørgsler at grafdatabaser udmærker sig ved.
Grafdatabaser fungerer ved at gemmerelationer sammen med dataene. Fordi relaterede noder er fysisk forbundet i databasen, er adgang til disse relationer lige så øjeblikkelig som at få adgang til selve dataene. Med andre ord, i stedet for at beregne forholdet, som relationsdatabaser skal gøre, læser grafdatabaser simpelthen forholdet fra lagring. Tilfredsstillende forespørgsler er et simpelt spørgsmål om at gå eller "traversere", grafen.
En grafdatabase gemmer ikke kun forholdet mellem objekter på en indfødt måde, hvilket gør forespørgsler om forhold hurtigt og nemt, men giver dig mulighed for at medtage forskellige slags objekter og forskellige slags forhold i grafen. Ligesom andre NoSQL-databaser er en grafdatabase skemafri. Med hensyn til ydeevne og fleksibilitet hugger grafdatabaser således tættere på dokumentdatabaser eller nøgleværdilagre, end de gør relationelle eller tabelorienterede databaser.
Brug af databaser til grafdatabaser
Grafdatabaser fungerer bedst, når de data, du arbejder med, er stærkt forbundet og skal repræsenteres af, hvordan de fungerer linker eller henviser til andre data, typisk i form af mange-til-mange relationer.
Igen er et socialt netværk et nyttigt eksempel. Grafdatabaser reducerer mængden af arbejde, der er nødvendigt for at konstruere og vise datavisningerne, der findes i sociale netværk, såsom aktivitetsfeeds, eller bestemme, om du måske kender en given person eller ej på grund af deres nærhed til andre venner, du har i netværket.
En anden applikation til grafdatabaser er at finde forbindelsesmønstre i grafdata, der ville være vanskelige at drille via andre datarepræsentationer. Systemer til afsløring af svig bruger grafdatabaser til at belyse forhold mellem enheder, der ellers måske har været svære at lægge mærke til.
Tilsvarende er grafdatabaser en naturlig pasform til applikationer, der styrer forholdet eller indbyrdes afhængighed mellem enheder. Du finder ofte grafdatabaser bag anbefalingsmotorer, indholds- og aktivstyringssystemer, identitets- og adgangsstyringssystemer og lovgivningsmæssige overholdelses- og risikostyringsløsninger.
Forespørgsler om grafdatabaser
Grafdatabaser - som andre NoSQL-databaser - bruger typisk deres egen tilpassede forespørgselsmetode i stedet for SQL.
Et almindeligt anvendt grafforespørgselssprog er Cypher, oprindeligt udviklet til Neo4j-grafdatabasen. Siden slutningen af 2015 er Cypher blevet udviklet som et separat open source-projekt, og en række andre leverandører har vedtaget det som et forespørgselssystem for deres produkter (fx SAP HANA).
Her er et eksempel på en Cypher-forespørgsel, der returnerer et søgeresultat for alle, der er en ven af Scott:
MATCH (a: Person {name: ’Scott’}) - [: FRIENDOF] -> (b) RETURN b Pilsymbolet (->) bruges i Cypher-forespørgsler til at repræsentere et rettet forhold i grafen.
Et andet almindeligt grafforespørgselssprog, Gremlin, blev udtænkt til Apache TinkerPop-grafberegningsrammen. Gremlin-syntaksen svarer til den, der bruges af nogle sprogs ORM-databaseadgangsbiblioteker.
Her er et eksempel på en "venner af Scott" -forespørgsel i Gremlin:
g.V (). har ("navn", "Scott"). ud ("ven af") Mange grafdatabaser understøtter Gremlin via et bibliotek, enten indbygget eller tredjepart.
Endnu et andet forespørgselssprog er SPARQL. Det blev oprindeligt udviklet af W3C til at forespørge om data, der er gemt i Resource Description Framework (RDF) -formatet for metadata. Med andre ord var SPARQL ikke udtænkt til grafdatabasesøgninger, men kan bruges til dem. I det store og hele er Cypher og Gremlin blevet bredere vedtaget.
SPARQL-forespørgsler har nogle elementer, der minder om SQL, nemligVÆLG og HVOR klausuler, men resten af syntaksen er radikalt forskellig. Tænk ikke på, at SPARQL overhovedet er relateret til SQL eller for den sags skyld andre sprog til grafforespørgsler.
Populære grafdatabaser
Da grafdatabaser tjener en relativt niche-brugssag, er der ikke næsten så mange af dem, som der er relationsdatabaser. På plussiden gør det de markante produkter lettere at identificere og diskutere.
Neo4j
Neo4j er let den mest modne (11 år og tæller) og bedst kendte af grafdatabaser til generel brug. I modsætning til tidligere grafdatabaseprodukter bruger den ikke en SQL-back-end. Neo4j er en oprindelig grafdatabase, der blev konstrueret indefra og ud til at understøtte store grafstrukturer, som i forespørgsler, der returnerer hundreder af tusinder af relationer og mere.
Neo4j kommer i både gratis open source og for-pay-forretningsudgaver, hvor sidstnævnte ikke har nogen begrænsninger for størrelsen på et datasæt (blandt andre funktioner). Du kan også eksperimentere med Neo4j online ved hjælp af sin Sandkasse, som indeholder nogle eksempler på datasæt at øve med.
Se gennemgang af Neo4j for flere detaljer.
Microsoft Azure Cosmos DB
Azure Cosmos DB skydatabasen er et ambitiøst projekt. Det er beregnet til at efterligne flere slags databaser - konventionelle tabeller, dokumentorienteret, kolonnefamilie og graf - alt sammen gennem en enkelt, samlet tjeneste med et ensartet sæt API'er.
Til dette formål er en grafdatabase kun en af de forskellige tilstande, Cosmos DB kan operere i. Den bruger Gremlin-forespørgselssproget og API til graf-type forespørgsler og understøtter Gremlin-konsollen oprettet til Apache TinkerPop som en anden grænseflade.
Et andet stort salgsargument for Cosmos DB er, at indeksering, skalering og geo-replikering håndteres automatisk i Azure-skyen uden at dreje på en knap i din ende. Det er endnu ikke klart, hvordan Microsofts all-in-one-arkitektur måler op til native grafdatabaser med hensyn til ydeevne, men Cosmos DB tilbyder bestemt en nyttig kombination af fleksibilitet og skala.
Se gennemgang af Azure Cosmos DB for flere detaljer.
JanusGraph
JanusGraph blev forked fra TitanDB-projektet og er nu under ledelse af Linux Foundation. Den bruger en hvilken som helst af et antal understøttede bagenden - Apache Cassandra, Apache HBase, Google Cloud Bigtable, Oracle BerkeleyDB - til at gemme grafdata, understøtter Gremlin-forespørgselssproget (såvel som andre elementer fra Apache TinkerPop-stakken) og kan også inkorporere fuldtekstsøgning ved hjælp af Apache Solr-, Apache Lucene- eller Elasticsearch-projekterne.
IBM, en af JanusGraph-projektets tilhængere, tilbyder en hostet version af JanusGraph på IBM Cloud, kaldet Compose for JanusGraph. Ligesom Azure Cosmos DB giver Compose til JanusGraph autoskalering og høj tilgængelighed med priser baseret på ressourceforbrug.
