Låt mig ge dig ett par tips baserat på min globala kunskap och erfarenhet:
Använd kortare fältnamn
MongoDB lagrar samma nyckel för varje dokument. Denna upprepning orsakar ökat diskutrymme. Detta kan ha vissa prestandaproblem på en väldigt stor databas som din.
Fördelar:
- Mindre storlek på dokumenten, så mindre diskutrymme
- Mer dokument för att få plats i RAM (mer cachning)
- Storleken på do-indexen blir mindre i vissa scenarier
Nackdelar:
- Mindre läsbara namn
Optimera på indexstorlek
Ju mindre indexstorleken är, desto mer får den plats i RAM och mindre indexmissen händer. Tänk på en SHA1-hash för git-commits till exempel. En git commit representeras många gånger av de första 5-6 tecknen. Lagra sedan helt enkelt de 5-6 tecknen istället för all-hash.
Förstå stoppningsfaktorn
För uppdateringar som sker i dokumentet som orsakar kostsamma dokumentflytt. Detta dokument flyttas vilket gör att det gamla dokumentet tas bort och uppdateras till en ny tom plats och att indexen uppdateras vilket är kostsamt.
Vi måste se till att dokumentet inte flyttas om någon uppdatering inträffar. För varje samling finns en utfyllnadsfaktor inblandad som talar om, under dokumentinsättning, hur mycket extra utrymme som ska tilldelas förutom den faktiska dokumentstorleken.
Du kan se utfyllnadsfaktorn för samlingen med:
db.collection.stats().paddingFactor
Lägg till en utfyllnad manuellt
I ditt fall är du ganska säker på att börja med ett litet dokument som kommer att växa. Att uppdatera ditt dokument efter ett tag kommer att orsaka flera dokumentflyttningar. Så det är bättre att lägga till en utfyllnad för dokumentet. Tyvärr finns det inget enkelt sätt att lägga till en stoppning. Vi kan göra det genom att lägga till några slumpmässiga bytes till någon nyckel medan vi infogar och sedan ta bort den nyckeln i nästa uppdateringsfråga.
Slutligen, om du är säker på att vissa nycklar kommer att komma till dokumenten i framtiden, förallokera dessa nycklar med vissa standardvärden så att ytterligare uppdateringar inte orsakar ökning av dokumentstorleken och orsakar dokumentflyttningar.
Du kan få information om frågan som orsakar dokumentflyttning:
db.system.profile.find({ moved: { $exists : true } })
Stort antal samlingar kontra stort antal dokument i få samlingar
Schema är något som beror på applikationskraven. Om det finns en enorm samling där vi endast efterfrågar de senaste N dagarna av data, kan vi valfritt välja att ha separat insamling och gamla data kan säkert arkiveras. Detta kommer att se till att cachning i RAM-minne görs korrekt.
Varje samling som skapas medför en kostnad som är mer än kostnaden för att skapa en samling. Varje samling har en minimistorlek som är några KB + ett index (8 KB). Varje samling har ett namnområde associerat, som standard har vi några 24K namnutrymmen. Till exempel att ha en samling per användare är ett dåligt val eftersom det inte är skalbart. Efter ett tag kommer Mongo inte att tillåta oss att skapa nya samlingar av index.
Att ha många samlingar har i allmänhet inga betydande prestationsstraff. Vi kan till exempel välja att ha en samling per månad, om vi vet att vi alltid frågar baserat på månader.
Denormalisering av data
Det rekommenderas alltid att hålla alla relaterade data för en fråga eller sekvens av frågor på samma diskplats. Du behöver duplicera informationen i olika dokument. Till exempel, i ett blogginlägg, vill du lagra inläggets kommentarer i inläggsdokumentet.
Fördelar:
- indexstorleken blir mycket mindre eftersom antalet indexposter blir mindre
- frågan kommer att vara mycket snabb, vilket inkluderar att hämta all nödvändig information
- Dokumentstorleken kommer att vara jämförbar med sidstorleken, vilket innebär att när vi tar med dessa data i RAM-minne, tar vi för det mesta inte med andra data längs sidan
- flyttning av dokument kommer att se till att vi frigör en sida, inte en liten bit på sidan som kanske inte kan användas i ytterligare inlägg
Begränsade samlingar
Capped samling beter sig som cirkulära buffertar. De är speciella typer av samlingar med fast storlek. Dessa samlingar kan ta emot skrivningar och sekventiell läsning i mycket hög hastighet. Eftersom det är fast storlek, skrivs de nya dokumenten när det tilldelade utrymmet är fyllt genom att de äldre raderas. Dokumentuppdateringar är dock endast tillåtna om det uppdaterade dokumentet passar originaldokumentets storlek (lek med utfyllnad för mer flexibilitet).