Horisontell partitionering för horisontell skalbarhet i Azure Cosmos DB för MongoDB vCore
Azure Cosmos DB for MongoDB vCore stöder horisontell partitionering för att fördela data och trafik horisontellt. Dokumenten i en samling är indelade i segment som kallas logiska shards.
Horisontell partitionering definieras individuellt för varje samling med hjälp av en utsedd shardnyckel från samlingens dokumentstruktur. Data bucketas sedan i segment där varje segment motsvarar en logisk partition. Dokument för varje unikt värde för shardnyckelegenskapen finns i samma logiska fragment.
För varje dokument som infogas i en fragmenterad samling hashas värdet för shardnyckelegenskapen för att beräkna den avsedda logiska fragmentet. Ansvaret för att placera den logiska fragmentet och distribuera alla logiska shards i klustret abstraheras från användaren och hanteras fullständigt av tjänsten.
Logiska shards
Alla dokument som innehåller samma värde för shardnyckeln tillhör samma logiska fragment.
Låt oss till exempel överväga en samling med namnet Anställda med dokumentstrukturen nedan.
Den här tabellen visar en mappning av shardnyckelvärden till logiska partitioner.
| Dokument-ID | Shard Key Value | Logisk shard |
|---|---|---|
| "12345" | "Steve Smith" | Shard 1 |
| "23456" | "Jane Doe" | Shard 2 |
| "34567" | "Steve Smith" | Shard 1 |
| "45678" | "Michael Smith" | Shard 3 |
| "56789" | "Jane Doe" | Shard 2 |
Det finns inga gränser för antalet logiska shards för en samling. En samling kan ha lika många logiska shards som dokument med ett unikt värde för egenskapen shardnyckel i varje dokument.
Det finns inte heller några gränser för storleken på en enda logisk shard.
Dessutom begränsar tjänsten inte transaktioner till omfånget för en logisk shard. Den vCore-baserade tjänsten för Azure Cosmos DB for MongoDB stöder läs- och skrivtransaktioner som gäller för flera logiska shards och över flera fysiska shards i klustret.
Fysiska shards
Fysiska shards är de underliggande datorer och diskar som ansvarar för att bevara data och uppfylla databastransaktioner. Till skillnad från logiska shards hanterar tjänsten fysiska fragment under täcket.
Antalet fysiska shards definieras när ett kluster skapas. Enskilda shardkluster har en fysisk shard som är helt ansvarig för klustrets lagrings- och databastransaktioner. Kluster med flera fragment distribuerar data- och transaktionsvolymen över de fysiska fragmenten i klustret.
Mappa logiska shards till fysiska shards
När nya logiska shards läggs till uppdaterar klustret sömlöst mappningen av logiska till fysiska shards. På samma sätt ändras tilldelningen av adressutrymmet till varje fysisk shard när nya fysiska shards läggs till i klustret varefter logiska shards balanseras om i klustret.
Hash-intervallet som används för att mappa logiska och fysiska shards fördelas jämnt över de fysiska fragmenten i klustret. Varje fysisk shard äger en bucket i samma storlek som hash-intervallet. För varje dokument som skrivs hashas värdet för egenskapen shardnyckel och hash-värdet avgör mappningen av dokumentet till den underliggande fysiska fragmentet. Internt mappas flera logiska shards till en enda fysisk shard. Dessutom delas logiska shards aldrig över fysiska shards och alla dokument för en logisk shard mappas bara till en fysisk shard.
Den här tabellen bygger på föregående exempel med hjälp av ett kluster med två fysiska shards och visar en exempelmappning av dokument till fysiska fragment.
| Dokument-ID | Shard Key Value | Logisk shard | Fysisk shard |
|---|---|---|---|
| "12345" | "Steve Smith" | Shard 1 | Fysisk shard 1 |
| "23456" | "Jane Doe" | Shard 2 | Fysisk shard 2 |
| "34567" | "Steve Smith" | Shard 1 | Fysisk shard 1 |
| "45678" | "Michael Smith" | Shard 3 | Fysisk shard 1 |
| "56789" | "Jane Doe" | Shard 2 | Fysisk shard 2 |
Kapacitet för fysiska shards
Den klusternivå som väljs när klustret etableras avgör processor- och minneskapaciteten för en fysisk shard. På samma sätt avgör lagrings-SKU:n lagrings- och IOPS-kapaciteten för en fysisk shard. Större klusternivåer ger mer beräkningskraft och större minne medan större lagringsdiskar ger mer lagringsutrymme och IOPS. Läsintensiva arbetsbelastningar drar nytta av en större klusternivå medan skrivintensiva arbetsbelastningar drar nytta av en större lagrings-SKU. Klusternivån kan skalas upp och ned när klustret har skapats baserat på programmets föränderliga behov.
I ett kluster med flera fragment är kapaciteten för varje fysisk shard densamma. Att skala upp klusternivån eller lagrings-SKU:n ändrar inte placeringen av logiska shards på de fysiska shardsna. Efter en uppskalningsåtgärd förblir antalet fysiska shards detsamma och undviker därför behovet av att balansera om data i klustret.
Den fysiska fragmentens beräknings-, minnes-, lagrings- och IOPS-kapacitet avgör vilka resurser som är tillgängliga för de logiska shardsna. Shardnycklar som inte har en jämn distribution av lagrings- och begärandevolymer kan orsaka ojämn lagrings- och dataflödesförbrukning i klustret. Frekventa partitioner kan orsaka att fysiska shards används ojämnt, vilket leder till oförutsägbart dataflöde och prestanda. Därför kräver fragmenterade kluster noggrann planering i förväg för att säkerställa att prestandan förblir konsekvent när kraven för programmet ändras över tid.
Replikuppsättningar
Varje fysisk shard består av en uppsättning repliker, som även kallas för en replikuppsättning. Varje replik är värd för en instans av databasmotorn. En replikuppsättning gör datalagret inom den fysiska fragmentet beständigt, högtillgängligt och konsekvent. Varje replik som utgör den fysiska fragmentet ärver den fysiska fragmentets lagrings- och beräkningskapacitet. Azure Cosmos DB for MongoDB vCore hanterar automatiskt replikuppsättningar.
Metodtips för horisontell partitionering av data
Horisontell partitionering i Azure Cosmos DB for MongoDB vCore krävs inte om inte samlingens lagrings- och transaktionsvolymer kan överskrida kapaciteten för en enda fysisk shard. Tjänsten tillhandahåller till exempel 32 TB diskar per shard. Om en samling kräver mer än 32 TB bör den partitioneras.
Det är inte nödvändigt att fragmentera varje samling i ett kluster med flera fysiska shards. Fragmenterade och ohardade samlingar kan samexistera i samma kluster. Tjänsten distribuerar samlingarna i klustret optimalt för att jämnt använda klustrets beräknings- och lagringsresurser så jämnt som möjligt.
För läsintensiva program måste shardnyckeln väljas baserat på de vanligaste frågemönstren. Det vanligaste frågefiltret för en samling bör väljas som shardnyckel för att optimera den högsta procentandelen databastransaktioner genom att lokalisera sökningen till en enda fysisk shard.
För skrivintensiva program som föredrar skrivprestanda framför läsningar bör en shardnyckel väljas för att fördela data jämnt över de fysiska fragmenten. Shardnycklar med högsta kardinalitet ger bästa möjliga möjlighet att fördela så jämnt som möjligt.
För optimala prestanda bör lagringsstorleken för en logisk shard vara mindre än 4 TB.
För optimala prestanda bör logiska shards fördelas jämnt i lagrings- och begärandevolymen över klustrets fysiska shards.
Så här shardar du en samling
Överväg följande dokument i databasen "cosmicworks" och "employee"-samlingen
{
"firstName": "Steve",
"lastName": "Smith",
"companyName": "Microsoft",
"division": "Azure",
"subDivision": "Data & AI",
"timeInOrgInYears": 7
}
Följande exempel fragmentar medarbetarsamlingen i databasen cosmicworks på egenskapen firstName.
use cosmicworks;
sh.shardCollection("cosmicworks.employee", {"firstName": "hashed"})
Samlingen kan också partitioneras med hjälp av ett administratörskommando:
use cosmicworks;
db.adminCommand({
"shardCollection": "cosmicworks.employee",
"key": {"firstName": "hashed"}
})
Även om det inte är idealiskt att ändra shardnyckeln när samlingen har vuxit avsevärt i lagringsvolymen, kan kommandot reshardCollection användas för att ändra shardnyckeln.
use cosmicworks;
sh.reshardCollection("cosmicworks.employee", {"lastName": "hashed"})
Samlingen kan också partitioneras om med hjälp av ett administratörskommando:
use cosmicworks;
db.adminCommand({
"reshardCollection": "cosmicworks.employee",
"key": {"lastName": "hashed"}
})
Bästa praxis är att ett index måste skapas på egenskapen shardnyckel.
use cosmicworks;
db.runCommand({
createIndexes: "employee",
indexes: [{"key":{"firstName":1}, "name":"firstName_1", "enableLargeIndexKeys": true}],
blocking: true
})