Not
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Azure DocumentDB stöder horisontell partitionering för att distribuera data och trafik vågrätt. 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 det avsedda logiska fragmentet. Ansvaret för att placera de logiska fragmenten och distribuera alla logiska fragment inom klustret abstraheras bort från användaren och hanteras fullt ut av tjänsten.
Logiska partitioner
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 | Shardnyckelvärde | 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 fragment som dokument med ett unikt värde för shard-nyckelegenskapen 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. Azure DocumentDB 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 fragment är de underliggande datorer och diskar som ansvarar för att lagra data och uppfylla databastransaktioner. Till skillnad från logiska delar hanterar tjänsten fysiska fragment 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.
Kartläggning av logiska shardar till fysiska shardar
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 jämnstor del av hash-intervallens spännvidd. För varje dokument som skapas hashas värdet för egenskapen shard-nyckel och hash-värdet avgör mappningen av dokumentet till underliggande fysiskt fragment. Internt mappas flera logiska shards till en enda fysisk shard. Dessutom delas logiska shards aldrig upp över fysiska shards, och alla dokument för en logisk shard mappas endast 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-nyckelvärde | Logisk shard | Fysisk fragment |
|---|---|---|---|
| "12345" | "Steve Smith" | Shard 1 | Fysisk shard 1 |
| "23456" | "Jane Doe" | Shard 2 | Fysisk skärva 2 |
| "34567" | "Steve Smith" | Shard 1 | Fysisk fragment 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 partitioner ä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. Heta partitioner kan orsaka att fysiska shards används ojämnt, vilket leder till oförutsägbart genomflö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 replikaset gör datalagret inom den fysiska skärvan beständigt, högtillgängligt och konsekvent. Varje replik som utgör del av det fysiska fragmentet ärver det fysiska fragmentets lagrings- och beräkningskapacitet. Azure DocumentDB hanterar automatiskt replikuppsättningar.
Metodtips för horisontell partitionering av data
Horisontell partitionering i Azure DocumentDB 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 dela upp varje datamängd i ett kluster med flera fysiska delar. 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 program med hög läsintensitet bör shardnyckeln väljas utifrån 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 optimal prestanda bör logiska shardar fördelas jämnt i lagring och begärandevolym över klustrets fysiska shardar.
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 Cosmicworks-databasen baserat på förstnamn-attributet.
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 bästa praxis är att ett index måste skapas på shard-nyckelns egenskap.
use cosmicworks;
db.runCommand({
createIndexes: "employee",
indexes: [{"key":{"firstName":1}, "name":"firstName_1", "enableLargeIndexKeys": true}],
blocking: true
})