Lad mig give dig et par tip baseret på min globale viden og erfaring:
Brug kortere feltnavne
MongoDB gemmer den samme nøgle for hvert dokument. Denne gentagelse forårsager øget diskplads. Dette kan have nogle problemer med ydeevnen på en meget stor database som din.
Fordele:
- Mindre størrelse på dokumenterne, så mindre diskplads
- Mere dokumenter, der passer til RAM (mere caching)
- Størrelsen af do-indekserne vil være mindre i nogle scenarier
Ulemper:
- Mindre læselige navne
Optimer på indeksstørrelse
Jo mindre indeksstørrelsen er, jo mere får den plads i RAM og mindre indeksmisser sker. Overvej for eksempel en SHA1-hash for git-commits. En git commit er mange gange repræsenteret med de første 5-6 tegn. Så skal du blot gemme de 5-6 tegn i stedet for alle hash.
Forstå polstringsfaktoren
For opdateringer, der sker i dokumentet, der forårsager dyre dokumentflytninger. Dette dokumentflytning forårsager sletning af det gamle dokument og opdatering af det til en ny tom placering og opdatering af indekserne, hvilket er dyrt.
Vi skal sikre os, at dokumentet ikke flytter sig, hvis der sker en opdatering. For hver samling er der en udfyldningsfaktor involveret, som fortæller, under dokumentindsættelse, hvor meget ekstra plads der skal tildeles bortset fra den faktiske dokumentstørrelse.
Du kan se opsamlingspolstringsfaktoren ved at bruge:
db.collection.stats().paddingFactor
Tilføj en polstring manuelt
I dit tilfælde er du ret sikker på at starte med et lille dokument, der vil vokse. Opdatering af dit dokument efter et stykke tid vil medføre flere dokumentflytninger. Så hellere tilføje en polstring til dokumentet. Desværre er der ingen nem måde at tilføje en polstring på. Vi kan gøre det ved at tilføje nogle tilfældige bytes til en eller anden nøgle, mens vi indsætter og derefter slette den nøgle i den næste opdateringsforespørgsel.
Til sidst, hvis du er sikker på, at nogle nøgler vil komme til dokumenterne i fremtiden, så tildel disse nøgler med nogle standardværdier, så yderligere opdateringer ikke forårsager vækst i dokumentstørrelsen og forårsager dokumentflytninger.
Du kan få detaljer om den forespørgsel, der forårsager dokumentflytning:
db.system.profile.find({ moved: { $exists : true } })
Stort antal samlinger VS stort antal dokumenter i få samlinger
Skema er noget, der afhænger af applikationskravene. Hvis der er en enorm samling, hvor vi kun forespørger på de seneste N dages data, så kan vi valgfrit vælge at have separat indsamling, og gamle data kan sikkert arkiveres. Dette vil sikre, at caching i RAM udføres korrekt.
Hver oprettet samling medfører en omkostning, der er mere end omkostningerne ved at oprette en samling. Hver af samlingerne har en minimumsstørrelse, som er et par KB'er + et indeks (8 KB). Hver samling har et navneområde tilknyttet, som standard har vi nogle 24K navnerum. For eksempel er det et dårligt valg at have en samling pr. bruger, da den ikke er skalerbar. Efter et tidspunkt vil Mongo ikke tillade os at oprette nye samlinger af indekser.
Generelt har mange samlinger ingen væsentlig præstationsstraf. For eksempel kan vi vælge at have én samling om måneden, hvis vi ved, at vi altid forespørger baseret på måneder.
Denormalisering af data
Det anbefales altid at opbevare alle de relaterede data for en forespørgsel eller sekvens af forespørgsler på den samme diskplacering. Du har brug for at duplikere oplysningerne på tværs af forskellige dokumenter. I et blogindlæg vil du f.eks. gemme indlæggets kommentarer i indlægsdokumentet.
Fordele:
- indeksstørrelse vil være meget mindre, da antallet af indeksposter vil være mindre
- forespørgslen vil være meget hurtig, hvilket inkluderer at hente alle nødvendige detaljer
- dokumentstørrelse vil være sammenlignelig med sidestørrelse, hvilket betyder, at når vi bringer disse data i RAM, bringer vi det meste af tiden ikke andre data med på siden
- dokumentflytning vil sikre, at vi frigiver en side, ikke en lille bitte del af siden, som måske ikke kan bruges i yderligere indsættelser
Begrænsede samlinger
Afdækket samling opfører sig som cirkulære buffere. De er specielle typer af fast størrelse samlinger. Disse samlinger kan modtage meget højhastighedsskrivninger og sekventielle læsninger. Da det er fast størrelse, skrives de nye dokumenter, når den tildelte plads er udfyldt, ved at slette de ældre. Dokumentopdateringer er dog kun tilladt, hvis det opdaterede dokument passer til den originale dokumentstørrelse (leg med polstring for mere fleksibilitet).