Partitionering och horisontell skalning i Azure Cosmos DB

Azure Cosmos DB använder partitionering för att skala containrar i en databas för att uppfylla programmets prestandabehov. Objekten i en container är indelade i distinkta delmängder som kallas logiska partitioner. Formuläret Logiska partitioner baseras 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.

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

Varje objekt i en container har en partitionsnyckel som avgör dess logiska partition och ett objekt-ID som är unikt i partitionen. Genom att kombinera 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.

I den här artikeln beskrivs relationen mellan logiska och fysiska partitioner, metodtips för partitionering och en djupgående vy över hur horisontell skalning fungerar i Azure Cosmos DB. Du behöver inte förstå den här interna informationen för att välja partitionsnyckeln, men den här artikeln beskriver dem för att klargöra hur Azure Cosmos DB fungerar.

Logiska partitioner

En logisk partition är en uppsättning objekt som delar samma partitionsnyckel. I en container som till exempel innehåller data om matnäring innehåller alla objekt en foodGroup egenskap. Använd foodGroup som partitionsnyckel för containern. Grupper med objekt som har specifika värden för foodGroup, till exempel Beef Products, Baked Productsoch Sausages and Luncheon Meats, bildar distinkta logiska partitioner.

En logisk partition definierar också omfattningen för databastransaktioner. Du kan uppdatera objekt i en logisk partition med hjälp av en transaktion med ögonblicksbildisolering. När nya objekt läggs till i en container skapar systemet transparent nya logiska partitioner. 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 en container. Varje logisk partition kan lagra upp till 20 GB data. Effektiva partitionsnycklar har ett brett utbud av möjliga värden. I en container där alla objekt innehåller en foodGroup egenskap kan data i den Beef Products logiska partitionen till exempel växa upp till 20 GB. Om du väljer en partitionsnyckel med ett stort antal möjliga värden ser du till att containern kan skalas.

Använd Azure Monitor-aviseringar för att övervaka om en logisk partitions storlek närmar sig 20 GB.

Fysiska partitioner

En container skalar genom att distribuera data och dataflöde mellan fysiska partitioner. Internt mappas en eller flera logiska partitioner till en enda fysisk partition. Vanligtvis har mindre containrar många logiska partitioner men kräver bara en enda fysisk partition. Till skillnad från logiska partitioner är fysiska partitioner en intern systemimplementering och Azure Cosmos DB hanterar dem fullständigt.

Antalet fysiska partitioner i en container beror på följande egenskaper:

• Mängden etablerat dataflöde (varje enskild fysisk partition kan ge ett dataflöde på upp till 10 000 enheter för begäranden 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 gigabyte data).

Det finns ingen gräns för det totala antalet fysiska partitioner i en container. När ditt etablerade dataflöde eller datastorlek 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 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.

Etablerat dataflöde 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 som dirigeras till en liten delmängd partitioner som blir "heta". Frekventa partitioner orsakar ineffektiv användning av etablerat dataflöde, vilket kan leda till hastighetsbegränsning och högre kostnader.

Du kan till exempel överväga en container med sökvägen /foodGroup som anges som partitionsnyckel. Containern kan ha valfritt antal fysiska partitioner, men i det här exemplet antar vi att den har tre. En enda fysisk partition kan innehålla flera partitionsnycklar. Till exempel kan den största fysiska partitionen innehålla de tre viktigaste logiska partitionerna: Beef Products, Vegetable and Vegetable Productsoch Soups, Sauces, and Gravies.

Om du tilldelar ett dataflöde på 18 000 enheter per sekund (RU/s) använder var och en av de tre fysiska partitionerna en tredjedel av det totala etablerade dataflödet. I den valda fysiska partitionen kan de logiska partitionsnycklarna Beef Products, Vegetable and Vegetable Productsoch Soups, Sauces, and Gravies tillsammans använda den fysiska partitionens 6 000 etablerade RU/s. Eftersom etablerat dataflöde är jämnt fördelat mellan containerns fysiska partitioner är det viktigt att välja en partitionsnyckel som jämnt distribuerar dataflödesförbrukningen. Mer information finns i Välja rätt logisk partitionsnyckel.

Hantera logiska partitioner

Azure Cosmos DB hanterar automatiskt placeringen av logiska partitioner på fysiska partitioner för att uppfylla containerns skalbarhets- och prestandabehov. När dataflödet och lagringskraven för ett program ökar flyttar Azure Cosmos DB logiska partitioner för att sprida belastningen över fler fysiska partitioner. Läs mer om fysiska partitioner.

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

Transaktioner i lagrade procedurer eller utlösare tillåts endast för objekt i en enda logisk partition.

Replikuppsättningar

Varje fysisk partition består av en uppsättning repliker, även kallade replikuppsättningar. Varje replik är värd för en instans av databasmotorn. En replikuppsättning gör datalagret i den fysiska partitionen beständigt, högtillgängligt och konsekvent. Varje replik i den fysiska partitionen ärver partitionens lagringskvot. Alla repliker av en fysisk partition stöder tillsammans det dataflöde som allokerats till den fysiska partitionen. Azure Cosmos DB hanterar automatiskt replikuppsättningar.

Mindre containrar kräver vanligtvis en enda fysisk partition, men de har fortfarande minst fyra repliker.

Den här bilden visar hur logiska partitioner mappas till fysiska partitioner som distribueras globalt. Partitionsuppsättningen i avbildningen refererar till en grupp fysiska partitioner som hanterar samma logiska partitionsnycklar i flera regioner:

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:

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

• Värdet för partitionsnyckeln (till exempel "Andrew"). Partitionsnyckelvärdet kan vara av sträng- eller numeriska typer.

Lär dig mer om gränserna för dataflöde, lagring och partitionsnyckellängd i artikeln om Azure Cosmos DB-tjänstkvoter .

Att välja partitionsnyckeln är ett enkelt men viktigt designval i Azure Cosmos DB. När du har valt partitionsnyckeln kan du inte ändra den på plats. Om du behöver ändra partitionsnyckeln flyttar du dina data till en ny container med önskad partitionsnyckel. Containerkopieringsjobb hjälper dig med den här processen. Alternativt kan du lägga till globala sekundära index (förhandsversion) för att skapa en kopia av dina data med olika partitionsnycklar optimerade för specifika frågemönster.

För alla containrar ska partitionsnyckeln:

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

• Innehåller endast String värden – eller konvertera tal till en String om de kan överskrida gränserna för dubbla precisionsnummer enligt Institute of Electrical and Electronics Engineers (IEEE) 754 binary64. Json-specifikationen förklarar varför användning av siffror utanför den här gränsen är en felaktig metod på grund av samverkansproblem. Dessa problem är särskilt relevanta för kolumnen partitionsnyckel eftersom den är oföränderlig och kräver att datamigreringen ändras senare.

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

• Sprida ru-förbrukning (request unit) och datalagring jämnt över alla logiska partitioner. Den här spridningen säkerställer även RU-förbrukning och lagringsdistribution över dina fysiska partitioner.

• Har värden som normalt inte är större än 2 048 byte eller 101 byte om stora partitionsnycklar inte är aktiverade. Mer information finns i stora partitionsnycklar

Om du behöver ACID-transaktioner med flera objekt i 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.

Typer av partitionsnycklar

Partitionsnycklar för läsintensiva containrar

För de flesta containrar är dessa kriterier allt du behöver tänka på när du väljer en partitionsnyckel. För stora läsintensiva containrar kanske du dock vill välja en partitionsnyckel som ofta visas som ett filter i dina frågor. Genom att inkludera partitionsnyckeln i filterpredikatet kan frågor effektivt dirigeras till endast relevanta fysiska partitioner.

Den här egenskapen är ett bra partitionsnyckelval om de flesta av arbetsbelastningens begäranden är frågor och de flesta av dina frågor använder ett likhetsfilter på samma egenskap. Om du till exempel ofta kör en fråga som filtrerar på UserIDskulle valet som partitionsnyckel minska antalet UserID.

Om containern är liten har du förmodligen inte tillräckligt med fysiska partitioner för att oroa dig för prestanda för frågor mellan partitioner. De flesta små containrar i Azure Cosmos DB kräver bara en eller två fysiska partitioner.

Om containern kan växa till fler än några fysiska partitioner bör du se till att du väljer en partitionsnyckel som minimerar frågor mellan partitioner. Containern behöver fler än några fysiska partitioner om något av följande scenarier är sant:

• Containern har över 30 000 enheter för begäranden etablerade

• Din container lagrar över 100 GB data

Globala sekundära index för frågor mellan partitioner

Om ditt program behöver köra frågor mot data med flera olika egenskaper effektivt, är globala sekundära index (förhandsversion) ett alternativ till att använda en partitionsnyckelstrategi för datamängden. Globala sekundära index är ytterligare containrar med olika partitionsnycklar, som automatiskt synkroniseras med data från källcontainern.

Överväg globala sekundära index när:

• Du har flera frågemönster som inte kan uppfyllas av en strategi för en enda partitionsnyckel
• Det skulle vara störande att ändra din befintliga partitionsnyckel
• Du måste isolera analys- eller sökarbetsbelastningar från transaktionsåtgärder

Globala sekundära index hjälper till att undvika frågor mellan partitioner genom att lagra samma data med olika partitionsnycklar som är optimerade för specifika frågemönster. Den här metoden kan avsevärt minska RU-förbrukningen och förbättra frågeprestanda för scenarier där enbart partitionsnyckeloptimering inte räcker.

Använda objekt-ID som partitionsnyckel

Om containern har en egenskap med ett stort antal möjliga värden är det förmodligen ett bra val av partitionsnyckel. Ett exempel på en sådan egenskap är objekt-ID:t. För små läsintensiva containrar eller skrivintensiva containrar av valfri storlek är objekt-ID:t (/id) naturligtvis ett bra val för partitionsnyckeln.

Systemegenskapens objekt-ID finns i varje objekt i containern. Du kan ha andra egenskaper som representerar ett logiskt ID för ditt objekt. I många fall är dessa unika identifierare också bra partitionsnyckelval av samma skäl som objekt-ID:t.

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

• Det finns ett stort antal 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 med 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.

Tänk på följande varningar när du väljer objekt-ID :t som partitionsnyckel:

• Om objekt-ID :t är partitionsnyckeln blir det en unik identifierare för hela containern. Du kan inte skapa objekt med duplicerade identifierare.
• Om du har en läsintensiv container med många fysiska partitioner är frågorna mer effektiva om de har ett likhetsfilter med objekt-ID:t.
• Lagrade procedurer eller utlösare kan inte rikta in sig på flera logiska partitioner.

Relaterat innehåll

• Etablerat dataflöde i Azure Cosmos DB
• Global distribution i Azure Cosmos DB
• Utbildning: modellera och partitionera dina data i Azure Cosmos DB