Även om denna lagringsmotor har föråldrats så långt tillbaka som MongoDB version 4.0, finns det några viktiga funktioner i den. MMAPv1 är den ursprungliga lagringsmotorn i MongoDB och är baserad på mappade filer. Endast 64-bitars Intel-arkitekturen (x86_64) stöder denna lagringsmotor.
MMAPv1 ger utmärkt prestanda vid arbetsbelastningar med...
- Stora uppdateringar
- Hög volym avläsningar
- Insatser med hög volym
- Högt utnyttjande av systemminnet
MMAPv1-arkitektur
MMAPv1 är ett B-trädbaserat system som driver många av funktionerna som lagringsinteraktion och minneshantering till operativsystemet.
Det var standarddatabasen för MongoDB för versioner tidigare än 3.2 fram till introduktionen av WiredTiger-lagringsmotorn. Dess namn kommer från det faktum att den använder minnesmappade filer för att komma åt data. Det gör det genom att direkt ladda och ändra filinnehåll, som finns i ett virtuellt minne genom en mmap() syscall-metod.
Alla poster är sammanhängande placerade på disken och om ett dokument blir större än den tilldelade poststorleken, tilldelar MongoDB en ny post. För MMAPv1 är detta fördelaktigt för sekventiell dataåtkomst men samtidigt en begränsning eftersom det kommer med en tidskostnad eftersom alla dokumentindex måste uppdateras och detta kan leda till lagringsfragmentering.
Den grundläggande arkitekturen för MMAPv1-lagringsmotorn visas nedan.
Som nämnts ovan, om en dokumentstorlek överstiger den tilldelade poststorleken, kommer det att resultera i en omfördelning som inte är bra. För att undvika detta använder MMAPv1-motorn en Power of 2 Sized Allocation så att varje dokument lagras i en post som innehåller själva dokumentet (inklusive lite extra utrymme som kallas utfyllnad). Utfyllnaden används sedan för att möjliggöra eventuell tillväxt av dokument som kan bli resultatet av uppdateringar samtidigt som det minskar chanserna för omfördelningar. Annars, om omfördelningar inträffar kan du få lagringsfragmentering. Vaddering byter ut ytterligare utrymme för att förbättra effektiviteten och därmed minska fragmenteringen. För arbetsbelastningar med stora volymer av infogningar, uppdateringar eller borttagningar bör kraften hos 2-allokering vara att föredra, medan exakt passformallokering är idealisk för samlingar som inte involverar några uppdateringar eller raderingsarbetsbelastningar.
Kraft av 2-storlekstilldelning
För smidig dokumenttillväxt används denna strategi i MMAPv1-lagringsmotorn. Varje post har en storlek i byte som är en potens av 2, dvs (32, 64, 128, 256, 512...2 MB). 2MB är standardgränsen för varje dokument som överträffar detta, dess minne avrundas till närmaste multipel av 2MB. Till exempel, om ett dokument är 200 MB, kommer denna storlek att avrundas till 256 MB och 56 MB bytesutrymme kommer att vara tillgängligt för eventuell ytterligare tillväxt. Detta gör att dokumenten kan växa istället för att utlösa en omfördelning som systemet måste göra när dokumenten når sina gränser för tillgängligt utrymme.
Merits of Power 2-storlekstilldelningar
- Återanvändning av frigjorda poster för att minska fragmentering: Med detta koncept kvantifieras poster i minnet för att ha en fast storlek som är tillräckligt stor för att rymma nya dokument som skulle passa in i tilldelat utrymme som skapats av en tidigare radering eller flytt av dokument.
- Minskar dokumentflyttningar: Som nämnts tidigare, som standard kommer MongoDB-infogningar och uppdateringar som gör dokumentstorleken större än den inställda poststorleken att resultera i uppdatering av indexen också. Detta betyder helt enkelt att dokumenten har flyttats. Men när det finns tillräckligt med utrymme för tillväxt i ett dokument, kommer dokumentet inte att flyttas, vilket innebär mindre uppdateringar av index.
Minnesanvändning
Allt ledigt minne på maskinen i MMAPv1-lagringsmotorn används som cache. Rätt dimensionerade arbetsset och optimal prestanda uppnås genom ett arbetsset som passar in i minnet. Dessutom, för var 60:e sekund, rensar MMAPv1 ändringar till data till disk och sparar på så sätt i cacheminnet. Detta värde kan ändras så att spolningen kan göras ofta. Eftersom allt ledigt minne används som cache, bli inte chockad över att systemresursövervakningsverktyg kommer att indikera att MongoDB använder mycket minne eftersom denna användning är dynamisk.
Fördelarna med MMAPv1 Storage Engine
- Minskad fragmentering på disken vid användning av förallokeringsstrategin.
- Mycket effektiv läsning när arbetsuppsättningen har konfigurerats för att passa in i minnet.
- Uppdateringar på plats, dvs. individuella fältuppdateringar kan resultera i att mer data lagras och därmed förbättras vid uppdatering av stora dokument med minimalt med samtidiga skrivningar.
- Med ett lågt antal samtidiga skrivare kan skrivprestandan förbättras genom konceptet att data spolning till disk ofta.
- Låsning på samlingsnivå underlättar skrivoperationer. Låsschema är en av de viktigaste faktorerna för databasprestanda. I det här fallet kan endast en klient komma åt databasen åt gången. Detta skapar ett scenario så att operationer flyter snabbare än när de presenteras på seriellt sätt av lagringsmotorn.
Begränsningar för MMAPv1 Storage Engine
- Högt utrymmesutnyttjande när du gör iterationer. MMAPv1 saknar en komprimeringsstrategi för filsystemet och gör därför en övertilldelning av postutrymme.
- Begränsning av samlingsåtkomst för många klienter när de gör en skrivoperation. MMAPv1 använder en samlingsnivålåsningsstrategi, vilket innebär att 2 eller fler klienter inte kan komma åt samma samling samtidigt, varför en skrivblockering blockerar alla läsningar till denna samling. Detta leder till grov samtidighet som gör det omöjligt att skala MMAPv1-motorn.
- Systemkrasch kan potentiellt resultera i dataförlust om journalföringsalternativet inte är aktiverat. Men även om det är det, är fönstret för litet men kan åtminstone skydda dig från en stor dataförlustscenario.
- Ineffektivt lagringsutnyttjande. När man använder förallokeringsstrategin kommer vissa dokument att ta upp mer utrymme på disken än själva data.
- Om arbetsuppsättningens storlek överstiger det tilldelade minnet, sjunker prestandan i stor utsträckning. Dessutom kan dokumentera betydande tillväxt efter initial lagring utlösa ytterligare I/O och därmed orsaka prestandaproblem.
Jämföra MMAPv1- och WiredTiger-lagringsmotorer
| Nyckelfunktion | MMAPv1 | WiredTiger |
|---|---|---|
| CPU-prestanda | Att lägga till fler CPU-kärnor ökar tyvärr inte prestandan | Prestandan förbättras med flerkärniga system |
| Kryptering | På grund av att minneskartade filer används stöder den ingen kryptering | Kryptering för både data under överföring och vila är tillgänglig i både MongoDB Enterprise och Beta-installation |
| Skalbarhet | Samtidiga skrivningar som är resultatet av låsning på samlingsnivå gör det omöjligt att skala ut. | Höga chanser att skala ut eftersom den minsta låsningsnivån är själva dokumentet. |
| Inställning | Mycket små chanser att trimma denna lagringsmotor | Många justeringar kan göras kring variabler som cachestorlek, kontrollpunktsintervall och läs/skrivbiljetter |
| Datakomprimering | Ingen datakomprimering, därför kan mer utrymme användas | Snappy och zlib-komprimeringsmetoder tillgängliga, så dokument kan uppta mindre utrymme än i MMAPv1 |
| Atomtransaktioner | Gäller endast för ett enda dokument | Från och med version 4.0 stöds atomär transaktion på multidokument. |
| Minne | Allt ledigt minne på maskinen används som dess cache | Filsystemcache och intern cache används |
| Uppdateringar | Stöder uppdateringar på plats och utmärker sig därför vid arbetsbelastningar med tunga volyminlägg, läsningar och uppdateringar på plats | Stöder inte uppdateringar på plats. Hela dokumentet måste skrivas om. |
Slutsats
När man kommer till val av lagringsmotor för en databas vet många inte vilken de ska välja. Valet beror normalt på den arbetsbelastning som den kommer att utsättas för. På en allmän mätare skulle MMAPv1 göra ett dåligt val och det är därför MongoDB gjorde många framsteg till WiredTiger-alternativet. Det kan dock fortfarande överträffa vissa andra lagringsmotorer beroende på användningsfallet, till exempel där du bara behöver utföra läsbelastningar eller behöver lagra många separata samlingar med stora dokument där 1 eller 2 fält uppdateras ofta.