Grafiekgegevensmodellering met Azure Cosmos DB voor Apache Gremlin

VAN TOEPASSING OP: Gremlin

Dit artikel bevat aanbevelingen voor het gebruik van grafiekgegevensmodellen. Deze best practices zijn essentieel voor het waarborgen van de schaalbaarheid en prestaties van een grafiekdatabasesysteem naarmate de gegevens zich ontwikkelen. Een efficiënt gegevensmodel is met name belangrijk voor grootschalige grafieken.

Vereisten

Het proces dat in deze handleiding wordt beschreven, is gebaseerd op de volgende veronderstellingen:

  • De entiteiten in de probleemruimte worden geïdentificeerd. Deze entiteiten zijn bedoeld om atomisch te worden gebruikt voor elke aanvraag. Met andere woorden, het databasesysteem is niet ontworpen om de gegevens van één entiteit op te halen in meerdere queryaanvragen.
  • Er is inzicht in lees- en schrijfvereisten voor het databasesysteem. Deze vereisten zijn van toepassing op de optimalisaties die nodig zijn voor het grafiekgegevensmodel.
  • De principes van de apache Tinkerpop-eigenschapsgrafiekstandaard zijn goed begrepen.

Wanneer heb ik een grafiekdatabase nodig?

Een grafiekdatabaseoplossing kan optimaal worden gebruikt als de entiteiten en relaties in een gegevensdomein een van de volgende kenmerken hebben:

  • De entiteiten zijn sterk verbonden via beschrijvende relaties. Het voordeel van dit scenario is dat de relaties behouden blijven in de opslag.
  • Er zijn cyclische relaties of entiteiten waarnaar zelf wordt verwezen. Dit patroon is vaak een uitdaging wanneer u relationele databases of documentdatabases gebruikt.
  • Er zijn dynamisch veranderende relaties tussen entiteiten. Dit patroon is met name van toepassing op hiërarchische of structuurgestructureerde gegevens met veel niveaus.
  • Er zijn veel-op-veel-relaties tussen entiteiten.
  • Er zijn vereisten voor schrijven en lezen voor zowel entiteiten als relaties.

Als aan de bovenstaande criteria wordt voldaan, biedt een grafiekdatabasebenadering waarschijnlijk voordelen voor querycomplexiteit, schaalbaarheid van gegevensmodellen en queryprestaties.

De volgende stap is om te bepalen of de grafiek wordt gebruikt voor analytische of transactionele doeleinden. Als de grafiek bedoeld is om te worden gebruikt voor zware reken- en gegevensverwerkingsworkloads, is het de moeite waard om de Cosmos DB Spark-connector en de GraphX-bibliotheek te verkennen.

Grafiekobjecten gebruiken

De apache Tinkerpop-eigenschapsgrafiekstandaard definieert twee typen objecten: hoekpunten en randen.

Hier volgen aanbevolen procedures voor de eigenschappen in de grafiekobjecten:

Object Eigenschap Type Opmerkingen
Hoekpunt Id Tekenreeks Uniek afgedwongen per partitie. Als er geen waarde wordt opgegeven bij het invoegen, wordt een automatisch gegenereerde GUID opgeslagen.
Hoekpunt Label Tekenreeks Deze eigenschap wordt gebruikt om het type entiteit te definiëren dat het hoekpunt vertegenwoordigt. Als er geen waarde wordt opgegeven, wordt een standaardwaardehoekpunt gebruikt.
Hoekpunt Eigenschappen Tekenreeks, booleaanse waarde, numeriek Een lijst met afzonderlijke eigenschappen die zijn opgeslagen als sleutel-waardeparen in elk hoekpunt.
Hoekpunt Partitiesleutel Tekenreeks, booleaanse waarde, numeriek Deze eigenschap definieert waar het hoekpunt en de uitgaande randen worden opgeslagen. Meer informatie over grafiekpartitionering.
Edge Id Tekenreeks Uniek afgedwongen per partitie. Standaard automatisch gegenereerd. Randen hoeven meestal niet uniek te worden opgehaald door een id.
Edge Label Tekenreeks Deze eigenschap wordt gebruikt om het type relatie te definiëren dat twee hoekpunten hebben.
Edge Eigenschappen Tekenreeks, booleaanse waarde, numeriek Een lijst met afzonderlijke eigenschappen die zijn opgeslagen als sleutel-waardeparen in elke rand.

Notitie

Voor randen is geen partitiesleutelwaarde vereist, omdat de waarde automatisch wordt toegewezen op basis van hun bronhoekpunt. Zie Een gepartitioneerde grafiek gebruiken in Azure Cosmos DB voor meer informatie.

Richtlijnen voor entiteits- en relatiemodellering

De volgende richtlijnen helpen u bij het benaderen van gegevensmodellering voor een Azure Cosmos DB voor Apache Gremlin-grafiekdatabase . In deze richtlijnen wordt ervan uitgegaan dat er een bestaande definitie van een gegevensdomein is en dat er query's voor worden uitgevoerd.

Notitie

De volgende stappen worden weergegeven als aanbevelingen. U moet het uiteindelijke model evalueren en testen voordat u het beschouwt als productieklaar. Daarnaast zijn de aanbevelingen specifiek voor de Gremlin-API-implementatie van Azure Cosmos DB.

Hoekpunten en eigenschappen modelleren

De eerste stap voor een grafiekgegevensmodel bestaat uit het toewijzen van elke geïdentificeerde entiteit aan een hoekpuntobject. Een een-op-een-toewijzing van alle entiteiten aan hoekpunten moet een eerste stap zijn en kan worden gewijzigd.

Een veelvoorkomende valkuil is het toewijzen van eigenschappen van één entiteit als afzonderlijke hoekpunten. Bekijk het volgende voorbeeld, waarbij dezelfde entiteit op twee verschillende manieren wordt weergegeven:

  • Eigenschappen op basis van hoekpunten: In deze benadering gebruikt de entiteit drie afzonderlijke hoekpunten en twee randen om de eigenschappen te beschrijven. Hoewel deze aanpak de redundantie kan verminderen, neemt de complexiteit van het model toe. Een toename van de complexiteit van het model kan leiden tot extra latentie, querycomplexiteit en rekenkosten. Dit model kan ook problemen opleveren bij het partitioneren.

    Diagram van entiteitsmodel met hoekpunten voor eigenschappen.

  • In eigenschappen ingesloten hoekpunten: deze benadering maakt gebruik van de lijst met sleutel-waardeparen om alle eigenschappen van de entiteit in een hoekpunt weer te geven. Deze benadering vermindert de complexiteit van het model, wat leidt tot eenvoudigere query's en kostenefficiënte doorkruisingen.

    Diagram van het Luis-hoekpunt uit het vorige diagram met id, label en eigenschappen.

Notitie

In de voorgaande diagrammen wordt een vereenvoudigd grafiekmodel weergegeven dat alleen de twee manieren vergelijkt om entiteitseigenschappen te verdelen.

Het in eigenschappen ingesloten hoekpuntenpatroon biedt over het algemeen een beter presterende en schaalbare benadering. De standaardbenadering van een nieuw grafiekgegevensmodel moet dit patroon benaderen.

Er zijn echter scenario's waarin het verwijzen naar een eigenschap voordelen kan bieden. Bijvoorbeeld als de eigenschap waarnaar wordt verwezen regelmatig wordt bijgewerkt. Gebruik een afzonderlijk hoekpunt om een eigenschap te vertegenwoordigen die voortdurend verandert om de hoeveelheid schrijfbewerkingen die nodig zijn voor de update te minimaliseren.

Relatiemodellen met randrichtingen

Nadat de hoekpunten zijn gemodelleerd, kunnen de randen worden toegevoegd om de relaties tussen de hoekpunten aan te geven. Het eerste aspect dat moet worden geëvalueerd, is de richting van de relatie.

Edge-objecten hebben een standaardrichting die wordt gevolgd door een doorkruising wanneer u de out() functies of outE() gebruikt. Het gebruik van deze natuurlijke richting resulteert in een efficiënte bewerking, omdat alle hoekpunten worden opgeslagen met hun uitgaande randen.

Als u echter in de tegenovergestelde richting van een rand doorkruist met behulp van de in() functie, resulteert dit altijd in een query voor meerdere partities. Meer informatie over grafiekpartitionering. Als u voortdurend moet doorkruisen met behulp van de in() functie, is het raadzaam om randen in beide richtingen toe te voegen.

U kunt de richting van de rand bepalen met behulp van de .to().from() of met de .addE() stap Gremlin. Of met behulp van de bulkexecutorbibliotheek voor de Gremlin-API.

Notitie

Edge-objecten hebben standaard een richting.

Relatielabels

Het gebruik van beschrijvende relatielabels kan de efficiëntie van randomzettingsbewerkingen verbeteren. U kunt dit patroon op de volgende manieren toepassen:

  • Gebruik niet-algemene termen om een relatie te labelen.
  • Koppel het label van het bronhoekpunt aan het label van het doelhoekpunt met de naam van de relatie.

Diagram van voorbeelden van relatielabels.

Hoe specifieker het label dat de traverser gebruikt om de randen te filteren, hoe beter. Deze beslissing kan ook een aanzienlijk effect hebben op de querykosten. U kunt de querykosten op elk gewenst moment evalueren met behulp van de stap executionProfile.

Volgende stappen