En utvecklarguide till MongoDB Sharding

En enorm ökning av data kommer med en kostnad för minskad genomströmning, särskilt när den betjänas av en enda server. Du kan dock förbättra denna prestanda genom att öka antalet servrar och även distribuera din data på flera antal av dessa servrar. I den här artikeln, Replica-set i MongoDB, diskuterade vi i detalj hur genomströmningsoperationerna kan förbättras förutom att säkerställa hög tillgänglighet av data. Denna process kan inte uppnås helt utan att nämna Sharding i MongoDB.

Vad är Sharding i MongoDB

MongoDB är utformad på ett flexibelt sätt så att det är skalbart för dig att köra i ett kluster över en distribuerad plattform. I denna plattform distribueras data över ett antal servrar för lagring. Denna process är vad som kallas skärning. Om en enskild server utsätts för en stor mängd data för lagring kan du få slut på lagringsutrymmet. Dessutom kan mycket kritiska genomströmningsoperationer som läsning och skrivning påverkas i stor utsträckning. Den horisontella skalningsfunktionen i MongoDB gör det möjligt för oss att distribuera data över flera maskiner med ett slutresultat av förbättrad lastbalansering.

MongoDB Shards

En shard kan anses vara en replikuppsättning som är värd för någon dataundergrupp som används i ett fragmenterat kluster. För en given mongod-instans med någon uppsättning data delas data upp och distribueras över ett antal databaser i detta fall shards. I grund och botten fungerar ett antal olika skärvor som oberoende databaser men tillsammans utgör de en logisk databas. Shards minskar arbetsbelastningen som ska utföras av hela databasen genom att minska antalet operationer som en shard ska hantera förutom den mindre mängden data som denna shard kommer att vara värd för. Detta mått ger utrymme för expansion av ett kluster horisontellt. En enkel arkitektur för skärning visas nedan.

Data som skickas från en klientapplikation fångas upp av serverdrivrutiner och matas sedan till routern. Routern kommer sedan att konsultera serverkonfigurationerna för att bestämma var läs- eller skrivoperationen ska tillämpas på shard-servrarna. I ett nötskal, för en operation som skriv, har den något index som kommer att diktera vilken shard som är posten som ska vara värd. Låt oss säga att en databas har 1 TB datakapacitet fördelat på 4 skärvor, varje skärva kommer att innehålla 256 GB av denna data. Med en minskad mängd data som en skärva kan hantera kan operationer utföras ganska snabbt. Du bör överväga att använda det fragmenterade klustret i din databas när:

Du förväntar dig att mängden data kommer att överträffa din lagringskapacitet för enstaka instanser i framtiden.
Om skrivoperationerna inte kan utföras av den enda MongodB-instansen
Du får slut på Random Access Memory RAM på bekostnad av ökad storlek på den aktiva arbetsuppsättningen.

Sharding kommer med ökad komplexitet i arkitekturen förutom ytterligare resurser. Det är dock tillrådligt att göra klippning i tidiga skeden innan din data växer ur eftersom det är ganska tråkigt att göra det när din data är över kapacitet.

MongoDB Shard Key

Som vi alla vet har ett dokument i MongoDB fält för att hålla värden. När du distribuerar en sharding måste du välja ett fält från en samling som du ska använda för att dela upp data. Det här fältet du valde är shard-nyckeln som bestämmer hur du ska dela upp dokumenten i samlingen över ett antal shards. I ett enkelt exempel kan din data ha fältnamn elever, klasslärare och märken. Du kan bestämma att en skärvuppsättning ska innehålla dokumenten med indexstudenten, en annan lärare och märken. Du kan dock kräva att din data distribueras slumpmässigt och använd därför en hashad shard-nyckel. Det finns en rad shard-nycklar som används för att dela data förutom den hashade shard-nyckeln, men de två huvudkategorierna är indexerade fält och indexerade sammansatta fält.

Välja en Shard Key

För bättre funktionalitet, kapacitet och prestanda för skärningsstrategin måste du välja lämplig skärningsnyckel. Urvalskriterierna är beroende av två faktorer:

Schemastruktur för dina data. Vi kan till exempel betrakta ett fält vars värde kan vara ökande eller minskande (förändras monotont). Detta kommer med största sannolikhet att påverka en fördelning av inlägg till en enda skärva inom ett kluster.
Hur dina frågekonfigurationer visas för att utföra skrivoperationer.

Vad är en Hashed Shard Key

Detta använder ett hashat index för ett enskilt fält som shard-nyckel. Ett hashat index är ett index som upprätthåller poster med hash av värdena för ett indexerat fält.dvs

{
    "_id" :"5b85117af532da651cc912cd"
}

För att skapa ett hashat index kan du använda det här kommandot i mongoskalet.

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

Där hashedValue-variabeln representerar en sträng av ditt angivna hashvärde. Hashed sharding främjar jämn datadistribution över ett fragmenterat kluster och minskar därigenom måloperationer. Dokument med nästan samma shard-nycklar kan dock osannolikt finnas på samma shard, vilket kräver att en mongoinstans gör en broadcast-operation för att uppfylla ett givet frågekriterium.

Räckviddsbaserad Shard-nyckel

I den här kategorin är datamängden uppdelad baserat på värdeintervall för en vald fältnyckel, vilket innebär ett stort antal partitioner. d.v.s. om du har en numerisk nyckel vars värden går från negativ oändlighet till positiv oändlighet, kommer varje skärvnyckel att hamna på en viss punkt inom den linjen. Denna linje är uppdelad i bitar där varje bit har ett visst värdeintervall. Exakt, de dokument med nästan liknande shard-nyckel finns i samma bit. Fördelen med denna teknik är att den stöder en rad frågor eftersom routern kommer att välja skärvan med den specifika biten.

Kännetecken hos en Optimal Shard Key

En idealisk shardnyckel bör kunna rikta in sig på en enstaka shard för att förbättra ett mongos-program för att returnera frågeoperationer från en enda mongod-instans. Det primära fältet kännetecknar detta. d.v.s. inte i ett inbäddat dokument.
Ha en hög grad av slumpmässighet. Det vill säga att fältet ska finnas tillgängligt i de flesta dokument. Detta säkerställer att skrivoperationer distribueras inom en shard.
Var lätt delbar. Med en lätt delbar shard-nyckel blir det ökad datadistribution och därmed fler shards.

Severalnines Become a MongoDB DBA - Bringing MongoDB to ProductionLäs om vad du behöver veta för att distribuera, övervaka, hantera och skala MongoDBDownload gratis

Komponenter i en produktionsklusterdistribution

När det gäller arkitekturen som visas ovan bör produktionsskärvklustret ha:

Mongos/Query-routrar. Dessa är mongo-instanser som fungerar som en server mellan applikationsdrivrutiner och själva databasen. I distributionen är lastbalanseraren konfigurerad för att möjliggöra anslutning från en enda klient för att nå samma mongos.
Skärvor. Det här är de partitioner inom vilka dokument som delar samma shard-nyckeldefinition är värd. Du bör ha minst 2 för att öka tillgängligheten för data.
Konfigurationsservrar:du kan antingen ha 3 separata konfigurationsservrar på olika maskiner eller en grupp av dem om du kommer att ha flera delade kluster.

Distribution av ett delat kluster

Följande steg ger dig en tydlig riktning mot att distribuera ditt sönderdelade kluster.

Skapar värd för konfigurationsservrarna. Som standard är serverfilerna tillgängliga i katalogen /data/configdb men du kan alltid ställa in den till din föredragna katalog. Kommandot för att skapa datakatalogen är:
```
$ mkdir /data/configdb
```
Starta konfigurationsservrarna genom att definiera porten och filsökvägen för varje med kommandot
```
$ mongod --configsvr --dbpath /data/config --port 27018
```
Detta kommando startar konfigurationsfilen i datakatalogen med namnet config på port 27018. Som standard körs alla MongoDB-servrar på port 27017.
Starta en mongos-instans med syntaxen:
```
$ mongo --host hostAddress --port 27018.
```
Variabeln hostAddress kommer att ha värdet för värdnamnet eller ip-adressen för din värd.
Starta mongod på shard-servern och initiera den med kommandot:
```
mongod --shardsvr --replSet
rs.initiate()
```
Starta dina mongos på routern med kommandot:
```
mongos --configdb rs/mongoconfig:27018
```
Lägga till skärvor i ditt kluster. Låt oss säga att vi har standardporten 27017 som vårt kluster, vi kan lägga till en shard på port 27018 så här:
```
mongo --host mongomaster --port 27017
sh.addShard( "rs/mongoshard:27018")
{ "shardAdded" : "rs", "ok" : 1 }
```

Aktivera sharding för databasen med shardnamnet med kommandot:

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

Du kan kontrollera statusen för skärvan med kommandot:

sh.status()

Du kommer att presenteras med denna information

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 }

Skärvbalansering

Efter att ha lagt till en shard till ett kluster, kan du observera att vissa shards fortfarande kan vara värd för mer data än andra och för att vara mer sekant kommer den nya shard att inte ha någon data. Du måste därför köra några bakgrundskontroller för att säkerställa lastbalansen. Balansering är grunden för vilken data omfördelas i ett kluster. Balanseraren kommer att upptäcka en ojämn fördelning och migrera därför bitar från en skärva till en annan tills ett balanskvorum uppnås.

Balanseringsprocessen förbrukar mycket bandbredd förutom omkostnader för arbetsbelastning och detta kommer att påverka driften av din databas. En bättre balanseringsprocess innebär:

Flytta en enskild bit åt gången.
Gör balanseringen när migreringströskeln har nåtts, det vill säga när skillnaden mellan det lägsta antalet bitar för en given samling och det högsta antalet bitar i den splittrade samlingen.