Programmering

Hva er en grafdatabase? En bedre måte å lagre tilkoblede data på

Nøkkelverdi, dokumentorientert, kolonnefamilie, graf, relasjonell ... I dag ser det ut til at vi har like mange typer databaser som det er slags data. Selv om dette kan gjøre valg av database vanskeligere, blir det valg avIkke sant database enklere. Selvfølgelig krever det å gjøre leksene dine. Du har blitt kjent med databasene dine.

En av de minst forståte typene databaser der ute er grafdatabasen. Designet for å arbeide med svært sammenkoblede data, kan en grafdatabase beskrives som mer ”relasjonell” enn en relasjonsdatabase. Grafdatabaser skinner når målet er å fange komplekse forhold i store informasjonsnett.

Her ser du nærmere på hva grafdatabaser er, hvorfor de ikke er i motsetning til andre databaser, og hva slags dataproblemer de er bygget for å løse.

Grafdatabase vs. relasjonsdatabase

I en tradisjonell relasjons- eller SQL-database er dataene organisert i tabeller. Hver tabell registrerer data i et bestemt format med et fast antall kolonner, hver kolonne med sin egen datatype (heltall, tid / dato, friformstekst osv.).

Denne modellen fungerer best når du hovedsakelig arbeider med data fra en hvilken som helst tabell. Det fungerer heller ikke så dårlig når du samler data som er lagret i flere tabeller. Men den oppførselen har noen bemerkelsesverdige grenser.

Vurder en musikkdatabase med album, band, etiketter og artister. Hvis du vil rapportere alle utøverne som ble omtalt på dette album av at band utgitt på disse etiketter - fire forskjellige tabeller - du må eksplisitt beskrive disse forholdene. Med en relasjonsdatabase oppnår du dette ved hjelp av nye datakolonner (for en-til-en eller en-til-mange relasjoner), eller nye tabeller (for mange-til-mange relasjoner).

Dette er praktisk så lenge du administrerer et beskjedent antall forhold. Hvis du har å gjøre med millioner eller til og med milliarder av forhold - for eksempel venner av venners venner - kan disse spørsmålene ikke skaleres bra.

Kort sagt, hvisforholdet mellom data, ikke selve dataene, er ditt hovedanliggende, så er en annen type database - en grafdatabase - i orden.

Grafdatabasefunksjoner

Begrepet "graf" kommer fra bruken av ordet i matematikk. Der brukes den til å beskrive en samling noder (eller hjørner), som hver inneholder informasjon (eiendommer), og med merkede forhold (eller kanter) mellom nodene.

Et sosialt nettverk er et godt eksempel på en graf. Menneskene i nettverket vil være nodene, egenskapene til hver person (for eksempel navn, alder og så videre) vil være egenskaper, og linjene som forbinder folket (med etiketter som "venn" eller "mor" eller " veileder ”) vil indikere forholdet deres.

I en konvensjonell database kan spørsmål om relasjoner ta lang tid å behandle. Dette er fordi relasjoner implementeres med utenlandske nøkler og blir spurt ved å bli med i tabeller. Som enhver SQL DBA kan fortelle deg, er det dyrt å utføre sammenføyninger, spesielt når du må sortere gjennom et stort antall objekter - eller, verre, når du må bli med i flere tabeller for å utføre slags indirekte (f.eks. "Venn av en venn") spørsmål at grafdatabaser utmerker seg ved.

Grafdatabaser fungerer ved å lagreforhold sammen med dataene. Fordi relaterte noder er fysisk koblet i databasen, er det like øyeblikkelig å få tilgang til disse forholdene som å få tilgang til selve dataene. Med andre ord, i stedet for å beregne forholdet slik relasjonsdatabaser må gjøre, leser grafdatabaser bare forholdet fra lagring. Å tilfredsstille spørsmål er et enkelt spørsmål om å gå, eller "krysse", grafen.

En grafdatabase lagrer ikke bare forholdet mellom objekter på en innfødt måte, noe som gjør spørsmål om forhold raskt og enkelt, men lar deg inkludere forskjellige typer objekter og forskjellige typer relasjoner i grafen. Som andre NoSQL-databaser er en grafdatabase skjemafri. Når det gjelder ytelse og fleksibilitet, hugger grafdatabaser nærmere dokumentdatabaser eller nøkkelverdilagre enn de gjør relasjons- eller tabellorienterte databaser.

Bruksområder for grafdatabaser

Grafdatabaser fungerer best når dataene du jobber med er sterkt koblet sammen og skal representeres av hvordan de fungerer lenker til eller henviser til andre data, vanligvis i form av mange-til-mange-forhold.

Igjen er et sosialt nettverk et nyttig eksempel. Grafdatabaser reduserer mengden arbeid som trengs for å konstruere og vise datavisningene som finnes i sosiale nettverk, for eksempel aktivitetsstrømmer, eller å avgjøre om du kanskje kjenner en gitt person på grunn av deres nærhet til andre venner du har i nettverket.

En annen applikasjon for grafdatabaser er å finne mønstre for tilkobling i grafdata som det ville være vanskelig å plage ut via andre datarepresentasjoner. Systemer for svindeloppdagelse bruker grafdatabaser for å få frem forholdet mellom enheter som ellers kan ha vært vanskelig å legge merke til.

Tilsvarende er grafdatabaser en naturlig passform for applikasjoner som styrer forholdet eller gjensidig avhengighet mellom enheter. Du vil ofte finne grafdatabaser bak anbefalingsmotorer, innholds- og kapitalforvaltningssystemer, identitets- og tilgangsstyringssystemer, og regelverksoverholdelses- og risikostyringsløsninger.

Spørsmål om grafdatabaser

Grafdatabaser - som andre NoSQL-databaser - bruker vanligvis sin egen tilpassede spørringsmetodikk i stedet for SQL.

Et ofte brukt språkspråk er Cypher, opprinnelig utviklet for Neo4j-grafdatabasen. Siden slutten av 2015 har Cypher blitt utviklet som et eget open source-prosjekt, og en rekke andre leverandører har tatt det i bruk som et spørresystem for sine produkter (f.eks. SAP HANA).

Her er et eksempel på et Cypher-spørsmål som returnerer et søkeresultat for alle som er en venn av Scott:

MATCH (a: Person {name: ’Scott’}) - [: FRIENDOF] -> (b) RETURN b 

Pilsymbolet (->) brukes i Cypher-spørsmål for å representere et rettet forhold i grafen.

Et annet vanlig grafspørrespråk, Gremlin, ble utviklet for Apache TinkerPop grafikkrammeverk. Gremlin-syntaksen er lik den som brukes av noen språk ORM-databasetilgangsbiblioteker.

Her er et eksempel på et "venner av Scott" -søket i Gremlin:

g.V (). har ("navn", "Scott"). ute ("venn av") 

Mange grafdatabaser har støtte for Gremlin ved hjelp av et bibliotek, enten innebygd eller tredjepart.

Nok et spørsmålsspråk er SPARQL. Den ble opprinnelig utviklet av W3C for å spørre om data som er lagret i RDF-format (Resource Description Framework) for metadata. Med andre ord, SPARQL var det ikke utarbeidet for grafdatabasesøk, men kan brukes til dem. I det hele tatt har Cypher og Gremlin blitt bredere adoptert.

SPARQL-spørsmål har noen elementer som minner om SQL, nemligÅ VELGE og HVOR klausuler, men resten av syntaksen er radikalt ulik. Ikke tenk på SPARQL som relatert til SQL i det hele tatt, eller for den saks skyld til andre grafspørsmål.

Populære grafdatabaser

Fordi grafdatabaser har en relativt nisje-brukstilfelle, er det ikke nesten like mange av dem som det er relasjonsdatabaser. På plussiden gjør det de fremtredende produktene lettere å identifisere og diskutere.

Neo4j

Neo4j er lett den mest modne (11 år og teller) og den mest kjente av grafdatabasene for generell bruk. I motsetning til tidligere grafdatabaseprodukter bruker den ikke en SQL-back-end. Neo4j er en innfødt grafdatabase som ble konstruert fra innsiden og ut for å støtte store grafstrukturer, som i spørsmål som returnerer hundretusenvis av relasjoner og mer.

Neo4j kommer i både gratis åpen kildekode og betalte bedriftsutgaver, med sistnevnte ingen begrensninger på størrelsen på et datasett (blant andre funksjoner). Du kan også eksperimentere med Neo4j online ved hjelp av Sandbox, som inkluderer noen eksempler på datasett å øve på.

Se gjennomgang av Neo4j for mer informasjon.

Microsoft Azure Cosmos DB

Azure Cosmos DB skydatabase er et ambisiøst prosjekt. Det er ment å etterligne flere typer databaser - konvensjonelle tabeller, dokumentorientert, kolonnefamilie og graf - alt gjennom en enkelt enhetlig tjeneste med et konsistent sett med APIer.

For det formål er en grafdatabase bare en av de forskjellige modusene Cosmos DB kan operere i. Den bruker Gremlin-spørringsspråket og API for graf-type spørsmål, og støtter Gremlin-konsollen opprettet for Apache TinkerPop som et annet grensesnitt.

Et annet stort salgsargument for Cosmos DB er at indeksering, skalering og georeplikering håndteres automatisk i Azure-skyen, uten at det dreier seg om en knott. Det er ikke klart ennå hvordan Microsofts alt-i-ett-arkitektur måler opp til innfødte grafdatabaser når det gjelder ytelse, men Cosmos DB tilbyr absolutt en nyttig kombinasjon av fleksibilitet og skala.

Se gjennomgang av Azure Cosmos DB for mer informasjon.

JanusGraph

JanusGraph ble forkjøpt fra TitanDB-prosjektet, og er nå under styring av Linux Foundation. Den bruker hvilken som helst av et antall støttede bakenden - Apache Cassandra, Apache HBase, Google Cloud Bigtable, Oracle BerkeleyDB - for å lagre grafdata, støtter Gremlin-spørringsspråket (så vel som andre elementer fra Apache TinkerPop-stakken), og kan også innlemme fulltekstsøk ved hjelp av Apache Solr-, Apache Lucene- eller Elasticsearch-prosjektene.

IBM, en av JanusGraph-prosjektets støttespillere, tilbyr en vertversjon av JanusGraph på IBM Cloud, kalt Compose for JanusGraph. I likhet med Azure Cosmos DB gir Compose for JanusGraph autoskalering og høy tilgjengelighet, med priser basert på ressursbruk.

$config[zx-auto] not found$config[zx-overlay] not found