Bedste praksis for at køre MongoDB i en klynge

Implementering af en klyngedatabase er én ting, men hvordan du vedligeholder din DBM, mens du er i klyngen, kan være en stor opgave for en ensartet betjening af dine applikationer. Man bør have en ofte opdatering af status for databasen, især de mest afgørende metrics for at få et fingerpeg om, hvad man skal opgradere eller rettere ændre for at forhindre eventuelle flaskehalse, der måtte opstå.

Der er mange overvejelser vedrørende MongoDB, som man bør tage i betragtning, især det faktum, at dets installation og kørsel er ret lette, chancerne for at negligere grundlæggende databasehåndteringspraksis er høje.

Mange til tider undlader udviklere at tage højde for fremtidig vækst og øget brug af databasen, hvilket resulterer i nedbrud af applikation eller data med nogle integritetsproblemer udover at være inkonsekvente.

I denne artikel vil vi diskutere nogle af de bedste praksisser, man bør anvende til MongoDB-klynge for en effektiv ydeevne af dine applikationer. Nogle af de faktorer, man bør overveje, inkluderer...

1. Opgradering til seneste version
2. Passende lagringsmotor
3. Tildeling af hardwareressourcer
4. Replikering og sønderdeling
5. Skift aldrig serverkonfigurationsfil
6. God sikkerhedsstrategi

Opgradering til seneste version

Jeg har arbejdet med MongoDB fra versioner før 3.2, og for at være ærlig var tingene ikke nemme på det tidspunkt. Med stor udvikling, rettet fejl og nyligt introducerede funktioner, vil jeg råde dig til altid at opgradere din database til den nyeste version. For eksempel havde introduktionen af ​​aggregeringsrammen en bedre præstationsindvirkning frem for at stole på Map-Reduce-konceptet, der allerede eksisterede. Med den seneste version 4.0 har man nu mulighed for at bruge funktionen til multidokumenttransaktioner, som generelt forbedrer gennemstrømningsoperationer. Den seneste version har også nogle ekstra nye type konverteringsoperatorer såsom $toInt, $toString, $trim og $toBool. Denne operatør vil i høj grad hjælpe med valideringen af ​​data og dermed skabe en vis følelse af datakonsistens. Når du opgraderer, skal du henvise til dokumenterne, så du kan undgå at lave små fejl, der kan eskalere til at være fejlagtige.

Vælg en passende lagermotor

MongoDB understøtter 3 lagringsmotorer som nu, det vil sige:WiredTiger, In-Memory og MMAPv1 lagringsmotorer. Hver af disse lagermotorer har fordele og begrænsninger frem for den anden, men dit valg afhænger af din applikationsspecifikation og motorens kernefunktionalitet. Jeg foretrækker dog personligt WiredTiger-lagringsmotoren, og jeg vil anbefale denne til en, der ikke er sikker på, hvilken man skal bruge. WiredTiger-lagringsmotoren er velegnet til de fleste arbejdsbelastninger, giver en samtidighedsmodel på dokumentniveau, checkpointing og komprimering.

Nogle af overvejelserne vedrørende valg af lagermotor afhænger af disse aspekter:

1. Transaktioner og atomicitet: levering af data under en indsættelse eller opdatering, som kun udføres, når alle betingelser og stadier i anvendelsen er blevet udført med succes. Operationer er derfor bundtet sammen i en uforanderlig enhed. Med dette på plads kan multidokumenttransaktion understøttes som det ses i den seneste version af MongoDB til WiredTiger-lagringsmotoren.
2. Låsetype: det er en kontrolstrategi for adgang eller opdatering af information. Under låsevarigheden kan ingen anden operation ændre dataene for det valgte objekt, før den aktuelle operation er blevet udført. Som følge heraf bliver forespørgsler påvirket på nuværende tidspunkt, og derfor er det vigtigt at overvåge dem og reducere hovedparten af ​​låsemekanismen ved at sikre, at du vælger den mest passende lagermaskine til dine data.
3. Indeksering: Lagermotorer i MongoDB giver forskellige indekseringsstrategier afhængigt af de datatyper, du gemmer. Effektiviteten af ​​den datastruktur bør være ret venlig med din arbejdsbyrde, og man kan bestemme dette ved at betragte hvert ekstra indeks som at have nogle præstationsomkostninger. Skriveoptimerede datastrukturer har lavere overhead for hvert indeks i et applikationsmiljø med høj indsættelse end ikke-skriveoptimerede datastrukturer. Dette vil være et stort tilbageslag, især hvor et stort antal indekser er involveret og valg af en upassende storage-motor. Derfor kan valget af en passende lagermotor have en dramatisk indvirkning.

Tildeling af hardwareressourcer

Efterhånden som nye brugere logger ind på din applikation, vokser databasen med tiden, og nye shards vil blive introduceret. Du kan dog ikke stole på de hardwareressourcer, du havde etableret under installationsfasen. Der vil være en tilsvarende stigning i arbejdsbyrden og kræver derfor flere behandlingsressourcer såsom CPU og RAM for at understøtte dine store dataklynger. Dette omtales ofte til kapacitetsplanlægning i MongoDB. Den bedste praksis omkring kapacitetsplanlægning omfatter:

• Overvåg din database konstant og juster i overensstemmelse med forventningerne. Som nævnt før vil en stigning i antallet af brugere udløse flere forespørgsler fremover med en øget arbejdsbelastning, især hvis du anvender indekser. Du kan begynde at opleve denne indvirkning på applikationsslutningen, når den begynder at registrere en ændring i procentdelen af ​​skrivninger i forhold til læsninger med tiden. Du bliver derfor nødt til at omkonfigurere dine hardwarekonfigurationer for at løse dette problem. Brug mongoperf og MMS-værktøj til at registrere ændringer i systemets ydeevneparametre.
• Dokumentér alle dine præstationskrav på forhånd. Når du støder på det samme problem, vil du i det mindste have et referencepunkt, som vil spare dig for noget tid. Din optagelse bør involvere størrelsen af ​​de data, du ønsker at gemme, analyse af forespørgsler med hensyn til latens og hvor meget data du gerne vil have adgang til på et givet tidspunkt. I produktionsmiljøet skal du bestemme, hvor mange anmodninger du vil håndtere pr. sekund og til sidst, hvor meget latenstid du vil tolerere.
• Iscenesætte et Proof of Concept. Udfør skema-/indeksdesign og forstå forespørgselsmønstrene og finjuster derefter dit estimat af arbejdssættets størrelse. Registrer denne konfiguration som et referencepunkt for test med successive revisioner af applikationen.
• Udfør dine tests med reel arbejdsbyrde. Efter at have gennemført et stadium af bevis-konceptet, skal du kun implementere efter at have gennemført en omfattende test med virkelige data- og ydeevnekrav.

Replikering og deling

Dette er de to hovedkoncepter for at sikre henholdsvis høj tilgængelighed af data og øget horisontal skalerbarhed i MongoDB-klyngen.

Sharding opdeler grundlæggende data på tværs af servere i små portioner kendt som shards. Balancering af data på tværs af shards er automatisk, shards kan tilføjes eller fjernes uden nødvendigvis at tage databasen offline.

Replikering i den anden ende opretholder flere redundante kopier af dataene for høj tilgængelighed. Det er en indbygget funktion i MongoDB og fungerer på tværs af et bredt netværk uden behov for specialiserede netværk. For en klyngeopsætning anbefaler jeg, at du mindst har 2+ mongo'er, 3 konfigurationsservere, 1 shard og sikrer forbindelse mellem maskiner involveret i den shardede klynge. Brug et DNS-navn i stedet for IP'er i konfigurationen.

Til produktionsmiljøer skal du bruge et replikasæt med mindst 3 medlemmer, og husk at udfylde flere konfigurationsvariabler såsom oplog-størrelse.

Når du starter dine mongod-instanser for dine medlemmer, skal du bruge den samme nøglefil.

Nogle af overvejelserne ved din shardkey bør omfatte:

• Nøgle og værdi er uforanderlige
• Overvej altid at bruge indekser i en shard samling
• Opdater driver-kommando skal indeholde en shard-nøgle
• Unikke begrænsninger, der skal vedligeholdes af shard-nøglen.
• En shard-nøgle kan ikke indeholde specielle indekstyper og må ikke overstige 512 bytes.

Skift aldrig serverkonfigurationsfil

Efter at have udført din første implementering, er det tilrådeligt ikke at ændre en masse parametre i konfigurationsfilen, ellers kan du havne i problemer, især med shards. Det svageste led med sharding er konfigurationsserverne. Det vil sige, at alle mongod-forekomsterne skal køre, for at sharding kan fungere.

God sikkerhedsstrategi

MongoDB har været sårbar over for eksterne angreb i de seneste år, og derfor er det en vigtig opgave for din database at have nogle sikkerhedsprotokoller. Udover at køre processerne i forskellige porte, bør man i det mindste anvende en af ​​de 5 forskellige måder at sikre MongoDB-databaser på. Du kan overveje platforme som MongoDB Atlas, som sikrer databaser som standard gennem kryptering af dataene både under transport og i hvile. Du kan bruge strategier som TLS/SSL til alle indgående og udgående forbindelser.

Konklusion

MongoDB klyngekontrol er ikke en nem opgave, og det involverer en masse løsninger. Databaser vokser som et resultat af flere brugere og dermed øget arbejdsbelastning. On har derfor mandat til at sikre, at DBM'ens ydeevne er på linje med dette øgede antal brugere. Den bedste praksis går ud over at øge hardwareressourcer og anvende nogle MongoDB-koncepter såsom sharding, replikering og indeksering. Men mange af de gener, der kan opstå, løses godt ved at opgradere din MongoDB-version. Oftere har de seneste versioner fejl rettet, nye funktionsanmodninger integreret og næsten ingen negativ indvirkning på opgradering, selv med større revisionsnumre.