Merk
Tilgang til denne siden krever autorisasjon. Du kan prøve å logge på eller endre kataloger.
Tilgang til denne siden krever autorisasjon. Du kan prøve å endre kataloger.
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. Hvis du vil ha mer informasjon, kan du se Supplerende vilkår for bruk for Microsoft Azure-forhåndsversjoner.
En grafdatabase modellerer data som et nettverk av tilkoblede enheter og relasjoner. Den mest brukte typen grafdatabase implementerer den merkede egenskapsgrafmodellen : enheter (noder) og relasjoner (kanter) kan ha etiketter og egenskaper (nøkkel-verdi-par). Denne fleksible modellen muliggjør både skjemavalgfrie og skjemadrevne utforminger, og den lar deg uttrykke rik semantikk. Fordi tilkoblinger lagres eksplisitt som kanter, krysser spørringer relasjoner ved å følge kanter i stedet for å beregne dyre sammenføyninger på spørringstidspunktet.
Viktig!
Denne artikkelen bruker utelukkende eksempeldatasett for sosiale nettverk.
Kjernekonsepter for grafdatabase
- Noder representerer ting som mennesker, produkter eller steder. Noder kan ha etiketter og egenskaper som beskriver attributtene deres.
- Kanter representerer hvordan disse tingene er koblet sammen, for eksempel FRIENDS_WITH, KJØPT eller LOCATED_IN. Kanter kan også inneholde egenskaper og etiketter for å kode relasjonsmetadata.
- Egenskaper knytter detaljer til noder og kanter (for eksempel en persons navn eller en kants siden-dato). Fordi relasjoner lagres eksplisitt som kanter, navigerer spørringer i grafen ved å følge tilkoblinger i stedet for å beregne dem på spørringstidspunktet.
Slik fungerer spørring av relasjoner
Grafspørringer henter tilkoblet informasjon ved å gå fra en startnode til naboene, deretter til naboene og så videre. Innsatsen en traversering utfører, er knyttet til antall kanter den berører (det lokale nabolaget), ikke den totale størrelsen på datasettet. Dette gjør spørsmål om baner, forbindelser og mønstre – for eksempel venners venner, korteste veier eller multi-hop-avhengigheter – naturlige og effektive å uttrykke.
Grafdatabaser bruker mønsterbaserte spørringsspråk, for eksempel det stadig mer vedtatte Graph Query Language (GQL), for å beskrive disse traversene kortfattet. GQL blir standardisert av den samme internasjonale arbeidsgruppen som fører tilsyn med SQL (ISO/IEC 39075), og tilpasser grafspørringer til 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 lyder: starter ved Person-noden for Annemarie, følger :knows kanter til hver venn, deretter følger :likes kanter til relaterte :Comment noder, og returnerer de 100 nyeste kommentarene.
Modellering og skjema
Grafdatamodeller er skjemavalgfrie: Du kan arbeide med et fast skjema når du trenger sterk styring, eller utvikle modellen etter hvert som nye nodetyper, relasjoner eller egenskaper vises. Denne tilnærmingen reduserer behovet for dataduplisering og lar team forene data fra flere kilder uten tung forhåndsdesign.
Vanlige bruksområder for grafdatabaser
Grafdatabaser stemmer tett overens med domener der tilkoblinger driver verdi, for eksempel sosiale nettverk, kunnskapsgrafer, anbefalingssystemer, svindel- og risikonettverk, nettverks- og IT-topologi og forsyningskjedeavhengighetsanalyse. 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
Velg en grafdatabase når hovedspørsmålene dine involverer baner, nabolag og mønstre i tilkoblede data; når antall humle er variabelt eller ikke kjent på forhånd; eller når du trenger å kombinere og navigere i relasjoner på tvers av ulike datasett. Hvis det er spørsmålene du må svare på gjentatte ganger, er en grafmodell en naturlig passform.
Hva med ETL
Å representere dataene dine som en graf og lagre dem i en separat, frittstående grafdatabase introduserer ofte ETL og styringskostnader. Grafen i Microsoft Fabric fungerer derimot direkte på OneLake, noe som reduserer eller eliminerer behovet for separate ETL-datasamlebånd og dataduplisering. Vurder disse avveiningene:
- Databevegelse og duplisering: Frittstående grafdatabaser krever vanligvis at data hentes ut, transformeres og lastes inn (ETL) i en separat lagring, noe som øker kompleksiteten og kan føre til dupliserte datasett. Graph i Microsoft Fabric fungerer på OneLake, slik at du kan modellere og spørre etter tilkoblede data uten å flytte dem.
- Driftskostnader: Frittstående grafstabler kjører som separate klynger eller tjenester og har ofte kostnader for ledig kapasitet. Graf-arbeidsbelastninger i Fabric bruker samlede kapasitetsenheter (CU-er) med automatisk nedskalering og sentraliserte måledata, noe som forenkler driften og kan redusere kostnadene.
- Skalerbarhet: Noen frittstående grafdatabaser er avhengige av oppskalering eller leverandørspesifikk klynging. Graph i Microsoft Fabric er utformet for store grafer og bruker utskalerbar fragmentering på tvers av flere arbeidere for å håndtere store dataarbeidsbelastninger effektivt.
- Verktøy og ferdigheter: Leverandørspesifikke grafsystemer kan kreve spesialiserte språk og separate analyserammeverk. Graph i Microsoft Fabric gir enhetlig modellering, standardbasert spørring (GQL), innebygde grafanalysealgoritmer, BI- og AI-integrasjon og lav-/ingen kode-utforskende verktøy slik at et bredere sett med brukere kan jobbe med tilkoblede data.
- Styring og sikkerhet: Separate grafutrullinger trenger uavhengig styring og sikkerhetsoppsett. Graph i Microsoft Fabric bruker OneLake-styring, avstamming og rollebasert tilgangskontroll (RBAC) for arbeidsområdet, slik at samsvar, overvåking og tillatelser forblir konsistente med resten av Fabric-miljøet.