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.

  • 🧩 Kärnkoncept: Sharding partitionerar en logisk samling över många shards, men frågor behandlar fortfarande data som en enda samling.
  • 🏗️ Cluster Komponenter: Ett shardat kluster behöver shards för data, en konfigurationsserver för metadata och en router för att dirigera klientkommandon.
  • ⚙️ Implementeringsflöde: Starta konfigurationsservern, starta mongos-routern, lägg till shards och aktivera sedan sharding på databasen och samlingen.
  • 🔑 Shard-nyckel: Shard-nyckeln avgör hur dokument distribueras, så hög kardinalitet och jämna åtkomstmönster är avgörande.
  • 📈 Primär fördel: Sharding ger horisontell skalbarhet, vilket sprider lagring och arbetsbelastning istället för att uppgradera en enda server.

MongoDB Sharding: Steg för steg handledning med exempel

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:

  1. 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.
  2. 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.
  3. 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.

Vanliga frågor

Ja. AI-verktyg kan analysera frågemönster och fältkardinalitet för att föreslå potentiella shard-nycklar och varna för monotona fält. Eftersom nyckeln är svår att ändra senare, validera eventuella rekommendationer mot verkliga arbetsbelastningar innan du tillämpar dem.

Ja. AI-baserad övervakning kan track-datatillväxt, CPU-belastning och frågetarens för att prognostisera när en enskild server kommer att bli överbelastad. Den markerar rätt tillfälle att shredda, men ingenjörer bör bekräfta kapacitetsplaner innan de agerar.

Avståndsbaserad sharding delar upp data i sammanhängande värdeintervall, vilket passar för intervallfrågor men riskerar ojämna delar. Hashad sharding-hash är nyckeln till att sprida skrivningar jämnt över shards, vilket förbättrar skrivfördelningen på bekostnad av effektiva intervallskanningar.

Ja. Aktivera sharding på databasen, se till att det finns ett index på den valda shard-nyckeln och kör sedan sh.shardCollection() på namnrymden. MongoDB börjar automatiskt distribuera befintliga dokument i block över de tillgängliga shards.

Sammanfatta detta inlägg med: