Het leren van MongoDB vereist veel nauwkeurig denken. Er wordt vaak weinig rekening mee gehouden bij essentiële ondernemingen die anders de prestaties van de database in productiemodus in gevaar zouden kunnen brengen.
MongoDB is een NoSQL DBMS dat letterlijk een ander patroon volgt dan SQL-databases, vooral wat betreft beveiliging en structuur. Hoewel sommige van de geïntegreerde functies de prestaties bevorderen en het tot een van de beste van de laatste tijd maken, vormen sommige functies bijgevolg potentiële bedreigingen die de prestaties kunnen verpesten als er geen rekening mee wordt gehouden.
In een recente 'worst case'-ervaring probeerde ik een verzameling te doorzoeken met documenten die grote arrays hadden en het duurde eeuwen voordat ik de resultaten terug kreeg. Ik besloot deze blog te schrijven omdat ik wist dat als iemand dezelfde problemen ervaart, deze blog van grote hulp zal zijn.
Belangrijke overwegingen voor MongoDB in productie
- Beveiliging en authenticatie.
- Uw documenten indexeren
- Een schema gebruiken in je collecties
- Afgetopte collectie
- Documentformaat
- Arraygrootte voor ingesloten documenten
- Aggregatiepijplijnfasen
- Volgorde van sleutels in hash-object
- 'undefined' en 'null' in MongoDB
- Schrijfbewerking
MongoDB-beveiliging en authenticatie
Gegevens variëren op veel manieren en het is duidelijk dat je bepaalde informatie vertrouwelijk moet houden. Standaard stellen MongoDB-installaties geen authenticatievereiste als een must, maar dat geeft u geen toestemming om het te gebruiken, vooral wanneer het om vertrouwelijke gegevens zoals financiële en medische gegevens gaat. Op een ontwikkelwerkstation is het niet erg, maar vanwege de betrokkenheid van meerdere gebruikers bij de productiemodus is het een goede gewoonte om de authenticatiecertificaten in te stellen. De meest gebruikelijke en gemakkelijk te gebruiken methode is de standaard MongoDB-gebruikersnaam en wachtwoordreferenties.
Gegevens worden geschreven naar bestanden die toegankelijk zijn via een hulpprogramma van een derde partij, meer nog als ze niet versleuteld zijn. De gegevens kunnen zonder uw medeweten worden gewijzigd als een anonieme persoon toegang krijgt tot de systeembestanden. Door de database op een speciale server te hosten en een enkele gebruiker toe te wijzen die volledige toegang heeft tot de gegevensbestanden, bespaart u de truc.
Het beschermen van gegevens tegen externe injectieaanvallen is ook een essentiële taak. Sommige operatoren zoals $group, $whereby en de mapReduce-bewerkingen zijn javascript(js) ontwikkeld en zijn daarom vatbaar voor js-manipulatie. Om elke vorm van gegevensintegriteit als resultaat te voorkomen, kunt u de willekeurige JS-instelling uitschakelen door de parameter javascriptEnabled:false in het configuratiebestand te configureren als u geen van de genoemde operators hebt gebruikt. Verder kunt u het risico op gegevenstoegang door netwerkinbreuken verminderen door enkele van de procedures te volgen die zijn aangegeven in de MongoDB-beveiligingschecklist.
Uw documenten indexeren
Indexeren wijst over het algemeen een unieke identificatiewaarde toe aan elk document in een MongoDB-verzameling. Indexering zorgt voor prestatie-upgrades bij zowel lees- als schrijfbewerkingen. Standaard is deze ingeschakeld en men moet die instelling altijd behouden. Zonder indexering moet de database van het begin tot het einde meerdere documenten doornemen en helaas zal de operatie veel tijd kosten voor documenten die aan het einde zijn, waardoor een slechte latentie voor de query ontstaat. Op een bepaald moment, aan het einde van de applicatie, kunnen gebruikers een vertraging ervaren en denken ze dat de applicatie eigenlijk niet werkt. Indexeren is handig bij het sorteren en opzoeken van query's, waarbij de zoekbewerking zelf niet wordt weggelaten. Sorteren is een veelvoorkomende bewerking voor veel geretourneerde documenten. Het wordt vaak uitgevoerd als de laatste fase nadat documenten zijn gefilterd, zodat een kleine hoeveelheid gegevens moet worden gesorteerd. Een index helpt in dit geval de gegevens te sorteren in de vorm van invoer en de geretourneerde gegevens te beperken tot een limiet van 32 MB. Als er geen indexering is, wordt de kans dat de 32 geheugenlimiet voor de gecombineerde grootte van geretourneerde documenten wordt overschreden en wanneer de database deze limiet bereikt, geeft deze een fout naast het retourneren van een lege recordset.
$lookup-bewerking wordt ook ondersteund met indexering. Een index op de sleutelwaarde die als refererende sleutel wordt gebruikt, is essentieel voor de verwerking van de voorgaande fasen.
Een schema gebruiken in uw verzamelingen
MongoDB heeft er geen nodig om velden (kolommen) te definiëren, net zoals je dat misschien moet doen voor SQL dbms. Hoezeer u de velden ook hoeft te definiëren, om inconsistentie in de gegevens en eventuele tegenslagen te voorkomen, is het altijd een goede gewoonte om een schema te definiëren. Schema-ontwerp stelt u in staat te bepalen welk type gegevens naar een bepaald veld gaan, welk veld moet worden voorzien van een waarde en in het algemeen de gegevensvalidatie verbeteren voordat deze worden ingevoerd of bijgewerkt, waardoor de integriteit en consistentie van gegevens wordt bevorderd. Een schemaontwerp zal u ook aangeven of u naar gegevens moet verwijzen of deze moet insluiten. Als beginner denk je misschien dat het enige model "One-to-N" zal zijn waarmee je subdocumentarray-ingangen kunt hebben, maar dat is niet het geval.
U moet de kardinaliteitsrelatie tussen documenten begrijpen voordat u uw model maakt. Enkele van de regels die u helpen een optimaal schema te krijgen, zijn:
- Als u het aantal zoekopdrachten wilt verminderen dat u moet uitvoeren voordat u toegang krijgt tot bepaalde gegevens en als er maar weinig velden of matrixelementen bij betrokken zijn, kunt u subdocumenten insluiten. Neem een voorbeeld van het onderstaande model:
-
{ Name: ‘John Doh’, Age:20 Addresses:[ {street: ‘Moi Avenue’, city:’Nairobi’, countryCode: ‘KE’}, {street: ‘Kenyatta Avenue’, city:’Nairobi’, countryCode: ‘KE’}, ] }
-
- Gebruik denormalisatie voor regelmatig bijgewerkte documenten. Als een veld regelmatig wordt bijgewerkt, is het de taak om alle instanties te vinden die moeten worden bijgewerkt. Dit zal resulteren in een trage verwerking van zoekopdrachten, waardoor zelfs de voordelen van denormalisatie worden overweldigd.
- Complexe query's zoals geaggregeerde pipelining nemen meer tijd in beslag als er veel subdocumenten bij betrokken zijn en het nodig is om een document afzonderlijk op te halen.
- Array-elementen met een grote set objectgegevens mogen uiteraard niet worden ingesloten omdat ze kunnen groeien en daardoor de documentgrootte kunnen overschrijden.
Het modelleren van een schema wordt vaak bepaald door het toegangspatroon van de toepassing. U kunt meer procedures vinden die kunnen helpen bij het ontwerp van uw model in de blog 6 vuistregels voor MongoDB Schema Design
Gebruik een gecapte verzameling voor prioriteit voor recente documenten
MongoDB biedt veel bronnen, zoals de gelimiteerde verzameling. Helaas worden sommige uiteindelijk niet gebruikt. Een gecapte collectie heeft een vaste grootte en het is bekend dat het high-throughput-bewerkingen ondersteunt die documenten invoegen en ophalen op basis van de invoegvolgorde. Wanneer de ruimte is opgevuld, worden oude documenten verwijderd om plaats te maken voor nieuwe.
Voorbeeld van gebruiksscenario voor verzamelingen met beperkingen:
- Het cachen van veelgebruikte gegevens, aangezien de verzameling zelf veel leesintensief is in plaats van schrijfintensief. Je moet ervoor zorgen dat de collectie altijd werkt.
- Loggegevens voor systemen met een hoog volume. Afgetopte verzamelingen gebruiken vaak geen index en dit is gunstig omdat de opnamesnelheid vrij snel is, net als bij het schrijven naar een bestand.
Let op MongoDB-documentgrootte
Elk MongoDB-document is beperkt tot een grootte van 16 megabyte. Het is echter optimaal voor het document om deze limiet te bereiken of te benaderen, omdat dit tot ernstige prestatieproblemen kan leiden. MongoDB zelf werkt het beste als de documenten enkele kilobytes groot zijn. Als het document groot genoeg is, duurt een complex projectieverzoek lang en kan er een time-out optreden voor de query.
Let op de arraygrootte van ingesloten documenten
Men kan subdocumenten naar een veld in een document pushen en zo een array-waarde op dit veld creëren. Zoals eerder vermeld, moet u de grootte van de subdocumenten laag houden. Het is net zo belangrijk om ervoor te zorgen dat het aantal array-elementen lager is dan vier. Anders wordt het document groter en moet het op schijf worden verplaatst. Een ander probleem dat met een dergelijke operatie gepaard gaat, is dat elk document opnieuw moet worden geïndexeerd. Bovendien moet elk subdocument evengoed opnieuw worden geïndexeerd. Dit betekent dat er veel indexschriften zullen zijn die leiden tot trage bewerkingen. Voor grote subdocumenten is het eerder belangrijk om de records in een nieuwe collectie te bewaren dan in te sluiten.
Aggregatiepijplijnstadia
Naast de normale MongoDB-querybewerkingen, is er een aggregatieraamwerk dat wordt gebruikt om gegevens te manipuleren en terug te sturen in overeenstemming met enkele specificaties, zoals bestellen en groeperen. MongoDB heeft geen query-optimizer en heeft er dus een nodig om query's op de juiste manier te bestellen. Zorg er met het aggregatieframework voor dat de pijplijnfasen goed geordend zijn. Begin met het verminderen van de hoeveelheid gegevens waarmee u te maken hebt door de operator $match te gebruiken en eventueel $sort op het einde indien nodig. U kunt tools van derden gebruiken, zoals Studio 3T, om uw aggregatiequery te optimaliseren voordat u deze in uw code integreert. Met de tool kunt u gegevensinvoer en -uitvoer in elk van de fasen bekijken, zodat u weet waar u mee te maken hebt.
Het gebruik van $limit en $sort zou altijd dezelfde resultaten moeten opleveren elke keer dat de query wordt uitgevoerd. Als u $limit gebruikt, zijn de geretourneerde gegevens niet bepalend en kunnen sommige problemen moeilijk te traceren zijn.
Controleer de volgorde van sleutels in hash-objecten
Overweeg om twee grote documenten met voorbeeldgegevens te hebben
{
FirstName: ‘John’,
LastName: ‘Doh’
}Als u een zoekbewerking uitvoert met de query {FirstName:'John', LastName:'Doh'}, komt de bewerking niet overeen met de query {LastName:'Doh' FirstName:'John' }. U dient daarom de volgorde van naam- en waardeparen in uw documenten aan te houden.
Vermijd 'undefined' en 'null' in MongoDB
MongoDB gebruikt het BSON-formaat voor zijn documenten. Met JSON-validatie wordt 'undefined' niet ondersteund en moet u het gebruik ervan vermijden. $null komt als een oplossing, maar je moet het ook vermijden.
Overweeg schrijfbewerkingen
Je zou MongoDB kunnen instellen voor schrijven met hoge snelheid, maar dit vormt een tegenvaller omdat een reactie wordt geretourneerd zelfs voordat de gegevens zijn geschreven. Logboekregistratie moet zijn ingeschakeld om dit scenario te voorkomen. Bovendien zijn de gegevens in het geval van een storing in de database nog steeds beschikbaar en wordt een controlepunt gecreëerd dat kan worden gebruikt in het herstelproces. De configuratie voor de duur van journaalschrijfacties kan worden ingesteld met de parameter commitIntervalMs.
Conclusie
Het databasesysteem moet de integriteit en consistentie van gegevens waarborgen en niet alleen bestand zijn tegen falen en kwaadaardigheid. Om tot deze factoren te komen, moet men echter de database zelf en de gegevens die deze bevat, begrijpen. MongoDB zal goed werken als rekening wordt gehouden met de bovengenoemde factoren. Het belangrijkste is dat ze een schema gebruiken. Met een schema kunt u uw gegevens valideren voordat ze worden ingevoerd of bijgewerkt en hoe u deze gegevens gaat modelleren. Gegevensmodellering wordt vaak aangedreven door het toegankelijkheidspatroon van de toepassing. Al deze opgeteld zullen een betere databaseprestatie bieden.