Hvad skal du vide, når du begynder at arbejde med MongoDB i produktionen

At lære MongoDB kræver en masse præcis tænkning. Der tages ofte ikke meget hensyn i væsentlige virksomheder, der ellers kunne bringe databasens ydeevne i produktionstilstand i fare.

MongoDB er et NoSQL DBMS, som bogstaveligt talt følger et andet mønster end SQL-databaser, især på linje med sikkerhed og struktur. Selvom nogle af de integrerede funktioner fremmer dens ydeevne og gør den til en af de bedste i nyere tid, udgør nogle af funktionerne derfor potentielle trusler, der kan ødelægge dens ydeevne, hvis de ikke tages i betragtning.

I en nylig "worst case"-oplevelse forsøgte jeg at forespørge på en samling med dokumenter, der havde store arrays, og det tog evigheder for mig at få resultaterne tilbage. Jeg besluttede at skrive denne blog, da jeg vidste, at hvis nogen oplever de samme problemer, vil denne blog være til stor hjælp.

Nøgleovervejelser for MongoDB i produktion

Sikkerhed og godkendelse.
Indeksering af dine dokumenter
Brug af et skema i dine samlinger
Begrænset samling
Dokumentstørrelse
Matrixstørrelse for indlejrede dokumenter
Aggregation pipeline stadier
Rækkefølgen af nøgler i hash-objektet
'undefined' og 'null' i MongoDB
Skrivehandling

MongoDB-sikkerhed og -godkendelse

Data varierer på mange måder, og du skal naturligvis holde nogle oplysninger fortrolige. Som standard sætter MongoDB-installationer ikke autentificeringskrav som et must, men det giver dig ikke mulighed for at bruge det, især når fortrolige data såsom økonomiske og medicinske optegnelser er involveret. På en udviklingsarbejdsstation er det ikke en stor sag, men på grund af involvering af flere brugere i produktionstilstanden er det god praksis at indstille godkendelsescertifikaterne. Den mest almindelige og nemme at bruge metode er standard MongoDB brugernavn og adgangskode legitimationsoplysninger.

Data skrives til filer, som i højere grad kan tilgås via et tredjepartsværktøj, hvis de ikke er krypteret. Dataene kan ændres uden din viden, hvis en anonym person får adgang til systemfilerne. At hoste databasen på en dedikeret server og tildele en enkelt bruger, som vil have fuld adgang til datafilerne, sparer dig for tricket.

Beskyttelse af data mod eksterne injektionsangreb er også en vigtig opgave. Nogle operatører såsom $group, $whereby og mapReduce-operationerne er javascript(js) udviklet og derfor tilbøjelige til js-manipulation. For at undgå enhver forekomst af dataintegritet som et resultat, kan du deaktivere vilkårlig JS-indstilling ved at konfigurere parameteren javascriptEnabled:false i konfigurationsfilen, hvis du ikke har brugt nogen af de nævnte operatorer. Yderligere kan du reducere risikoen for dataadgang gennem netværksbrud ved at bruge nogle af de procedurer, der er fremhævet i MongoDB Security Checklist.

Indeksering af dine dokumenter

Indeksering er generelt at tildele en unik identifikationsværdi til hvert dokument i en MongoDB-samling. Indeksering medfører ydelsesopgradering i både læse- og skriveoperationer. Som standard er den aktiveret, og man bør altid bevare denne indstilling. Uden indeksering skal databasen gennemse flere dokumenter fra start til slut, og desværre vil operationen være tidskrævende for dokumenter, der er mod slutningen, hvilket giver dårlig latenstid for forespørgslen. På et tidspunkt, i applikationsenden, kan brugere opleve en forsinkelse og tror måske, at applikationen faktisk ikke virker. Indeksering er nyttig i sorterings- og opslagsforespørgselsoperationer og udelader ikke selve findeoperationen. Sortering er en almindelig operation for mange returnerede dokumenter. Det udføres ofte som den sidste fase, efter at dokumenter er blevet filtreret, så en lille mængde data skal sorteres. Et indeks i dette tilfælde vil hjælpe med at sortere dataene i arten af indtastning og begrænse de returnerede data til en grænse på 32MB. Hvis der ikke er nogen indeksering, vil chancerne for hukommelsesgrænsen på 32 på den kombinerede størrelse af returnerede dokumenter blive overskredet, og når databasen rammer denne grænse, vil den give en fejl udover at returnere et tomt postsæt.

$lookup-operationen er også understøttet med indeksering på plads. Et indeks på nøgleværdien, der bruges som fremmednøgle, er afgørende for de foregående trins behandling.

Brug af et skema i dine samlinger

MongoDB behøver ikke en til at definere felter(kolonner), ligesom det kan kræve, at du gør for SQL dbms. Uanset hvor meget du ikke behøver at definere felterne, for at undgå datainkonsistens og nogle tilbageslag, der måtte opstå, er det altid en god praksis at definere et skema. Skemadesign giver dig mulighed for at bestemme, hvilken type data der går til et bestemt felt, hvilket felt der skal forsynes med en værdi og generelt forbedre datavalideringen før indtastning eller opdatering, hvilket fremmer dataintegritet og konsistens. Et skemadesign vil også vejlede dig om, hvorvidt du skal referere eller integrere data. Som nybegynder tror du måske, at den eneste model vil være "One-to-N", der vil gøre det lettere for en at have subdokument-array-indgange, men det er ikke tilfældet.

Du skal forstå kardinalitetsforholdet mellem dokumenter, før du laver din model. Nogle af de regler, der vil hjælpe dig med at få et optimalt skema, er:

For at reducere antallet af forespørgsler, som du skal udføre før adgang til nogle data, og hvis få felter eller array-elementer er involveret, kan du indlejre underdokumenter. Tag et eksempel på modellen nedenfor:
1. ```
{
 Name: ‘John Doh’,
 Age:20
 Addresses:[
   {street: ‘Moi Avenue’, city:’Nairobi’, countryCode: ‘KE’},
   {street: ‘Kenyatta Avenue’, city:’Nairobi’, countryCode: ‘KE’},
 ]
}
```
For ofte opdaterede dokumenter skal du bruge denormalisering . Hvis et felt skal opdateres ofte, så vil der være opgaven med at finde alle de forekomster, der skal opdateres. Dette vil resultere i langsom forespørgselsbehandling, og dermed overvældende selv fordelene forbundet med denormalisering.
Komplekse forespørgsler såsom aggregeret pipelining tager længere tid at udføre, når mange underdokumenter er involveret, og der er behov for at hente et dokument separat.
Arrayelementer med et stort sæt objektdata bør naturligvis ikke indlejres på grund af det faktum, at de kan vokse og følgelig overskride dokumentstørrelsen.

Modellering af et skema bestemmes ofte af applikationsadgangsmønsteret. Du kan finde flere procedurer, der kan hjælpe med designet af din model i bloggen 6 tommelfingerregler for MongoDB Schema Design

Brug en begrænset samling til prioritet for seneste dokumenter

MongoDB giver en masse ressourcer såsom den begrænsede samling. Desværre ender nogle med ikke at blive brugt. En begrænset samling har en fast størrelse, og den er kendt for at understøtte high-throughput-operationer, der indsætter og henter dokumenter baseret på indsættelsesrækkefølgen. Når pladsen er fyldt op, slettes gamle dokumenter for at give plads til nye.

Eksempel på anvendelsestilfælde med begrænset samling:

Caching af ofte tilgåede data, da selve samlingen er læsetung i stedet for skrivetung. Du skal sikre dig, at samlingen altid fungerer.
Logoplysninger for højvolumensystemer. Begrænset samling bruger ofte ikke et indeks, og det er fordelagtigt, da optagelseshastigheden er ret hurtig ligesom at skrive ind i en fil.

Vær opmærksom på MongoDB-dokumentstørrelsen

Hvert MongoDB-dokument er begrænset til en størrelse på 16 megabyte. Det er dog optimalt for dokumentet at nå eller nærme sig denne grænse, da det vil give nogle grufulde ydeevneproblemer. MongoDB i sig selv fungerer bedst, når størrelsen af dokumenterne er på et par kilobyte. Hvis dokumentet er stort nok i størrelse, vil en kompleks projektionsanmodning tage lang tid, og forespørgslen kan timeout.

Vær opmærksom på matrixstørrelsen af indlejrede dokumenter

Man kan skubbe underdokumenter til et felt i et dokument og derved skabe en matrixværdi på dette felt. Som nævnt før, skal du holde størrelsen af underdokumenterne lav. Det er lige så vigtigt at sikre, at antallet af array-elementer er under et firecifret. Ellers vil dokumentet vokse ud over dets størrelse, og det skal flyttes til disken. Et yderligere problem forbundet med en sådan operation er, at hvert dokument skal genindekseres. Desuden skal hvert underdokument også indekseres igen. Det betyder, at der vil være mange indeksskrivninger, som resulterer i langsomme operationer. For store underdokumentstørrelser er det snarere vigtigt at opbevare posterne i en ny samling end at indlejre.

Aggregation Pipeline Stadier

Udover de normale MongoDB-forespørgselsoperationer er der en aggregeringsramme, der bruges til at manipulere og returnere data i overensstemmelse med nogle specifikationer, såsom bestilling og gruppering. MongoDB har ikke en forespørgselsoptimering, og derfor er der brug for en for at bestille forespørgsler korrekt. Med aggregeringsrammen skal du sikre, at pipelinestadierne er velordnet. Start med at reducere mængden af data, du beskæftiger dig med, ved at bruge $match-operatoren og eventuelt $sort til sidst, hvis det er nødvendigt at sortere. Du kan bruge tredjepartsværktøjer såsom Studio 3T til at optimere din aggregeringsforespørgsel, før du integrerer den i din kode. Værktøjet giver dig mulighed for at se datainput og -output i et hvilket som helst af stadierne, så du ved, hvad du har med at gøre.

Brug af $limit og $sort bør altid give de samme resultater, hver gang forespørgslen udføres. Hvis du bruger $limit, vil de returnerede data ikke være deterministiske og kan give nogle problemer, som er svære at spore.

Tjek rækkefølgen af nøgler i Hash-objekter

Overvej at have to store dokumenter med eksempeldata

{

   FirstName: ‘John’,

   LastName: ‘Doh’

}

Hvis du udfører en søgeoperation med forespørgslen {FirstName:'John', LastName:'Doh'}, stemmer handlingen ikke overens med forespørgslen {LastName:'Doh' Fornavn:'John' }. Du skal derfor bevare rækkefølgen af navne- og værdipar i dine dokumenter.

Undgå "udefineret" og "nul" i MongoDB

MongoDB bruger BSON-format til sine dokumenter. Med JSON-validering understøttes 'undefined' ikke, og du bør undgå at bruge det. $null kommer som en løsning, men du bør også undgå det.

Overvej skrivehandlinger

Du kan måske indstille MongoDB til højhastighedsskrivning, men dette udgør et tilbageslag i det, at et svar returneres, selv før dataene er skrevet. Journalføring bør være aktiveret for at undgå dette scenarie. Derudover vil dataene stadig være tilgængelige i tilfælde af et databasebrud, og det vil skabe et kontrolpunkt, som kan bruges i gendannelsesprocessen. Konfigurationen for varigheden af journalskrivninger kan indstilles ved hjælp af parameteren commitIntervalMs.

Konklusion

Databasesystemet skal sikre dataintegritet og konsistens udover at være modstandsdygtigt over for fejl og ondskab. Men for at nå frem til disse faktorer er man nødt til at forstå selve databasen og de data, den indeholder. MongoDB vil fungere godt, når de nævnte faktorer ovenfor tages i betragtning. Det vigtigste for dem er at bruge et skema. Et skema giver dig mulighed for at validere dine data før indtastning eller opdatering, og hvordan du vil modellere disse data. Datamodellering er ofte drevet af applikationens tilgængelighedsmønster. Alle disse opsummerede vil give en bedre databaseydelse.

Hvad skal du vide, når du begynder at arbejde med MongoDB i produktionen - ti tips