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.

Sharding bestäms separat för varje kollektion med hjälp av en utsedd shard key från kollektionens 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 det avsedda logiska fragmentet. Ansvaret för att placera det logiska fragmentet och distribuera alla logiska fragment i klustret tas bort från användarens ansvar och hanteras fullständigt av tjänsten.

Logiska fragment

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.

• Det finns inga gränser för antalet logiska shards för en samling. En samling kan ha lika många logiska skärvor som dokument med ett unikt värde för egenskapen skärvnyckel 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 skärvor

Fysiska shards är de underliggande maskiner och diskar som ansvarar för att bevara data och utföra databastransaktioner. Till skillnad från logiska skärvor hanterar tjänsten fysiska skärvor i bakgrunden.

Antalet fysiska shards definieras när ett kluster skapas och kan ökas om databasstorleken växer över tid. Enskilda shardkluster har en fysisk shard (nod) som är helt ansvarig för klustrets lagrings- och databastransaktioner. Multishard-kluster 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 beräknas ett hashvärde av egenskapen shard-nyckel, och detta hashvärde avgör mappningen av dokumentet till de underliggande fysiska fragmenten. 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.

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 partitioner är kapaciteten för varje fysisk shard densamma. Att skala upp klusternivån eller lagrings-SKU:n ändrar inte placeringen av logiska fragment på de fysiska fragmenten. 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. Varma partitioner kan orsaka att fysiska shards används ojämnt, vilket leder till oförutsägbar genomströmning och systemprestanda. 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 fragment. 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 applikationer bör shardnyckeln väljas utifrån de mest frekventa 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 delar upp medarbetarsamlingen i databasen cosmicworks baserat 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"}
})

En rekommenderad praxis är att ett index måste skapas på shardnyckelns egenskap.

use cosmicworks;
db.runCommand({
  createIndexes: "employee",
  indexes: [{"key":{"firstName":1}, "name":"firstName_1", "enableLargeIndexKeys": true}],
  blocking: true
})

Nästa steg

• Lär dig hur du skalar Azure Cosmos DB för MongoDB vCore-kluster
• Kolla in metodtips för indexering