En udviklervejledning til MongoDB Sharding

En massiv vækst af data kommer med en omkostning ved reduceret gennemløbsoperationer, især når de betjenes af en enkelt server. Du kan dog forbedre denne ydeevne ved at øge antallet af servere og også distribuere dine data på flere numre af disse servere. I denne artikel, Replica-sæt i MongoDB, diskuterede vi detaljeret, hvordan gennemstrømningsoperationerne kan forbedres udover at sikre høj tilgængelighed af data. Denne proces kan ikke opnås fuldstændigt uden at nævne Sharding i MongoDB.

Hvad er Sharding i MongoDB

MongoDB er designet på en fleksibel måde, så det er skalerbart for dig at køre i en klynge på tværs af en distribueret platform. I denne platform distribueres data på tværs af en række servere til opbevaring. Denne proces er det, der betegnes som sønderdeling. Hvis en enkelt server udsættes for en stor mængde data til opbevaring, kan du løbe tør for lagerplads. Derudover kan meget kritiske gennemstrømningsoperationer såsom læse og skrive blive påvirket i høj grad. Den horisontale skaleringsfunktion i MongoDB gør det muligt for os at distribuere data på tværs af flere maskiner med et slutresultat af forbedret belastningsbalancering.

MongoDB-skår

Et shard kan anses for at være et replikasæt, der er vært for nogle dataundersæt, der bruges i en sharded klynge. For en given mongod-instans med et eller andet sæt data, er dataene opdelt og fordelt på tværs af en række databaser i dette tilfælde shards. Grundlæggende fungerer en række forskellige shards som uafhængige databaser, men tilsammen udgør de en logisk database. Shards reducerer den arbejdsbyrde, der skal udføres af hele databasen, ved at reducere antallet af operationer, en shard skal håndtere udover den mindre mængde data, som denne shard vil være vært for. Denne metrik giver plads til at udvide en klynge horisontalt. En simpel arkitektur for sønderdeling er vist nedenfor.

Data sendt fra en klientapplikation opfanges af serverdrivere og føres derefter til routeren. Routeren vil derefter konsultere serverkonfigurationerne for at bestemme, hvor læse- eller skriveoperationen skal anvendes på shard-serverne. I en nøddeskal, for en operation som f.eks. skrivning, har den et eller andet indeks, som vil diktere, hvilken shard der er rekorden for at være vært. Lad os sige, at en database har 1 TB datakapacitet fordelt på 4 shards, hver shard vil indeholde 256 GB af disse data. Med en reduceret mængde data, som et shard kan håndtere, kan operationer udføres ret hurtigt. Du bør overveje at bruge den shardede klynge i din database, når:

Du forventer, at mængden af data i fremtiden vil overgå din lagerkapacitet for enkeltforekomster.
Hvis skrivehandlingerne ikke kan udføres af den enkelte MongodB-instans
Du løber tør for Random Access Memory RAM på bekostning af øget størrelse af det aktive arbejdssæt.

Sharding kommer med øget kompleksitet i arkitekturen udover yderligere ressourcer. Det er dog tilrådeligt at foretage sharding på et tidligt stadie, før dine data vokser ud, da det er ret kedeligt at gøre det, når dine data er over kapacitet.

MongoDB Shard Key

Som vi alle ved, har et dokument i MongoDB felter til at holde værdier. Når du implementerer en sharding, bliver du bedt om at vælge et felt fra en samling, som du vil bruge til at opdele dataene. Dette felt, du valgte, er shard-nøglen, som bestemmer, hvordan du vil opdele dokumenterne i samlingen på tværs af en række shards. I et simpelt eksempel kan dine data have feltnavne elever, klasselærere og mærker. Du kan beslutte, at et shard-sæt skal indeholde dokumenterne med indekseleven, et andet lærere og mærker. Du kan dog kræve, at dine data distribueres tilfældigt, og brug derfor en hashed shard-nøgle. Der er en række shard-nøgler, der bruges til at opdele data udover den hashed-shard-nøgle, men de to hovedkategorier er indekserede felter og indekserede sammensatte felter.

Valg af en Shard-nøgle

For bedre funktionalitet, kapacitet og ydeevne af sharding-strategien skal du vælge den passende sharded-nøgle. Udvælgelseskriterierne afhænger af 2 faktorer:

Skemastruktur for dine data. Vi kan for eksempel overveje et felt, hvis værdi kan være stigende eller faldende (ændres monotont). Dette vil højst sandsynligt påvirke en fordeling af inserts til et enkelt shard i en klynge.
Hvordan dine forespørgende konfigurationer er vist for at udføre skrivehandlinger.

Hvad er en hashed Shard Key

Dette bruger et hashed indeks for et enkelt felt som shard-nøgle. Et hash-indeks er et indeks, der vedligeholder poster med hashes af værdierne af et indekseret felt.i.e

{
    "_id" :"5b85117af532da651cc912cd"
}

For at oprette et hashed indeks kan du bruge denne kommando i mongo-skallen.

db.collection.createIndex( { _id: hashedValue } )

Hvor hashedValue-variablen repræsenterer en streng af din angivne hashværdi. Hashed sharding fremmer jævn datafordeling på tværs af en sharded klynge og reducerer derved måloperationer. Det er dog usandsynligt, at dokumenter med næsten samme shard-nøgler er på samme shard, og det kræver derfor, at en mongo-instans udfører en broadcast-operation for at opfylde et givet forespørgselskriterium.

Rangebaseret Shard-tast

I denne kategori er datasættet opdelt baseret på værdiintervaller for en valgt feltnøgle, og dermed et højt udvalg af partitioner. dvs. hvis du har en numerisk nøgle, hvis værdier går fra negativ uendelig til positiv uendelig, vil hver shard-tast falde på et bestemt punkt inden for den linje. Denne linje er opdelt i bidder, hvor hver chunk har en vis række af værdier. Præcis de dokumenter med næsten ens shard-nøgle er hostet i samme del. Fordelen ved denne teknik er, at den understøtter en række forespørgsler, da routeren vil vælge shard med den specifikke chunk.

Karakteristika for en Optimal Shard Key

En ideel shard-nøgle bør være i stand til at målrette mod et enkelt shard for at forbedre et mongos-program til at returnere forespørgselsoperationer fra en enkelt mongod-instans. Nøglen er primært felt karakteriserer dette. dvs. ikke i et indlejret dokument.
Har en høj grad af tilfældighed. Det vil sige, at feltet skulle være tilgængeligt i de fleste dokumenter. Dette sikrer, at skriveoperationer distribueres i et shard.
Vær let delelig. Med en let delelig shard-nøgle er der øget datafordeling og dermed flere shards.

Severalnines Bliv en MongoDB DBA - Bring MongoDB to ProductionLær om, hvad du skal vide for at implementere, overvåge, administrere og skalere MongoDBDownload gratis

Komponenter af en produktionsklynge-implementering

Med hensyn til arkitekturen vist ovenfor, skal produktionsshard-klyngen have:

Mongoer/Forespørgselsroutere. Disse er mongo-forekomster, der fungerer som en server mellem applikationsdrivere og selve databasen. Under implementering er belastningsbalanceren konfigureret til at muliggøre forbindelse fra en enkelt klient for at nå de samme mongoer.
Skår. Disse er de partitioner, inden for hvilke dokumenter, der deler den samme shard-nøgledefinition, hostes. Du bør have mindst 2 for at øge tilgængeligheden af data.
Konfigurationsservere:Du kan enten have 3 separate konfigurationsservere på forskellige maskiner eller en gruppe af dem, hvis du vil have flere shardede klynger.

Implementering af en Sharded Cluster

De følgende trin vil give dig en klar retning mod implementering af din sharded cluster.

Opretter vært for konfigurationsserverne. Som standard er serverfilerne tilgængelige i mappen /data/configdb, men du kan altid indstille dette til din foretrukne mappe. Kommandoen til at oprette databiblioteket er:
```
$ mkdir /data/configdb
```
Start konfigurationsserverne ved at definere porten og filstien for hver ved at bruge kommandoen
```
$ mongod --configsvr --dbpath /data/config --port 27018
```
Denne kommando starter konfigurationsfilen i databiblioteket med navnet config på port 27018. Som standard kører alle MongoDB-servere på port 27017.
Start en mongos-instans ved hjælp af syntaksen:
```
$ mongo --host hostAddress --port 27018.
```
HostAddress-variablen vil have værdien for værtsnavnet eller ip-adressen på din vært.
Start mongod på shard-serveren og start den ved at bruge kommandoen:
```
mongod --shardsvr --replSet
rs.initiate()
```
Start dine mongoer på routeren med kommandoen:
```
mongos --configdb rs/mongoconfig:27018
```
Tilføjelse af skår til din klynge. Lad os sige, at vi har standardporten til at være 27017 som vores klynge, vi kan tilføje et shard på port 27018 sådan her:
```
mongo --host mongomaster --port 27017
sh.addShard( "rs/mongoshard:27018")
{ "shardAdded" : "rs", "ok" : 1 }
```

Aktiver sharding for databasen ved at bruge shard-navnet med kommandoen:

sh.enableSharding(shardname)
{ "ok" : 1 }

Du kan kontrollere status for shard med kommandoen:

sh.status()

Du vil blive præsenteret for disse oplysninger

sharding version: {
"_id" : 1,
"minCompatibleVersion" : 5,
"currentVersion" : 6,
"clusterId" : ObjectId("59f425f12fdbabb0daflfa82")
}
shards:
{ "_id" : "rs", "host" : "rs/mongoshard:27018", "state" : 1 }
active mongoses:
"3.4.10" : 1
autosplit:
Currently enabled: yes
balancer:
Currently enabled: yes
Currently running: no
NaN
Failed balancer rounds in last 5 attempts: 0
Migration Results for the last 24 hours:
No recent migrations
databases:
{ "_id" : shardname, "primary" : "rs", "partitioned" : true }

Shard balancering

Efter at have tilføjet et shard til en klynge, vil du muligvis observere, at nogle shards stadig kan være vært for flere data end andre, og for at være mere sekant vil det nye shard ikke have nogen data. Du skal derfor køre nogle baggrundstjek for at sikre belastningsbalance. Balancering er grundlaget for, at data omfordeles i en klynge. Balanceren vil detektere en ujævn fordeling og migrerer derfor bidder fra et skår til et andet, indtil et balancekvorum er nået.

Balanceringsprocessen bruger masser af båndbredde udover arbejdsbyrde, og dette vil påvirke driften af din database. En bedre balanceringsproces indebærer:

Flytning af et enkelt stykke ad gangen.
Udfør balanceringen, når migreringstærsklen er nået, dvs. når forskellen mellem det laveste antal bidder for en given samling og det højeste antal bidder i den sønderdelte samling.