Een handleiding voor ontwikkelaars voor MongoDB Sharding

Een enorme groei van gegevens gaat gepaard met kosten voor verminderde doorvoer, vooral wanneer ze worden bediend door een enkele server. U kunt deze prestatie echter verbeteren door het aantal servers te vergroten en uw gegevens ook over meerdere nummers van deze servers te verspreiden. In dit artikel, Replica-sets in MongoDB, hebben we in detail besproken hoe de doorvoerbewerkingen kunnen worden verbeterd, naast het garanderen van een hoge beschikbaarheid van gegevens. Dit proces kan niet volledig worden bereikt zonder Sharding in MongoDB te vermelden.

Wat is Sharding in MongoDB

MongoDB is op een flexibele manier ontworpen, zodat het schaalbaar is om in een cluster over een gedistribueerd platform te draaien. In dit platform worden gegevens voor opslag over een aantal servers verdeeld. Dit proces wordt sharding genoemd. Als een enkele server wordt onderworpen aan een grote hoeveelheid gegevens voor opslag, kan de opslagruimte opraken. Bovendien kunnen zeer kritische doorvoerbewerkingen zoals lezen en schrijven in grote mate worden beïnvloed. De horizontale schaalfunctie in MongoDB stelt ons in staat om gegevens over meerdere machines te distribueren met als eindresultaat een betere taakverdeling.

MongoDB-scherven

Een shard kan worden beschouwd als een replicaset die als host fungeert voor een gegevenssubset die wordt gebruikt in een shardcluster. Voor een bepaalde mongod-instantie met een set gegevens worden de gegevens gesplitst en gedistribueerd over een aantal databases, in dit geval shards. Kortom, een aantal verschillende shards dienen als onafhankelijke databases, maar samen vormen ze een logische database. Shards verminderen de werk belasting die door de hele database moet worden uitgevoerd door het aantal bewerkingen te verminderen dat een shard moet verwerken, naast de kleinere hoeveelheid gegevens die deze shard zal hosten. Deze statistiek geeft ruimte voor de uitbreiding van een cluster horizontaal. Hieronder ziet u een eenvoudige architectuur van sharding.

Gegevens die door een clienttoepassing worden verzonden, worden onderschept door serverstuurprogramma's en vervolgens naar de router gevoerd. De router raadpleegt vervolgens de serverconfiguraties om te bepalen waar de lees- of schrijfbewerking op de shardservers moet worden toegepast. In een notendop, voor een bewerking zoals schrijven, heeft het een index die dicteert naar welke shard het record de host moet zijn. Laten we zeggen dat een database 1 TB datacapaciteit heeft, verdeeld over 4 shards, elke shard zal 256 GB van deze gegevens bevatten. Met een verminderde hoeveelheid gegevens die een shard aankan, kunnen bewerkingen vrij snel worden uitgevoerd. Overweeg het gebruik van het shard-cluster in uw database wanneer:

U verwacht dat de hoeveelheid gegevens in de toekomst uw opslagcapaciteit voor één instantie zal overtreffen.
Als de schrijfbewerkingen niet kunnen worden uitgevoerd door de enkele MongodB-instantie
U heeft geen RAM meer in het RAM-geheugen met willekeurige toegang ten koste van de grotere omvang van de actieve werkset.

Sharding wordt geleverd met een verhoogde complexiteit in de architectuur naast extra bronnen. Het is echter aan te raden om sharding in een vroeg stadium uit te voeren voordat uw gegevens te groot worden, aangezien het nogal vervelend is om dit te doen wanneer uw gegevens te groot zijn.

MongoDB Shard-sleutel

Zoals we allemaal weten, heeft een document in MongoDB velden voor het vasthouden van waarden. Wanneer u een sharding implementeert, moet u een veld uit een verzameling selecteren dat u gaat gebruiken om de gegevens te splitsen. Dit veld dat u hebt geselecteerd, is de shard-sleutel die bepaalt hoe u de documenten in de verzameling over een aantal shards gaat splitsen. In een eenvoudig voorbeeld kunnen uw gegevens veldnamen hebben:studenten, klasdocenten en cijfers. U kunt beslissen dat één shardset de documenten met de indexstudent, een andere docenten en cijfers bevat. U kunt echter vereisen dat uw gegevens willekeurig worden verspreid en daarom een gehashte Shard-sleutel gebruiken. Er is een reeks shardsleutels die worden gebruikt bij het splitsen van gegevens naast de gehashte shardsleutel, maar de twee hoofdcategorieën zijn geïndexeerde velden en geïndexeerde samengestelde velden.

Een Shard-sleutel kiezen

Voor betere functionaliteit, mogelijkheden en prestaties van de sharding-strategie moet u de juiste sharded-sleutel selecteren. De selectiecriteria zijn afhankelijk van 2 factoren:

Schemastructuur van uw gegevens. We kunnen bijvoorbeeld een veld beschouwen waarvan de waarde kan toenemen of afnemen (monotoon veranderen). Dit zal hoogstwaarschijnlijk invloed hebben op een distributie van inserts naar een enkele scherf binnen een cluster.
Hoe uw queryconfiguraties worden weergegeven om schrijfbewerkingen uit te voeren.

Wat is een gehashte Shard-sleutel

Dit gebruikt een gehashte index van een enkel veld als de Shard-sleutel. Een gehashte index is een index die items bijhoudt met hashes van de waarden van een geïndexeerd veld.d.w.z.

{
    "_id" :"5b85117af532da651cc912cd"
}

Om een gehashte index te maken, kun je dit commando in de mongo-shell gebruiken.

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

Waarbij de hashedValue-variabele een tekenreeks van uw opgegeven hash-waarde vertegenwoordigt. Gehashte sharding bevordert een gelijkmatige gegevensdistributie over een shard-cluster, waardoor doelbewerkingen worden verminderd. Het is echter onwaarschijnlijk dat documenten met bijna dezelfde Shard-sleutels zich op dezelfde Shard bevinden, waardoor een mongo-instantie een broadcast-bewerking moet uitvoeren om aan een bepaald zoekcriterium te voldoen.

Op bereik gebaseerde Shard-sleutel

In deze categorie wordt de dataset gepartitioneerd op basis van waardebereiken van een gekozen veldsleutel, vandaar een groot aantal partities. D.w.z. als u een numerieke sleutel hebt waarvan de waarden lopen van negatief oneindig tot positief oneindig, valt elke Shard-sleutel op een bepaald punt binnen die lijn. Deze regel is verdeeld in chunks, waarbij elke chunk een bepaald waardenbereik heeft. Precies, die documenten met bijna dezelfde shard-sleutel worden in hetzelfde stuk gehost. Het voordeel van deze techniek is dat het een reeks zoekopdrachten ondersteunt, aangezien de router de shard met het specifieke stuk selecteert.

Kenmerken van een optimale Shard-sleutel

Een ideale shard-sleutel zou in staat moeten zijn om een enkele shard te targeten om een mongos-programma te verbeteren om querybewerkingen van een enkele mongod-instantie te retourneren. De sleutel die het primaire veld is, kenmerkt dit. D.w.z. niet in een ingesloten document.
Een hoge mate van willekeur hebben. Dit wil zeggen dat het veld in de meeste documenten beschikbaar moet zijn. Dit zorgt ervoor dat schrijfbewerkingen binnen een shard worden gedistribueerd.
Wees gemakkelijk deelbaar. Met een gemakkelijk deelbare shard-sleutel is er meer gegevensdistributie en dus meer shards.

Multiplenines Word een MongoDB DBA - MongoDB naar productie brengenLeer over wat u moet weten om MongoDB gratis te implementeren, bewaken, beheren en schalen

Componenten van een implementatie van een productiecluster

Wat betreft de hierboven getoonde architectuur, zou het productie-shardcluster het volgende moeten hebben:

Mongo's/ Query-routers. Dit zijn mongo-instanties die fungeren als een server tussen applicatiestuurprogramma's en de database zelf. Tijdens de implementatie is de load balancer zo geconfigureerd dat verbinding vanaf een enkele client dezelfde mongo's kan bereiken.
Scherven. Dit zijn de partities waarbinnen documenten die dezelfde Shard-sleuteldefinitie delen, worden gehost. U moet er minimaal 2 hebben om de beschikbaarheid van gegevens te vergroten.
Config-servers:u kunt ofwel 3 afzonderlijke configuratieservers op verschillende machines hebben of een groep daarvan als u meerdere shard-clusters hebt.

Inzet van een Sharded Cluster

De volgende stappen geven u een duidelijke richting voor het implementeren van uw Sharded-cluster.

Host maken voor de configuratieservers. Standaard zijn de serverbestanden beschikbaar in de directory /data/configdb, maar u kunt dit altijd instellen op de directory van uw voorkeur. De opdracht voor het maken van de gegevensmap is:
```
$ mkdir /data/configdb
```
Start de configuratieservers door de poort en het bestandspad voor elk te definiëren met behulp van de opdracht
```
$ mongod --configsvr --dbpath /data/config --port 27018
```
Deze opdracht start het configuratiebestand in de datadirectory met de naam config op poort 27018. Standaard draaien alle MongoDB-servers op poort 27017.
Start een mongos-instantie met behulp van de syntaxis:
```
$ mongo --host hostAddress --port 27018.
```
De hostAddress-variabele heeft de waarde voor de hostnaam of het ip-adres van uw host.
Start mongod op de shard-server en start het met het commando:
```
mongod --shardsvr --replSet
rs.initiate()
```
Start je mongo's op de router met het commando:
```
mongos --configdb rs/mongoconfig:27018
```
Shards toevoegen aan uw cluster. Laten we zeggen dat we de standaardpoort 27017 hebben als ons cluster, we kunnen een shard op poort 27018 als volgt toevoegen:
```
mongo --host mongomaster --port 27017
sh.addShard( "rs/mongoshard:27018")
{ "shardAdded" : "rs", "ok" : 1 }
```

Schakel sharding in voor de database met behulp van de shardnaam met de opdracht:

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

U kunt de status van de scherf controleren met het commando:

sh.status()

U krijgt deze informatie te zien

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 }

Shardbalancering

Nadat u een shard aan een cluster hebt toegevoegd, ziet u mogelijk dat sommige shards nog steeds meer gegevens hosten dan andere en om secanter te zijn, zal de nieuwe shard geen gegevens bevatten. U moet daarom een aantal achtergrondcontroles uitvoeren om de load balance te garanderen. Balanceren is de basis waarvoor data in een cluster wordt herverdeeld. De balancer detecteert een ongelijke verdeling en migreert daarom brokken van de ene shard naar de andere totdat een evenwichtsquorum is bereikt.

Het balanceringsproces verbruikt naast de overhead van de workload ook veel bandbreedte en dit heeft invloed op de werking van uw database. Een beter evenwichtsproces omvat:

Een enkel stuk tegelijk verplaatsen.
Voer de balans uit wanneer de migratiedrempel is bereikt, dat wil zeggen wanneer het verschil tussen het laagste aantal chunks voor een bepaalde verzameling en het hoogste aantal chunks in de shard-verzameling.