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. For mer informasjon, se Supplemental Terms of Use for Microsoft Azure Previews.
Grafdatabaser tilbyr en kraftig måte å modellere og spørre i tilkoblede data på. I motsetning til tradisjonelle relasjonsdatabaser som lagrer data i tabeller, representerer grafdatabaser informasjon som noder (enheter) og kanter (relasjoner), noe som gjør det enklere å utforske komplekse forbindelser og mønstre mer fleksibelt. Denne artikkelen forklarer kjernekonseptene bak grafdatabaser, hvordan grafspørringer fungerer, og skisserer når du bør vurdere å bruke en grafdatabase for arbeidsmengden din. Den sammenligner også grafer i Microsoft Fabric med frittstående grafdatabasedistribusjoner.
Den mest brukte typen grafdatabase implementerer modellen for merkede egenskapsgrafer (LPG): 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 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 fornavn, etternavn og alder.
- Kanter representerer hvordan enhetene er forbundet, 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. 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, for eksempel det stadig mer vedtatte Graph Query Language (GQL), for å beskrive disse traversene 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.
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 samsvarer tett med domener der forbindelser driver verdi, slik som:
- Sosiale nettverk
- Kunnskapsgrafer
- Anbefalingssystemer
- Svindel- og risikonettverk
- Nettverks- og IT-topologi
- 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:
- 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 graf 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 Graph 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, integrasjon av BI og AI, samt 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 samsvar, revisjon og tillatelser forblir konsistente med resten av Fabric-miljøet ditt.