Graph gegevensmodelleren voor Azure Cosmos DB Gremlin-API

  • Artikel
  • 5 minuten om te lezen

VAN TOEPASSING OP: Gremlin-API

Het volgende document is ontworpen om aanbevelingen voor het modelleren van grafiekgegevens te bieden. Deze stap is essentieel om de schaalbaarheid en prestaties van een grafiekdatabasesysteem te garanderen naarmate de gegevens zich ontwikkelen. Een efficiënt gegevensmodel is vooral belangrijk bij 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 gegevens van één entiteit op te halen in meerdere queryaanvragen.
  • Er is een goed begrip van de lees- en schrijfvereisten voor het databasesysteem. Deze vereisten zijn richtlijnen voor de optimalisaties die nodig zijn voor het grafiekgegevensmodel.
  • De principes van de apache Tinkerpop-eigenschappengrafiekstandaard zijn goed te begrijpen.

Wanneer heb ik een grafiekdatabase nodig?

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

  • De entiteiten zijn sterk verbonden via beschrijvende relaties. Het voordeel in dit scenario is dat de relaties in de opslag worden opgeslagen.
  • Er zijn cyclische relaties of entiteiten waarnaar naar u wordt verwezen. Dit patroon is vaak een uitdaging bij het gebruik van relationele of documentdatabases.
  • Er zijn dynamisch veranderende relaties tussen entiteiten. Dit patroon is met name van toepassing op hiërarchische of structuurgestructurede gegevens met veel niveaus.
  • Er zijn veel-op-veel-relaties tussen entiteiten.
  • Er zijn schrijf- en leesvereisten voor zowel entiteiten als relaties.

Als aan de bovenstaande criteria wordt voldaan, biedt een graafdatabasebenadering 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 graaf is bedoeld om te worden gebruikt voor zware reken- en gegevensverwerkingsworkloads, is het de moeite waard om de Cosmos DB Spark-connector en het gebruik van de GraphX-bibliotheek te verkennen.

Grafiekobjecten gebruiken

De standaard voor de apache Tinkerpop-eigenschapsgrafiek definieert twee typen objecten Hoekingen en Randen.

Hier volgen de best practices 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 standaardwaarde 'hoekpunt' gebruikt.
Hoekpunt properties 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. Lees meer over het partitioneren van grafen.
Edge Id Tekenreeks Uniek afgedwongen per partitie. Standaard automatisch gegenereerd. Randen hoeven doorgaans niet uniek te worden opgehaald door een id.
Edge label Tekenreeks Deze eigenschap wordt gebruikt om het type relatie te definiëren dat twee vertices hebben.
Edge properties 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 ervan automatisch wordt toegewezen op basis van het bronpunt. Meer informatie in het artikel over het partitioneren van grafen.

Richtlijnen voor entiteits- en relatiemodelleer

Hier volgt een reeks richtlijnen voor het benaderen van gegevensmodelleer voor een Azure Cosmos DB gremlin API-grafiekdatabase. In deze richtlijnen wordt ervan uitgenomen dat er een bestaande definitie van een gegevensdomein is en dat er query's voor worden gebruikt.

Notitie

De onderstaande stappen worden weergegeven als aanbevelingen. Het uiteindelijke model moet worden geëvalueerd en getest voordat het wordt overwogen als gereed voor productie. Daarnaast zijn de onderstaande aanbevelingen specifiek voor Azure Cosmos DB gremlin-API-implementatie.

Modellering van de vertices en eigenschappen

De eerste stap voor een grafiekgegevensmodel is om elke geïdentificeerde entiteit toe te wijs aan een hoekpuntobject. Een een-op-een-toewijzing van alle entiteiten aan de vertices moet een eerste stap zijn en kan worden gewijzigd.

Een veelvoorkomende valkuil is het in kaart brengen van eigenschappen van één entiteit als afzonderlijke vertices. Bekijk het onderstaande voorbeeld, waarbij dezelfde entiteit op twee verschillende manieren wordt weergegeven:

  • Eigenschappen op basis van hoekpunt: Bij deze benadering gebruikt de entiteit drie afzonderlijke hoekpuntjes en twee randen om de eigenschappen te beschrijven. Hoewel deze aanpak de redundantie kan verminderen, verhoogt dit de complexiteit van het model. Een toename van de complexiteit van het model kan leiden tot extra latentie, complexiteit van query's en rekenkosten. Dit model kan ook uitdagingen met zich mee met partitioneren.

Entiteitsmodel met vertices voor eigenschappen.

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

Diagram met het Luis-hoekpunt uit het vorige diagram met i d, label en eigenschappen.

Notitie

In de bovenstaande voorbeelden ziet u een vereenvoudigd grafiekmodel om alleen de vergelijking te tonen tussen de twee manieren om entiteitseigenschappen te delen.

Het patroon van ingesloten eigenschappen biedt over het algemeen een beter presterende en schaalbare benadering. De standaardbenadering van een nieuw grafiekgegevensmodel moet zich naar dit patroon vertaken.

Er zijn echter scenario's waarin het verwijzen naar een eigenschap voordelen kan bieden. Bijvoorbeeld: als de eigenschap waarnaar wordt verwezen regelmatig wordt bijgewerkt. Als u een afzonderlijk hoekpunt gebruikt om een eigenschap weer te geven die voortdurend wordt gewijzigd, wordt de hoeveelheid schrijfbewerkingen die nodig zijn voor de update geminimaliseerd.

Modellering van relaties met randrichtingen

Nadat de hoek punten zijn gemodelleerd, kunnen de randen worden toegevoegd om de relaties ertussen 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 traversal wanneer u de out() functie or outE() gebruikt. Het gebruik van deze natuurlijke richting resulteert in een efficiënte bewerking, omdat alle hoek punten worden opgeslagen met hun uitgaande randen.

Als u echter de tegenovergestelde richting van een rand doorkruist met behulp van de functie , resulteert dit altijd in() in een query op verschillende partities. Meer informatie over het partitioneren van grafen. Als het nodig is om voortdurend door de functie te gaan, is het raadzaam om randen in beide richtingen in() toe te voegen.

U kunt de randrichting bepalen met behulp van de .to() of .from() predicaten voor de .addE() Gremlin-stap. Of met behulp van de bulkuitvoerbibliotheek voor gremlin-API.

Notitie

Edge-objecten hebben standaard een richting.

Labelen van relaties

Het gebruik van beschrijvende relatielabels kan de efficiëntie van bewerkingen voor randresolutie verbeteren. Dit patroon kan op de volgende manieren worden toegepast:

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

Voorbeelden van labelen van relaties.

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

Volgende stappen: