Diagramdatamodellering med Azure Cosmos DB för Apache Gremlin

  • Artikel

GÄLLER FÖR: Gremlin

Den här artikeln innehåller rekommendationer för användning av diagramdatamodeller. Dessa metodtips är viktiga för att säkerställa skalbarhet och prestanda för ett grafdatabassystem allt eftersom data utvecklas. En effektiv datamodell är särskilt viktig för storskaliga grafer.

Krav

Processen som beskrivs i den här guiden baseras på följande antaganden:

  • Entiteterna i problemutrymmet identifieras. Dessa entiteter är avsedda att användas atomiskt för varje begäran. Databassystemet är med andra ord inte utformat för att hämta en enskild entitets data i flera frågebegäranden.
  • Det finns en förståelse för läs- och skrivkraven för databassystemet. Dessa krav vägleder de optimeringar som behövs för grafdatamodellen.
  • Principerna för Apache Tinkerpop-egenskapsgrafstandarden är väl förstådda.

När behöver jag en grafdatabas?

En grafdatabaslösning kan användas optimalt om entiteterna och relationerna i en datadomän har någon av följande egenskaper:

  • Entiteterna är starkt anslutna via beskrivande relationer. Fördelen i det här scenariot är att relationerna bevaras i lagringen.
  • Det finns cykliska relationer eller själv refererade entiteter. Det här mönstret är ofta en utmaning när du använder relations- eller dokumentdatabaser.
  • Det finns dynamiskt föränderliga relationer mellan entiteter . Det här mönstret gäller särskilt för hierarkiska eller trädstrukturerade data med många nivåer.
  • Det finns många-till-många-relationer mellan entiteter.
  • Det finns skriv- och läskrav för både entiteter och relationer.

Om ovanstående villkor uppfylls ger en grafdatabasmetod sannolikt fördelar för frågekomplexitet, skalbarhet för datamodeller och frågeprestanda.

Nästa steg är att avgöra om grafen ska användas för analys- eller transaktionsändamål. Om diagrammet är avsett att användas för tunga arbetsbelastningar för beräkning och databearbetning är det värt att utforska Cosmos DB Spark-anslutningsappen och GraphX-biblioteket.

Så här använder du grafobjekt

Apache Tinkerpop-egenskapsgrafstandarden definierar två typer av objekt: hörn och kanter.

Följande är metodtips för egenskaperna i grafobjekten:

Objekt Egenskap Typ Kommentarer
Vertex ID Sträng Unikt framtvingad per partition. Om ett värde inte anges vid infogning lagras ett automatiskt genererat GUID.
Vertex Etikett Sträng Den här egenskapen används för att definiera vilken typ av entitet som hörnet representerar. Om ett värde inte anges används ett standardvärdehörn .
Vertex Egenskaper Sträng, booleskt, numeriskt En lista över separata egenskaper som lagras som nyckel/värde-par i varje hörn.
Vertex Partitionsnyckel Sträng, booleskt, numeriskt Den här egenskapen definierar var brytpunkten och dess utgående kanter lagras. Läs mer om grafpartitionering.
Edge ID Sträng Unikt framtvingad per partition. Genereras automatiskt som standard. Kanter behöver vanligtvis inte hämtas unikt med ett ID.
Edge Etikett Sträng Den här egenskapen används för att definiera vilken typ av relation som två hörn har.
Edge Egenskaper Sträng, booleskt, numeriskt En lista över separata egenskaper som lagras som nyckel/värde-par i varje kant.

Anteckning

Kanter kräver inte ett partitionsnyckelvärde, eftersom värdet tilldelas automatiskt baserat på deras källhörn. Läs mer i Använda en partitionerad graf i Azure Cosmos DB.

Riktlinjer för entitets- och relationsmodellering

Följande riktlinjer hjälper dig att hantera datamodellering för en Azure Cosmos DB för Apache Gremlin-grafdatabas . Dessa riktlinjer förutsätter att det finns en befintlig definition av en datadomän och frågor för den.

Anteckning

Följande steg presenteras som rekommendationer. Du bör utvärdera och testa den slutliga modellen innan du överväger den som produktionsklar. Dessutom är rekommendationerna specifika för Azure Cosmos DB:s Gremlin API-implementering.

Modellering av hörn och egenskaper

Det första steget för en grafdatamodell är att mappa varje identifierad entitet till ett hörnobjekt. En en-till-en-mappning av alla entiteter till hörn bör vara ett första steg och kan komma att ändras.

En vanlig fallgrop är att mappa egenskaper för en enda entitet som separata hörn. Tänk dig följande exempel, där samma entitet representeras på två olika sätt:

  • Hörnbaserade egenskaper: I den här metoden använder entiteten tre separata hörn och två kanter för att beskriva dess egenskaper. Även om den här metoden kan minska redundansen ökar modellens komplexitet. En ökning av modellkomplexiteten kan resultera i ökad svarstid, frågekomplexitet och beräkningskostnader. Den här modellen kan också innebära utmaningar vid partitionering.

    Diagram över entitetsmodell med hörn för egenskaper.

  • Egenskapsbäddade hörn: Den här metoden utnyttjar nyckel/värde-parlistan för att representera alla egenskaper för entiteten i ett hörn. Den här metoden minskar modellens komplexitet, vilket leder till enklare frågor och mer kostnadseffektiva blädderingar.

    Diagram över Luis-hörnet från föregående diagram med ID, etikett och egenskaper.

Anteckning

Föregående diagram visar en förenklad grafmodell som bara jämför de två sätten att dela upp entitetsegenskaper.

Mönstret för egenskapsbäddade hörn ger vanligtvis en mer högpresterande och skalbar metod. Standardmetoden för en ny diagramdatamodell bör dras mot det här mönstret.

Det finns dock scenarier där hänvisning till en egenskap kan ge fördelar. Om den refererade egenskapen till exempel uppdateras ofta. Använd ett separat hörn för att representera en egenskap som ständigt ändras för att minimera mängden skrivåtgärder som krävs för uppdateringen.

Relationsmodeller med kantriktningar

När hörnen har modellerats kan kanterna läggas till för att ange relationerna mellan dem. Den första aspekten som behöver utvärderas är relationens riktning.

Edge-objekt har en standardriktning som följs av en bläddering när du använder out() funktionerna eller outE() . Den här naturliga riktningen resulterar i en effektiv åtgärd, eftersom alla hörn lagras med utgående kanter.

Att bläddra i motsatt riktning mot en kant med hjälp in() av funktionen resulterar dock alltid i en fråga mellan partitioner. Läs mer om grafpartitionering. Om du ständigt behöver bläddra med hjälp av in() funktionen rekommenderar vi att du lägger till kanter i båda riktningarna.

Du kan fastställa kantriktningen med hjälp .to() av eller .from() predikat med .addE() Gremlin-steget. Eller genom att använda massexekutorbiblioteket för Gremlin API.

Anteckning

Kantobjekt har som standard en riktning.

Relationsetiketter

Om du använder beskrivande relationsetiketter kan du förbättra effektiviteten för gränsmatchningsåtgärder. Du kan använda det här mönstret på följande sätt:

  • Använd icke-generiska termer för att märka en relation.
  • Associera etiketten för källhörnet med etiketten för målhörnet med relationsnamnet.

Diagram över exempel på relationsetiketter.

Ju mer specifik etikett som bläddraren använder för att filtrera kanterna desto bättre. Det här beslutet kan också ha en betydande effekt på frågekostnaden. Du kan utvärdera frågekostnaden när som helst med hjälp av steget executionProfile.

Nästa steg