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. For mere information, se Supplerende Brugsvilkår for Microsoft Azure Forhåndsvisninger.

En grafdatabase er en type database, der repræsenterer information som noder (enheder) og kanter (relationer) i stedet for tabeller og rækker. Denne struktur gør det nemt at udforske komplekse forbindelser og mønstre på tværs af dine data.

Den mest anvendte type grafdatabase implementerer modellen med mærkede egenskabsgrafer (LPG): entiteter (noder) og relationer (kanter) kan have etiketter og egenskaber (nøgle-værdi-par). Denne fleksible model muliggør både skema-valgfrie og skema-drevne designs, og den lader dig udtrykke komplekse relationer. 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.

Notat

Eksempler i denne artikel bruger datasættet for sociale netværks eksempelgrafer.

Kernebegreber i grafdatabasen

En grafdatabase organiserer data i tre grundlæggende byggesten:

  • Noder repræsenterer enheder som personer, produkter eller steder. Noder kan have etiketter og egenskaber, der beskriver deres attributter. For eksempel kan en Person node have egenskaber som firstName, lastName, og age.
  • Kanter repræsenterer, hvordan enhederne er forbundne, for eksempel FRIENDS_WITH, PURCHASED, eller LOCATED_IN. Kanter kan også bære egenskaber og etiketter for at indfange relationsmetadata.
  • Egenskaber knytter detaljer til noder og kanter (for eksempel en persons navn eller en kants siden-dato).

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. En traverseringsomkostning afhænger af antallet af kanter, den berører (det lokale nabolag), ikke af datasættets samlede størrelse. Denne egenskab 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 Graph Query Language (GQL), til at beskrive disse gennemgange kortfattet. Den samme internationale arbejdsgruppe, der fører tilsyn med SQL (ISO/IEC 39075), standardiserer GQL, som tilpasser grafforespørgsler med 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-node, og følg :likes derefter kanter til relaterede :Comment noder. Returner de 100 nyeste af disse kommentarer, ordnet efter deres oprettelsesdato.

AI-assisteret grafræsonnement (forhåndsvisning)

Grafdatabaser passer naturligt til AI-ræsonnering, fordi de koder de relationer, som sprogmodeller har brug for for at besvare multi-hop spørgsmål præcist. I Microsoft Fabric understøtter Fabric Data Agent graf som datakilde, hvilket gør det muligt for brugere at stille spørgsmål i naturligt sprog, som agenten besvarer ved at forespørge grafen. For detaljer om, hvordan NL2GQL oversætter naturligt sprog til GQL, se Graph-powered AI-ræsonnementmeddelelsen.

Grafdatamodel og skemafleksibilitet

Grafdatamodeller er skema-valgfrie: du kan starte med en fleksibel model og formalisere den over tid. I grafer i Microsoft Fabric kræver strukturelle ændringer — såsom tilføjelse af nye egenskaber, ændring af etiketter eller ændring af relationstyper — i øjeblikket genindsættelse af data i en ny model. Denne tilgang reducerer behovet for dataduplikering og giver teams mulighed for at samle data fra flere kilder uden omfattende genstart på forhånd. For mere information om datamodellen, der bruges i graf i Microsoft Fabric, se Labeled property graphs.

Almindelige anvendelser af grafdatabaser

Grafdatabaser er tæt tilpasset domæner, hvor forbindelser driver værdi, såsom:

  • Sociale netværk — modellerer relationer mellem mennesker og deres interaktioner
  • Vidensgrafer — forbind begreber, entiteter og fakta til semantisk søgning og ræsonnement
  • Anbefalingssystemer — gennemgår bruger-objekt-interaktioner for at fremvise personlige forslag
  • Svindel- og risikonetværk — opdager mistænkelige mønstre på tværs af konti, transaktioner og enheder
  • Netværks- og IT-topologi — kortafhængigheder mellem servere, tjenester og infrastrukturkomponenter
  • Forsyningskædeafhængighedsanalyse — spor komponentoprindelse og relationer på tværs af leverandører
  • Grafbaseret retrieval-augmented generation (RAG) — brug grafstruktur som videnskilde for AI-agenter, der har brug for multi-hop ræsonnement med forklarlige, jordnære svar

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?

En grafdatabase passer godt, når relationer driver de kernespørgsmål, du skal besvare. Vælg en grafdatabase når:

  • Dine primære spørgsmål handler om stier, nabolag og mønstre i forbundne data.
  • Antallet af humle varierer eller er ikke kendt på forhånd.
  • Du skal kombinere og navigere relationer på tværs af forskellige datasæt.

Hvis du regelmæssigt stiller denne slags spørgsmål, er en grafmodel et naturligt match.

Hvordan grafer i Microsoft Fabric sammenlignes med selvstændige grafdatabaser

At repræsentere dine data som en graf og gemme dem i en separat, selvstændig grafdatabase medfører ofte ETL (extract, transform, load) og governance-overhead. Til sammenligning kører 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æk, transformation og indlæsning af data i en separat lager, hvilket øger kompleksiteten og kan føre til duplikerede datasæt. Graph kører på OneLake, så du kan modellere og forespørge forbundne data uden at flytte dem.
  • Driftsomkostninger: Enkeltstående grafstakke kører som separate klynger eller tjenester og har ofte gebyrer for tomgangskapacitet. I graf forbruger arbejdsbelastninger pooled capacity units (CU'er) med automatisk nedskalering og centraliserede målinger, hvilket forenkler driften og kan sænke omkostningerne.
  • Skalerbarhed: Nogle enkeltstående grafdatabaser er afhængige af opskalering eller leverandørspecifik klyngedannelse. Graph er designet til store grafer og bruger scale-out sharding på tværs af flere medarbejdere for effektivt at håndtere big data-arbejdsbelastninger.
  • Værktøjer og færdigheder: Leverandørspecifikke grafsystemer kan kræve specialiserede sprog og separate analyseframeworks. Graph tilbyder samlet modellering, standardbaseret forespørgsler (GQL), indbyggede grafanalysealgoritmer, BI- og AI-integration inklusive Fabric Data Agent understøttelse af naturlig sprog grafforespørgsler (forhåndsvisning) samt lav/ingen-kode udforskende værktøjer. Disse funktioner gør det muligt for et bredere antal brugere at arbejde med forbundne data.
  • Styring og sikkerhed: Separate grafudrulninger kræver uafhængig styring og sikkerhedsopsætninger. Graph bruger OneLake governance, lineage og workspace role-based access control (RBAC), så compliance, audit og tilladelser forbliver konsistente med resten af dit Fabric-miljø.

Relateret indhold

  • Last updated on