Använda en partitionerad graf i Azure Cosmos DB

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

GÄLLER för: Gremlin-API

En av de viktigaste funktionerna i Gremlin-API:et i Azure Cosmos DB är möjligheten att hantera storskaliga grafer via horisontell skalning. Containrarna kan skalas oberoende av varandra vad gäller lagring och dataflöde. Du kan skapa containrar i Azure Cosmos DB som kan skalas automatiskt för att lagra diagramdata. Data balanseras automatiskt baserat på den angivna partitionsnyckeln.

Partitionering utförs internt om containern förväntas lagra mer än 20 GB i storlek eller om du vill allokera mer än 10 000 enheter för programbegäran per sekund (RU:er). Data partitioneras automatiskt baserat på den partitionsnyckel som du anger. Partitionsnyckel krävs om du skapar grafcontainrar från Azure Portal eller 3.x eller senare versioner av Gremlin-drivrutiner. Partitionsnyckel krävs inte om du använder 2.x eller lägre versioner av Gremlin-drivrutiner.

Samma allmänna principer från Azure Cosmos DB för partitionering gäller med några grafspecifika optimeringar som beskrivs nedan.

Graph partitionering.

Graph partitioneringsmekanism

Följande riktlinjer beskriver hur partitioneringsstrategin i Azure Cosmos DB fungerar:

  • Både hörn och kanter lagras som JSON-dokument.

  • Hörn kräver en partitionsnyckel. Den här nyckeln avgör i vilken partition brytpunkt ska lagras via en hash-algoritm. Egenskapsnamnet för partitionsnyckeln definieras när du skapar en ny container och har formatet : /partitioning-key-name .

  • Kanter lagras med källhörnet. För varje hörn definierar med andra ord dess partitionsnyckel var de lagras tillsammans med de utgående kanterna. Den här optimeringen görs för att undvika frågor mellan partitioner när du använder out() kardinaliteten i graffrågor.

  • Kanter innehåller referenser till de hörn som de pekar på. Alla kanter lagras med partitionsnycklarna och DED:erna för de hörn som de pekar på. Den här beräkningen gör out() att alla riktningsfrågor alltid är en begränsad partitionerad fråga och inte en blind fråga mellan partitioner.

  • Graph-frågor måste ange en partitionsnyckel. Om du vill dra full nytta av den horisontella partitionering i Azure Cosmos DB ska partitionsnyckeln anges när ett enda hörn väljs när det är möjligt. Följande är frågor för att välja ett eller flera hörn i en partitionerad graf:

    • /id och /label stöds inte som partitionsnycklar för en container i Gremlin-API:et.

    • Välja ett hörn efter ID och sedan använda steget för att ange .has() partitionsnyckelegenskapen:

      g.V('vertex_id').has('partitionKey', 'partitionKey_value')

    • Välja ett hörn genom att ange en tuppel, inklusive partitionsnyckelvärde och ID:

      g.V(['partitionKey_value', 'vertex_id'])

    • Ange en matris med tupplar med partitionsnyckelvärden och -ID:er:

      g.V(['partitionKey_value0', 'verted_id0'], ['partitionKey_value1', 'vertex_id1'], ...)

    • Välja en uppsättning hörn med sina-ID:er och ange en lista med partitionsnyckelvärden:

      g.V('vertex_id0', 'vertex_id1', 'vertex_id2', …).has('partitionKey', within('partitionKey_value0', 'partitionKey_value01', 'partitionKey_value02', …)

    • Använd partitionsstrategin i början av en fråga och ange en partition för omfånget för resten av Gremlin-frågan:

      g.withStrategies(PartitionStrategy.build().partitionKey('partitionKey').readPartitions('partitionKey_value').create()).V()

Metodtips när du använder en partitionerad graf

Använd följande riktlinjer för att säkerställa prestanda och skalbarhet när du använder partitionerade grafer med obegränsade containrar:

  • Ange alltid partitionsnyckelvärdet när du frågar en brytpunkt. Att hämta brytpunkt från en känd partition är ett sätt att uppnå prestanda. Alla efterföljande angränsande åtgärder är alltid begränsade till en partition eftersom kanter innehåller referens-ID och partitionsnyckel för sina målhörn.

  • Använd utgående riktning när du frågar kanter när det är möjligt. Som nämnts ovan lagras kanter med sina källhörn i utgående riktning. Chansen att använda frågor mellan partitioner minimeras därför när data och frågor utformas med det här mönstret i åtanke. Frågan är å andra in() sidan alltid en dyr förfjärrfråga.

  • Välj en partitionsnyckel som distribuerar data jämnt mellan partitionerna. Det här beslutet är starkt beroende av lösningens datamodell. Läs mer om att skapa en lämplig partitionsnyckel i Partitionering och skalning i Azure Cosmos DB.

  • Optimera frågor för att hämta data inom gränserna för en partition. En optimal partitioneringsstrategi skulle justeras efter frågemönstren. Frågor som hämtar data från en enda partition ger bästa möjliga prestanda.

Nästa steg

Därefter kan du fortsätta att läsa följande artiklar: