Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Anmärkning
Den här funktionen är för närvarande i offentlig förhandsversion. Den här förhandsversionen tillhandahålls utan ett serviceavtal och rekommenderas inte för produktionsarbetsbelastningar. Vissa funktioner kanske inte stöds eller kan vara begränsade. Mer information finns i Supplemental Terms of Use for Microsoft Azure Previews.
En grafdatabas är en typ av databas som representerar information som noder (entiteter) och kanter (relationer) i stället för tabeller och rader. Den här strukturen gör det enkelt att utforska komplexa anslutningar och mönster i dina data.
Den vanligaste typen av grafdatabas implementerar lpg-modellen (labeled property graph): entiteter (noder) och relationer (kanter) kan ha etiketter och egenskaper (nyckel/värde-par). Den här flexibla modellen möjliggör både schema-valfria och schemadrivna design, och det gör att du kan uttrycka komplexa relationer. Eftersom anslutningar lagras explicit som kanter navigerar frågor genom relationer genom att följa kanter i stället för att beräkna dyra sammanfogningar när frågor ställs.
Anmärkning
Exempel i den här artikeln använder diagramdatauppsättningen för sociala nätverksexempel.
Grundläggande begrepp för Graph Database
En grafdatabas organiserar data i tre grundläggande byggstenar:
-
Noder representerar entiteter som personer, produkter eller platser. Noder kan ha etiketter och egenskaper som beskriver deras attribut. En nod kan till exempel
Personha egenskaper somfirstName,lastNameochage. -
Kanter representerar hur entiteterna är anslutna, till exempel
FRIENDS_WITH,PURCHASEDellerLOCATED_IN. Kanter kan också innehålla egenskaper och etiketter för att samla in relationsmetadata. - Egenskaper kopplar information till noder och kanter (till exempel en persons namn eller en kants sedan datum).
Så här fungerar frågehantering mot relationer
Graf-frågor hämtar ansluten information genom att gå från en startnod till dess grannar, sedan deras grannar och så vidare. En traverseringskostnad beror på hur många kanter den berör (det lokala grannskapet), inte datamängdens totala storlek. Denna egenskap gör det naturligt och effektivt att ställa frågor om vägar, anslutningar och mönster – så som vänners vänner, kortaste vägar eller beroenden i flerstegsförlopp.
Graph-databaser använder mönsterbaserade frågespråk, till exempel GQL (Graph Query Language) för att beskriva dessa blädderingar kortfattat. Samma internationella arbetsgrupp som övervakar SQL (ISO/IEC 39075) standardiserar GQL, som justerar graffrågor med etablerade databasstandarder.
Exempel (mönstermatchning med GQL):
MATCH (p:Person {firstName: "Annemarie"})-[:knows]->(friend)-[:likes]->(c:Comment)
RETURN c
ORDER BY c.creationDate
LIMIT 100
Det här mönstret ser ut så här: börja vid Person noden för Annemarie och följ via :knows kanterna till varje vän-nod, och följ sedan :likes kanter till relaterade :Comment noder. Returnera de 100 nyaste kommentarerna sorterade efter deras skapandedatum.
Grafdatamodell och schemaflexibilitet
Diagramdatamodeller är schemaval: du kan arbeta med ett fast schema när du behöver stark styrning eller utveckla modellen när nya nodtyper, relationer eller egenskaper visas. Den här metoden minskar behovet av dataduplicering och gör att teamen kan förena data från flera källor utan omfattande omdesign i förväg. Mer information om datamodellen som används i grafen i Microsoft Fabric finns i Etikettade egenskapsdiagram.
Vanliga användningsområden för grafdatabaser
Graph-databaser ligger nära domäner där anslutningar driver värde, till exempel:
- Sociala nätverk – modellera relationer mellan människor och deras interaktioner
- Kunskapsdiagram – ansluta begrepp, entiteter och fakta för semantisk sökning och resonemang
- Rekommendationssystem – gå igenom användarobjektsinteraktioner för att visa personliga förslag
- Bedrägeri- och risknätverk – identifiera misstänkta mönster mellan konton, transaktioner och enheter
- Nätverks- och IT-topologi – mappa beroenden mellan servrar, tjänster och infrastrukturkomponenter
- Beroendeanalys för leveranskedjan – spåra komponentens ursprung och relationer mellan leverantörer
I dessa scenarier handlar frågor mindre om enskilda poster och mer om hur många entiteter som har samband och interagerar över flera steg.
När du ska överväga en grafdatabas
En grafdatabas passar bra när relationer driver de grundläggande frågor som du behöver besvara. Välj en grafdatabas när:
- Dina primära frågor omfattar sökvägar, stadsdelar och mönster i anslutna data.
- Antalet hopp är variabelt eller inte känt i förväg.
- Du måste kombinera och navigera relationer mellan olika datauppsättningar.
Om du regelbundet ställer den här typen av frågor är en grafmodell en naturlig passform.
Hur grafen i Microsoft Fabric jämförs med fristående grafdatabaser
Att representera dina data som ett diagram och lagra dem i en separat, fristående grafdatabas introducerar ofta ETL (extrahering, transformering, inläsning) och styrningskostnader. Grafen i Microsoft Fabric fungerar däremot direkt på OneLake, vilket minskar eller eliminerar behovet av separata ETL-pipelines och dataduplicering. Tänk på dessa kompromisser:
- Dataförflyttning och duplicering: Fristående grafdatabaser kräver vanligtvis extrahering, transformering och inläsning av data till ett separat lager, vilket ökar komplexiteten och kan leda till duplicerade datamängder. Graph fungerar på OneLake så att du kan modellera och köra frågor mot anslutna data utan att flytta dem.
- Driftskostnader: Fristående grafstackar körs som separata kluster eller tjänster och medför ofta avgifter för inaktiv kapacitet. I grafen använder arbetslaster poolade kapacitetsenheter (CUs) med automatisk nedskalning och centraliserade måttdata, vilket förenklar driften och kan sänka kostnaderna.
- Skalbarhet: Vissa fristående grafdatabaser är beroende av uppskalning eller leverantörsspecifik klustring. Graph är utformat för storskaliga grafer och använder skalbar horisontell partitionering över flera arbetare för att effektivt hantera stordataarbetsbelastningar.
- Verktyg och färdigheter: Leverantörsspecifika grafsystem kan kräva specialiserade språk och separata analysramverk. Graph tillhandahåller enhetlig modellering, standardbaserad frågekörning (GQL), inbyggda grafanalysalgoritmer, BI- och AI-integrering samt undersökande verktyg med låg/ingen kod. Med de här funktionerna kan en bredare uppsättning användare arbeta med anslutna data.
- Styrning och säkerhet: Separata diagramdistributioner behöver oberoende styrnings- och säkerhetsinställningar. Graph använder OneLake-styrning, ursprungsdata och arbetsytans rollbaserad åtkomstkontroll (RBAC) för att säkerställa att efterlevnad, granskning och behörigheter förblir konsekventa med resten av din Fabric-miljö.