Graph datamodellering för Azure Cosmos DB Gremlin-API

  • Artikel
  • 4 minuter för att läsa

GÄLLER för: Gremlin-API

Följande dokument är utformat för att ge rekommendationer för diagramdatamodellering. Det här steget är viktigt för att säkerställa skalbarhet och prestanda för ett grafdatabassystem allt eftersom data utvecklas. En effektiv datamodell är särskilt viktig med 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 diagramdatamodellen.
  • Principerna för Apache Tinkerpops egenskapsgrafstandard är väl förstådda.

När behöver jag en grafdatabas?

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

  • Entiteterna är mycket anslutna via beskrivande relationer. Fördelen i det här scenariot är att relationerna är beständiga 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 växande 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 är det troligt att en grafdatabas-metod ger fördelar för frågekomplexitet, skalbarhet för datamodell och frågeprestanda.

Nästa steg är att avgöra om diagrammet ska användas i analys- eller transaktionssyfte. Om diagrammet är avsett att användas för tunga beräknings- och databearbetningsarbetsbelastningar, skulle det vara värt att utforska Cosmos DB Spark-anslutningsappen och användningen av GraphX-biblioteket.

Så här använder du diagramobjekt

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

Här följer metodtipsen för egenskaperna i diagramobjekten:

Objekt Egenskap Typ Kommentarer
Vertex ID Sträng Unikt framtvingat per partition. Om inget värde anges vid infogningen lagras ett automatiskt genererat GUID.
Vertex etikett Sträng Den här egenskapen används för att definiera typen av entitet som hörnet representerar. Om inget värde anges används standardvärdet "hörn".
Vertex properties Sträng, boolesk, numerisk En lista med separata egenskaper som lagras som nyckel/värde-par i varje hörn.
Vertex partitionsnyckel Sträng, boolesk, numerisk Den här egenskapen definierar var hörnet och dess utgående kanter ska lagras. Läs mer om grafpartitionering.
Edge ID Sträng Unikt framtvingat per partition. Genereras automatiskt som standard. Kanter behöver vanligtvis inte hämtas unikt av 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 properties Sträng, boolesk, numerisk En lista med separata egenskaper som lagras som nyckel/värde-par i varje kant.

Anteckning

Kanter kräver inte något partitionsnyckelvärde eftersom dess värde tilldelas automatiskt baserat på källans hörn. Läs mer i artikeln om grafpartitionering.

Riktlinjer för entitets- och relationsmodellering

Följande är en uppsättning riktlinjer för att använda datamodellering för en Azure Cosmos DB Gremlin API-grafdatabas. Dessa riktlinjer förutsätter att det finns en befintlig definition av en datadomän och frågor för den.

Anteckning

Stegen som beskrivs nedan visas som rekommendationer. Den slutliga modellen bör utvärderas och testas innan den övervägs som produktionsklar. Rekommendationerna nedan är dessutom specifika för Azure Cosmos DB Gremlin API-implementering.

Modellera 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 enskild entitet som separata hörn. Titta på exemplet nedan, 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. Den här metoden kan minska redundansen, men den ökar modellens komplexitet. En ökning av modellens komplexitet kan resultera i ökad svarstid, frågekomplexitet och beräkningskostnader. Den här modellen kan också ge utmaningar vid partitionering.

Entitetsmodell med hörn för egenskaper.

  • Egenskapsinbäddade hörn: Den här metoden utnyttjar nyckel/värde-parlistan för att representera alla egenskaper för entiteten inuti ett hörn. Den här metoden ger minskad modellkomplexitet, vilket leder till enklare frågor och mer kostnadseffektiva traverserar.

Diagram som visar Luis-hörnet från föregående diagram med i d, etikett och egenskaper.

Anteckning

I exemplen ovan visas en förenklad grafmodell som endast visar jämförelsen mellan de två sätten att dela upp entitetsegenskaper.

Mönstret för egenskapsinbäddade hörn ger vanligtvis en mer bra och skalbar metod. Standardsättet för en ny grafdatamodell bör dras mot det här mönstret.

Det finns dock scenarier där en referens till en egenskap kan ge fördelar. Exempel: om den refererade egenskapen uppdateras ofta. Om du använder ett separat hörn för att representera en egenskap som ändras kontinuerligt minimeras mängden skrivåtgärder som skulle krävas i uppdateringen.

Relationsmodellering 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 måste utvärderas är riktningen för relationen.

Kantobjekt har en standardriktning som följs av en genomgång när du använder out() outE() funktionen eller . Att använda den här naturliga riktningen resulterar i en effektiv åtgärd, eftersom alla hörn lagras med sina utgående kanter.

Men om du bläddrar i motsatt riktning mot en kant med funktionen in() resulterar det alltid i en fråga mellan partitioner. Läs mer om grafpartitionering. Om du behöver bläddra kontinuerligt med funktionen rekommenderar vi in() att du lägger till kanter i båda riktningarna.

Du kan fastställa kantriktningen med hjälp .to() av eller .from() predikaten för .addE() Gremlin-steget. Eller genom att använda massut executor-biblioteket för Gremlin-API:et.

Anteckning

Kantobjekt har en riktning som standard.

Relationsetiketter

Genom att använda beskrivande relationsetiketter kan du förbättra effektiviteten för åtgärder med kantupplösning. Det här mönstret kan tillämpas på följande sätt:

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

Exempel på relationsetiketter.

Ju mer specifik etiketten som traversern använder för att filtrera kanterna, desto bättre. Det här beslutet kan även ha en betydande inverkan på frågekostnaden. Du kan utvärdera frågekostnaden när som helst med hjälp av executionProfile-steget.

Nästa steg: