Välja en partitionsnyckel
Kom ihåg att data i JSON-dokument lagras i Azure Cosmos DB-databaser i containrar som i sin tur distribueras över fysiska partitioner och där data dirigeras till lämplig fysisk partition baserat på värdet för en partitionsnyckel.
Partitionsnyckeln är en nödvändig dokumentegenskap som säkerställer att dokument med samma partitionsnyckelvärde dirigeras till och lagras i en specifik fysisk partition. En fysisk partition stöder en fast maximal mängd lagring och dataflöde (RU/s). Azure Cosmos DB distribuerar automatiskt de logiska partitionerna över de tillgängliga fysiska partitionerna, och använder återigen partitionsnyckelvärdet för att göra det på ett förutsägbart sätt.
I den här lektionen lär du dig mer om logiska partitioner och hur du undviker frekventa partitioner. Den här informationen hjälper oss att välja lämplig partitionsnyckel för kunddata i vårt scenario.
I Azure Cosmos DB ökar du lagringen och dataflödet genom att lägga till fler fysiska partitioner för att komma åt och lagra data. Den maximala lagringsstorleken för en fysisk partition är 50 GB och det maximala dataflödet är 10 000 RU/s.
Logiska partitioner i Azure Cosmos DB
Partitionsnyckeln säkerställer att dokument med samma partitionsnyckelvärde anses tillhöra samma logiska partition och dirigeras till och lagras i en specifik fysisk partition. Begreppet logisk partition möjliggör gruppering av dokument med samma partitionsnyckelvärde. Flera logiska partitioner kan lagras i en enda fysisk partition och containern kan ha ett obegränsat antal logiska partitioner. Enskilda logiska partitioner flyttas till nya fysiska partitioner som en enhet när containern växer. Om du flyttar logiska partitioner som en enhet ser du till att alla dokument i den finns på samma fysiska partition. Den maximala storleken för en logisk partition är 20 GB. Med en partitionsnyckel med hög kardinalitet kan du undvika den här gränsen på 20 GB genom att sprida dina data över ett större antal logiska partitioner.
En partitionsnyckel är ett sätt att dirigera data för en logisk partition. Det är en egenskap som finns i varje dokument i containern som dirigerar dina data. En container är en annan abstraktion och gäller för alla data som lagras med samma partitionsnyckel. Partitionsnyckeln definieras när du skapar en container.
I följande exempel har containern en partitionsnyckel på /username.
Undvik frekventa partitioner
När du modellerar data för Azure Cosmos DB är det mycket viktigt att partitionsnyckeln som du väljer resulterar i en jämn fördelning av data och begäranden mellan fysiska partitioner i containern. Detta gäller särskilt när containrar blir större och har ett ökande antal fysiska partitioner.
Om du inte testar designen av databasen under belastning under utveckling kanske ett dåligt val för partitionsnyckeln inte visas förrän programmet är i produktion och betydande data redan har skrivits.
När data inte partitioneras korrekt kan det resultera i frekventa partitioner. Frekventa partitioner hindrar programarbetsbelastningen från att skalas, och de kan ske på både lagring och dataflöde.
Frekventa lagringspartitioner
En frekvent partition på lagring sker när du har en partitionsnyckel som resulterar i mycket asymmetriska lagringsmönster. Anta till exempel att ett program med flera klienter som använder TenantId som partitionsnyckel med sex klienter: A till F. Klientorganisationer B, C, E och F är mycket små, klientorganisation D har lite mer data. Klient A är dock massiv och når snabbt gränsen på 20 GB för partitionen. I det här scenariot måste vi välja en annan partitionsnyckel som sprider lagringen över fler logiska partitioner.
Frekventa dataflödespartitioner
Dataflödet kan drabbas av frekventa partitioner när de flesta eller alla begäranden går till samma logiska partition.
Det är viktigt att förstå åtkomstmönstren för ditt program för att säkerställa att begäranden sprids så jämnt som möjligt över partitionsnyckelvärden. När dataflödet etableras för en container i Azure Cosmos DB allokeras det jämnt över alla fysiska partitioner i en container.
Om du till exempel har en container med 30 000 RU/s sprids den här arbetsbelastningen över de tre fysiska partitionerna för samma sex klienter som nämndes tidigare. Varje fysisk partition får därför 10 000 RU/s. Om klientorganisation D förbrukar alla sina 10 000 RU/s blir den begränsad eftersom den inte kan använda det dataflöde som allokerats till de andra partitionerna. Detta resulterar i dåliga prestanda för klientorganisationen C och D och lämnar outnyttjad beräkningskapacitet i de andra fysiska partitionerna och återstående klientorganisationer. I slutändan resulterar den här partitionsnyckeln i en databasdesign där programarbetsbelastningen inte kan skalas.
När data och begäranden sprids jämnt kan databasen växa på ett sätt som fullt ut utnyttjar både lagringen och dataflödet. Resultatet blir bästa möjliga prestanda och högsta effektivitet. Kort och kort skalas databasdesignen.
Överväg läsning jämfört med skrivningar
När du väljer en partitionsnyckel måste du också överväga om data läse tunga eller skrivintensiva. Du bör försöka distribuera skrivintensiva begäranden med en partitionsnyckel som har hög kardinalitet.
För läsintensiva arbetsbelastningar bör du se till att frågor bearbetas av en eller ett begränsat antal fysiska partitioner genom att inkludera en WHERE sats med ett likhetsfilter på partitionsnyckeln eller en IN-operator på en delmängd av partitionsnyckelvärden i dina frågor.
I scenarier där programarbetsbelastningen både är skrivintensiv och läsintensiv finns det en lösning. Vi ska utforska det i nästa modul.
Följande bild visar en container som partitioneras med användarnamn. Den här frågan träffar bara en enda logisk partition, så dess prestanda kommer alltid att vara bra.
En fråga som filtrerar på en annan egenskap, till exempel favoriteColor, skulle "fläkta ut" till alla partitioner i containern. Detta kallas även för en fråga mellan partitioner. En sådan fråga fungerar som förväntat när containern är liten och endast upptar en enda partition. Men när containern växer och antalet fysiska partitioner ökar blir den här frågan långsammare och dyrare eftersom den måste kontrollera varje partition för att få resultaten om den fysiska partitionen innehåller data som är relaterade till frågan eller inte.
Välj en partitionsnyckel för kunder
Nu när du förstår partitionering i Azure Cosmos DB kan vi välja en partitionsnyckel för våra kunddata. Som vi beskrev tidigare utför vi tre åtgärder på kunder: skapa en kund, uppdatera en kund och hämta en kund. I det här fallet hämtar vi kunden med deras ID. Eftersom den åtgärden kommer att kallas mest är det klokt att göra kundens ID till partitionsnyckeln för containern.
Här kan du oroa dig för att partitionsnyckeln innebär att vi har lika många logiska partitioner som det finns kunder, där varje logisk partition endast innehåller ett enda dokument. Miljontals kunder skulle resultera i miljontals logiska partitioner.
Men det här är helt okej! Logiska partitioner är ett virtuellt begrepp och det finns ingen gräns för hur många logiska partitioner du kan ha. Azure Cosmos DB samlar flera logiska partitioner på samma fysiska partition. När logiska partitioner växer i antal eller i storlek flyttar Cosmos DB dem till nya fysiska partitioner när det behövs.