Hva er en grafdatabase?

Note

Denne funksjonen er for øyeblikket i offentlig forhåndsversjon. Denne forhåndsvisningen leveres uten en tjenesteavtale, og anbefales ikke for produksjonsarbeidsbelastninger. Enkelte funksjoner støttes kanskje ikke eller kan ha begrensede funksjoner. For mer informasjon, se Supplemental Terms of Use for Microsoft Azure Previews.

En grafdatabase er en type database som representerer informasjon som noder (enheter) og kanter (relasjoner) i stedet for tabeller og rader. Denne strukturen gjør det enkelt å utforske komplekse forbindelser og mønstre på tvers av dataene dine.

Den mest brukte typen grafdatabase implementerer modellen med merkede egenskapsgrafer (LPG): enheter (noder) og relasjoner (kanter) kan ha etiketter og egenskaper (nøkkel-verdi-par). Denne fleksible modellen muliggjør både skjema-valgfrie og skjema-drevne design, og lar deg uttrykke komplekse relasjoner. Fordi tilkoblinger lagres eksplisitt som kanter, krysser spørringer relasjoner ved å følge kanter i stedet for å beregne dyre sammenføyninger på spørringstidspunktet.

Note

Eksempler i denne artikkelen bruker datasett for sosiale nettverks eksempelgrafer.

Kjernekonsepter for grafdatabase

En grafdatabase organiserer data i tre grunnleggende byggesteiner:

  • Noder representerer enheter som personer, produkter eller steder. Noder kan ha etiketter og egenskaper som beskriver attributtene deres. For eksempel kan en Person node ha egenskaper som firstName, lastName, og age.
  • Kanter representerer hvordan entitetene er sammenhengende, for eksempel FRIENDS_WITH, PURCHASED, eller LOCATED_IN. Kanter kan også bære egenskaper og etiketter for å fange relasjonsmetadata.
  • Egenskaper knytter detaljer til noder og kanter (for eksempel en persons navn eller en kants siden dato).

Slik fungerer spørring av relasjoner

Grafspørringer henter tilkoblet informasjon ved å gå fra en startnode til naboene, deretter til naboene og så videre. Kostnaden for en traversering avhenger av antall kanter den berører (det lokale nabolaget), ikke den totale størrelsen på datasettet. Denne egenskapen gjør spørsmål om stier, forbindelser og mønstre – som venner av venner, korteste stier eller flerhoppavhengigheter – naturlige og effektive å uttrykke.

Grafdatabaser bruker mønsterbaserte spørringsspråk, som Graph Query Language (GQL), for å beskrive disse gjennomgangene kortfattet. Den samme internasjonale arbeidsgruppen som har ansvar for SQL (ISO/IEC 39075) standardiserer GQL, som tilpasser grafforespørsler med etablerte databasestandarder.

Eksempel (mønstermatching med GQL):

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

Dette mønsteret ser ut som: starter ved Person-noden for Annemarie, følg :knows kanter til hver venn-node, og følg :likes deretter kanter til relaterte :Comment noder. Returner de 100 nyeste av disse kommentarene, sortert etter opprettelsesdato.

AI-assistert grafresonnement (forhåndsvisning)

Grafdatabaser passer naturlig for AI-resonnement fordi de koder relasjonene som språkmodeller trenger for å svare nøyaktig på spørsmål med flere hopp. I Microsoft Fabric støtter Fabric Data Agent graf som datakilde, noe som gjør det mulig for brukere å stille naturlige spørsmål som agenten svarer på ved å spørre grafen. For detaljer om hvordan NL2GQL oversetter naturlig språk til GQL, se kunngjøringen om Graph-powered AI-resonnement.

Grafdatamodell og skjemafleksibilitet

Grafdatamodeller er skjema-valgfrie: du kan starte med en fleksibel modell og formalisere den over tid. I graf i Microsoft Fabric krever strukturelle endringer — som å legge til nye egenskaper, endre etiketter eller endre relasjonstyper — for øyeblikket at data legges inn i en ny modell. Denne tilnærmingen reduserer behovet for dataduplisering og lar team forene data fra flere kilder uten tung forhåndsdesign. For mer informasjon om datamodellen som brukes i graf i Microsoft Fabric, se Labeled property graphs.

Vanlige bruksområder for grafdatabaser

Grafdatabaser samsvarer tett med domener der forbindelser driver verdi, slik som:

  • Sosiale nettverk — modellerer relasjoner mellom mennesker og deres interaksjoner
  • Kunnskapsgrafer — koble konsepter, entiteter og fakta for semantisk søk og resonnement
  • Anbefalingssystemer — navigerer bruker-objekt-interaksjoner for å fremheve personlige forslag
  • Svindel- og risikonettverk — oppdager mistenkelige mønstre på tvers av kontoer, transaksjoner og enheter
  • Nettverks- og IT-topologi — kartlegger avhengigheter mellom servere, tjenester og infrastrukturkomponenter
  • Forsyningskjedeavhengighetsanalyse — spor komponentopprinnelse og relasjoner mellom leverandører
  • Grafbasert gjenfinnings-utvidet generering (RAG) — bruk grafstruktur som kunnskapskilde for AI-agenter som trenger multi-hop resonnement med forklarbare, jordnære svar

I disse scenariene handler spørsmålene mindre om enkeltoppføringer og mer om hvor mange enheter som er relatert til og samhandler over flere hopp.

Når bør du vurdere en grafdatabase

En grafdatabase passer godt når relasjoner driver kjernespørsmålene du må svare på. Velg en grafdatabase når:

  • Dine hovedspørsmål handler om stier, nabolag og mønstre i sammenkoblede data.
  • Antallet humle varierer eller er ikke kjent på forhånd.
  • Du må kombinere og navigere relasjoner på tvers av ulike datasett.

Hvis du jevnlig stiller slike spørsmål, er en grafmodell en naturlig løsning.

Hvordan grafer i Microsoft Fabric sammenlignes med frittstående grafdatabaser

Å representere dataene dine som en graf og lagre dem i en separat, frittstående grafdatabase medfører ofte ETL (extract, transform, load) og styringsoverhead. Til sammenligning opererer graf i Microsoft Fabric direkte på OneLake, noe som reduserer eller eliminerer behovet for separate ETL-pipelines og dataduplisering. Vurder disse avveiningene:

  • Databevegelse og duplisering: Frittstående grafdatabaser krever vanligvis uthenting, transformasjon og lasting av data til en separat lagring, noe som øker kompleksiteten og kan føre til dupliserte datasett. Graph fungerer på OneLake, så du kan modellere og spørre i tilkoblede data uten å flytte den.
  • Driftskostnader: Frittstående grafstabler kjører som separate klynger eller tjenester og har ofte kostnader for ledig kapasitet. I graf bruker arbeidsbelastninger pooled capacity units (CU) med automatisk nedskalering og sentraliserte måleparametere, noe som forenkler driften og kan redusere kostnadene.
  • Skalerbarhet: Noen frittstående grafdatabaser er avhengige av oppskalering eller leverandørspesifikk klynging. Graph er designet for store grafer og bruker scale-out sharding på tvers av flere arbeidere for å håndtere store data-arbeidsbelastninger effektivt.
  • Verktøy og ferdigheter: Leverandørspesifikke grafsystemer kan kreve spesialiserte språk og separate analyserammeverk. Graph tilbyr enhetlig modellering, standardbasert spørring (GQL), innebygde grafanalysealgoritmer, BI- og AI-integrasjon inkludert Fabric Data Agent støtte for naturlig språk grafspørring (forhåndsvisning), og lav/ingen-kode utforskende verktøy. Disse mulighetene gjør det mulig for et bredere antall brukere å arbeide med tilkoblede data.
  • Styring og sikkerhet: Separate grafutrullinger trenger uavhengig styring og sikkerhetsoppsett. Graph bruker OneLake-styring, lineage og arbeidsområde rollebasert tilgangskontroll (RBAC) slik at overholdelse, revisjon og tillatelser forblir konsistente med resten av Fabric-miljøet ditt.

Beslektet innhold

  • Last updated on