Het implementeren van een geclusterde database is één ding, maar hoe u uw DBM onderhoudt terwijl u zich in een cluster bevindt, kan een grote onderneming zijn voor een consistente bediening van uw applicaties. Men zou de status van de database vaak moeten bijwerken, vooral de meest cruciale statistieken om een idee te krijgen van wat te upgraden of beter gezegd te wijzigen om eventuele knelpunten te voorkomen.
Er zijn veel overwegingen met betrekking tot MongoDB waar men rekening mee moet houden, vooral het feit dat het installeren en draaien vrij eenvoudig is, de kans is groot dat de basispraktijken voor databasebeheer worden verwaarloosd.
Vaak houden ontwikkelaars geen rekening met toekomstige groei en toenemend gebruik van de database, wat resulteert in het crashen van applicaties of gegevens met enkele integriteitsproblemen, behalve dat ze inconsistent zijn.
In dit artikel gaan we enkele van de best practices bespreken die men zou moeten gebruiken voor MongoDB-cluster voor een efficiënte prestatie van uw applicaties. Enkele van de factoren waarmee u rekening moet houden, zijn onder meer...
- Upgraden naar de nieuwste versie
- Geschikte opslagengine
- Allocatie van hardwarebronnen
- Replicatie en sharding
- Verander nooit het serverconfiguratiebestand
- Goede beveiligingsstrategie
Upgraden naar de nieuwste versie
Ik heb met MongoDB gewerkt vanaf versies vóór 3.2 en om eerlijk te zijn, het was in die tijd niet gemakkelijk. Met geweldige ontwikkelingen, opgeloste bugs en nieuw geïntroduceerde functies, raad ik je aan om je database altijd te upgraden naar de nieuwste versie. De introductie van het aggregatieraamwerk had bijvoorbeeld een betere prestatie-impact in plaats van te vertrouwen op het al bestaande Map-Reduce-concept. Met de nieuwste versie 4.0 heeft men nu de mogelijkheid om de functie voor transacties met meerdere documenten te gebruiken, wat over het algemeen de doorvoer verbetert. De nieuwste versie heeft ook enkele extra conversie-operators voor nieuwe typen, zoals $toInt, $toString, $trim en $toBool. Deze operators zullen enorm helpen bij de validatie van gegevens en creëren zo een gevoel van gegevensconsistentie. Raadpleeg bij het upgraden de documenten om te voorkomen dat u kleine fouten maakt die kunnen escaleren tot onjuistheden.
Kies een geschikte opslagengine
MongoDB ondersteunt vanaf nu 3 storage-engines:WiredTiger, In-Memory en MMAPv1-storage-engines. Elk van deze storage-engines heeft voordelen en beperkingen ten opzichte van de andere, maar uw keuze hangt af van uw toepassingsspecificatie en de kernfunctionaliteit van de engine. Persoonlijk geef ik echter de voorkeur aan de WiredTiger-opslagengine en ik zou dit aanraden voor iemand die niet zeker weet welke te gebruiken. De WiredTiger-opslagengine is zeer geschikt voor de meeste workloads en biedt een gelijktijdigheidsmodel op documentniveau, controlepunten en compressie.
Sommige overwegingen met betrekking tot het selecteren van een opslagengine zijn afhankelijk van deze aspecten:
- Transacties en atomiciteit: het verstrekken van gegevens tijdens een invoeging of update die alleen wordt uitgevoerd wanneer alle voorwaarden en fasen in de toepassing met succes zijn uitgevoerd. Operaties worden daarom gebundeld in een onveranderlijke eenheid. Met deze op zijn plaats kunnen transacties met meerdere documenten worden ondersteund, zoals te zien is in de nieuwste versie van MongoDB voor de WiredTiger-opslagengine.
- Vergrendelingstype: het is een controlestrategie voor toegang tot of update van informatie. Tijdens de vergrendelingsduur kan geen enkele andere handeling de gegevens van het geselecteerde object wijzigen totdat de huidige handeling is uitgevoerd. Bijgevolg worden zoekopdrachten op dit moment beïnvloed en daarom is het belangrijk om ze te controleren en het grootste deel van het vergrendelingsmechanisme te verminderen door ervoor te zorgen dat u de meest geschikte opslagengine voor uw gegevens selecteert.
- Indexeren: Opslagengines in MongoDB bieden verschillende indexeringsstrategieën, afhankelijk van de gegevenstypen die u opslaat. De efficiëntie van die gegevensstructuur zou heel vriendelijk moeten zijn met uw werklast en men kan dit bepalen door elke extra index te beschouwen als prestatieoverhead. Voor schrijven geoptimaliseerde gegevensstructuren hebben een lagere overhead voor elke index in een toepassingsomgeving met hoge invoeging dan niet-schrijven geoptimaliseerde gegevensstructuren. Dit zal een grote tegenvaller zijn, vooral als er een groot aantal indexen bij betrokken is en bij het selecteren van een ongeschikte opslagengine. Daarom kan het kiezen van een geschikte opslagengine een enorme impact hebben.
Toewijzing van hardwarebronnen
Naarmate nieuwe gebruikers zich aanmelden bij uw toepassing, groeit de database met de tijd en worden er nieuwe shards geïntroduceerd. U kunt echter niet vertrouwen op de hardwarebronnen die u tijdens de implementatiefase had ingesteld. Er zal een overeenkomstige toename van de werklast zijn en daarom zijn er meer verwerkingsbronnen nodig, zoals CPU en RAM om uw grote gegevensclusters te ondersteunen. In MongoDB wordt dit vaak capaciteitsplanning genoemd. De best practices rond capaciteitsplanning zijn onder meer:
- Bewaak uw database voortdurend en pas deze aan volgens de verwachtingen. Zoals eerder vermeld, zal een toename van het aantal gebruikers voortaan leiden tot meer zoekopdrachten met een hogere werklast, vooral als u indexen gebruikt. U kunt deze gevolgen gaan ervaren voor het einde van de toepassing wanneer het na verloop van tijd een verandering in het percentage schrijven versus lezen begint vast te leggen. U moet daarom uw hardwareconfiguraties opnieuw configureren om dit probleem op te lossen. Gebruik mongoperf en MMS-tool om veranderingen in systeemprestatieparameters te detecteren.
- Documenteer vooraf al uw prestatie-eisen. Wanneer u hetzelfde probleem tegenkomt, heeft u in ieder geval een referentiepunt dat u wat tijd zal besparen. Uw opname moet betrekking hebben op de grootte van de gegevens die u wilt opslaan, analyse van zoekopdrachten in termen van latentie en hoeveel gegevens u op een bepaald moment wilt openen. In de productieomgeving moet je bepalen hoeveel verzoeken je per seconde gaat verwerken en tot slot hoeveel latentie je gaat tolereren.
- Maak een Proof of Concept. Voer een schema/indexontwerp uit en begrijp de querypatronen en verfijn vervolgens uw schatting van de grootte van de werkset. Noteer deze configuratie als referentiepunt voor testen met opeenvolgende revisies van de applicatie.
- Doe uw tests met echte werkdruk. Na het uitvoeren van het proof-concept, pas implementeren na het uitvoeren van een substantiële test met real-world gegevens en prestatie-eisen.
Replicatie en sharding
Dit zijn de twee belangrijkste concepten om respectievelijk hoge beschikbaarheid van gegevens en verhoogde horizontale schaalbaarheid in MongoDB-cluster te garanderen.
Sharding verdeelt in feite gegevens over servers in kleine porties die shards worden genoemd. Het uitbalanceren van gegevens over shards is automatisch, shards kunnen worden toegevoegd of verwijderd zonder dat de database noodzakelijkerwijs offline hoeft te worden genomen.
Replicatie aan de andere kant onderhoudt meerdere redundante kopieën van de gegevens voor hoge beschikbaarheid. Het is een ingebouwde functie in MongoDB en werkt via wide area-netwerken zonder dat er gespecialiseerde netwerken nodig zijn. Voor een clusterconfiguratie raad ik aan dat u minimaal 2+ mongo's, 3 configuratieservers, 1 shard heeft en zorgt voor connectiviteit tussen machines die betrokken zijn bij de sharded-cluster. Gebruik een DNS-naam in plaats van IP's in de configuratie.
Gebruik voor productieomgevingen een replicaset met ten minste 3 leden en vergeet niet om meer configuratievariabelen in te vullen, zoals oplog-grootte.
Gebruik bij het starten van uw mongod-instanties voor uw leden hetzelfde sleutelbestand.
Enkele overwegingen van uw shardkey moeten zijn:
- Sleutel en waarde zijn onveranderlijk
- Overweeg altijd om indexen te gebruiken in een shard-verzameling
- Opdracht Stuurprogramma bijwerken moet een Shard-sleutel bevatten
- Unieke beperkingen waaraan de Shard-sleutel moet voldoen.
- Een shardsleutel kan geen speciale indextypen bevatten en mag niet groter zijn dan 512 bytes.
Verander nooit serverconfiguratiebestand
Na uw eerste implementatie is het raadzaam om niet veel parameters in het configuratiebestand te wijzigen, anders kunt u in de problemen komen, vooral met shards. De zwakste schakel bij sharding zijn de configuratieservers. Dit wil zeggen dat alle mongod-instanties moeten worden uitgevoerd om sharding te laten werken.
Goede beveiligingsstrategie
MongoDB is de afgelopen jaren kwetsbaar geweest voor aanvallen van buitenaf en daarom is het een belangrijke taak voor uw database om enkele beveiligingsprotocollen te hebben. Naast het uitvoeren van de processen in verschillende poorten, moet men op zijn minst een van de 5 verschillende manieren gebruiken om MongoDB-databases te beveiligen. U kunt platforms zoals MongoDB Atlas overwegen die databases standaard beveiligen door middel van codering van de gegevens, zowel onderweg als in rust. U kunt strategieën zoals TLS/SSL gebruiken voor alle inkomende en uitgaande verbindingen.
Conclusie
MongoDB-clusterbeheer is geen gemakkelijke taak en er zijn veel tijdelijke oplossingen voor nodig. Databases groeien als gevolg van meer gebruikers en dus een grotere werkbelasting. On heeft daarom een mandaat om ervoor te zorgen dat de prestaties van de DBM in lijn zijn met dit toegenomen aantal gebruikers. De best practices gaan verder dan het vergroten van hardwarebronnen en het toepassen van enkele MongoDB-concepten zoals sharding, replicatie en indexering. Veel van de ongemakken die zich kunnen voordoen, worden echter goed verholpen door uw MongoDB-versie te upgraden. Vaker hebben de nieuwste versies bugs opgelost, nieuwe functieverzoeken geïntegreerd en bijna geen negatieve gevolgen voor upgrades, zelfs met grote revisienummers.