Efter at have udviklet din applikation og databasemodel (når det er tid til at flytte miljøet i produktion) er der et par ting, der skal gøres først. Ofte undlader udviklere at tage højde for yderligere vigtige MongoDB-trin, før de implementerer databasen i produktion. Det er derfor i produktionstilstanden, de ender med at støde på underliggende tilbageslag, som ikke præsenteres i udviklingstilstanden. Nogle gange kan det være for sent, eller rettere vil en masse data gå tabt, hvis katastrofen rammer. Desuden vil nogle af de trin, der diskuteres her, gøre det muligt for en at måle databasens helbred og dermed planlægge nødvendige foranstaltninger, før katastrofen rammer.
Brug den aktuelle version og seneste drivere
Generelt kommer de nyeste versioner inden for enhver teknologi med forbedrede funktioner i forhold til den underliggende funktionalitet end deres forgængere. MongoDBs seneste versioner er mere robuste og forbedrede end deres forgængere med hensyn til ydeevne, skalerbarhed og hukommelseskapacitet. Det samme gælder for de relaterede drivere, da de er udviklet af kernedatabaseingeniørerne og bliver opdateret oftere end selve databasen.
Native udvidelser installeret til dit sprog kan nemt skabe en platform for hurtige og standardprocedurer til test, godkendelse og opgradering af de nye drivere. Der er også automotive software såsom Ansible, Puppet, SaltStack og Chef, der kan bruges til nem opgradering af MongoDB i alle dine noder uden at pådrage sig professionelle udgifter og tid.
Overvej også at bruge WiredTiger-lagringsmotoren, da den er den mest udviklede med moderne funktioner, der passer til moderne databaseforventninger
Abonner på en MongoDB-mailingliste for at få de seneste oplysninger om ændringer af nye versioner og drivere og fejlrettelser, og hold dig derfor opdateret.
Brug et 64-bit system til at køre MongoDB
I 32-bit-systemer er MongoDB-processer begrænset til omkring 2,5 GB data, fordi databasen bruger hukommelseskortede filer til ydeevne. Dette bliver en begrænsning for processer, der kan overskride grænsen, hvilket fører til et crush. Kernepåvirkningen vil være:I tilfælde af en fejl vil du ikke være i stand til at genstarte serveren, før du fjerner dine data eller migrerer din database til et højere system som f.eks. 64-bit og dermed en højere nedetid for din applikation.
Hvis du er nødt til at blive ved med at bruge et 32-bit system, skal din kodning være meget enkel for at reducere antallet af fejl og latens for gennemstrømningsoperationer.
Men for kodekompleksiteter såsom aggregeringspipeline og geodata er det dog tilrådeligt at bruge 64-bit systemet.
Sørg for, at dokumenter er afgrænset til 16 MB størrelse
MongoDB-dokumenter er begrænset til 16 MB-størrelsen, men du behøver ikke at komme tæt på denne grænse, da det vil implicere en vis ydeevneforringelse. I praksis er dokumenterne for det meste KB eller mindre i størrelse. Dokumentstørrelsen er afhængig af datamodelleringsstrategien mellem indlejring og reference. Indlejring foretrækkes, hvor dokumentstørrelsen ikke forventes at vokse meget i størrelse. Hvis du f.eks. har en applikation til sociale medier, hvor brugere poster, og den har kommentarer, vil den bedste praksis være at have to samlinger, den ene til at indeholde opslagsoplysninger.
{
_id:1,
post: 'What is in your mind?',
datePosted: '12-06-2019',
postedBy:'xyz',
likes: 10,
comments: 30
}og den anden til at holde kommentarer til det indlæg.
{
_id: ObjectId('2434k23k4'),
postId: 1,
dateCommented: '12-06-2019',
commentedBy:'ABCD',
comment: 'When will we get better again',
}Ved at have sådanne datamodeller vil kommentarer blive gemt i en anden samling end indlægget. Dette forhindrer dokumentet i postindsamlingen i at vokse ud af bundet, hvis der kommer så mange kommentarer. Sørg for, at du undgår applikationsmønstre, der gør det muligt for dokumenter at vokse ubegrænset.
Sørg for, at arbejdssæt passer i hukommelsen
Databasen kan muligvis ikke læse data fra virtuel hukommelse (RAM), hvilket kan føre til sidefejl. Sidefejl vil tvinge databasen til at læse data fra en fysisk disk, hvilket fører til øget latenstid og dermed en forsinkelse i den overordnede applikationsydelse. Sidefejl opstår på grund af arbejde med et stort sæt, der ikke passer i hukommelsen. Dette kan skyldes, at nogle dokumenter har en ubegrænset størrelse eller dårlig sønderdelingsstrategi. Afhjælpning af sidefejl vil være:
- Sikring af dokumenter er afgrænset til størrelsen 16 MB.
- Sikring af en god sønderdelingsstrategi ved at vælge en optimal sønderdelingsnøgle, der vil begrænse antallet af dokumenter, en gennemløbsoperation vil blive udsat for.
- Forøg størrelsen af MongoDB-instansen for at rumme flere arbejdssæt.
Sørg for, at du har replikasæt på plads
I databaseverdenen er det ikke ideelt at stole på en enkelt database på grund af det faktum, at katastrofen kan ramme. Desuden ville du forvente en stigning i antallet af brugere til databasen, og derfor er det nødvendigt at sikre høj tilgængelighed af data. Replikering er en afgørende tilgang til at sikre høj tilgængelighed i tilfælde af failover. MongoDB har evnen til at betjene data geografisk:hvilket betyder, at brugere fra forskellige lokationer vil blive betjent af den nærmeste cloud-vært som en måde at reducere latens for anmodninger.
I tilfælde af at den primære knude svigter, kan de sekundære knudepunkter vælge en ny til at holde trit med skriveoperationer i stedet for, at applikationen har en nedetid under failover. Faktisk understøtter nogle cloud-hostingplatforme, der er ret hensynsfulde med replikering, ikke ikke-replikeret MongoDB til produktionsmiljøer.
Aktiver journalføring
Så meget som journalføring implicerer en vis ydeevneforringelse, er det også vigtigt. Journalføring forbedrer skrive-forud-operationer, hvilket betyder, at hvis databasen fejler i processen med at lave en opdatering, ville opdateringen være blevet gemt et sted, og når den kommer til live igen, kan processen fuldføres. Journalføring kan nemt lette gendannelse af nedbrud og bør derfor være slået til som standard.
Sørg for, at du opsætter en sikkerhedskopieringsstrategi
Mange virksomheder kan ikke fortsætte efter datatab på grund af ingen eller dårlige backupsystemer. Før du implementerer din database i produktion, skal du sikre dig, at du har brugt en af disse sikkerhedskopieringsstrategier:
- Mongodump :optimal til små implementeringer og ved fremstilling af sikkerhedskopier filtreret efter specifikke behov.
- Kopiering af underliggende :optimal til store udrulninger og effektiv tilgang til at tage fuld sikkerhedskopiering og gendanne dem.
- MongoDB Management Service (MMS) :leverer kontinuerlig online backup til MongoDB som en fuldt administreret tjeneste. Optimal til en sønderdelt klynge og replikasæt.
Sikkerhedskopier filer bør heller ikke gemmes i den samme værtsudbyder af databasen. Backup Ninja er en tjeneste, der kan bruges til dette.
Vær forberedt på langsomme forespørgsler
Næppe kan man realisere langsomme forespørgsler i udviklingsmiljøet på grund af det faktum, at der er lidt data involveret. Det er dog muligvis ikke tilfældet i produktionen, da du vil have mange brugere eller en masse data vil være involveret. Langsomme forespørgsler kan opstå, hvis du undlod at bruge indekser eller brugte en indekseringsnøgle, der ikke er optimal. Ikke desto mindre bør vi finde en måde, der viser dig årsagen til langsomme forespørgsler.
Vi beslutter derfor at aktivere MongoDB Query Profiler. Så meget som dette kan føre til ydeevneforringelse, vil profileren hjælpe med at afsløre ydeevneproblemer. Før du implementerer din database, skal du aktivere profileringsværktøjet for de samlinger, som du har mistanke om kan have langsomme forespørgsler, især dem, der involverer dokumenter med en masse indlejring.
Opret forbindelse til et overvågningsværktøj
Kapacitetsplanlægning er en meget vigtig opgave i MongoDB. Du skal også kende din db's helbred til enhver tid. For nemheds skyld sparer du noget tid ved at forbinde din database med et overvågningsværktøj, når du forstår, hvad du skal forbedre din database med tiden. For eksempel vil en grafisk repræsentation, der angiver langsom CPU-ydelse som følge af øgede forespørgsler, lede dig til at tilføje flere hardwareressourcer til dit system.
Overvågningsværktøjer har også et advarselssystem via mails eller korte beskeder, der bekvemt opdaterer dig om nogle problemer, før de bliver til en katastrofe. Sørg derfor i produktionen for, at din database er forbundet med et overvågningsværktøj.
ClusterControl giver gratis MongoDB-overvågning i Community Edition.
Implementer sikkerhedsforanstaltninger
Databasesikkerhed er en anden vigtig funktion, der skal tages strengt i betragtning. Du skal beskytte MongoDB-installationen i produktionen ved at sikre, at nogle sikkerhedstjeklister før produktion overholdes. Nogle af overvejelserne er:
- Konfiguration af rollebaseret adgangskontrol
- Aktivering af adgangskontrol og håndhævelse af godkendelse
- Kryptering af indgående og udgående forbindelser (TLS/SSL)
- Begrænsning af netværkseksponering
- Kryptering og beskyttelse af data
- Har en sporplan for adgang og ændringer til databasekonfigurationer
Undgå eksterne injektioner ved at køre MongoDB med sikre konfigurationsmuligheder. For eksempel at deaktivere server-side scripting, hvis du ikke bruger JavaScript server side operationer såsom mapReduce og $where. Brug JSON-validatoren til dine indsamlingsdata gennem nogle moduler såsom mongoose for at sikre, at alle lagrede dokumenter er i det gyldige BSON-format.
Hardware- og softwareovervejelser
MongoDB har få hardwareforudsætninger, da den er eksplicit designet med stor hensyntagen til den nødvendige råvarehardware. Følgende er de vigtigste hardwareovervejelser for MongoDB, du skal overveje, før du installerer i produktion.
- Tildel tilstrækkelig RAM og CPU
- Brug WiredTiger-lagringsmotoren. Designet til at bruge filsystemcache og WiredTiger intern cache og dermed øget ydeevne. Når du for eksempel arbejder med et system med 4 GB RAM, bruger WiredTiger-cachen 1,5 GB RAM (0,5 * (4 GB -1 GB) =1,5 GB), mens et system med 1,2 GB RAM WiredTiger-cache kun bruger 256 MB.
- NUMA Hardware. Der er adskillige driftsproblemer, som inkluderer langsom ydeevne og høj systemprocesbrug, derfor bør man overveje at konfigurere en hukommelsesinterleave-politik.
- Disk og lagersystem:Brug solid state-disk (SSD'er):MongoDB viser et bedre pris-ydelsesforhold med SATA SSD
Konklusion
Databaser i produktionen er meget afgørende for at sikre en problemfri drift af en virksomhed, og derfor bør der tages mange hensyn. Man bør fastlægge nogle procedurer, der kan hjælpe med at reducere fejl eller rettere give en nem måde at finde disse fejl på. Desuden er det tilrådeligt at opsætte et varslingssystem, der viser databasens helbred med tid til kapacitetsplanlægning og opdagelse af problemer, før de afbøder til katastrofe.