Laat me je een paar hints geven op basis van mijn wereldwijde kennis en ervaring:
Gebruik kortere veldnamen
MongoDB slaat dezelfde sleutel op voor elk document. Deze herhaling zorgt voor meer schijfruimte. Dit kan een prestatieprobleem hebben op een zeer grote database zoals die van jou.
Voordelen:
- Minder formaat van de documenten, dus minder schijfruimte
- Meer documenten om in RAM te passen (meer caching)
- De grootte van de do-indexen zal in sommige scenario's kleiner zijn
Nadelen:
- Minder leesbare namen
Optimaliseren op indexgrootte
Hoe kleiner de indexgrootte is, hoe meer deze in het RAM past en hoe minder indexmissers er gebeuren. Overweeg bijvoorbeeld een SHA1-hash voor git-commits. Een git-commit wordt vaak weergegeven door de eerste 5-6 tekens. Sla dan gewoon de 5-6 tekens op in plaats van de hele hash.
Begrijp de opvulfactor
Voor updates die plaatsvinden in het document, waardoor kostbare documentverplaatsing wordt veroorzaakt. Deze documentverplaatsing veroorzaakt het verwijderen van het oude document en het bijwerken naar een nieuwe lege locatie en het bijwerken van de indexen, wat kostbaar is.
We moeten ervoor zorgen dat het document niet beweegt als er een update plaatsvindt. Voor elke verzameling is er een opvulfactor die bij het invoegen van het document aangeeft hoeveel extra ruimte moet worden toegewezen naast de werkelijke documentgrootte.
U kunt de opvulfactor van de collectie zien met:
db.collection.stats().paddingFactor
Handmatig een opvulling toevoegen
In jouw geval ben je er vrij zeker van dat je begint met een klein document dat zal groeien. Als u uw document na een tijdje bijwerkt, worden meerdere documenten verplaatst. Voeg dus beter een opvulling toe voor het document. Helaas is er geen gemakkelijke manier om een opvulling toe te voegen. We kunnen dit doen door enkele willekeurige bytes aan een sleutel toe te voegen tijdens het invoegen en vervolgens verwijderen van die sleutel in de volgende update-query.
Tot slot, als u er zeker van bent dat sommige sleutels in de toekomst naar de documenten zullen komen, wijs die sleutels dan vooraf toe met een aantal standaardwaarden zodat verdere updates geen groei van de documentgrootte veroorzaken, waardoor documentverplaatsingen ontstaan.
U kunt details krijgen over de query die de documentverplaatsing veroorzaakt:
db.system.profile.find({ moved: { $exists : true } })
Groot aantal collecties versus groot aantal documenten in weinig collecties
Schema is iets dat afhangt van de toepassingsvereisten. Als er een enorme verzameling is waarin we alleen de laatste N dagen aan gegevens opvragen, dan kunnen we optioneel kiezen voor gescheiden verzameling en kunnen oude gegevens veilig worden gearchiveerd. Dit zorgt ervoor dat het cachen in het RAM-geheugen correct wordt uitgevoerd.
Elke gemaakte collectie brengt kosten met zich mee die hoger zijn dan de kosten voor het maken van een collectie. Elk van de collecties heeft een minimumgrootte van enkele KB's + één index (8 KB). Elke collectie heeft een bijbehorende naamruimte, standaard hebben we zo'n 24K naamruimten. Het hebben van een verzameling per gebruiker is bijvoorbeeld een slechte keuze omdat het niet schaalbaar is. Na een tijdje zal Mongo ons niet meer toestaan om nieuwe verzamelingen indexen te maken.
Over het algemeen heeft het hebben van veel collecties geen significante prestatievermindering. We kunnen er bijvoorbeeld voor kiezen om één ophaling per maand te doen, als we weten dat we altijd vragen op basis van maanden.
Denormalisatie van gegevens
Het wordt altijd aanbevolen om alle gerelateerde gegevens voor een query of reeks query's op dezelfde schijflocatie te bewaren. U moet de informatie over verschillende documenten dupliceren. In een blogpost wil je bijvoorbeeld de opmerkingen van de post in het postdocument opslaan.
Voordelen:
- indexgrootte zal veel kleiner zijn omdat het aantal indexitems kleiner zal zijn
- query zal erg snel zijn, inclusief het ophalen van alle benodigde details
- documentgrootte zal vergelijkbaar zijn met paginagrootte, wat betekent dat wanneer we deze gegevens in het RAM-geheugen plaatsen, we meestal geen andere gegevens langs de pagina brengen
- documentverplaatsing zorgt ervoor dat we een pagina vrijmaken, niet een klein stukje in de pagina dat niet in verdere invoegingen mag worden gebruikt
Afgetopte collecties
Afgetopte verzamelingen gedragen zich als cirkelvormige buffers. Het zijn speciale collecties met een vast formaat. Deze verzameling kan schrijf- en sequentiële leesbewerkingen met zeer hoge snelheid ontvangen. Omdat ze een vaste grootte hebben, worden de nieuwe documenten, zodra de toegewezen ruimte is gevuld, geschreven door de oudere te verwijderen. Documentupdates zijn echter alleen toegestaan als het bijgewerkte document past in de originele documentgrootte (speel met opvulling voor meer flexibiliteit).