MongoDB Schema Planning Tips

Een van de meest geadverteerde functies van MongoDB is het vermogen om "schemaloos" te zijn. Dit betekent dat MongoDB geen enkel schema oplegt aan documenten die in een verzameling zijn opgeslagen. Normaal gesproken slaat MongoDB documenten op in een JSON-indeling, zodat elk document verschillende soorten schema's/structuren kan opslaan. Dit is gunstig voor de beginfasen van de ontwikkeling, maar in de latere stadia wilt u misschien wat schemavalidatie afdwingen terwijl u nieuwe documenten invoegt voor betere prestaties en schaalbaarheid. Kortom, "Schemaloos" betekent niet dat u uw schema niet hoeft te ontwerpen. In dit artikel bespreek ik enkele algemene tips voor het plannen van je MongoDB-schema.

Het vinden van het beste schemaontwerp dat bij uw toepassing past, kan soms vervelend zijn. Hier zijn enkele punten waarmee u rekening kunt houden bij het ontwerpen van uw schema.

Vermijd groeiende documenten

Als uw schema het mogelijk maakt om documenten te maken die voortdurend in omvang toenemen, moet u stappen ondernemen om dit te voorkomen, omdat dit kan leiden tot verslechtering van de DB- en schijf-IO-prestaties. MongoDB staat standaard een grootte van 16 MB per document toe. Als uw documentgrootte in de loop van de tijd meer dan 16 MB groter wordt, is dit een teken van een slecht schemaontwerp. Het kan soms leiden tot het mislukken van query's. U kunt documentbuckets of technieken voor het vooraf toewijzen van documenten gebruiken om deze situatie te voorkomen. Als uw toepassing documenten van meer dan 16 MB moet opslaan, kunt u overwegen om MongoDB GridFS API te gebruiken.

Vermijd het bijwerken van hele documenten

Als u het hele document probeert bij te werken, zal MongoDB het hele document ergens anders in het geheugen herschrijven. Dit kan de schrijfprestaties van uw database drastisch verminderen. In plaats van het hele document bij te werken, kunt u veldaanpassingen gebruiken om alleen specifieke velden in de documenten bij te werken. Hierdoor wordt een interne update in het geheugen geactiveerd, waardoor de prestaties worden verbeterd.

Probeer joins op applicatieniveau te vermijden

Zoals we allemaal weten, ondersteunt MongoDB geen joins op serverniveau. Daarom moeten we alle gegevens uit DB halen en vervolgens join uitvoeren op toepassingsniveau. Als u gegevens uit meerdere verzamelingen ophaalt en een grote hoeveelheid gegevens samenvoegt, moet u DB verschillende keren bellen om alle benodigde gegevens te krijgen. Dit zal uiteraard meer tijd vergen aangezien het om het netwerk gaat. Als oplossing voor dit scenario is het logischer als uw toepassing sterk afhankelijk is van joins. U kunt ingesloten documenten gebruiken om alle vereiste gegevens in één vraagoproep te krijgen.

Gebruik juiste indexering

Tijdens het zoeken of aggregeren sorteert men vaak gegevens. Ook al solliciteer je om te sorteren in de laatste fase van een pijplijn, je hebt nog steeds een index nodig om de sortering te dekken. Als de index op het sorteerveld niet beschikbaar is, wordt MongoDB gedwongen om zonder index te sorteren. Er is een geheugenlimiet van 32 MB van de totale grootte van alle documenten die betrokken zijn bij de sorteerbewerking. Als MongoDB die limiet bereikt, kan het een fout produceren of een lege set retourneren.

Na het bespreken van het toevoegen van indexen, is het ook belangrijk om geen onnodige indexen toe te voegen. Elke index die u aan de database toevoegt, moet u al deze indexen bijwerken terwijl u documenten in de collectie bijwerkt. Dit kan de prestaties van de database verslechteren. Elke index neemt ook wat ruimte en geheugen in beslag, dus het aantal indexen kan leiden tot opslaggerelateerde problemen.

Een andere manier om het gebruik van een index te optimaliseren, is door het standaard _id-veld te overschrijven. Het enige doel van dit veld is het behouden van één uniek veld per document. Als uw gegevens een tijdstempel of een id-veld bevatten, kunt u het _id-veld overschrijven en één extra index opslaan.

Lezen vs/s Schrijven Verhouding

Het ontwerpen van schema's voor elke toepassing hangt er enorm van af of een toepassing zwaar lezen of schrijven is. Als u bijvoorbeeld een dashboard bouwt om tijdreeksgegevens weer te geven, moet u uw schema zo ontwerpen dat de schrijfdoorvoer wordt gemaximaliseerd. Als uw toepassing op e-commerce is gebaseerd, zijn de meeste bewerkingen leesbewerkingen, aangezien de meeste gebruikers alle producten doornemen en door verschillende catalogi bladeren. In dergelijke gevallen moet u een gedenormaliseerd schema gebruiken om het aantal aanroepen naar DB voor het verkrijgen van relevante gegevens te verminderen.

BSON-gegevenstypen

Zorg ervoor dat u BSON-gegevenstypen voor alle velden correct definieert tijdens het ontwerpen van het schema. Want wanneer u het gegevenstype van een veld wijzigt, zal MongoDB het hele document in een nieuwe geheugenruimte herschrijven. Als u bijvoorbeeld (int)0 probeert op te slaan in plaats van (float)0.0-veld, herschrijft MongoDB het hele document op een nieuw adres vanwege een wijziging in het BSON-gegevenstype.

Conclusie

Kortom, het is verstandig om een ​​schema voor uw Mongo-database te ontwerpen, omdat dit de prestaties van uw toepassing alleen maar zal verbeteren. Vanaf versie 3.2 is MongoDB begonnen met het ondersteunen van documentvalidatie waarbij u kunt definiëren welke velden vereist zijn om een ​​nieuw document in te voegen. Vanaf versie 3.6 introduceerde MongoDB een elegantere manier om schemavalidatie af te dwingen met behulp van JSON Schema Validation. Met deze validatiemethode kunt u controle van het gegevenstype afdwingen, samen met verplichte veldcontrole. U kunt de bovenstaande benaderingen gebruiken om te controleren of alle documenten hetzelfde type schema gebruiken of niet.