Anteckning
Å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 Kompletterande villkor för användning av Microsoft Azure-förhandsversioner.
En grafdatabas modellerar data som ett nätverk av anslutna entiteter och relationer. Den vanligaste typen av grafdatabas implementerar den märkta egenskapsgrafmodellen : 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 omfattande semantik. 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.
Grundläggande begrepp för Graph Database
- Noder representerar saker som personer, produkter eller platser. Noder kan ha etiketter och egenskaper som beskriver deras attribut.
- Kanter representerar hur dessa saker är anslutna, till exempel FRIENDS_WITH, KÖPT eller LOCATED_IN. Kanter kan också innehålla egenskaper och etiketter för att koda relationsmetadata.
- Egenskaper kopplar information till noder och kanter (till exempel en persons namn eller en kants sedan datum). Eftersom relationer lagras explicit som kanter navigerar frågorna i diagrammet genom att följa anslutningar i stället för att beräkna dem vid frågetillfället.
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. Den ansträngning som en bläddering utför är kopplad till det antal kanter som den berör (det lokala grannskapet), inte datamängdens totala storlek. Detta ger frågor om sökvägar, anslutningar och mönster – till exempel vänners vänner, kortaste sökvägar eller multihoppsberoenden – naturliga och effektiva att uttrycka.
Graph-databaser använder mönsterbaserade frågespråk, till exempel det alltmer använda Graph Query Language (GQL) för att beskriva dessa blädderingar kortfattat. GQL standardiseras av samma internationella arbetsgrupp som övervakar SQL (ISO/IEC 39075) och justerar graffrågor med etablerade databasstandarder.
Exempel (mönstermatchning med GQL):
MATCH (p:Person {name: "Alice"})-[:FRIENDS_WITH]->(friend)-[:PURCHASED]->(o:Order)
RETURN o
Det här mönstret ser ut så här: Börja vid Person-noden för Alice, följ FRIENDS_WITH-kanter till varje vän, följ sedan KÖPT-kanter till relaterade beställningsnoder och returnera dessa beställningar.
Modellering och schema
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.
Vanliga användningsområden för grafdatabaser
Grafdatabaser är nära anpassade till domäner där anslutningar driver värde, till exempel sociala nätverk, kunskapsdiagram, rekommendationssystem, bedrägeri- och risknätverk, nätverks- och IT-topologi samt beroendeanalys av leveranskedjan. 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
Välj en grafdatabas när dina primära frågor omfattar sökvägar, stadsdelar och mönster i anslutna data. när antalet hopp är variabelt eller inte känt i förväg. eller när du behöver kombinera och navigera relationer mellan olika datauppsättningar. Om det är de frågor du behöver besvara upprepade gånger är en grafmodell en naturlig passform.
Hur är det med ETL
Att representera dina data som ett diagram och lagra dem i en separat, fristående grafdatabas introducerar ofta ETL 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 (ETL) till ett separat lager, vilket ökar komplexiteten och kan leda till duplicerade datamängder. Graph i Microsoft Fabric 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. Graph-arbetsbelastningar i Fabric-miljö förbrukar poolade kapacitetsenheter (CUs) med automatisk nedskalning och centraliserade mått, vilket förenklar åtgärder och kan sänka kostnaderna.
- Skalbarhet: Vissa fristående grafdatabaser är beroende av uppskalning eller leverantörsspecifik klustring. Graph i Microsoft Fabric ä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 i Microsoft Fabric tillhandahåller enhetlig modellering, standardbaserad frågespråk (GQL), inbyggda algoritmer för grafanalys, BI- och AI-integrering och verktyg för utforskning med låg eller ingen kod, så att ett bredare spektrum av användare kan arbeta med anslutna data.
- Styrning och säkerhet: Separata grafdistributioner behöver oberoende styrnings- och säkerhetsinställningar. Graph i Microsoft Fabric använder OneLake-styrning, datalinje och workspace-rollbaserad åtkomstkontroll (RBAC) för att efterlevnad, granskning och behörigheter förblir konsekventa med resten av din Fabric-miljö.