Bemærk
Adgang til denne side kræver godkendelse. Du kan prøve at logge på eller ændre mapper.
Adgang til denne side kræver godkendelse. Du kan prøve at ændre mapper.
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.
Grafdatabaser tilbyder en kraftfuld måde at modellere og forespørge forbundne data på. I modsætning til traditionelle relationelle databaser, der gemmer data i tabeller, repræsenterer grafdatabaser information som noder (enheder) og kanter (relationer), hvilket gør det lettere at udforske komplekse forbindelser og mønstre mere fleksibelt. Denne artikel forklarer kernekoncepterne bag grafdatabaser, hvordan grafforespørgsler fungerer, og skitserer, hvornår du bør overveje at bruge en grafdatabase til din arbejdsbyrde. Den sammenligner også Fabric Graph med selvstændige grafdatabase-implementeringer.
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 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 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 fornavn, efternavn og alder.
- Kanter repræsenterer, hvordan enhederne er forbundet, for eksempel 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 (for eksempel 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. 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 det stadig mere vedtagne Graph Query Language (GQL), til at beskrive disse krydsninger 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.
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 tilpasset domæner, hvor forbindelser driver værdi, såsom:
- Sociale netværk
- Vidensgrafer
- Anbefalingssystemer
- Svindel- og risikonetværk
- Netværks- og IT-topologi
- Forsyningskædeafhængighedsanalyse
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 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 Fabric Graph 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 opererer Graph 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. Grafarbejdsbelastninger i Graph forbruger pooled capacity units (CUs) 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, integration af BI og AI 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 rollebaseret adgangskontrol (RBAC), så compliance, revision og tilladelser forbliver konsistente med resten af dit Fabric-miljø.