Översättningen av artikeln förbereddes strax före kursstart .
Höjdpunkter:
- Det är extremt viktigt att utveckla ett schema även om det är valfritt i MongoDB.
- På samma sätt måste index matcha ditt schema och åtkomstmönster.
- Undvik att använda stora föremål och stora arrayer.
- Var försiktig med MongoDB-inställningar, särskilt när det kommer till säkerhet och tillförlitlighet.
- MongoDB har ingen frågeoptimerare, så du måste vara försiktig när du utför frågeoperationer.
Jag har jobbat med databaser väldigt länge, men upptäckte MongoDB nyligen. Det finns några saker jag önskar att jag visste innan jag började arbeta med det. När en person redan har erfarenhet inom ett visst område har de förutfattade meningar om vad databaser är och vad de gör. I hopp om att göra det lättare för andra att förstå presenterar jag en lista över vanliga misstag.
Skapa en MongoDB-server utan autentisering
Tyvärr installeras MongoDB utan autentisering som standard. För en arbetsstation som nås lokalt är denna praxis normal. Men eftersom MongoDB är ett fleranvändarsystem som gillar att använda stora mängder minne så blir det bättre om du lägger det på en server med så mycket RAM som möjligt även om du bara ska använda det för utveckling. Att installera på servern via standardporten kan vara problematiskt, särskilt om någon JavaScript-kod kan köras i begäran (till exempel, $where som en idé för ).
Det finns flera autentiseringsmetoder, men det enklaste är att ställa in ett användar-ID/lösenord. Använd den här idén medan du funderar på snygg autentisering baserat på . När det kommer till säkerhet bör MongoDB ständigt uppdateras, och loggar bör alltid kontrolleras för obehörig åtkomst. Till exempel gillar jag att välja en annan port som standardport.
Glöm inte att binda attackytan till MongoDB
innehåller bra tips för att minska risken för nätintrång och dataläckage. Det är lätt att borsta bort det och säga att en utvecklingsserver inte behöver en hög säkerhetsnivå. Det är dock inte så enkelt och det gäller alla MongoDB-servrar. I synnerhet om det inte finns någon tvingande anledning att använda , eller , måste du inaktivera användningen av godtycklig kod i JavaScript genom att skriva i konfigurationsfilen . Eftersom datafiler inte är krypterade i standard MongoDB är det vettigt att köra MongoDB med , som har full åtkomst till filer, med begränsad åtkomst endast till dem och möjligheten att använda operativsystemets egna filåtkomstkontroller.
Fel vid utveckling av kretsen
MongoDB använder inget schema. Men detta betyder inte att systemet inte behövs. Om du bara vill lagra dokument utan något konsekvent mönster kan det vara snabbt och enkelt att lagra dem, men att hämta dem senare kan vara svårt. .
Klassisk artikel " Det är värt att läsa, och funktioner som i tredjepartsverktyget Studio 3T är det värt att använda för regelbundna kontroller av kretsar.
Glöm inte sorteringsordningen
Att glömma sorteringsordningen kan orsaka mer frustration och slösa mer tid än någon annan felaktig konfiguration. Som standard använder MongoBD . Men det är osannolikt att det är användbart för någon. Skiftlägeskänsliga, accentkänsliga, binära sorter ansågs vara nyfikna anakronismer tillsammans med pärlor, kaftaner och lockiga mustascher redan på 80-talet av förra seklet. Nu är deras användning oförlåtlig. I verkliga livet är "motorcykel" detsamma som "motorcykel". Och "Storbritannien" och "Storbritannien" är samma plats. En liten bokstav är helt enkelt den stora motsvarigheten till en stor bokstav. Och låt mig inte börja med att sortera diakritiska tecken. När du skapar en databas i MongoDB, använd accentokänslig sortering och , som motsvarar språket och . Detta kommer att göra det mycket lättare att söka igenom strängdata.
Skapa samlingar med stora dokument
MongoDB är glad att vara värd för stora dokument upp till 16MB i samlingar, och Designad för stora dokument större än 16 MB. Men bara för att stora dokument kan placeras där är det ingen bra idé att lagra dem där. MongoDB fungerar bäst om du lagrar enskilda dokument som är några kilobyte stora, och behandlar dem mer som rader i en bred SQL-tabell. Stora dokument kommer att vara en källa till problem med .
Skapa dokument med stora arrayer
Dokument kan innehålla arrayer. Det är bäst om antalet element i arrayen är långt ifrån ett fyrsiffrigt tal. Om element ofta läggs till i en array kommer den att växa ur dokumentet som innehåller den och måste , vilket betyder att det kommer att vara nödvändigt . När du indexerar om ett dokument med en stor array kommer indexen ofta att skrivas över, eftersom det finns en , som lagrar sitt index. Denna omindexering sker även när ett dokument infogas eller raderas.
MongoDB har något som heter , vilket ger utrymme för dokument att växa för att minimera detta problem.
Du kanske tror att du klarar dig utan arrayindexering. Tyvärr kan bristen på index göra att du får andra problem. Eftersom dokument skannas från början till slut tar det längre tid att söka efter element i slutet av arrayen, och de flesta operationer som är kopplade till ett sådant dokument kommer att .
Glöm inte att ordningen på stegen i en aggregering spelar roll
I ett databassystem med en frågeoptimerare är frågorna du skriver förklaringar av vad du vill få, inte hur du får det. Denna mekanism fungerar i analogi med att beställa på en restaurang: vanligtvis beställer du helt enkelt en maträtt och ger inte detaljerade instruktioner till kocken.
I MongoDB instruerar du kocken. Du måste till exempel se till att data passerar igenom reduce så tidigt som möjligt i pipeline med hjälp av $match и $project, och sortering sker först efter reduce, och att sökningen sker i exakt den ordning du vill. Att ha en frågeoptimerare som eliminerar onödigt arbete, sekvenserar steg optimalt och väljer kopplingstyper kan skämma bort dig. Med MongoDB har du mer kontroll till bekostnad av bekvämlighet.
Verktyg som kommer att förenkla konstruktionen av aggregeringsfrågor i . Funktionen Aggregation Editor låter dig tillämpa pipeline-satser ett steg i taget och inspektera in- och utdata vid varje steg för att förenkla felsökningen.
Använda snabbinspelning
Ställ aldrig in MongoDB-skrivalternativ för att ha hög hastighet men låg tillförlitlighet. Detta läge "arkivera och glömma" verkar snabbt eftersom kommandot returneras innan skrivningen sker. Om systemet kraschar innan data skrivs till disk kommer den att gå förlorad och hamna i ett inkonsekvent tillstånd. Lyckligtvis har 64-bitars MongoDB loggning aktiverat.
MMAPv1- och WiredTiger-lagringsmotorerna använder loggning för att förhindra detta, även om WiredTiger kan återhämta sig till den sista konsekventa , om loggning är inaktiverad.
Journalföring säkerställer att databasen är i ett konsekvent tillstånd efter återställning och behåller all data tills den skrivs till loggen. Inspelningsfrekvensen konfigureras med parametern .
För att vara säker på posterna, se till att loggning är aktiverad i konfigurationsfilen ), och frekvensen av inspelningar motsvarar mängden information som du har råd att förlora.
Sortering utan index
Vid sökning och aggregering finns det ofta behov av att sortera data. Låt oss hoppas att detta görs i ett av de sista stadierna, efter filtrering av resultatet för att minska mängden data som sorteras. Och även i det här fallet, för sortering behöver du . Du kan använda ett enda eller sammansatt index.
Om det inte finns något lämpligt index kommer MongoDB att klara sig utan det. Det finns en minnesgräns på 32 MB på den totala storleken på alla dokument i , och om MongoDB når denna gräns kommer den antingen att ge ett fel eller returnera .
Sök utan indexstöd
Sökfrågor utför en funktion som liknar JOIN-operationen i SQL. För att fungera bäst behöver de indexet för värdet på nyckeln som används som främmande nyckel. Detta är inte självklart eftersom användningen inte återspeglas i explain(). Sådana index är utöver det inskrivna indexet explain(), som i sin tur används av rörledningsoperatörer $match и $sort, när de möts i början av pipelinen. Index kan nu täcka alla stadier .
Välja bort att använda flera uppdateringar
metod används för att ändra en del av ett befintligt dokument eller hela dokumentet, upp till en fullständig ersättning, beroende på vilken parameter du anger . Vad som inte är så uppenbart är att det inte kommer att behandla alla dokument i samlingen om du inte ställer in alternativet att uppdatera alla dokument som uppfyller kraven på begäran.
Glöm inte vikten av nycklarnas ordning i en hashtabell
I JSON består ett objekt av en oordnad samling av storlek noll eller fler namn/värdepar, där namn är en sträng och värde är en sträng, tal, boolean, null, objekt eller matris.
Tyvärr lägger BSON stor vikt vid ordning vid sökning. I MongoDB, ordningen på nycklar inom inbyggda objekt , d.v.s. { firstname: "Phil", surname: "factor" } - det här är inte samma sak som { { surname: "factor", firstname: "Phil" }. Det vill säga att du måste lagra ordningen på namn/värdepar i dina dokument om du vill vara säker på att hitta dem.
Förvirra inte "Null" и "odefinierad"
Värde "odefinierad" var aldrig giltig i JSON, enligt JSON (ECMA-404 avsnitt 5), även om det används i JavaScript. Dessutom är den för BSON föråldrad och konverteras till $null, vilket inte alltid är en bra lösning. .
Använd $limit() без $sort()
Ganska ofta när du utvecklar i MongoDB är det användbart att bara se ett exempel på resultatet som kommer att returneras från en fråga eller aggregering. För denna uppgift behöver du $limit(), men det bör aldrig finnas i den slutliga koden om du inte använder det tidigare $sort. Denna mekaniker är nödvändig eftersom du annars inte kan garantera ordningen på resultatet och du kommer inte att kunna se data på ett tillförlitligt sätt. Överst i resultatet får du olika poster beroende på sortering. För att fungera tillförlitligt måste frågor och aggregationer vara deterministiska, det vill säga ge samma resultat varje gång de exekveras. Kod som innehåller $limit(), men nej $sort, kommer inte att vara deterministisk och kan i efterhand orsaka fel som kommer att vara 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, till exempel en DBMS, eller att komma att använda den baserat på vissa förväntningar. Det är som att jämföra en apelsin med en gaffel. Databassystem tjänar specifika syften. Det är bäst att helt enkelt förstå och uppskatta dessa skillnader själv. Det skulle vara synd att pressa MongoDB-utvecklarna över en väg som tvingade dem ner på DBMS-vägen. Jag vill se nya och intressanta sätt att lösa gamla problem, som att säkerställa dataintegritet och skapa datasystem som är motståndskraftiga mot misslyckanden och skadliga attacker.
MongoDB:s införande av ACID-transaktionalitet i version 4.0 är ett bra exempel på att introducera viktiga förbättringar på ett innovativt sätt. Transaktioner med flera dokument och flera uttalanden är nu atomära. Det är också möjligt att justera tiden som krävs för att skaffa lås och avsluta transaktioner som har fastnat, samt ändra isoleringsnivån.
Läs mer:
Källa: will.com