🥇14 saker jag skulle vilja veta innan jag började jobba med MongoDB

Översättningen av artikeln är framtagen inför kursstarten »Icke-relationella databaser«.

Huvudpunkter:

Det är mycket viktigt att utforma en skiss, även om det inte är obligatoriskt i MongoDB.
På samma sätt bör indexen matcha din skiss och åtkomstmönster.
Undvik att använda stora objekt och stora arrayer.
Var försiktig med inställningarna i MongoDB, speciellt när det gäller säkerhet och pålitlighet.
Det finns ingen frågaoptimerare i MongoDB, så var försiktig när du utför förfrågningsoperationer.

Jag har arbetat med databaser länge, men upptäckte MongoDB först nyligen. Det finns några saker som jag önskar att jag hade vetat innan jag började använda den. När man har erfarenhet inom ett specifikt område, får man förutfattade meningar om vad databaser är och vad de gör. För att underlätta förståelsen för andra, presenterar jag en lista över vanliga misstag.

Att skapa en MongoDB-server utan autentisering

Tyvärr installeras MongoDB som standard utan autentisering. För en arbetsstation med lokal åtkomst är detta normalt. Men eftersom MongoDB är ett flervalsystem som gärna använder stora mängder minne, är det bättre att installera den på en server med så mycket RAM som möjligt, även om du bara ska använda den för utveckling. Installation på server genom standardport kan bli problematisk, särskilt om förfrågningar kan utföra vilken kod som helst på javascript (t.ex. $where som idé för injektion).

Det finns flera autentiseringsmetoder, men det enklaste är att ställa in ID/lösenord för användaren. Använd denna idé medan du funderar på en mer invecklad autentisering baserad på LDAP. När det kommer till säkerhet bör MongoDB hållas uppdaterad, och loggar bör alltid kontrolleras för obehörig åtkomst. Jag gillar till exempel att välja en annan port än standardporten.

Glöm inte att koppla attackytan till MongoDB

Checklista för säkerhet i MongoDB Innehåller bra råd för att minska risken för nätintrång och dataläckor. Det är lätt att avfärda och säga att en utvecklingsserver inte behöver hög säkerhetsnivå. Men det är inte så enkelt och detta gäller alla MongoDB-servrar. Särskilt om det inte finns någon stark anledning att använda mapReduce, grupp eller $where, bör användningen av godtycklig JavaScript-kod stängas av genom att ange detta i konfigurationsfilen javascriptAktiverat:false. Eftersom standard MongoDB-datafiler inte är krypterade, är det rimligt att köra MongoDB med Dedikerad användare, som har full åtkomst till filerna, med begränsad åtkomst endast för sig själv och möjlighet att använda sina egna åtkomstkontrollverktyg i operativsystemet.

Fel vid schemadesign

MongoDB använder ingen schema. Men det betyder inte att schema är onödigt. Om du bara vill lagra dokument utan någon sammanhängande schema, kan du snabbt och enkelt spara dem, men att extrahera dem senare kan vara jävligt svårt.

Den klassiska artikeln “6 empiriska regler för att designa MongoDB-scheman” är värt att läsa, och funktioner som Schema Explorer i det externa verktyget Studio 3T, är värt att använda för regelbundna schemakontroller.

Glöm inte bort sorteringsordningen

Att glömma bort sorteringsordningen kan leda till stor besvikelse och förlora mer tid än med någon annan felaktig konfiguration. Som standard använder MongoDB binär sortering. Men det är osannolikt att det är till någon nytta. Skiftlägeskänsliga, diakritiska, binära sorteringar ansågs vara underliga anachronismer tillsammans med pärlor, kaftaner och krullade mustascher redan på 80-talet. Nu är deras användning oförlåtlig. I verkliga livet är "motorcykel" samma sak som "Motorcykel". Och "Britania" och "britania" är samma plats. Liten bokstav är helt enkelt en versal motsvarighet. Och låt mig inte ens börja prata om sortering av diakritiska tecken. När du skapar en databas i MongoDB, använd sorteringsalternativ utan hänsyn till diakritiska och skiftlägen, som motsvarar språket och kulturen hos systemets användare. Detta gör det betydligt enklare att söka bland strängdata.

Att skapa samlingar med stora dokument

MongoDB kan hantera stora dokument på upp till 16 MB i samlingar, och GridFS är avsedd för dokument som är större än 16 MB. Men bara för att stora dokument kan lagras där, betyder det inte att det är en bra idé att lagra dem där. MongoDB fungerar bäst om du sparar enskilda dokument som är några kilobyte stora, och behandlar dem mer som rader i en bred SQL-tabell. Stora dokument kan orsaka problem med prestanda.

Att skapa dokument med stora matriser

Dokument kan innehålla arrayer. Det är bäst om antalet element i arrayen är långt ifrån tusentals. Om element ofta läggs till i arrayen kan den överskrida det dokument som innehåller den, och då måste den flyttas, vilket innebär att du behöver uppdatera och index. Vid omindexering av ett dokument med en stor array skrivs indexen ofta över, eftersom det finns en post, som lagrar dess index. Sådan omindexering sker också när dokumentet infogas eller tas bort.

I MongoDB finns det så kallat «utfyllnadsfaktor», som ger utrymme för att dokumenten ska växa för att minimera detta problem.
Du kan tänka att det går bra utan att indexera arrayer. Tyvärr kan bristen på index leda till andra problem. Eftersom dokumenten genomgås från början till slut, kommer sökningar efter element i slutet av arrayen att ta mer tid, och de flesta operationer som rör sådana dokument kommer att vara långsamma.

Kom ihåg att ordningen för stegen i aggregation är viktig

I en databas med en frågeoptimerare är de frågor du skriver förklaringar av vad du vill ha, och inte hur du vill ha det. Den här mekanismen fungerar på ett sätt som liknar att lägga en beställning i en restaurang: vanligtvis beställer du bara en rätt, snarare än att ge detaljerade instruktioner till kocken.

I MongoDB instruerar du kocken. Till exempel, se till att data passerar genom reduce så tidigt som möjligt i pipelinen med hjälp av $match och $project, och sorteringen sker först efteråt. reduce, och att sökningen sker precis i den ordning som du behöver. Att ha en frågeoptimerare som tar bort onödigt arbete, optimerar stegen och väljer typ av anslutning kan vara en lyx. I MongoDB får du mer kontroll till priset av bekvämlighet.

Verktyg som Studio 3T förenklar konstruktionen av aggregationsfrågor i MongoDB. Aggregation Editor-funktionen låter dig tillämpa pipeline-operatörer steg för steg och kontrollera ingångs- och utdata i varje steg för att förenkla felsökning.

Användning av snabb skrivning

Installera aldrig höghastighetsinloggningsinställningar i MongoDB med låg tillförlitlighet. Detta läge «file-and-forget» verkar snabbt eftersom kommandot återvänder innan skrivningen genomförs. Om systemet kraschar innan data skrivs till disken går de förlorade och hamnar i ett inkonsekvent tillstånd. Lyckligtvis ingår journalföring i 64-bitars MongoDB.

Lagringsmotorerna MMAPv1 och WiredTiger använder journalföring för att förhindra detta, även om WiredTiger kan återhämta sig till den senaste konsekventa kontrollpunkten, om journalföringen stängs av.

Journalföring garanterar att databasen är i ett konsekvent tillstånd efter återställning och behåller all data fram till den tidpunkt då den loggas. Frekvensen för loggning ställs in med parametern commitIntervalMs.

För att vara säker på inloggningar, se till att journalföringen är aktiverad i konfigurationsfilen (storage.journal.enabled), och att loggningsfrekvensen motsvarar den mängd information som du har råd att förlora.

Sortering utan index

Vid sökning och aggregering uppstår ofta behovet av att sortera data. Förhoppningsvis görs detta vid ett av de slutliga stegen, efter att resultatet har filtrerats för att minska volymen av sorterad data. Och även i så fall behöver du ett index. Du kan använda ett enkelt eller sammansatt index.

Om det inte finns något lämpligt index kan MongoDB klara sig utan det. Det finns en minnesbegränsning på 32 MB för den totala storleken på alla dokument i sorteringsoperationen, och om MongoDB når denna gräns kommer den antingen att ge ett felmeddelande eller returnera en tom resultatsats.

Sökning utan indexstöd

Sökfrågor utför en funktion som liknar JOIN-operationen i SQL. För att fungera bättre behöver de en index för nyckelvärdet som används som en extern nyckel. Detta är inte uppenbart, eftersom användningen inte återspeglas i explain(). Sådana index är ett komplement till indexet som är skrivet i explain(), vilket i sin tur används av pipelineoperatörer $match och $sort, när de uppträder i början av pipelinen. Index kan nu omfatta vilken fas som helst i aggregationspipen.

Avstå från att använda fleruppdateringar

Metod db.collection.update() som används för att ändra en del av ett befintligt dokument eller hela dokumentet, upp till fullständig ersättning beroende på det parameter du angivit update. Det är inte så uppenbart att det inte kommer att bearbeta alla dokument i samlingen, förrän du ställer in parametern multi för att uppdatera alla dokument som uppfyller sökkriterierna.

Tänk på vikten av ordningen på nycklar i hash-tabellen.

I JSON består ett objekt av en osorterad samling som innehåller noll eller fler namn/värde-par, där namnet är en sträng och värdet är en sträng, ett nummer, ett booleskt värde, noll, ett objekt eller en array.

Tyvärr lägger BSON stor vikt vid ordningen vid sökning. I MongoDB har ordningen på nycklar inne i inbäddade objekt betydelse, dvs. { firstname: "Phil", surname: "factor" } är inte detsamma som { { surname: "factor", firstname: "Phil" }. Det betyder att du måste behålla ordningen på namn/värde-par i dokumenten om du vill vara säker på att du hittar dem.

Förväxla inte «null» och «undefined»

Värde «undefined» har aldrig varit tillåtet i JSON, enligt den officiella standarden JSON (ECMA-404, Sektion 5), trots att det används i JavaScript. Dessutom är det för BSON föråldrat och konverteras till $null, vilket inte alltid är en bra lösning. Undvik att använda «undefined» i MongoDB.

Användning `$limit()` utan `$sort()`

Mycket ofta, när du utvecklar i MongoDB, är det bra att se ett exempel på resultatet som kommer att returneras från en fråga eller aggregation. För detta ändamål kommer du att ha nytta av $limit(), men det bör aldrig finnas i den slutliga versionen av koden, såvida du inte använder det framför $sort. Den här mekanismen är nödvändig eftersom du annars inte kan garantera resultatordningen och inte kan utföra pålitliga datavisningar. I den övre delen av resultatet kommer du att få olika poster beroende på sortering. För att fungera pålitligt måste frågor och aggregeringar vara deterministiska, det vill säga ge samma resultat varje gång de körs. Kod som har $limit(), men inte $sort, kommer inte att vara deterministisk och kan senare orsaka fel som är svåra att spåra.

Slutsats

Det enda sättet att bli besviken på MongoDB är att jämföra den direkt med en annan typ av databas, såsom RDBMS, eller att närma sig användningen utifrån vissa förväntningar. Det är som att jämföra en apelsin med en gaffel. Databassystem har specifika mål. Det är bäst att bara förstå och uppskatta dessa skillnader för sig själv. Det skulle vara en skam att pressa utvecklarna av MongoDB för vägen de tvingades gå med RDBMS. Jag vill se nya och intressanta sätt att lösa gamla problem, som att säkerställa dataintegritet och att skapa datorsystem som är motståndskraftiga mot fel och attacker från illvilliga aktörer.

Implementeringen av ACID-transaktionalitet i MongoDB version 4.0 är ett bra exempel på hur viktiga förbättringar kan införas på ett innovativt sätt. Multidokument- och multioperationstransaktioner är nu atomära. Möjligheten att reglera den tid som behövs för att få lås och avsluta hängande transaktioner, samt att ändra isoleringsnivån, har också lagts till.