Att lära sig MongoDB kräver mycket exakt tänkande. Lite hänsyn tas ofta inte till väsentliga företag som annars skulle kunna äventyra databasens prestanda i produktionsläge.
MongoDB är ett NoSQL DBMS som bokstavligen följer ett annat mönster än SQL-databaser, särskilt i linje med säkerhet och struktur. Även om några av de integrerade funktionerna främjar dess prestanda och gör den till en av de bästa på senare tid, utgör några av funktionerna följaktligen potentiella hot som kan förstöra dess prestanda om de inte tas i beaktande.
I en "värsta fall"-upplevelse nyligen försökte jag söka efter en samling med dokument som hade stora arrayer och det tog evigheter för mig att få tillbaka resultaten. Jag bestämde mig för att skriva den här bloggen eftersom jag visste att om någon upplever samma problem att den här bloggen kommer att vara till stor hjälp.
Nyckelöverväganden för MongoDB i produktion
- Säkerhet och autentisering.
- Indexera dina dokument
- Använda ett schema i dina samlingar
- Begränsad samling
- Dokumentstorlek
- Arraystorlek för inbäddade dokument
- Aggregationspipelinestadier
- Nycklarnas ordning i hashobjekt
- 'odefinierad' och 'null' i MongoDB
- Skrivåtgärd
MongoDB säkerhet och autentisering
Data varierar på många sätt och du kommer självklart att behöva hålla viss information konfidentiell. Som standard ställer MongoDB-installationer inte in autentiseringskrav som ett måste, men det ger dig inte ett framsteg när du använder det, särskilt när konfidentiell data som ekonomiska och medicinska register är inblandade. På en utvecklingsarbetsstation är det ingen stor sak, men på grund av flera användares engagemang i produktionsläget är det bra att ställa in autentiseringscertifikaten. Den vanligaste och lättanvända metoden är standardinloggningsuppgifterna för MongoDB-användarnamn och lösenord.
Data skrivs till filer som kan nås via ett tredjepartsverktyg mer än om de inte är krypterade. Data kan ändras utan din vetskap om någon anonym person får tillgång till systemfilerna. Att vara värd för databasen på en dedikerad server och tilldela en enskild användare som kommer att ha full tillgång till datafilerna sparar dig tricket.
Att skydda data från externa injektionsattacker är också ett viktigt åtagande. Vissa operatorer som $group, $whereby och mapReduce-operationerna är javascript(js) utvecklade och därför benägna att manipulera js. För att undvika en instans av dataintegritet som ett resultat kan du inaktivera godtycklig JS-inställning genom att konfigurera parametern javascriptEnabled:false i konfigurationsfilen om du inte har använt någon av de nämnda operatorerna. Dessutom kan du minska risken för dataåtkomst genom nätverksintrång genom att använda några av procedurerna som markeras i MongoDB säkerhetschecklista.
Indexera dina dokument
Indexering är i allmänhet att tilldela ett unikt identifieringsvärde till varje dokument i en MongoDB-samling. Indexering åstadkommer prestandauppgraderingar i både läs- och skrivoperationer. Som standard är den aktiverad och man bör alltid behålla den inställningen. Utan indexering måste databasen gå igenom flera dokument från början till slut och tyvärr kommer operationen att kosta tid för dokument som är mot slutet, vilket ger dålig latens för frågan. Vid någon tidpunkt, på applikationssidan, kan användare uppleva en fördröjning och kan tro att applikationen faktiskt inte fungerar. Indexering är till hjälp vid sorterings- och uppslagsfrågeoperationer och utelämnar inte själva sökoperationen. Sortering är en vanlig operation för många returnerade dokument. Det utförs ofta som det sista steget efter att dokument har filtrerats så att en liten mängd data behöver sorteras. Ett index i det här fallet kommer att hjälpa till att sortera data i inmatningstyp och begränsa returnerad data till en gräns på 32MB. Om det inte finns någon indexering kommer chansen att 32 minnesgränsen på den kombinerade storleken på returnerade dokument att överskridas och när databasen når denna gräns kommer den att ge ett fel förutom att returnera en tom postuppsättning.
$lookup-operationen stöds också med indexering på plats. Ett index på nyckelvärdet som används som främmande nyckel är väsentligt för de föregående stegen.
Använda ett schema i dina samlingar
MongoDB behöver inte en för att definiera fält (kolumner) precis som det kan kräva att du gör för SQL dbms. Hur mycket du än inte behöver definiera fälten, för att undvika datainkonsekvens och vissa bakslag som kan uppstå, är det alltid en bra praxis att definiera ett schema. Schemadesign låter dig bestämma vilken typ av data som går till ett visst fält, vilket fält som måste förses med ett värde och generellt förbättra datavalideringen före inmatning eller uppdatering, vilket främjar dataintegritet och konsistens. En schemadesign kommer också att styra dig om du ska referera eller bädda in data. Som nybörjare kanske du tror att den enda modellen kommer att vara "One-to-N" som kommer att underlätta för en att ha underdokument array-poster men så är inte fallet.
Du måste förstå kardinalitetsrelationen mellan dokument innan du gör din modell. Några av reglerna som hjälper dig att få ett optimalt schema är:
- För att minska antalet frågor som du måste köra innan du kommer åt vissa data och om få fält eller matriselement är inblandade, kan du bädda in underdokument. Ta ett exempel på modellen nedan:
-
{ Name: ‘John Doh’, Age:20 Addresses:[ {street: ‘Moi Avenue’, city:’Nairobi’, countryCode: ‘KE’}, {street: ‘Kenyatta Avenue’, city:’Nairobi’, countryCode: ‘KE’}, ] }
-
- För ofta uppdaterade dokument, använd denormalisering . Om något fält kommer att uppdateras ofta, kommer det att finnas uppgiften att hitta alla instanser som behöver uppdateras. Detta kommer att resultera i långsam frågebearbetning, och därmed överväldigande även fördelarna som är förknippade med denormalisering.
- Komplexa frågor som aggregerad pipelining tar längre tid att köra när många underdokument är inblandade och det finns behov av att hämta ett dokument separat.
- Arrayelement med stor uppsättning objektdata bör inte bäddas in uppenbarligen på grund av att de kan växa och följaktligen överskrida dokumentstorleken.
Modellering av ett schema bestäms ofta av applikationsåtkomstmönstret. Du kan hitta fler procedurer som kan hjälpa till med designen av din modell i bloggen 6 Rules of Thumb for MongoDB Schema Design
Använd en begränsad samling för prioritet för senaste dokument
MongoDB tillhandahåller många resurser som den begränsade samlingen. Tyvärr slutar vissa med att inte utnyttjas. En begränsad samling har en fast storlek och den är känd för att stödja operationer med hög genomströmning som infogar och hämtar dokument baserat på insättningsordningen. När utrymmet är fyllt raderas gamla dokument för att ge plats åt nya.
Exempel på användningsfall för begränsad samling:
- Cachar ofta åtkomna data eftersom samlingen i sig är lästung snarare än skrivtung. Du måste se till att samlingen alltid fungerar.
- Logginformation för högvolymsystem. Begränsad samling använder ofta inte ett index och detta är fördelaktigt eftersom inspelningshastigheten är ganska snabb precis som att skriva in i en fil.
Var uppmärksam på MongoDB-dokumentstorlek
Varje MongoDB-dokument är begränsat till en storlek på 16 megabyte. Det är dock optimalt för dokumentet att nå eller närma sig denna gräns eftersom det kommer att medföra en del fruktansvärda prestandaproblem. MongoDB i sig fungerar bäst när storleken på dokumenten är på några kilobyte. Om dokumentet är tillräckligt stort kommer en komplex projektionsbegäran att ta lång tid och frågan kan ta en timeout.
Var uppmärksam på arraystorleken för inbäddade dokument
Man kan skjuta underdokument till ett fält i ett dokument och därigenom skapa ett matrisvärde på detta fält. Som nämnts tidigare måste du hålla storleken på underdokumenten låg. Det är lika viktigt att se till att antalet arrayelement är under en fyrsiffrig. Annars kommer dokumentet att växa utöver sin storlek och det kommer att behöva flyttas till disken. Ett ytterligare problem förknippat med en sådan operation är att varje dokument kommer att behöva återindexeras. Dessutom kommer varje underdokument också behöva indexeras på nytt. Det gör att det blir en hel del indexskrivningar som resulterar i långsamma operationer. För stora underdokument är det snarare viktigt att behålla posterna i en ny samling än att bädda in.
Aggregation Pipeline Stages
Förutom de normala MongoDB-frågeoperationerna finns det ett aggregeringsramverk som används för att manipulera och returnera data i enlighet med vissa specifikationer som ordning och gruppering. MongoDB har ingen frågeoptimerare och behöver därför en för att beställa frågor på lämpligt sätt. Se till att stegen i pipeline är välordnade med aggregeringsramverket. Börja med att minska mängden data du hanterar med hjälp av $match-operatorn och eventuellt $sort i slutändan om du behöver sortera. Du kan använda tredjepartsverktyg som Studio 3T för att optimera din aggregeringsfråga innan du integrerar den i din kod. Verktyget gör att du kan se datainmatning och -utdata i alla stadier och därmed veta vad du har att göra med.
Användning av $limit och $sort bör alltid ge samma resultat varje gång frågan exekveras. Om du använder $limit kommer den returnerade informationen inte att vara deterministisk och kan ge vissa problem som är svåra att spåra.
Kontrollera ordningen på nycklar i Hash-objekt
Överväg att ha två stora dokument med exempeldata
{
FirstName: ‘John’,
LastName: ‘Doh’
}Om du gör en sökoperation med frågan {FirstName:'John', LastName:'Doh'}, matchar operationen inte med frågan {LastName:'Doh' FirstName:'John' }. Du måste därför behålla ordningen på namn- och värdepar i dina dokument.
Undvik "odefinierad" och "null" i MongoDB
MongoDB använder BSON-format för sina dokument. Med JSON-validering stöds inte 'undefined' och du bör undvika att använda det. $null kommer som en lösning men du bör undvika det också.
Överväg skrivoperationer
Du kanske ställer in MongoDB för höghastighetsskrivning men detta utgör ett bakslag i det att ett svar returneras redan innan data skrivs. Journalföring bör aktiveras för att undvika detta scenario. Dessutom, i fallet med ett databasbrott, kommer data fortfarande att vara tillgängliga och det kommer att skapa en kontrollpunkt som kan användas i återställningsprocessen. Konfigurationen för varaktigheten av journalskrivningar kan ställas in med parametern commitIntervalMs.
Slutsats
Databassystemet bör säkerställa dataintegritet och konsistens förutom att vara motståndskraftigt mot misslyckanden och illvilja. Men för att komma fram till dessa faktorer måste man förstå själva databasen och de data den innehåller. MongoDB kommer att fungera bra när de nämnda faktorerna ovan beaktas. Det viktigaste av dem är att använda ett schema. Ett schema gör det möjligt för dig att validera dina data före inmatning eller uppdatering och hur du kommer att modellera dessa data. Datamodellering drivs ofta av applikationens tillgänglighetsmönster. Alla dessa summerade kommer att erbjuda bättre databasprestanda.