MongoDB Sharding: Steg för steg handledning med exempel
⚡ Smart sammanfattning
MongoDB Sharding delar upp stora datamängder i mindre delmängder fördelade över flera MongoDB instanser, vilket minskar CPU-belastningen på en enskild server. Ett shardat kluster kombinerar shards, en konfigurationsserver och en router för att skala lagring och frågedata horisontellt.
Vad är Sharding in MongoDB?
Sharding är ett begrepp inom MongoDB, som delar upp stora datamängder i små datamängder över flera MongoDB instanser.
Ibland data inom MongoDB kommer att vara så enorma att frågor mot sådana stora datamängder kan orsaka mycket CPU-utnyttjande på servern. För att hantera denna situation, MongoDB har ett koncept med Sharding, som i grunden är uppdelningen av datamängder över flera MongoDB instanser.
Samlingen, som kan vara stor i storlek, är faktiskt uppdelad i flera samlingar, eller Shards som de kallas. Logiskt sett fungerar alla shards som en samling.
Fördelar med sharding i MongoDB
Innan man implementerar ett shardat kluster är det bra att förstå varför team använder sharding. De viktigaste fördelarna är:
- Horisontell skalbarhet: Data distribueras över många standardservrar istället för att tvinga en enda maskin att växa sig allt större.
- Högre genomströmning: Läs- och skrivåtgärder körs parallellt över shards, så klustret hanterar fler begäranden per sekund.
- Större lagringskapacitet: Den kombinerade disken med alla shards kan innehålla datamängder som är mycket större än vad en server skulle kunna lagra.
- Hög tillgänglighet: När varje shard distribueras som en replikuppsättning, kommer inte klustret att stängas av om en enskild nod misslyckas.
- Balanserad last: Ocuco-landskapet MongoDB Balancer omdistribuerar datablock automatiskt för att förhindra att en enskild shard blir en hotspot.
Tillsammans gör dessa fördelar sharding till standardmetoden för skalning MongoDB bortom gränserna för en enda server.
Hur man implementerar Sharding
Shards implementeras med hjälp av kluster, vilka inte är något annat än en grupp av MongoDB instanser.
Komponenterna i en Shard inkluderar:
- Lika hård – Det här är det grundläggande, och det här är inget annat än en MongoDB instans som innehåller delmängden av datan. I produktionsmiljöer måste alla skärvor vara en del av replikuppsättningar.
- Konfigurera server - Det här är en MongoDB instans som innehåller metadata om klustret, i princip information om de olika MongoDB instanser som kommer att lagra shard-data.
- En router - Det här är en MongoDB instans som i grunden ansvarar för att omdirigera kommandon som skickas av klienten till rätt servrar.
Steg för steg skärning Cluster Exempelvis
Steg 1) Skapa en separat databas för konfigurationsservern.
mkdir /data/configdb
Steg 2) Starta MongoDB instans i konfigurationsläge. Anta att vi har en server som heter Server D, vilket skulle vara vår konfigurationsserver. Vi skulle behöva köra kommandot nedan för att konfigurera servern som en konfigurationsserver.
mongod --configdb ServerD:27019
Steg 3) Starta mongos-instansen genom att ange konfigurationsservern.
mongos --configdb ServerD:27019
Steg 4) Från mongo-skalet, anslut till mongos-instansen.
mongo --host ServerD --port 27017
Steg 5) Om du har Server A och Server B som behöver läggas till i klustret, kör följande kommandon.
sh.addShard("ServerA:27017") sh.addShard("ServerB:27017")
Steg 6) Aktivera sharding för databasen. Så om vi behöver sharda Employeedb-databasen, kör kommandot nedan.
sh.enableSharding("Employeedb")
Steg 7) Aktivera sharding för samlingen. Så om vi behöver sharda Employee-samlingen, kör kommandot nedan.
sh.shardCollection("Employeedb.Employee", { "Employeeid": 1, "EmployeeName": 1 })
Hur man väljer en Shard-nyckel i MongoDB
Shard-nyckeln är det indexerade fältet, eller den indexerade uppsättningen fält, som MongoDB använder för att bestämma vilken shard som lagrar varje dokument. Eftersom nyckeln styr datadistributionen är det enskilt viktigaste beslutet i en shardad distribution att välja den väl. En dålig nyckel koncentrerar data och trafik på en shard, vilket omintetgör fördelarna med sharding.
En stark shard-nyckel har generellt följande egenskaper:
- Hög kardinalitet: Fältet bör ha många möjliga värden så att data kan delas upp i många finkorniga delar.
- Låg frekvens: Inget enskilt värde bör dominera, annars staplas dokumenten som delar det värdet på en shard.
- Icke-monoton förändring: Nycklar som alltid ökar, till exempel tidsstämplar, skickar varje ny skrivning till samma shard, vilket skapar en hotspot.
MongoDB stöder två sharding-strategier baserade på nyckeln. Ranged sharding delar upp data i sammanhängande intervall och passar intervallfrågor, medan hashad sharding tillämpar en hashfunktion för att sprida skrivningar jämnt över shards. Team börjar ofta med hashad sharding när skrivningarna är stora och byter till ranged sharding när intervallbaserade läsningar dominerar. Oavsett vilken strategi du väljer, testa nyckeln mot realistiska frågemönster innan du genomför, eftersom shard-nyckeln inte enkelt kan ändras när data har laddats.
Sharding kontra replikering i MongoDB
Sharding och replikering är kompletterande men distinkta funktioner. Tabellen nedan visar skillnaderna så att du kan tillämpa var och en korrekt, och i praktiken använder produktionskluster båda tillsammans.
| Aspect | Sharding | replikation |
|---|---|---|
| Syfte | Skala horisontellt genom att dela data | Skydda data och håll dem tillgängliga |
| Data på varje nod | En delmängd (en shard) av data | En fullständig kopia av informationen |
| Primär fördel | Mer lagring och dataflöde | Feltolerans och lässkalning |
| Nyckelkomponenter | Shards, konfigurationsserver, mongos-router | Primär- och sekundärmedlemmar |
Kort sagt, sharding svarar på behovet av skalbarhet, medan replikering svarar på behovet av tillgänglighet, och en robust distribution kombinerar båda.

