Del via


Hvad er en grafdatabase?

Notat

Denne funktion er i øjeblikket tilgængelig som offentlig prøveversion. Denne prøveversion leveres uden en serviceniveauaftale og anbefales ikke til produktionsarbejdsbelastninger. Visse funktioner understøttes muligvis ikke eller kan have begrænsede funktioner. Du kan finde flere oplysninger under Supplerende vilkår for anvendelse af Microsoft Azure Previews.

En grafdatabase modellerer data som et netværk af forbundne enheder og relationer. Den mest almindeligt anvendte type grafdatabase implementerer den mærkede egenskabsgrafmodel : enheder (noder) og relationer (kanter) kan have etiketter og egenskaber (nøgle-værdi-par). Denne fleksible model muliggør både skemavalgfrie og skemadrevne design, og den giver dig mulighed for at udtrykke omfattende semantik. Da forbindelser gemmes eksplicit som kanter, krydser forespørgsler relationer ved at følge kanter i stedet for at beregne dyre joinforbindelser på forespørgselstidspunktet.

Vigtigt

Denne artikel bruger udelukkende datasættet for eksempelgrafer på sociale netværk.

Kernebegreber i grafdatabasen

  • Noder repræsenterer ting som mennesker, produkter eller steder. Noder kan have etiketter og egenskaber, der beskriver deres attributter.
  • Kanter repræsenterer, hvordan disse ting er forbundet, f.eks. FRIENDS_WITH, KØBT eller LOCATED_IN. Kanter kan også indeholde egenskaber og etiketter for at kode relationsmetadata.
  • Egenskaber knytter detaljer til noder og kanter (f.eks. en persons navn eller en kants siden dato). Da relationer gemmes eksplicit som kanter, navigerer forespørgsler i grafen ved at følge forbindelser i stedet for at beregne dem på forespørgselstidspunktet.

Sådan fungerer forespørgsler om relationer

Grafforespørgsler henter forbundne oplysninger ved at gå fra en startnode til dens naboer, derefter til deres naboer og så videre. Den indsats, en gennemgang udfører, er bundet til antallet af kanter, den berører (det lokale nabolag), ikke den samlede størrelse af datasættet. Dette gør spørgsmål om stier, forbindelser og mønstre – såsom venners venner, korteste stier eller multi-hop-afhængigheder – naturlige og effektive at udtrykke.

Grafdatabaser bruger mønsterbaserede forespørgselssprog, såsom det stadig mere vedtagne Graph Query Language (GQL), til at beskrive disse krydsninger kortfattet. GQL standardiseres af den samme internationale arbejdsgruppe, der fører tilsyn med SQL (ISO/IEC 39075), og tilpasser grafforespørgsler til etablerede databasestandarder.

Eksempel (mønstermatchning med GQL):

MATCH (p:Person {firstName: "Annemarie"})-[:knows]->(friend)-[:likes]->(c:Comment)
RETURN c
ORDER BY c.creationDate
LIMIT 100

Dette mønster lyder som: startende ved Person-noden for Annemarie, følg :knows kanter til hver ven, følg :likes derefter kanter til relaterede :Comment noder og returner de 100 nyeste af disse kommentarer.

Modellering og skema

Grafdatamodeller er skemavalgfrie: Du kan arbejde med et fast skema, når du har brug for stærk styring, eller udvikle modellen, efterhånden som nye nodetyper, relationer eller egenskaber vises. Denne tilgang reducerer behovet for dataduplikering og giver teams mulighed for at samle data fra flere kilder uden omfattende genstart på forhånd.

Almindelige anvendelser af grafdatabaser

Grafdatabaser er tæt på domæner, hvor forbindelser skaber værdi, såsom sociale netværk, vidensgrafer, anbefalingssystemer, svindel- og risikonetværk, netværks- og it-topologi og afhængighedsanalyse af forsyningskæden. I disse scenarier handler spørgsmålene mindre om enkelte poster og mere om, hvor mange objekter der relaterer til og interagerer over flere hop.

Hvornår skal man overveje en grafdatabase?

Vælg en grafdatabase, når dine primære spørgsmål involverer stier, nabolag og mønstre i forbundne data; når antallet af humle er variabelt eller ikke kendt på forhånd eller når du har brug for at kombinere og navigere i relationer på tværs af forskellige datasæt. Hvis det er de spørgsmål, du skal besvare gentagne gange, er en grafmodel et naturligt match.

Hvad med ETL

Repræsentation af dine data som en graf og lagring af dem i en separat, selvstændig grafdatabase introducerer ofte ETL og styringsomkostninger. I modsætning hertil fungerer grafen i Microsoft Fabric direkte på OneLake, hvilket reducerer eller eliminerer behovet for separate ETL-pipelines og dataduplikering. Overvej disse afvejninger:

  • Databevægelse og duplikering: Selvstændige grafdatabaser kræver typisk udtrækning, transformation og indlæsning af data (ETL) i en separat butik, hvilket øger kompleksiteten og kan føre til duplikerede datasæt. Graph i Microsoft Fabric fungerer på OneLake, så du kan modellere og forespørge på forbundne data uden at flytte dem.
  • Driftsomkostninger: Enkeltstående grafstakke kører som separate klynger eller tjenester og har ofte gebyrer for tomgangskapacitet. Grafarbejdsbelastninger i Fabric bruger puljekapacitetsenheder (CU'er) med automatisk nedskalering og centraliserede målepunkter, hvilket forenkler driften og kan sænke omkostningerne.
  • Skalerbarhed: Nogle enkeltstående grafdatabaser er afhængige af opskalering eller leverandørspecifik klyngedannelse. Graph i Microsoft Fabric er designet til store grafer og bruger udskalerbar sharding på tværs af flere medarbejdere til at håndtere big data-arbejdsbelastninger effektivt.
  • Værktøjer og færdigheder: Leverandørspecifikke grafsystemer kan kræve specialiserede sprog og separate analyseframeworks. Graph i Microsoft Fabric giver samlet modellering, standardbaseret forespørgsel (GQL), indbyggede grafanalysealgoritmer, BI- og AI-integration og undersøgelsesværktøjer med lav / ingen kode, så et bredere sæt brugere kan arbejde med forbundne data.
  • Styring og sikkerhed: Separate grafudrulninger kræver uafhængig styring og sikkerhedsopsætninger. Graph i Microsoft Fabric bruger OneLake-styring, afstamning og rollebaseret adgangskontrol (RBAC) til arbejdsområdet, så overholdelse af angivne standarder, overvågning og tilladelser forbliver konsistente med resten af dit Fabric-miljø.