I když byl tento úložný modul zastaralý již od verze MongoDB 4.0, jsou v něm některé důležité funkce. MMAPv1 je původní modul úložiště v MongoDB a je založen na mapovaných souborech. Toto úložiště podporuje pouze 64bitová architektura Intel (x86_64).
MMAPv1 poskytuje vynikající výkon při pracovní zátěži s...
- Velké aktualizace
- Vysoká hlasitost čtení
- Vysokoobjemové vložky
- Vysoké využití systémové paměti
Architektura MMAPv1
MMAPv1 je systém založený na B-stromu, který pohání mnoho funkcí operačního systému, jako je interakce s úložištěm a správa paměti.
Byla to výchozí databáze pro MongoDB pro verze starší než 3.2 až do zavedení úložiště WiredTiger. Jeho název pochází ze skutečnosti, že pro přístup k datům používá soubory mapované v paměti. Činí tak přímým načtením a úpravou obsahu souborů, které jsou ve virtuální paměti pomocí metodologie mmap() syscall.
Všechny záznamy jsou na disku umístěny souvisle a v případě, že se dokument zvětší, než je přidělená velikost záznamu, MongoDB přidělí nový záznam. Pro MMAPv1 je to výhodné pro sekvenční přístup k datům, ale zároveň je to omezení, protože to přináší časové náklady, protože je třeba aktualizovat všechny indexy dokumentů, což může vést k fragmentaci úložiště.
Základní architektura úložiště MMAPv1 je uvedena níže.
Jak bylo uvedeno výše, pokud velikost dokumentu překročí přidělenou velikost záznamu, dojde k přerozdělení, což není dobrá věc. Aby se tomu zabránilo, MMAPv1 engine využívá Power of 2 Sized Allocation, takže každý dokument je uložen v záznamu, který obsahuje samotný dokument (včetně určitého prostoru navíc známého jako padding). Výplň se pak používá k umožnění růstu jakéhokoli dokumentu, který může být důsledkem aktualizací, a zároveň snižuje šance na přerozdělení. V opačném případě, pokud dojde k přerozdělení, můžete skončit s fragmentací úložiště. Vycpávka poskytuje další prostor pro zlepšení efektivity, čímž se snižuje fragmentace. Pro úlohy s velkým objemem vložení, aktualizací nebo odstranění by měla být nejvíce preferována alokace síly 2, zatímco alokace přesné přizpůsobení je ideální pro kolekce, které nezahrnují žádnou aktualizaci nebo odstranění úloh.
Síla alokace 2 velikosti
Pro hladký růst dokumentů se tato strategie používá v úložném jádru MMAPv1. Každý záznam má velikost v bajtech, což je mocnina 2, tj. (32, 64, 128, 256, 512...2 MB). 2 MB je výchozí větší limit pro jakýkoli dokument, který tento limit překročí, jeho paměť je zaokrouhlena na nejbližší násobek 2 MB. Pokud má dokument například 200 MB, bude tato velikost zaokrouhlena na 256 MB a pro další růst bude k dispozici 56 MB prostoru. To umožňuje dokumentům růst namísto spouštění přerozdělení, které bude systém muset provést, když dokumenty dosáhnou svého limity dostupného prostoru.
Merites of Power 2 Size Allocations
- Opětovné použití uvolněných záznamů ke snížení fragmentace: Díky tomuto konceptu jsou záznamy kvantizovány tak, aby měly pevnou velikost, která je dostatečně velká na to, aby se do něj vešly nové dokumenty, které by se vešly do přiděleného prostoru vytvořeného dřívějším odstraněním nebo přemístěním dokumentu.
- Snižuje počet přesunů dokumentů: Jak již bylo zmíněno, ve výchozím nastavení MongoDB vloží a aktualizace, které zvětší velikost dokumentu nad nastavenou velikost záznamu, povedou k aktualizaci indexů. To jednoduše znamená, že dokumenty byly přesunuty. Pokud je však v dokumentu dostatek místa pro růst, dokument se nepřesune, a proto bude indexů méně aktualizováno.
Využití paměti
Veškerá volná paměť na počítači v úložném jádru MMAPv1 se používá jako mezipaměť. Správně dimenzované pracovní sady a optimální výkon je dosažen prostřednictvím pracovní sady, která se vejde do paměti. Kromě toho každých 60 sekund MMAPv1 vyprázdní změny dat na disk, čímž šetří vyrovnávací paměť. Tuto hodnotu lze změnit tak, aby proplachování bylo možné provádět často. Protože se veškerá volná paměť používá jako mezipaměť, nebuďte šokováni tím, že nástroje pro monitorování systémových prostředků budou indikovat, že MongoDB využívá hodně paměti, protože toto využití je dynamické.
Výhody MMAPv1 Storage Engine
- Snížená fragmentace na disku při použití strategie předběžného přidělení.
- Velmi efektivní čtení, když byla pracovní sada nakonfigurována tak, aby se vešla do paměti.
- Aktualizace na místě, tj. aktualizace jednotlivých polí, mohou mít za následek uložení většího množství dat, čímž se zlepší aktualizace velkých dokumentů s minimálním počtem souběžných zapisovačů.
- Vzhledem k nízkému počtu souběžných zapisovačů lze výkon zápisu zlepšit díky koncepci častého vyplachování dat na disk.
- Zamykání na úrovni kolekce usnadňuje operace zápisu. Schéma zamykání je jedním z nejdůležitějších faktorů výkonu databáze. V tomto případě může k databázi přistupovat současně pouze 1 klient. To vytváří scénář, ve kterém operace plynou rychleji, než když jsou sériovým způsobem prezentovány úložným modulem.
Omezení MMAPv1 Storage Engine
- Vysoké využití prostoru při provádění iterací. MMAPv1 postrádá strategii komprese pro systém souborů, a proto dochází k nadměrnému přidělování prostoru pro záznamy.
- Omezení přístupu ke sbírce pro mnoho klientů při provádění operace zápisu. MMAPv1 používá strategii zamykání na úrovni kolekce, což znamená, že 2 nebo více klientů nemůže přistupovat ke stejné kolekci současně, a proto zápis blokuje všechna čtení této kolekce. To vede k hrubé souběžnosti, která znemožňuje škálování motoru MMAPv1.
- Zhroucení systému může potenciálně vést ke ztrátě dat, pokud není povolena možnost žurnálování. I kdyby však bylo, okno je příliš malé, ale alespoň vás může ochránit před scénářem velké ztráty dat.
- Neefektivní využití úložiště. Při použití strategie předběžného přidělení budou některé dokumenty zabírat více místa na disku než samotná data.
- Pokud velikost pracovní sady překročí přidělenou paměť, výkon se do značné míry sníží. Kromě toho může významný nárůst dokumentů po počátečním úložišti spustit další I/O a způsobit tak problém s výkonem.
Porovnání MMAPv1 a WiredTiger Storage Engine
| Klíčová funkce | MMAPv1 | WiredTiger |
|---|---|---|
| Výkon CPU | Přidání dalších jader CPU bohužel nezvýší výkon | S vícejádrovými systémy se zlepšuje výkon |
| Šifrování | Vzhledem k tomu, že se používají soubory mapované v paměti, nepodporuje žádné šifrování | Šifrování pro data v přenosu i pro ostatní je k dispozici v MongoDB enterprise i beta instalaci |
| Škálovatelnost | Souběžné zápisy, které jsou výsledkem zamykání na úrovni kolekce, znemožňují škálování. | Vysoká šance na zmenšení, protože nejmenší úrovní zamykání je samotný dokument. |
| Ladění | Velmi malá šance na vyladění tohoto úložiště | Je možné provést spoustu úprav proměnných, jako je velikost mezipaměti, intervaly kontrolních bodů a lístky pro čtení/zápis |
| Komprese dat | Žádná komprese dat, proto lze použít více místa | K dispozici jsou metody komprese Snappy a zlib, takže dokumenty mohou zabírat méně místa než v MMAPv1 |
| Atomové transakce | Platí pouze pro jeden dokument | Od verze 4.0 jsou podporovány atomické transakce na více dokumentech. |
| Paměť | Veškerá volná paměť v počítači se používá jako jeho mezipaměť | Využívá se mezipaměť systému souborů a interní mezipaměť |
| Aktualizace | Podporuje aktualizace na místě, a proto vyniká při pracovní zátěži s velkými objemovými vložkami, čteními a aktualizacemi na místě | Nepodporuje aktualizace na místě. Celý dokument je třeba přepsat. |
Závěr
Při výběru úložiště pro databázi mnoho lidí neví, který si vybrat. Volba obvykle závisí na pracovní zátěži, které bude vystavena. Na obecném rozchodu by MMAPv1 udělal špatnou volbu, a proto MongoDB udělal mnoho vylepšení možnosti WiredTiger. Stále však může překonávat některé jiné úložné stroje v závislosti na případu použití, například když potřebujete provádět pouze úlohy čtení nebo potřebujete uložit mnoho samostatných kolekcí s velkými dokumenty, přičemž 1 nebo 2 pole jsou často aktualizována.