MongoDB Academy · Lektion

Rangeret kontra hash-baseret sharding

De lærende vil konfigurere en samling med rangeret sharding til intervalforespørgsler eller hash-baseret sharding til ensartet skrivefordeling og sammenligne deres afvejninger.

Lektion 3 af 413 trin

Rangeret kontra hash-baseret sharding er en gratis MongoDB Academy-lektion på CoddyKit. Dette er lektion 3 af 4. Du kan læse hele lektionen gratis nedenfor — og derefter øve dig praktisk i browseren med en indbygget kodeeditor og en AI-vejleder, der er tilgængelig døgnet rundt. Den er en del af læringsforløbet i MongoDB Academy, og dine fremskridt synkroniseres på tværs af nettet og CoddyKit-appen. MongoDB Academy-kurset indeholder 4 lektioner i alt.

To sharding-strategier sammenlignet

MongoDB understøtter to indbyggede sharding-strategier: ranged sharding og hashed sharding. Ranged sharding tildeler sammenhængende intervaller af shard-nøgleværdier til bestemte shards, mens hashed sharding først anvender en hashfunktion på nøglen og derefter fordeler ud fra hashen. Begge har særlige styrker, og det rigtige valg afhænger af dine mønstre for dataadgang.

Ranged sharding: Sådan fungerer det

Ved ranged sharding opdeler MongoDB shard-nøglens værdirum i sammenhængende intervaller og tildeler hvert interval (chunk) til en shard. For eksempel sendes brugere med userId fra 1–10.000 til shard A, 10.001–20.000 til shard B og så videre. Dokumenter med nærliggende shard-nøgleværdier placeres på samme shard, hvilket er ideelt til intervalforespørgsler.

// Enable ranged sharding on a field
sh.shardCollection('mydb.products', { category: 1, price: 1 })

// Range query is now targeted to the shard(s) holding that range
db.products.find({ category: 'electronics', price: { $lt: 100 } })

Ranged sharding: Fordele

Ranged sharding er særligt effektivt, når din applikation ofte forespørger efter intervaller af værdier: datointervaller, prisintervaller, alfabetiske navneintervaller eller paginerede resultater sorteret efter et numerisk id. Fordi nærliggende værdier placeres samme sted, bliver intervalforespørgsler til målrettede forespørgsler, som kun berører én eller få shards og dermed holder latenstiden lav.

// With ranged sharding on { orderId: 1 }, this is targeted:
db.orders.find({
  orderId: { $gte: 50000, $lte: 60000 }
})
// mongos knows exactly which shard owns this range

Ranged sharding: Ulempe — varme punkter

Den afgørende svaghed ved ranged sharding er varme skrivepunkter, når shard-nøglen stiger monotonisk (tidsstempler, automatisk inkrementerede id'er, ObjectId). Alle nye dokumenter samler sig i den høje ende af intervallet og lander på én shard. Indtil balanceren migrerer chunks, håndterer denne shard al skrive- trafik, mens de andre shards står ubenyttede.

// Problematic: all new events go to the max-range shard
sh.shardCollection('mydb.events', { createdAt: 1 }) // ranged, monotonic = hot spot

// Production symptom: one shard has 90%+ of recent data
// and absorbs all write IOPS

Hashed sharding: Sådan fungerer det

Ved hash-baseret sharding beregner MongoDB en hashværdi af shard-nøgleværdien og bruger hashen til at bestemme chunken. Dokumenter fordeles baseret på hashværdier, som ser tilfældige ud, selv når de oprindelige nøgler stiger monotont. Det sikrer en næsten ensartet indledende skrivefordeling på tværs af alle shards.

// Hashed sharding on _id (neutralizes ObjectId monotonicity)
sh.shardCollection('mydb.events', { _id: 'hashed' })

// Hashed sharding on userId
sh.shardCollection('mydb.sessions', { userId: 'hashed' })

Hash-baseret sharding: styrker

Hash-baseret sharding er det bedste valg, når dit primære mål er ensartet skrivefordeling på tværs af shards, og du ikke har brug for intervalforespørgsler på shard-nøglen. Det er ideelt til arbejdsbelastninger med høj indsættelsesfrekvens og monotone nøgler (hændelseslogge, IoT-sensordata og meddelelser), hvor hver shard skal håndtere en lige stor andel af skrivebelastningen.

// With hashed sharding, inserts are spread uniformly:
// doc1 (hash: 2345...) -> shard A
// doc2 (hash: 8901...) -> shard C
// doc3 (hash: 4567...) -> shard B
// No hot spot regardless of insert order

Hash-baseret sharding: svaghed — ingen effektivitet ved intervaller

Ulempen ved hash-baseret sharding er, at intervalforespørgsler på shard-nøglen bliver til scatter-gather. Da tilstødende hashværdier er spredt på tværs af shards, skal en forespørgsel som { createdAt: { $gte: t1, $lte: t2 } } sendes til alle shards. Hvis intervalforespørgsler er hyppige og følsomme over for svartid, kan hash-baseret sharding udligne de ydelsesfordele, som sharding giver.

// With hashed sharding on createdAt:
// Range query CANNOT be targeted — fans out to all shards
db.events.find({ createdAt: { $gte: ISODate('2025-01-01'), $lte: ISODate('2025-02-01') } })
// Equivalent to a full collection scan across all shards

Valg mellem intervalbaseret og hash-baseret sharding

Beslutningsvejledning: Intervalbaseret sharding → shard-nøglen har en naturlig fordeling (ikke monoton), OG dine vigtigste forespørgsler er intervalforespørgsler på denne nøgle. Hash-baseret sharding → shard-nøglen er monoton, ELLER dine vigtigste forespørgsler er punktopslag (lighed) på et felt med høj kardinalitet. Hvis du er i tvivl, og indsættelser er flaskehalsen, bør du foretrække hash-baseret sharding.

Hybrid: sammensat nøgle med hash-baseret komponent

Du kan kombinere begge strategier med en sammensat shard-nøgle, hvor det første felt er intervalbaseret og giver forespørgselsaffinitet, mens et andet felt med hashing spreder belastningen inden for hvert interval. Eksempel: { tenantId: 1, _id: 'hashed' } placerer data for den samme tenant sammen til målrettede forespørgsler, samtidig med at skrivebelastningen fordeles på shards inden for hver tenant.

// Ranged tenantId + hashed _id within tenant
// Writes are distributed; per-tenant queries are targeted
sh.shardCollection('mydb.events', { tenantId: 1, _id: 'hashed' })

// Targeted: all tenantId queries go to the right shard(s)
db.events.find({ tenantId: 'acme', _id: ObjectId('...') })

Kontrol af den aktive strategi

Du kan undersøge en samlings sharding-konfiguration for at afgøre, hvilken strategi der er i brug. Metadataene på konfigurationsserveren gemmer shard-nøglen og angiver, om den bruger 'hashed'. Kommandoerne sh.status() og db.collection.stats() viser begge disse oplysninger.

// Check sharding info for a collection
use config
db.collections.findOne({ _id: 'mydb.events' })
// { key: { _id: 'hashed' }, unique: false, ... }

// Or via sh.status()
sh.status()

Forudopdeling af chunks til masseindlæsninger

Når du masseindlæser data i en nyoprettet shardet samling, ligger alle chunks oprindeligt på én shard og skal migreres af balanceren — det kan være langsomt. Forudopdeling opretter et indledende sæt tomme chunks, som fordeles på alle shards før indlæsningen. Det sikrer, at balancerens arbejde minimeres, og at skrivninger fordeles fra den første indsættelse.

// Pre-split chunks for ranged sharding
// Define desired split points and assign to shards
db.adminCommand({ split: 'mydb.events', middle: { userId: 500000 } })
db.adminCommand({ moveChunk: 'mydb.events',
  find: { userId: 500000 }, to: 'shard02' })

Hurtigt tjek

Test din forståelse af begreberne MongoDB og NoSQL-databaser fra denne lektion.

Besvar den i den interaktive lektion

Opsummering af lektionen

I denne lektion lærte du, at intervalbaseret sharding placerer lignende nøgleværdier sammen for effektive intervalforespørgsler, men skaber hotspots med monotone nøgler, at hash-baseret sharding fordeler data ensartet på tværs af shards, men gør intervalforespørgsler til scatter-gather, og at sammensatte nøgler kan kombinere begge fordele. Nu ser vi nærmere på zonesharding, som fastgør data til bestemte regioner.

Gratis at komme i gang

Lær JavaScript med en AI-underviser — gratis

Skriv og kør rigtig kode i din browser, få øjeblikkelig hjælp fra en AI-underviser døgnet rundt, og fortsæt, hvor du slap, på web eller i appen.

Kurser: 30
Lektioner: 120

Start gratis Se hele kurset

Ofte stillede spørgsmål

Er lektionen “Rangeret kontra hash-baseret sharding” gratis?

Ja — hele teksten til “Rangeret kontra hash-baseret sharding” kan læses gratis her på nettet. Hvis du vil øve dig interaktivt med en indbygget kodeeditor og en AI-vejleder døgnet rundt og få adgang til resten af MongoDB Academy-kurset, skal du opgradere til CoddyKit PRO. MongoDB Academy-kurset indeholder 4 lektioner i alt.

Hvad lærer jeg i “Rangeret kontra hash-baseret sharding”?

De lærende vil konfigurere en samling med rangeret sharding til intervalforespørgsler eller hash-baseret sharding til ensartet skrivefordeling og sammenligne deres afvejninger. Du øver dig i MongoDB Academy med praktisk kode, som du kører direkte i browseren, og en AI-vejleder døgnet rundt besvarer dine spørgsmål, mens du arbejder dig gennem lektionen.

Skal jeg have erfaring for at begynde på MongoDB Academy?

Der kræves ingen tidligere erfaring. MongoDB Academy på CoddyKit er tilrettelagt for både begyndere og øvede, så du kan starte her eller fra begyndelsen og lære i dit eget tempo. Dette er lektion 3 af 4.

Hvor lang tid tager lektionen “Rangeret kontra hash-baseret sharding”?

De fleste CoddyKit-lektioner tager cirka 5–10 minutter. Hver lektion er kort og interaktiv, så du gør løbende fremskridt og kan fortsætte, hvor du slap – på både web og app.

Kan jeg skrive og køre kode i denne MongoDB Academy-lektion?

Ja. Alle MongoDB Academy-lektioner har en indbygget kodeeditor, så du kan skrive og køre rigtig kode direkte i din browser og få øjeblikkelig feedback fra AI – uden lokal opsætning.

Alle lektioner i dette kursus

Shardingkoncepter: chunks, balancer og shard keys
Valg af shard key: kardinalitet, frekvens og monotonitet
Rangeret kontra hash-baseret sharding
Zonesharding: Binding af data til regioner

← Tilbage til MongoDB Academy