Partitionering och horisontell skalning i Azure Cosmos DB

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

GÄLLER för: SQL API API för Cassandra Gremlin API tabell-API Azure Cosmos DB API för MongoDB

Azure Cosmos DB använder partitionering för att skala enskilda containrar i en databas för att uppfylla programmets prestandabehov. Vid partitionering delas objekten i en container in i distinkta delmängder som kallas logiska partitioner. Logiska partitioner skapas baserat på värdet för en partitionsnyckel som är associerad med varje objekt i en container. Alla objekt i en logisk partition har samma partitionsnyckelvärde.

Till exempel innehåller en container objekt. Varje objekt har ett unikt värde för UserID egenskapen . Om fungerar som partitionsnyckel för objekten i containern och det finns UserID 1 000 unika värden UserID skapas 1 000 logiska partitioner för containern.

Förutom en partitionsnyckel som bestämmer objektets logiska partition har varje objekt i en container ett objekt-ID (unikt inom en logisk partition). Om du kombinerar partitionsnyckeln och objekt-ID:t skapas objektets index, som unikt identifierar objektet. Att välja en partitionsnyckel är ett viktigt beslut som påverkar programmets prestanda.

Den här artikeln beskriver relationen mellan logiska och fysiska partitioner. Den beskriver också metodtips för partitionering och ger en detaljerad vy över hur horisontell skalning fungerar i Azure Cosmos DB. Det är inte nödvändigt att förstå den här interna informationen för att välja din partitionsnyckel, men vi har gått in på dem så att du vet hur Azure Cosmos DB fungerar.

Logiska partitioner

En logisk partition består av en uppsättning objekt som har samma partitionsnyckel. I en container som innehåller data om matmat innehåller till exempel alla objekt en foodGroup egenskap. Du kan använda foodGroup som partitionsnyckel för containern. Grupper med objekt som har specifika värden foodGroup för , till exempel , och , bildar Beef Products Baked Products Sausages and Luncheon Meats distinkta logiska partitioner.

En logisk partition definierar också omfånget för databastransaktioner. Du kan uppdatera objekt inom en logisk partition med hjälp av en transaktion med ögonblicksbildisolering. När nya objekt läggs till i en container skapas nya logiska partitioner transparent av systemet. Du behöver inte bekymra dig om att ta bort en logisk partition när underliggande data tas bort.

Det finns ingen gräns för antalet logiska partitioner i containern. Varje logisk partition kan lagra upp till 20 GB data. Bra alternativ för partitionsnyckel har en mängd olika möjliga värden. I en container där alla objekt innehåller en egenskap kan till exempel data i den logiska foodGroup Beef Products partitionen växa upp till 20 GB. Om du väljer en partitionsnyckel med en mängd olika möjliga värden säkerställer du att containern kan skalas.

Fysiska partitioner

En container skalas genom att data och dataflöde distribueras över fysiska partitioner. Internt mappas en eller flera logiska partitioner till en enda fysisk partition. Vanligtvis har mindre containrar många logiska partitioner, men de kräver bara en enda fysisk partition. Till skillnad från logiska partitioner är fysiska partitioner en intern implementering av systemet och de hanteras helt av Azure Cosmos DB.

Antalet fysiska partitioner i containern beror på följande:

  • Antalet etablerade dataflöden (varje enskild fysisk partition kan ge ett dataflöde på upp till 10 000 enheter för programbegäran per sekund). Gränsen på 10 000 RU/s för fysiska partitioner innebär att logiska partitioner också har en gräns på 10 000 RU/s, eftersom varje logisk partition endast mappas till en fysisk partition.

  • Den totala datalagringen (varje enskild fysisk partition kan lagra upp till 50 GB data).

Anteckning

Fysiska partitioner är en intern implementering av systemet och de hanteras helt av Azure Cosmos DB. När du utvecklar dina lösningar ska du inte fokusera på fysiska partitioner eftersom du inte kan kontrollera dem. Fokusera i stället på dina partitionsnycklar. Om du väljer en partitionsnyckel som fördelar dataflödesförbrukningen jämnt mellan logiska partitioner ser du till att dataflödesförbrukningen över fysiska partitioner balanseras.

Det finns ingen gräns för det totala antalet fysiska partitioner i containern. När det etablerade dataflödet eller datastorleken växer skapar Azure Cosmos DB automatiskt nya fysiska partitioner genom att dela upp befintliga. Fysiska partitionsdelningar påverkar inte programmets tillgänglighet. Efter den fysiska partitionsdelningen lagras fortfarande alla data i en enda logisk partition på samma fysiska partition. En fysisk partitionsdelning skapar helt enkelt en ny mappning av logiska partitioner till fysiska partitioner.

Dataflödet som etableras för en container delas jämnt mellan fysiska partitioner. En partitionsnyckeldesign som inte distribuerar begäranden jämnt kan resultera i för många begäranden riktade till en liten delmängd av partitioner som blir "heta". Heta partitioner leder till ineffektiv användning av etablerat dataflöde, vilket kan leda till hastighetsbegränsning och högre kostnader.

Du kan se containerns fysiska partitioner i Storage på bladet Mått i Azure Portal:

Visa antalet fysiska partitioner

I skärmbilden ovan har en container /foodGroup som partitionsnyckel. Var och en av de tre staplarna i diagrammet representerar en fysisk partition. I avbildningen är partitionsnyckelintervallet detsamma som en fysisk partition. Den valda fysiska partitionen innehåller de tre viktigaste logiska partitionerna: Beef Products Vegetable and Vegetable Products , och Soups, Sauces, and Gravies .

Om du etablerar ett dataflöde på 18 000 enheter för programbegäran per sekund (RU/s) kan var och en av de tre fysiska partitionerna använda 1/3 av det totala etablerade dataflödet. Inom den valda fysiska partitionen kan de logiska partitionsnycklarna , och tillsammans använda den fysiska Beef Products Vegetable and Vegetable Products Soups, Sauces, and Gravies partitionens 6 000 etablerade RU/s. Eftersom det etablerade dataflödet är jämnt fördelat över containerns fysiska partitioner, är det viktigt att välja en partitionsnyckel som fördelar dataflödesförbrukningen jämnt genom att välja rätt logisk partitionsnyckel.

Hantera logiska partitioner

Azure Cosmos DB transparent och hanterar automatiskt placeringen av logiska partitioner på fysiska partitioner för att effektivt uppfylla containern skalbarhets- och prestandabehov. När dataflödes- och lagringskraven för ett program ökar flyttar Azure Cosmos DB logiska partitioner för att automatiskt sprida belastningen över ett större antal fysiska partitioner. Du kan lära dig mer om fysiska partitioner.

Azure Cosmos DB använder hash-baserad partitionering för att sprida logiska partitioner över fysiska partitioner. Azure Cosmos DB hash-värdet för partitionsnyckeln för ett objekt. Det hashade resultatet avgör den fysiska partitionen. Sedan Azure Cosmos DB nyckelutrymmet för partitionsnyckelns hash-värden jämnt över de fysiska partitionerna.

Transaktioner (i lagrade procedurer eller utlösare) tillåts endast mot objekt i en enda logisk partition.

Replikuppsättningar

Varje fysisk partition består av en uppsättning repliker, som även kallas för en replikuppsättning. Varje replikuppsättning är värd för en instans av databasmotorn. En replikuppsättning gör att data som lagras i den fysiska partitionen är beständiga, har hög tillgång och är konsekventa. Varje replik som utgör den fysiska partitionen ärver partitionens lagringskvot. Alla repliker av en fysisk partition stöder gemensamt dataflödet som allokeras till den fysiska partitionen. Azure Cosmos DB hanterar replikuppsättningar automatiskt.

Vanligtvis kräver mindre containrar bara en enda fysisk partition, men de har fortfarande minst 4 repliker.

Följande bild visar hur logiska partitioner mappas till fysiska partitioner som distribueras globalt. Partitionsuppsättningen i avbildningen refererar till en grupp med fysiska partitioner som hanterar samma logiska partitionsnycklar i flera regioner:

En bild som visar Azure Cosmos DB partitionering

Välja en partitionsnyckel

En partitionsnyckel har två komponenter: partitionsnyckelsökvägen och partitionsnyckelvärdet. Tänk dig till exempel ett objekt { "userId" : "Andrew", "worksFor": "Microsoft" } om du väljer "userId" som partitionsnyckel. Följande är de två partitionsnyckelkomponenterna:

  • Partitionsnyckelns sökväg (till exempel: "/userId"). Partitionsnyckelsökvägen accepterar alfanumeriska tecken och understreck(_). Du kan också använda kapslade objekt med hjälp av standardsökvägen notation(/).

  • Partitionsnyckelvärdet (till exempel: "Andrew"). Partitionsnyckelvärdet kan vara av strängtyper eller numeriska typer.

Mer information om gränserna för dataflöde, lagring och längden på partitionsnyckeln finns i artikeln Azure Cosmos DB om tjänstkvoter.

Att välja partitionsnyckel är ett enkelt men viktigt designval i Azure Cosmos DB. När du har valt din partitionsnyckel går det inte att ändra den på plats. Om du behöver ändra partitionsnyckeln bör du flytta dina data till en ny container med den nya partitionsnyckeln.

För alla containrar bör partitionsnyckeln:

  • Vara en egenskap som har ett värde som inte ändras. Om en egenskap är din partitionsnyckel kan du inte uppdatera egenskapens värde.

  • Ha en hög kardinalitet. Med andra ord bör egenskapen ha ett brett utbud av möjliga värden.

  • Sprida förbrukning av enheter för programbegäran (RU) och datalagring jämnt över alla logiska partitioner. Detta säkerställer även RU-förbrukning och lagringsdistribution över dina fysiska partitioner.

Om du behöver ACID-transaktioner med flera objekt Azure Cosmos DB måste du använda lagrade procedurer eller utlösare. Alla JavaScript-baserade lagrade procedurer och utlösare är begränsade till en enda logisk partition.

Partitionsnycklar för lästunga containrar

För de flesta containrar är ovanstående kriterier allt du behöver tänka på när du väljer en partitionsnyckel. För stora lästunga containrar kan du dock välja en partitionsnyckel som ofta visas som ett filter i dina frågor. Frågor kan effektivt dirigeras till endast relevanta fysiska partitioner genom att inkludera partitionsnyckeln i filterför predikatet.

Om de flesta av arbetsbelastningens begäranden är frågor och de flesta av dina frågor har ett likhetsfilter för samma egenskap, kan den här egenskapen vara ett bra alternativ för partitionsnyckel. Om du till exempel ofta kör en fråga som filtrerar på och sedan väljer som partitionsnyckel minskar antalet frågor UserID UserID mellan partitioner.

Men om containern är liten har du förmodligen inte tillräckligt med fysiska partitioner för att behöva bekymra dig om prestandapåverkan av frågor mellan partitioner. De flesta små containrar Azure Cosmos DB kräver bara en eller två fysiska partitioner.

Om containern kan växa till fler än några få fysiska partitioner bör du välja en partitionsnyckel som minimerar frågor mellan partitioner. Containern kräver fler än några fysiska partitioner när något av följande stämmer:

  • Containern har över 30 000 RU:er etablerade

  • Din container lagrar över 100 GB data

Använda objekt-ID som partitionsnyckel

Om containern har en egenskap som har en mängd olika möjliga värden är det förmodligen ett bra val av partitionsnyckel. Ett möjligt exempel på en sådan egenskap är objekt-ID:t. För små lästunga containrar eller skrivtunga containrar av valfri storlek är objekt-ID:t ett bra val för partitionsnyckeln.

Systemegenskapsobjektets ID finns i varje objekt i containern. Du kan ha andra egenskaper som representerar ett logiskt ID för objektet. I många fall är de också bra alternativ för partitionsnyckel av samma skäl som objekt-ID:t.

Objekt-ID:t är ett bra alternativ för partitionsnyckel av följande skäl:

  • Det finns ett brett utbud av möjliga värden (ett unikt objekt-ID per objekt).
  • Eftersom det finns ett unikt objekt-ID per objekt gör objekt-ID:t ett bra jobb på att balansera ru-förbrukning och datalagring jämnt.
  • Du kan enkelt göra effektiva punktläsningar eftersom du alltid känner till ett objekts partitionsnyckel om du känner till dess objekt-ID.

Några saker att tänka på när du väljer objekt-ID som partitionsnyckel är:

  • Om objekt-ID:t är partitionsnyckeln blir det en unik identifierare i hela containern. Du kan inte ha objekt som har ett dubblettobjekt-ID.
  • Om du har en skrivskyddad container med många fysiska partitionerblir frågorna mer effektiva om de har ett likhetsfilter med objekt-ID:t.
  • Du kan inte köra lagrade procedurer eller utlösare över flera logiska partitioner.

Nästa steg