MongoDB Schema Planlægningstips

En af de mest annoncerede funktioner i MongoDB er dens evne til at være "skemaløs". Dette betyder, at MongoDB ikke pålægger noget skema på dokumenter, der er gemt i en samling. Normalt gemmer MongoDB dokumenter i et JSON-format, så hvert dokument kan gemme forskellige slags skemaer/strukturer. Dette er gavnligt for de indledende stadier af udviklingen, men i de senere stadier vil du måske gennemtvinge en vis skemavalidering, mens du indsætter nye dokumenter for bedre ydeevne og skalerbarhed. Kort sagt betyder "Skemaløs" ikke, at du ikke behøver at designe dit skema. I denne artikel vil jeg diskutere nogle generelle tips til planlægning af dit MongoDB-skema.

At finde ud af det bedste skemadesign, der passer til din applikation, kan nogle gange blive kedeligt. Her er nogle punkter, som du kan overveje, når du designer dit skema.

Undgå at vokse dokumenter

Hvis dit skema tillader oprettelse af dokumenter, der vokser i størrelse kontinuerligt, bør du tage skridt til at undgå dette, fordi det kan føre til forringelse af DB- og disk IO-ydeevne. Som standard tillader MongoDB 16 MB størrelse pr. dokument. Hvis din dokumentstørrelse øges med mere end 16 MB over en periode, er det et tegn på dårligt skemadesign. Det kan nogle gange føre til fejl i forespørgsler. Du kan bruge dokumentsamlinger eller teknikker til forhåndstildeling af dokumenter for at undgå denne situation. Hvis din applikation skal gemme dokumenter på mere end 16 MB, kan du overveje at bruge MongoDB GridFS API.

Undgå at opdatere hele dokumenter

Hvis du forsøger at opdatere hele dokumentet, vil MongoDB omskrive hele dokumentet et andet sted i hukommelsen. Dette kan drastisk forringe skriveydelsen af ​​din database. I stedet for at opdatere hele dokumentet, kan du bruge feltmodifikatorer til kun at opdatere specifikke felter i dokumenterne. Dette vil udløse en in-place opdatering i hukommelsen, og dermed forbedret ydeevne.

Prøv at undgå tilslutninger på applikationsniveau

Som vi alle ved, understøtter MongoDB ikke tilslutninger på serverniveau. Derfor skal vi hente alle data fra DB og derefter udføre join på applikationsniveau. Hvis du henter data fra flere samlinger og samler en stor mængde data, skal du ringe til DB flere gange for at få alle de nødvendige data. Dette vil naturligvis kræve mere tid, da det involverer netværket. Som en løsning på dette scenarie, hvis din applikation er stærkt afhængig af joinforbindelser, giver denormalisering af skema mere mening. Du kan bruge indlejrede dokumenter til at få alle de nødvendige data i et enkelt forespørgselsopkald.

Brug korrekt indeksering

Mens man foretager søgninger eller sammenlægninger, sorterer man ofte data. Selvom du ansøger om sortering i den sidste fase af en pipeline, har du stadig brug for et indeks til at dække sorteringen. Hvis indekset på sorteringsfeltet ikke er tilgængeligt, er MongoDB tvunget til at sortere uden et indeks. Der er en hukommelsesgrænse på 32 MB af den samlede størrelse af alle dokumenter, der er involveret i sorteringsoperationen. Hvis MongoDB rammer den grænse, kan det enten producere en fejl eller returnere et tomt sæt.

Efter at have diskuteret tilføjelse af indekser, er det også vigtigt ikke at tilføje unødvendige indekser. Hvert indeks du tilføjer i databasen, skal du opdatere alle disse indekser, mens du opdaterer dokumenter i samlingen. Dette kan forringe databasens ydeevne. Hvert indeks vil også optage noget plads og hukommelse, så antallet af indekser kan føre til lagerrelaterede problemer.

En anden måde at optimere brugen af ​​et indeks på er at tilsidesætte standard _id-feltet. Det eneste formål med dette felt er at beholde ét unikt felt pr. dokument. Hvis dine data indeholder et tidsstempel eller et id-felt, kan du tilsidesætte _id-feltet og gemme et ekstra indeks.

Læs v/s skriveforhold

Design af skemaer til enhver applikation afhænger i høj grad af, om en applikation er læsetung eller skrivetung. For eksempel, hvis du bygger et dashboard til at vise tidsseriedata, bør du designe dit skema på en sådan måde, at skrivegennemstrømningen maksimeres. Hvis din applikation er baseret på e-handel, vil de fleste af operationerne være læseoperationer, da de fleste brugere vil gennemgå alle produkterne og gennemse forskellige kataloger. I sådanne tilfælde bør du bruge denormaliseret skema til at reducere antallet af opkald til DB for at få relevante data.

BSON-datatyper

Sørg for, at du definerer BSON-datatyper for alle felter korrekt, mens du designer skemaet. Fordi når du ændrer datatypen for et hvilket som helst felt, vil MongoDB omskrive hele dokumentet i et nyt hukommelsesrum. For eksempel, hvis du forsøger at gemme (int)0 i stedet for (float)0.0-feltet, omskriver MongoDB hele dokumentet på en ny adresse på grund af ændring i BSON-datatype.

Konklusion

I en nøddeskal er det klogt at designe et skema til din Mongo-database, da det kun vil forbedre din applikations ydeevne. Fra version 3.2 begyndte MongoDB at understøtte dokumentvalidering, hvor du kan definere hvilke felter der skal indsættes for at indsætte et nyt dokument. Fra version 3.6 introducerede MongoDB en mere elegant måde at håndhæve skemavalidering ved hjælp af JSON Schema Validation. Ved at bruge denne valideringsmetode kan du gennemtvinge datatypekontrol sammen med påkrævet feltkontrol. Du kan bruge ovenstående fremgangsmåder til at kontrollere, om alle dokumenter bruger den samme type skema eller ej.