Selvom denne lagermotor er blevet forældet så langt tilbage som MongoDB version 4.0, er der nogle vigtige funktioner i den. MMAPv1 er den originale lagermotor i MongoDB og er baseret på kortlagte filer. Kun 64-bit Intel-arkitekturen (x86_64) understøtter denne lagermotor.
MMAPv1 giver fremragende ydeevne ved arbejdsbelastninger med...
- Store opdateringer
- Læsninger med høj lydstyrke
- Indsæt med høj lydstyrke
- Høj udnyttelse af systemhukommelsen
MMAPv1-arkitektur
MMAPv1 er et B-træbaseret system, som driver mange af funktionerne, såsom lagerinteraktion og hukommelsesstyring, til operativsystemet.
Det var standarddatabasen for MongoDB for versioner tidligere end 3.2 indtil introduktionen af WiredTiger-lagringsmotoren. Dens navn kommer fra det faktum, at den bruger hukommelseskortede filer til at få adgang til data. Det gør det ved direkte at indlæse og ændre filindhold, som er i en virtuel hukommelse gennem en mmap() syscall-metodologi.
Alle poster er sammenhængende placeret på disken, og i tilfælde af at et dokument bliver større end den tildelte poststørrelse, tildeler MongoDB en ny post. For MMAPv1 er dette fordelagtigt for sekventiel dataadgang, men samtidig en begrænsning, da det kommer med en tidsomkostning, da alle dokumentindekser skal opdateres, og dette kan resultere i lagerfragmentering.
Den grundlæggende arkitektur for MMAPv1-lagermotoren er vist nedenfor.
Som nævnt ovenfor, hvis en dokumentstørrelse overstiger den tildelte poststørrelse, vil det resultere i en omallokering, som ikke er en god ting. For at undgå dette bruger MMAPv1-motoren en Power of 2 Sized Allocation, så hvert dokument gemmes i en post, der indeholder selve dokumentet (inklusive noget ekstra plads kendt som polstring). Polstringen bruges derefter til at tillade enhver dokumentvækst, der kan være et resultat af opdateringer, mens det reducerer chancerne for omfordelinger. Ellers, hvis der sker omfordelinger, kan du ende med at have lagerfragmentering. Polstring bytter ekstra plads for at forbedre effektiviteten og dermed reducere fragmentering. For arbejdsbelastninger med store mængder indsættelser, opdateringer eller sletninger, bør styrken af 2-allokering være mest foretrukket, mens tildeling af nøjagtig tilpasning er ideel til samlinger, der ikke involverer nogen opdatering eller sletning af arbejdsbelastninger.
Tildeling af 2 størrelser
For jævn dokumentvækst anvendes denne strategi i MMAPv1-lagringsmotoren. Hver post har en størrelse i bytes, som er en potens på 2, dvs. (32, 64, 128, 256, 512...2 MB). 2MB er standardgrænsen for ethvert dokument, der overgår dette, og dets hukommelse afrundes til nærmeste multiplum af 2MB. For eksempel, hvis et dokument er 200 MB, vil denne størrelse blive afrundet til 256 MB, og 56 MB handel med plads vil være tilgængelig for enhver yderligere vækst. Dette gør det muligt for dokumenter at vokse i stedet for at udløse en omfordeling, som systemet skal foretage, når dokumenter når deres grænser for tilgængelig plads.
Merits of Power 2-størrelsestildelinger
- Genbrug af frigivne poster for at reducere fragmentering: Med dette koncept kvantificeres registreringer til at have en fast størrelse, som er stor nok til at rumme nye dokumenter, der ville passe ind i den tildelte plads, der er oprettet ved en tidligere dokumentsletning eller flytning.
- Reducerer dokumentflytninger: Som tidligere nævnt vil MongoDB-indsættelser og opdateringer som standard, der gør dokumentstørrelsen større end den indstillede poststørrelse, også resultere i opdatering af indekserne. Dette betyder blot, at dokumenterne er blevet flyttet. Men når der er plads nok til vækst i et dokument, vil dokumentet ikke blive flyttet og derfor færre opdateringer til indekser.
Hukommelsesbrug
Al ledig hukommelse på maskinen i MMAPv1-lagermotoren bruges som cache. Korrekt størrelse arbejdssæt og optimal ydeevne opnås gennem et arbejdssæt, der passer ind i hukommelsen. Desuden tømmer MMAPv1 for hvert 60. sekund ændringer til data til disk og sparer på cachehukommelsen. Denne værdi kan ændres, således at skylningen kan udføres ofte. Fordi al ledig hukommelse bruges som cache, skal du ikke blive chokeret over, at systemressourceovervågningsværktøjer vil indikere, at MongoDB bruger meget hukommelse, da denne brug er dynamisk.
Fordele ved MMAPv1 Storage Engine
- Reduceret fragmentering på disken ved brug af præ-allokeringsstrategien.
- Meget effektiv læsning, når arbejdssættet er blevet konfigureret til at passe ind i hukommelsen.
- Opdateringer på stedet, dvs. individuelle feltopdateringer, kan resultere i, at flere data gemmes og dermed forbedres ved opdatering af store dokumenter med minimale samtidige skrivninger.
- Med et lavt antal samtidige skrivere kan skriveydeevnen forbedres gennem konceptet med at flushe til disk ofte.
- Låsning på samlingsniveau letter skriveoperationer. Låseskema er en af de vigtigste faktorer i databasens ydeevne. I dette tilfælde kan kun 1 klient få adgang til databasen ad gangen. Dette skaber et scenarie, så operationer flyder hurtigere, end når de præsenteres på seriel måde af lagermotoren.
Begrænsninger af MMAPv1 Storage Engine
- Høj pladsudnyttelse ved gentagelser. MMAPv1 mangler en komprimeringsstrategi for filsystemet, og derfor over-allokerer postpladsen.
- Samlingsadgangsbegrænsning for mange klienter, når de udfører en skrivehandling. MMAPv1 bruger samlingsniveau-låsningsstrategi, hvilket betyder, at 2 eller flere klienter ikke kan få adgang til den samme samling på samme tid, og derfor blokerer en skrivning for alle læsninger til denne samling. Dette fører til grov samtidighed, der gør det umuligt at skalere MMAPv1-motoren.
- Systemnedbrud kan potentielt resultere i tab af data, hvis journaliseringsindstillingen ikke er aktiveret. Men selvom det er det, er vinduet for lille, men det kan i det mindste sikre dig mod et stort datatabsscenarie.
- Ineffektiv lagerudnyttelse. Når du bruger præ-allokeringsstrategien, vil nogle dokumenter optage mere plads på disken, end selve dataene ville.
- Hvis arbejdssættets størrelse overstiger den tildelte hukommelse, falder ydeevnen i vid udstrækning. Desuden kan dokumentere betydelig vækst efter indledende lagring udløse yderligere I/O og dermed forårsage ydeevneproblemer.
Sammenligning af MMAPv1 og WiredTiger Storage Engines
| Nøglefunktion | MMAPv1 | WiredTiger |
|---|---|---|
| CPU-ydeevne | Tilføjelse af flere CPU-kerner øger desværre ikke ydeevnen | Ydeevnen forbedres med multicore-systemer |
| Kryptering | På grund af hukommelseskortede filer, der bruges, understøtter den ikke nogen kryptering | Kryptering for både data i transit og hvile er tilgængelig i både MongoDB enterprise- og beta-installation |
| Skalerbarhed | Samtidige skrivninger, der er resultatet af låsning på samlingsniveau, gør det umuligt at skalere ud. | Store chancer for udskalering, da det mindste låseniveau er selve dokumentet. |
| Tuning | Meget små chancer for at tune denne lagermotor | Der kan laves masser af tuning omkring variabler såsom cachestørrelse, checkpoint-intervaller og læse/skrive billetter |
| Datakomprimering | Ingen datakomprimering, derfor kan der bruges mere plads | Snappy og zlib komprimeringsmetoder tilgængelige, derfor kan dokumenter optage mindre plads end i MMAPv1 |
| Atomtransaktioner | Gælder kun for et enkelt dokument | Fra version 4.0 understøttes atomtransaktion på multidokumenter. |
| Hukommelse | Al ledig hukommelse på maskinen bruges som dens cache | Filsystemcache og intern cache bruges |
| Opdateringer | Understøtter opdateringer på stedet og udmærker sig derfor ved arbejdsbelastninger med tunge volumenindsættelser, læsninger og opdateringer på stedet | Understøtter ikke opdateringer på stedet. Hele dokumentet skal omskrives. |
Konklusion
Når de kommer til valg af lagermotor til en database, ved mange mennesker ikke, hvilken de skal vælge. Valget afhænger normalt af den arbejdsbyrde, det vil blive udsat for. På en generel måler ville MMAPv1 gøre et dårligt valg, og det er derfor, MongoDB gjorde mange fremskridt til WiredTiger-indstillingen. Det kan dog stadig overgå nogle andre lagringsmotorer afhængigt af brugssituationen, for eksempel hvor du kun skal udføre læse-arbejdsbelastninger eller skal gemme mange separate samlinger med store dokumenter, hvorved 1 eller 2 felter ofte opdateres.