Delen via


Wat is een grafiekdatabase?

Opmerking

Deze functie is momenteel beschikbaar als openbare preview-versie. Deze preview wordt geleverd zonder een service level agreement en wordt niet aanbevolen voor productieworkloads. Bepaalde functies worden mogelijk niet ondersteund of hebben mogelijk beperkte mogelijkheden. Zie Aanvullende gebruiksvoorwaarden voor Microsoft Azure previews voor meer informatie.

Grafiekdatabases bieden een krachtige manier om verbonden gegevens te modelleren en er query's op uit te voeren. In tegenstelling tot traditionele relationele databases die gegevens in tabellen opslaan, vertegenwoordigen grafiekdatabases informatie als knooppunten (entiteiten) en randen (relaties), waardoor het gemakkelijker is om complexe verbindingen en patronen flexibeler te verkennen. In dit artikel worden de belangrijkste concepten van grafiekdatabases uitgelegd, hoe grafiekquery's werken en wordt beschreven wanneer u een grafiekdatabase voor uw workload kunt gebruiken. Fabric Graph wordt ook vergeleken met zelfstandige grafiekdatabaseimplementaties.

Het meest gebruikte type grafiekdatabase implementeert het model van de gelabelde eigenschapsgrafiek (LNG): entiteiten (knooppunten) en relaties (randen) kunnen labels en eigenschappen (sleutel-waardeparen) bevatten. Met dit flexibele model kunt u zowel schema-optionele als schemagestuurde ontwerpen uitvoeren en kunt u uitgebreide semantiek uitdrukken. Omdat verbindingen expliciet als randen worden opgeslagen, doorlopen query's relaties door de randen te volgen in plaats van dure joins tijdens het uitvoeren van de query's te berekenen.

Belangrijk

Dit artikel gebruikt uitsluitend de voorbeeldgrafiekdataset van sociale netwerken.

Basisconcepten voor graph-databases

  • Knooppunten vertegenwoordigen entiteiten zoals personen, producten of plaatsen. Knooppunten kunnen labels en eigenschappen hebben die hun kenmerken beschrijven. Een knooppunt Persoon kan bijvoorbeeld eigenschappen hebben, zoals firstName, lastName en leeftijd.
  • Kanten geven aan hoe de entiteiten zijn verbonden, bijvoorbeeld FRIENDS_WITH, GEKOCHT of LOCATED_IN. Randen kunnen ook eigenschappen en labels bevatten om metagegevens van relaties te coderen.
  • Eigenschappen voegen details toe aan knooppunten en randen (bijvoorbeeld de naam van een persoon of de datum van een rand). Omdat relaties expliciet als randen worden opgeslagen, navigeren query's in de grafiek door verbindingen te volgen in plaats van ze te berekenen tijdens de query.

Hoe relaties opvragen werkt

Grafiekquery's halen verbonden informatie op door van een beginknooppunt naar de buren te gaan, vervolgens naar hun buren, enzovoort. De inspanning die een traversal uitvoert, is gekoppeld aan het aantal randen dat wordt aangeraakt (de lokale omgeving), niet de totale grootte van de dataset. Dit kenmerk maakt vragen over paden, verbindingen en patronen, zoals vrienden van vrienden, kortste paden of afhankelijkheden met meerdere hops, natuurlijk en efficiënt om uit te drukken.

Grafiekdatabases maken gebruik van querytalen op basis van patronen, zoals de steeds vaker aangenomen Graph Query Language (GQL) om deze doorkruisingen beknopt te beschrijven. Dezelfde internationale werkgroep die toezicht houdt op SQL (ISO/IEC 39075) is het standaardiseren van GQL, waarmee grafiekquery's worden afgestemd op vastgestelde databasestandaarden.

Voorbeeld (patroonkoppeling met GQL):

MATCH (p:Person {firstName: "Annemarie"})-[:knows]->(friend)-[:likes]->(c:Comment)
RETURN c
ORDER BY c.creationDate
LIMIT 100

Dit patroon wordt gelezen als: begin bij het Persoon-knooppunt van Annemarie, volg :knows randen naar elk vriendknooppunt en volg vervolgens :likes randen naar gerelateerde :Comment-knooppunten. Retourneer de 100 nieuwste van deze opmerkingen op basis van de aanmaakdatum.

Modellering en schema

Grafiekgegevensmodellen zijn schema-optioneel: u kunt werken met een vast schema wanneer u een sterk beheer nodig hebt of het model ontwikkelt als nieuwe knooppunttypen, relaties of eigenschappen worden weergegeven. Deze aanpak vermindert de noodzaak van gegevensduplicatie en stelt teams in staat om gegevens uit meerdere bronnen samen te voegen zonder dat ze vooraf opnieuw hoeven te worden ontworpen.

Algemene toepassingen voor grafiekdatabases

Grafiekdatabases zijn nauw afgestemd op domeinen waarin de waarde van verbindingen wordt aangedreven, zoals:

  • Sociale netwerken
  • Kennisgrafieken
  • Aanbevelingssystemen
  • Fraude- en risiconetwerken
  • Netwerk- en IT-topologie
  • Analyse van afhankelijkheid van toeleveringsketen

In deze scenario's gaan de vragen minder over individuele records en meer over het aantal entiteiten die verband houden met en interageren over verschillende tussenstappen.

Wanneer moet u een grafiekdatabase overwegen

Kies een grafiekdatabase wanneer:

  • Uw belangrijkste vragen zijn paden, buurten en patronen in verbonden gegevens.
  • Het aantal hops is variabel of niet van tevoren bekend.
  • U moet relaties combineren en navigeren in verschillende gegevenssets.

Als u dit soort vragen regelmatig stelt, is een grafiekmodel een natuurlijke pasvorm.

Hoe Fabric Graph zich verhoudt tot zelfstandige grafiekdatabases

Het vertegenwoordigen van uw gegevens als een grafiek en deze opslaan in een afzonderlijke, zelfstandige grafiekdatabase introduceert vaak ETL (extraheren, transformeren, laden) en governance-overhead. Graph werkt daarentegen rechtstreeks op OneLake, waardoor de noodzaak voor afzonderlijke ETL-pijplijnen en gegevensduplicatie wordt verminderd of geëlimineerd. Houd rekening met deze compromissen:

  • Gegevensverplaatsing en -duplicatie: zelfstandige grafiekdatabases vereisen doorgaans het extraheren, transformeren en laden van gegevens in een afzonderlijk archief, wat de complexiteit verhoogt en kan leiden tot dubbele gegevenssets. Graph werkt op OneLake, zodat u verbonden gegevens kunt modelleren en er query's op kunt uitvoeren zonder deze te verplaatsen.
  • Operationele kosten: zelfstandige grafiekstacks worden uitgevoerd als afzonderlijke clusters of services en dragen vaak niet-actieve capaciteitskosten met zich mee. Graph-workloads in Graph verbruiken poolcapaciteitseenheden (CA's) met automatische schaal omlaag en gecentraliseerde metrische gegevens, waardoor bewerkingen worden vereenvoudigd en de kosten kunnen worden verlaagd.
  • Schaalbaarheid: sommige zelfstandige grafiekdatabases zijn afhankelijk van omhoog schalen of leverancierspecifieke clustering. Graph is ontworpen voor grootschalige grafieken en maakt gebruik van scale-out sharding voor meerdere werkrollen om big data-workloads efficiënt te verwerken.
  • Hulpprogramma's en vaardigheden: Leverancierspecifieke grafieksystemen kunnen gespecialiseerde talen en afzonderlijke analyseframeworks vereisen. Graph biedt geïntegreerde modellering, op standaarden gebaseerde query's (GQL), ingebouwde graph analytics-algoritmen, BI- en AI-integratie en verkennende hulpprogramma's met weinig/geen code. Met deze mogelijkheden kan een bredere set gebruikers werken met verbonden gegevens.
  • Governance en beveiliging: afzonderlijke grafiekimplementaties hebben onafhankelijke governance- en beveiligingsinstellingen nodig. Graph gebruikt OneLake-governance, overerving en op rollen gebaseerd toegangsbeheer (RBAC) voor werkruimten, zodat naleving, controle en machtigingen consistent blijven met de rest van uw Fabric-omgeving.