MongoDB Sharing: Trin for trin vejledning med eksempel
Stephen Twain
⚡ Smart opsummering
MongoDB Sharding opdeler store datasæt i mindre delmængder fordelt på flere MongoDB instanser, hvilket reducerer CPU-belastningen på en enkelt server. En sharded-klynge kombinerer shards, en konfigurationsserver og en router for at skalere lager og forespørgselsgennemstrømning horisontalt.
Hvad er Sharding i MongoDB?
Sharding er et begreb i MongoDB, som opdeler store datasæt i små datasæt på tværs af flere MongoDB forekomster.
Nogle gange data indeni MongoDB vil være så enorme, at forespørgsler mod så store datasæt kan forårsage en stor CPU-udnyttelse på serveren. For at håndtere denne situation, MongoDB har et koncept med Sharding, som grundlæggende er opdeling af datasæt på tværs af flere MongoDB forekomster.
Samlingen, som kan være stor i størrelse, er faktisk opdelt på tværs af flere samlinger, eller Shards, som de kaldes. Logisk set fungerer alle shards som én samling.
Fordele ved sharding i MongoDB
Før man implementerer en sharded cluster, er det nyttigt at forstå, hvorfor teams anvender sharding. De vigtigste fordele er:
- Horisontal skalerbarhed: Data distribueres på tværs af mange standardservere i stedet for at tvinge en enkelt maskine til at vokse sig stadig større.
- Højere gennemløb: Læse- og skriveoperationer kører parallelt på tværs af shards, så klyngen håndterer flere anmodninger pr. sekund.
- Større lagerkapacitet: Den kombinerede disk med alle shards kan indeholde datasæt, der er langt større, end én server kan gemme.
- Høj tilgængelighed: Når hver shard implementeres som et replikasæt, vil fejl i en enkelt node ikke føre til, at klyngen lukker ned.
- Balanceret belastning: MongoDB Balancer omfordeler automatisk datastykker for at forhindre, at en enkelt shard bliver et hotspot.
Tilsammen gør disse fordele sharding til standardmetoden til skalering MongoDB ud over grænserne for en enkelt server.
Sådan implementeres Sharding
Shards implementeres ved hjælp af klynger, som ikke er andet end en gruppe af MongoDB forekomster.
Komponenterne i en Shard inkluderer:
- En skærv – Det er det grundlæggende, og det er ikke andet end en MongoDB instans, som indeholder delmængden af dataene. I produktionsmiljøer skal alle shards være en del af replikasæt.
- Konfigurationsserver - Dette er en MongoDB instans, der indeholder metadata om klyngen, dybest set information om de forskellige MongoDB instanser, der vil indeholde shard-dataene.
- En router - Dette er en MongoDB instans, som grundlæggende er ansvarlig for at omdirigere de kommandoer, der sendes af klienten, til de rigtige servere.
Trin for trin skæring Cluster Eksempel
Trin 1) Opret en separat database til konfigurationsserveren.
mkdir /data/configdb
Trin 2) Start MongoDB instans i konfigurationstilstand. Antag, at vi har en server ved navn Server D, som ville være vores konfigurationsserver. Vi skal køre nedenstående kommando for at konfigurere serveren som en konfigurationsserver.
mongod --configdb ServerD:27019
Trin 3) Start mongos-instansen ved at angive konfigurationsserveren.
mongos --configdb ServerD:27019
Trin 4) Fra mongo-shellen skal du oprette forbindelse til mongos-instansen.
mongo --host ServerD --port 27017
Trin 5) Hvis du har Server A og Server B, som skal føjes til klyngen, skal du udstede nedenstående kommandoer.
sh.addShard("ServerA:27017") sh.addShard("ServerB:27017")
Trin 6) Aktivér sharding for databasen. Hvis vi har brug for at shardere Employeedb-databasen, skal du udføre nedenstående kommando.
sh.enableSharding("Employeedb")
Trin 7) Aktivér sharding for samlingen. Så hvis vi har brug for at shard-e Employee-samlingen, skal du udstede nedenstående kommando.
sh.shardCollection("Employeedb.Employee", { "Employeeid": 1, "EmployeeName": 1 })
Sådan vælger du en Shard-nøgle i MongoDB
Shard-nøglen er det indekserede felt eller sæt af felter, der MongoDB bruger til at bestemme, hvilken shard der gemmer hvert dokument. Fordi nøglen styrer datadistributionen, er det den vigtigste beslutning i en sharded-implementering at vælge den korrekt. En dårlig nøgle koncentrerer data og trafik på én shard, hvilket ophæver fordelene ved sharding.
En stærk shard-nøgle har generelt følgende egenskaber:
- Høj kardinalitet: Feltet skal have mange mulige værdier, så data kan opdeles i mange finkornede bidder.
- Lav frekvens: Ingen enkelt værdi bør dominere, ellers hober dokumenterne, der deler den værdi, sig op på én shard.
- Ikke-monoton ændring: Nøgler, der altid stiger, såsom tidsstempler, sender alle nye skrivninger til den samme shard og skaber et hotspot.
MongoDB understøtter to sharding-strategier baseret på nøglen. Ranged sharding opdeler data i sammenhængende områder og passer til områdeforespørgsler, mens hashed sharding anvender en hash-funktion til at fordele skrivninger jævnt på tværs af shards. Teams starter ofte med hashed sharding, når der er mange skrivninger, og skifter til ranged sharding, når områdebaserede læsninger dominerer. Uanset hvilken strategi du vælger, skal du teste nøglen mod realistiske forespørgselsmønstre, før du committer, da shard-nøglen ikke let kan ændres, når dataene er indlæst.
Sharding vs. Replikering i MongoDB
Sharding og replikering er komplementære, men forskellige funktioner. Tabellen nedenfor fremhæver forskellene, så du kan anvende hver enkelt korrekt, og i praksis bruger produktionsklynger begge sammen.
| Aspect | sharding | Replication |
|---|---|---|
| Formål | Skalér vandret ved at opdele data | Beskyt data og hold dem tilgængelige |
| Data på hver node | En delmængde (én shard) af dataene | En fuld kopi af dataene |
| Primær fordel | Mere lagerplads og gennemløbshastighed | Fejltolerance og læseskalering |
| Nøglekomponenter | Shards, konfigurationsserver, mongos-router | Primære og sekundære medlemmer |
Kort sagt imødekommer sharding behovet for skalering, mens replikering imødekommer behovet for tilgængelighed, og en robust implementering kombinerer begge dele.
