Na het ontwikkelen van uw applicatie- en databasemodel (wanneer het tijd is om de omgeving in productie te nemen) zijn er een aantal dingen die eerst moeten worden gedaan. Vaak houden ontwikkelaars geen rekening met aanvullende belangrijke MongoDB-stappen voordat ze de database in productie nemen. Het is dus in de productiemodus dat ze op onderliggende tegenslagen stuiten die in de ontwikkelingsmodus niet worden gepresenteerd. Soms is het te laat of gaan er juist veel gegevens verloren als zich een ramp voordoet. Bovendien zullen sommige van de hier besproken stappen iemand in staat stellen de gezondheid van de database te meten en dus de nodige maatregelen te plannen voordat een ramp toeslaat.
Gebruik de huidige versie en nieuwste stuurprogramma's
Over het algemeen hebben de nieuwste versies van elke technologie verbeterde functies met betrekking tot de onderliggende functionaliteit dan hun voorgangers. De nieuwste versies van MongoDB zijn robuuster en verbeterd dan hun voorgangers op het gebied van prestaties, schaalbaarheid en geheugencapaciteit. Hetzelfde geldt voor de gerelateerde stuurprogramma's, aangezien ze zijn ontwikkeld door de belangrijkste database-engineers en vaker worden bijgewerkt, zelfs dan de database zelf.
Native extensies die voor uw taal zijn geïnstalleerd, kunnen gemakkelijk een platform vormen voor snelle en standaardprocedures voor het testen, goedkeuren en upgraden van de nieuwe stuurprogramma's. Er is ook autosoftware zoals Ansible, Puppet, SaltStack en Chef die kan worden gebruikt voor een eenvoudige upgrade van de MongoDB in al uw nodes zonder professionele kosten en tijd.
Overweeg ook om de WiredTiger-opslagengine te gebruiken, aangezien deze het meest ontwikkeld is met moderne functies die voldoen aan de verwachtingen van moderne databases
Abonneer u op een MongoDB-mailinglijst om de laatste informatie te krijgen met betrekking tot wijzigingen in nieuwe versies en stuurprogramma's en bugfixes en blijf dus up-to-date.
Gebruik een 64-bits systeem om MongoDB uit te voeren
In 32-bits systemen zijn MongoDB-processen beperkt tot ongeveer 2,5 GB aan gegevens, omdat de database voor prestaties gebruikmaakt van aan het geheugen toegewezen bestanden. Dit wordt een beperking voor processen die mogelijk de grens overschrijden die leidt tot verliefdheid. De belangrijkste impact zal zijn:in geval van een fout kunt u de server niet opnieuw opstarten tot het moment dat u uw gegevens verwijdert of uw database migreert naar een hoger systeem zoals de 64-bits, dus een hogere uitvaltijd voor uw toepassing.
Als u een 32-bits systeem moet blijven gebruiken, moet uw codering heel eenvoudig zijn om het aantal bugs en latentie voor doorvoerbewerkingen te verminderen.
Voor codecomplexen zoals aggregatiepijplijn en geodata is het echter raadzaam om het 64-bits systeem te gebruiken.
Zorg ervoor dat documenten zijn beperkt tot een grootte van 16 MB
MongoDB-documenten zijn beperkt tot 16 MB, maar u hoeft niet in de buurt van deze limiet te komen, omdat dit enige prestatievermindering met zich meebrengt. In de praktijk zijn de documenten meestal KB of kleiner. De documentgrootte is afhankelijk van de datamodelleringsstrategie tussen inbedding en verwijzing. Inbedding heeft de voorkeur wanneer het documentformaat naar verwachting niet veel groter zal worden. Als u bijvoorbeeld een toepassing voor sociale media heeft waar gebruikers berichten plaatsen en die opmerkingen heeft, kunt u het beste twee verzamelingen hebben, één om berichtinformatie te bewaren.
{
_id:1,
post: 'What is in your mind?',
datePosted: '12-06-2019',
postedBy:'xyz',
likes: 10,
comments: 30
}en de andere om opmerkingen voor die post vast te houden.
{
_id: ObjectId('2434k23k4'),
postId: 1,
dateCommented: '12-06-2019',
commentedBy:'ABCD',
comment: 'When will we get better again',
}Door over dergelijke datamodellen te beschikken, worden opmerkingen opgeslagen in een andere verzameling dan de post. Dit voorkomt dat het document in de postverzameling uit de binding groeit als er zoveel opmerkingen zijn. Zorg ervoor dat u toepassingspatronen vermijdt waardoor documenten onbegrensd kunnen groeien.
Zorg ervoor dat de werkset in het geheugen past
De database leest mogelijk geen gegevens uit het virtuele geheugen (RAM) wat leidt tot paginafouten. Paginafouten dwingen de database om gegevens van een fysieke schijf te lezen, wat leidt tot een langere latentie en bijgevolg een vertraging in de algehele app-prestaties. Paginafouten ontstaan door het werken met een grote set die niet in het geheugen past. Dit kan het gevolg zijn van sommige documenten met een onbeperkte grootte of een slechte shardingstrategie. Oplossingen voor paginafouten zijn:
- Ervoor zorgen dat documenten worden beperkt tot een grootte van 16 MB.
- Zorgen voor een goede sharding-strategie door een optimale sharding-sleutel te selecteren die het aantal documenten beperkt waaraan een doorvoerbewerking wordt onderworpen.
- Vergroot de MongoDB-instantie om plaats te bieden aan meer werksets.
Zorg ervoor dat je replicasets op hun plaats hebt
In de databasewereld is het niet ideaal om te vertrouwen op één enkele database, omdat er een catastrofe kan plaatsvinden. Bovendien zou je een toename van het aantal gebruikers van de database verwachten en daarom moet je zorgen voor een hoge beschikbaarheid van gegevens. Replicatie is een cruciale benadering om hoge beschikbaarheid te garanderen in geval van failover. MongoDB heeft de mogelijkheid om gegevens geografisch te leveren:wat betekent dat gebruikers van verschillende locaties worden bediend door de dichtstbijzijnde cloudhost als een manier om de latentie voor verzoeken te verminderen.
In het geval dat het primaire knooppunt uitvalt, kunnen de secundaire knooppunten een nieuwe kiezen om de schrijfbewerkingen bij te houden in plaats van dat de applicatie een downtime heeft tijdens de failover. Sommige cloudhostingplatforms die heel attent zijn op replicatie, ondersteunen geen niet-gerepliceerde MongoDB voor productieomgevingen.
Logboekregistratie inschakelen
Hoewel journaling enige prestatievermindering met zich meebrengt, is het ook belangrijk. Journaling verbetert de vooruitschrijfbewerkingen, wat betekent dat in het geval dat de database faalt tijdens het uitvoeren van een update, de update ergens zou zijn opgeslagen en wanneer deze weer tot leven komt, het proces kan worden voltooid. Journaling kan gemakkelijk crashherstel vergemakkelijken en moet daarom standaard worden ingeschakeld.
Zorg ervoor dat u een back-upstrategie instelt
Veel bedrijven kunnen niet doorgaan na gegevensverlies vanwege geen of slechte back-upsystemen. Voordat u uw database in productie gaat nemen, moet u ervoor zorgen dat u een van deze back-upstrategieën hebt gebruikt:
- Mongodump :optimaal voor kleine implementaties en bij het maken van back-ups gefilterd op specifieke behoeften.
- Onderliggend kopiëren :optimaal voor grote implementaties en efficiënte aanpak voor het maken van volledige back-ups en het herstellen ervan.
- MongoDB Management Service (MMS) :biedt continue online back-up voor MongoDB als een volledig beheerde service. Optimaal voor een shard-cluster en replicasets.
Back-upbestanden mogen ook niet worden opgeslagen in dezelfde hostprovider van de database. Backup Ninja is een dienst die hiervoor gebruikt kan worden.
Wees voorbereid op langzame zoekopdrachten
Nauwelijks kan men trage queries realiseren in de ontwikkelomgeving vanwege het feit dat er weinig data bij betrokken is. Dit kan echter niet het geval zijn in productie, aangezien u veel gebruikers zult hebben of dat er veel gegevens bij betrokken zijn. Er kunnen trage query's optreden als u geen indexen hebt gebruikt of een indexeringssleutel hebt gebruikt die niet optimaal is. Desalniettemin moeten we een manier vinden om u de reden voor trage zoekopdrachten te laten zien.
We besluiten daarom om MongoDB Query Profiler in te schakelen. Hoezeer dit ook kan leiden tot prestatievermindering, de profiler zal helpen bij het blootleggen van prestatieproblemen. Voordat u uw database implementeert, moet u de profiler inschakelen voor de collecties waarvan u vermoedt dat ze langzame zoekopdrachten hebben, vooral die met documenten met veel insluiting.
Verbinden met een monitoringtool
Capaciteitsplanning is een zeer essentiële onderneming in MongoDB. U moet ook op elk moment de gezondheid van uw db weten. Voor het gemak zal het aansluiten van uw database op een monitoringtool u wat tijd besparen bij het realiseren van wat u in de loop van de tijd aan uw database moet verbeteren. Een grafische weergave die de trage prestaties van de CPU aangeeft als gevolg van meer zoekopdrachten, zal u bijvoorbeeld aansporen om meer hardwarebronnen aan uw systeem toe te voegen.
Bewakingstools hebben ook een waarschuwingssysteem via mailing of korte berichten die je gemakkelijk op de hoogte houden van sommige problemen voordat ze tot een catastrofe uitgroeien. Zorg er daarom tijdens de productie voor dat uw database is verbonden met een monitoringtool.
ClusterControl biedt gratis MongoDB-monitoring in de Community-editie.
Beveiligingsmaatregelen implementeren
Databasebeveiliging is een ander belangrijk kenmerk waarmee strikt rekening moet worden gehouden. U moet de MongoDB-installatie in productie beschermen door ervoor te zorgen dat een aantal veiligheidscontrolelijsten vóór de productie worden nageleefd. Enkele overwegingen zijn:
- Op rollen gebaseerde toegangscontrole configureren
- Toegangscontrole inschakelen en authenticatie afdwingen
- Inkomende en uitgaande verbindingen versleutelen (TLS/SSL)
- Beperking van netwerkblootstelling
- Versleutelen en beschermen van gegevens
- Een routeplan hebben voor toegang en wijzigingen in databaseconfiguraties
Vermijd externe injecties door MongoDB uit te voeren met veilige configuratie-opties. Bijvoorbeeld het uitschakelen van scripting aan de serverzijde als u geen JavaScript-bewerkingen aan de serverzijde gebruikt, zoals mapReduce en $where. Gebruik de JSON-validator voor uw verzamelingsgegevens via sommige modules, zoals mangoest, om ervoor te zorgen dat alle opgeslagen documenten de geldige BSON-indeling hebben.
Overwegingen voor hardware en software
MongoDB heeft weinig hardwarevereisten, omdat het expliciet is ontworpen met veel aandacht voor de benodigde hardware. Hieronder volgen de belangrijkste hardware-overwegingen voor MongoDB die u moet overwegen voordat u deze in productie neemt.
- Voldoende RAM en CPU toewijzen
- Gebruik de WiredTiger-opslagengine. Ontworpen om de cache van het bestandssysteem en de interne cache van WiredTiger te gebruiken, waardoor de prestaties zijn verbeterd. Als u bijvoorbeeld werkt met een systeem van 4 GB RAM, gebruikt de WiredTiger-cache 1,5 GB RAM (0,5 * (4 GB -1 GB) =1,5 GB), terwijl een systeem met 1,2 GB RAM WiredTiger-cache slechts 256 MB gebruikt.
- NUMA-hardware. Er zijn tal van operationele problemen, waaronder trage prestaties en een hoog systeemprocesgebruik. Daarom moet u overwegen een geheugeninterleave-beleid te configureren.
- Schijf- en opslagsysteem:gebruik solid-state schijven (SSD's):MongoDB toont betere prijs-prestatieverhouding met SATA SSD
Conclusie
Databases in productie zijn zeer cruciaal voor een soepele bedrijfsvoering en moeten daarom met veel overwegingen worden behandeld. Men zou enkele procedures moeten vastleggen die kunnen helpen om fouten te verminderen, of liever een gemakkelijke manier bieden om deze fouten te vinden. Daarnaast is het raadzaam om een waarschuwingssysteem op te zetten dat de gezondheid van de database laat zien met tijd voor capaciteitsplanning en het detecteren van problemen voordat ze tot een catastrofe leiden.