Hoewel deze opslagengine al in MongoDB-versie 4.0 is verouderd, zitten er enkele belangrijke functies in. MMAPv1 is de originele opslagengine in MongoDB en is gebaseerd op toegewezen bestanden. Alleen de 64-bits Intel-architectuur (x86_64) ondersteunt deze opslagengine.
MMAPv1 zorgt voor uitstekende prestaties bij workloads met...
- Grote updates
- Hoog leesvolume
- Inzetstukken met hoog volume
- Hoog gebruik van systeemgeheugen
MMAPv1-architectuur
MMAPv1 is een op B-tree gebaseerd systeem dat veel van de functies, zoals opslaginteractie en geheugenbeheer, naar het besturingssysteem stuurt.
Het was de standaarddatabase voor MongoDB voor versies eerder dan 3.2 tot de introductie van de WiredTiger-opslagengine. De naam komt van het feit dat het geheugen toegewezen bestanden gebruikt om toegang te krijgen tot gegevens. Het doet dit door de bestandsinhoud, die zich in een virtueel geheugen bevindt, rechtstreeks te laden en te wijzigen via een mmap() syscall-methodologie.
Alle records bevinden zich aaneengesloten op de schijf en in het geval dat een document groter wordt dan de toegewezen recordgrootte, wijst MongoDB een nieuw record toe. Voor MMAPv1 is dit voordelig voor sequentiële gegevenstoegang, maar tegelijkertijd een beperking omdat het gepaard gaat met tijdskosten, aangezien alle documentindexen moeten worden bijgewerkt en dit kan leiden tot fragmentatie van de opslag.
De basisarchitectuur van de MMAPv1-opslagengine wordt hieronder weergegeven.
Zoals hierboven vermeld, als een documentgrootte de toegewezen recordgrootte overschrijdt, zal dit leiden tot een hertoewijzing, wat geen goede zaak is. Om dit te voorkomen gebruikt de MMAPv1-engine een Power of 2 Sized Allocation, zodat elk document wordt opgeslagen in een record dat het document zelf bevat (inclusief wat extra ruimte die opvulling wordt genoemd). De opvulling wordt vervolgens gebruikt om eventuele documentgroei mogelijk te maken die het gevolg kan zijn van updates, terwijl de kans op hertoewijzingen wordt verkleind. Als er zich hertoewijzingen voordoen, kan het zijn dat u opslagfragmentatie krijgt. Padding ruilt extra ruimte in om de efficiëntie te verbeteren en zo fragmentatie te verminderen. Voor werkbelastingen met grote hoeveelheden invoegingen, updates of verwijderingen, verdient de kracht van 2-toewijzing de meeste voorkeur, terwijl exacte toewijzing ideaal is voor verzamelingen die geen werkbelasting voor bijwerken of verwijderen met zich meebrengen.
Kracht van toewijzing van twee formaten
Voor een soepele documentgroei wordt deze strategie gebruikt in de MMAPv1-opslagengine. Elk record heeft een grootte in bytes die een macht van 2 is, d.w.z. (32, 64, 128, 256, 512...2MB). 2 MB is de standaard grotere limiet voor elk document dat dit overschrijdt, het geheugen wordt afgerond op het dichtstbijzijnde veelvoud van 2 MB. Als een document bijvoorbeeld 200 MB is, wordt deze grootte afgerond op 256 MB en is er 56 MB inruilruimte beschikbaar voor eventuele extra groei. Hierdoor kunnen documenten groeien in plaats van dat het systeem opnieuw moet worden toegewezen wanneer documenten hun grenzen van de beschikbare ruimte.
Verdiensten van macht 2-formaat toewijzingen
- Hergebruik van vrijgekomen records om fragmentatie te verminderen: Met dit concept worden records in het geheugen gekwantificeerd om een vaste grootte te hebben die groot genoeg is voor nieuwe documenten die zouden passen in de toegewezen ruimte die is gecreëerd door een eerdere verwijdering of verplaatsing van documenten.
- Vermindert documentverplaatsingen: Zoals eerder vermeld, zullen MongoDB-inserts en updates die de documentgrootte groter maken dan de ingestelde recordgrootte standaard ook resulteren in het bijwerken van de indexen. Dit betekent simpelweg dat de documenten zijn verplaatst. Als er echter voldoende ruimte is voor groei binnen een document, wordt het document niet verplaatst, dus minder updates voor indexen.
Geheugengebruik
Al het vrije geheugen op de machine in de MMAPv1-opslagengine wordt gebruikt als cache. Werksets van de juiste grootte en optimale prestaties worden bereikt door een werkset die in het geheugen past. Bovendien spoelt de MMAPv1 elke 60 seconden wijzigingen in de gegevens naar de schijf en bespaart zo op het cachegeheugen. Deze waarde kan zodanig worden gewijzigd dat het spoelen frequent kan worden uitgevoerd. Omdat al het vrije geheugen als cache wordt gebruikt, hoeft u zich geen zorgen te maken dat hulpprogramma's voor het bewaken van systeembronnen aangeven dat MongoDB veel geheugen gebruikt, aangezien dit gebruik dynamisch is.
Verdiensten van MMAPv1-opslagengine
- Verminderde fragmentatie op schijf bij gebruik van de pre-allocatiestrategie.
- Zeer efficiënte leest wanneer de werkset is geconfigureerd om in het geheugen te passen.
- In-place updates, d.w.z. individuele veldupdates kunnen ertoe leiden dat meer gegevens worden opgeslagen, waardoor de update van grote documenten wordt verbeterd met een minimum aan gelijktijdige schrijvers.
- Met een laag aantal gelijktijdige schrijvers kunnen de schrijfprestaties worden verbeterd door het concept regelmatig naar de schijf te spoelen.
- Vergrendeling op collectieniveau vereenvoudigt schrijfbewerkingen. Het vergrendelingsschema is een van de belangrijkste factoren voor de prestaties van de database. In dit geval heeft slechts 1 client tegelijk toegang tot de database. Dit creëert een scenario zodat bewerkingen sneller verlopen dan wanneer ze op een seriële manier worden gepresenteerd door de opslagengine.
Beperkingen van de MMAPv1-opslagengine
- Hoog ruimtegebruik bij iteraties. MMAPv1 mist een compressiestrategie voor het bestandssysteem en daarom wordt er teveel recordruimte toegewezen.
- Toegangsbeperking voor verzamelingen voor veel clients bij het uitvoeren van een schrijfbewerking. MMAPv1 gebruikt een vergrendelingsstrategie op collectieniveau, wat betekent dat 2 of meer clients niet tegelijkertijd toegang hebben tot dezelfde collectie, vandaar dat een schrijfblokkering alle leesbewerkingen naar deze collectie blokkeert. Dit leidt tot grove gelijktijdigheid die het onmogelijk maakt om de MMAPv1-engine te schalen.
- Systeemcrash kan mogelijk leiden tot gegevensverlies als de journaaloptie niet is ingeschakeld. Maar zelfs als dat zo is, is het venster te klein, maar het kan u in ieder geval behoeden voor een groot gegevensverliesscenario.
- Inefficiënt gebruik van opslag. Bij gebruik van de pre-allocatiestrategie zullen sommige documenten meer schijfruimte in beslag nemen dan de gegevens zelf.
- Als de werkset groter is dan het toegewezen geheugen, nemen de prestaties sterk af. Bovendien kan een aanzienlijke groei van documenten na de eerste opslag leiden tot extra I/O en dus prestatieproblemen veroorzaken.
MMAPv1 en WiredTiger Storage Engines vergelijken
| Belangrijkste functie | MMAPv1 | WiredTiger |
|---|---|---|
| CPU-prestaties | Het toevoegen van meer CPU-cores verbetert de prestaties helaas niet | Prestaties verbeteren met multicore-systemen |
| Encryptie | Vanwege het gebruik van in het geheugen toegewezen bestanden, ondersteunt het geen encryptie | Encryptie voor zowel data in transit als rest is beschikbaar in zowel MongoDB enterprise als Beta-installatie |
| Schaalbaarheid | Gelijktijdige schrijfacties die het gevolg zijn van vergrendeling op collectieniveau maken het onmogelijk om uit te schalen. | Hoge kansen op uitschalen omdat het document zelf het minste vergrendelingsniveau is. |
| Afstemming | Zeer kleine kans om deze opslagengine af te stemmen | Er kan veel worden afgestemd op variabelen zoals cachegrootte, checkpoint-intervallen en lees-/schrijftickets |
| Gegevenscompressie | Geen gegevenscompressie, daarom kan er meer ruimte worden gebruikt | Snappy- en zlib-compressiemethoden beschikbaar, daarom kunnen documenten minder ruimte innemen dan in MMAPv1 |
| Atoomtransacties | Alleen van toepassing op één document | Vanaf versie 4.0 wordt atomaire transactie op meerdere documenten ondersteund. |
| Geheugen | Al het vrije geheugen op de machine wordt gebruikt als cache | Bestandssysteemcache en interne cache worden gebruikt |
| Updates | Ondersteunt in-place updates en blinkt uit in workloads met zware volume-inserts, reads en in-place updates | Ondersteunt geen interne updates. Het hele document moet worden herschreven. |
Conclusie
Bij het kiezen van een opslagengine voor een database, weten veel mensen niet welke ze moeten kiezen. De keuze hangt normaal gesproken af van de werklast waaraan het zal worden onderworpen. Over het algemeen zou de MMAPv1 een slechte keuze zijn en daarom heeft MongoDB veel vooruitgang geboekt met de WiredTiger-optie. Het kan echter nog steeds sommige andere opslagengines overtreffen, afhankelijk van het gebruik, bijvoorbeeld waar u alleen leeswerkbelastingen hoeft uit te voeren of veel afzonderlijke verzamelingen met grote documenten moet opslaan, waarbij 1 of 2 velden regelmatig worden bijgewerkt.