Sebbene questo motore di archiviazione sia stato deprecato fin dalla versione 4.0 di MongoDB, contiene alcune funzionalità importanti. MMAPv1 è il motore di archiviazione originale in MongoDB ed è basato su file mappati. Solo l'architettura Intel a 64 bit (x86_64) supporta questo motore di archiviazione.
MMAPv1 garantisce prestazioni eccellenti ai carichi di lavoro con...
- Grandi aggiornamenti
- Letture ad alto volume
- Inserti ad alto volume
- Utilizzo elevato della memoria di sistema
Architettura MMAPv1
MMAPv1 è un sistema basato su B-tree che alimenta molte delle funzioni come l'interazione con lo storage e la gestione della memoria al sistema operativo.
Era il database predefinito per MongoDB per le versioni precedenti alla 3.2 fino all'introduzione del motore di archiviazione WiredTiger. Il suo nome deriva dal fatto che utilizza file mappati in memoria per accedere ai dati. Lo fa caricando e modificando direttamente i contenuti dei file, che si trovano in una memoria virtuale attraverso una metodologia syscall mmap().
Tutti i record sono posizionati in modo contiguo sul disco e nel caso in cui un documento diventi più grande della dimensione del record allocata, MongoDB alloca un nuovo record. Per MMAPv1 questo è vantaggioso per l'accesso sequenziale ai dati, ma allo stesso tempo rappresenta una limitazione in quanto comporta un costo di tempo poiché tutti gli indici dei documenti devono essere aggiornati e ciò potrebbe comportare la frammentazione della memoria.
L'architettura di base del motore di archiviazione MMAPv1 è mostrata di seguito.
Come accennato in precedenza, se una dimensione del documento supera la dimensione del record allocata, risulterà in una riallocazione che non è una buona cosa. Per evitare ciò, il motore MMAPv1 utilizza un'allocazione di dimensioni 2 in modo che ogni documento sia archiviato in un record che contiene il documento stesso (incluso uno spazio aggiuntivo noto come riempimento). Il riempimento viene quindi utilizzato per consentire la crescita del documento che potrebbe derivare dagli aggiornamenti, riducendo al contempo le possibilità di riallocazione. Altrimenti, se si verificano riallocazioni, potresti finire per avere una frammentazione dello spazio di archiviazione. Il riempimento scambia spazio aggiuntivo per migliorare l'efficienza, riducendo così la frammentazione. Per carichi di lavoro con volumi elevati di inserimenti, aggiornamenti o eliminazioni, l'allocazione di potenza 2 dovrebbe essere preferita, mentre l'allocazione esatta è l'ideale per raccolte che non comportano alcun aggiornamento o eliminazione di carichi di lavoro.
Potere dell'allocazione di 2 dimensioni
Per una crescita regolare dei documenti, questa strategia viene utilizzata nel motore di archiviazione MMAPv1. Ogni record ha una dimensione in byte che è una potenza di 2, cioè (32, 64, 128, 256, 512...2 MB). Essendo 2 MB il limite maggiore predefinito per qualsiasi documento che lo superi, la sua memoria viene arrotondata al multiplo più vicino di 2 MB. Ad esempio, se un documento è di 200 MB, questa dimensione verrà arrotondata a 256 MB e 56 MB di spazio commerciale saranno disponibili per qualsiasi ulteriore crescita. Ciò consente ai documenti di crescere invece di attivare una riallocazione che il sistema dovrà effettuare quando i documenti raggiungono la loro limiti di spazio disponibile.
Meriti di allocazioni di dimensioni 2 del potere
- Riutilizzo dei record liberati per ridurre la frammentazione: Con questo concetto, i record vengono quantizzati in memoria per avere una dimensione fissa sufficientemente grande da contenere nuovi documenti che si adatterebbero allo spazio allocato creato da una precedente eliminazione o riposizionamento di documenti.
- Riduce gli spostamenti dei documenti: Come accennato in precedenza, per impostazione predefinita, gli inserimenti e gli aggiornamenti di MongoDB che aumentano la dimensione del documento rispetto alla dimensione del record impostata comporteranno anche l'aggiornamento degli indici. Ciò significa semplicemente che i documenti sono stati spostati. Tuttavia, quando c'è abbastanza spazio per la crescita all'interno di un documento, il documento non verrà spostato, quindi meno aggiornamenti agli indici.
Utilizzo della memoria
Tutta la memoria libera sulla macchina nel motore di archiviazione MMAPv1 viene utilizzata come cache. Set di lavoro correttamente dimensionati e prestazioni ottimali si ottengono attraverso un set di lavoro che si inserisce nella memoria. Inoltre, per ogni 60 secondi, MMAPv1 scarica le modifiche ai dati su disco, salvando così nella memoria cache. Questo valore può essere modificato in modo tale che il lavaggio possa essere eseguito frequentemente. Poiché tutta la memoria libera viene utilizzata come cache, non stupirti del fatto che gli strumenti di monitoraggio delle risorse di sistema indicheranno che MongoDB utilizza molta memoria poiché questo utilizzo è dinamico.
Pregi del motore di archiviazione MMAPv1
- Ridotta frammentazione su disco quando si utilizza la strategia di pre-allocazione.
- Letture molto efficienti quando il working set è stato configurato per adattarsi alla memoria.
- Gli aggiornamenti sul posto, ovvero gli aggiornamenti dei singoli campi possono comportare l'archiviazione di più dati, migliorando così l'aggiornamento di documenti di grandi dimensioni con un numero minimo di autori simultanei.
- Con un numero ridotto di writer simultanei, le prestazioni di scrittura possono essere migliorate grazie al concetto di scaricamento frequente dei dati su disco.
- Il blocco a livello di raccolta facilita le operazioni di scrittura. Lo schema di blocco è uno dei fattori più importanti nelle prestazioni del database. In questo caso, solo 1 client alla volta può accedere al database. Ciò crea uno scenario tale che le operazioni scorrono più rapidamente rispetto a quando vengono presentate in modo seriale dal motore di archiviazione.
Limitazioni del motore di archiviazione MMAPv1
- Utilizzo elevato dello spazio durante le iterazioni. MMAPv1 manca di una strategia di compressione per il file system, quindi fa un'allocazione eccessiva dello spazio di registrazione.
- Limitazione dell'accesso alla raccolta per molti client durante l'esecuzione di un'operazione di scrittura. MMAPv1 utilizza la strategia di blocco a livello di raccolta, il che significa che 2 o più client non possono accedere alla stessa raccolta contemporaneamente, quindi una scrittura blocca tutte le letture in questa raccolta. Questo porta a una concorrenza grossolana che rende impossibile ridimensionare il motore MMAPv1.
- L'arresto anomalo del sistema potrebbe potenzialmente causare la perdita di dati se l'opzione di inserimento nel journal non è abilitata. Tuttavia, anche se lo fosse, la finestra è troppo piccola ma almeno potrebbe proteggerti da uno scenario di grande perdita di dati.
- Utilizzo dello storage inefficiente. Quando si utilizza la strategia di preallocazione, alcuni documenti occuperanno più spazio su disco rispetto ai dati stessi.
- Se la dimensione del set di lavoro supera la memoria allocata, le prestazioni diminuiscono in larga misura. Inoltre, documentare una crescita significativa dopo l'archiviazione iniziale può attivare ulteriori I/O, quindi causare problemi di prestazioni.
Confronto tra i motori di archiviazione MMAPv1 e WiredTiger
| Caratteristica chiave | MMAPv1 | WiredTiger |
|---|---|---|
| Prestazioni della CPU | L'aggiunta di più core della CPU purtroppo non aumenta le prestazioni | Le prestazioni migliorano con i sistemi multicore |
| Crittografia | A causa dell'utilizzo di file mappati in memoria, non supporta alcuna crittografia | La crittografia sia per i dati in transito che per quelli inattivi è disponibile sia nell'installazione di MongoDB Enterprise che in quella Beta |
| Scalabilità | Le scritture simultanee risultanti dal blocco a livello di raccolta rendono impossibile la scalabilità orizzontale. | Alte possibilità di ridimensionamento poiché il livello di blocco minimo è il documento stesso. |
| Regolazione | Pochissime possibilità di ottimizzare questo motore di archiviazione | È possibile eseguire numerose regolazioni su variabili come la dimensione della cache, gli intervalli dei checkpoint e i ticket di lettura/scrittura |
| Compressione dati | Nessuna compressione dei dati, quindi è possibile utilizzare più spazio | Sono disponibili metodi di compressione Snappy e zlib, quindi i documenti possono occupare meno spazio rispetto a MMAPv1 |
| Transazioni atomiche | Applicabile solo per un singolo documento | A partire dalla versione 4.0 è supportata la transazione atomica su più documenti. |
| Memoria | Tutta la memoria libera sulla macchina viene utilizzata come cache | Sono utilizzate la cache del filesystem e la cache interna |
| Aggiornamenti | Supporta gli aggiornamenti sul posto, quindi eccelle nei carichi di lavoro con inserimenti di volumi elevati, letture e aggiornamenti sul posto | Non supporta gli aggiornamenti sul posto. L'intero documento deve essere riscritto. |
Conclusione
Quando si arriva alla selezione del motore di archiviazione per un database, molte persone non sanno quale scegliere. La scelta normalmente dipende dal carico di lavoro a cui sarà sottoposto. In generale, MMAPv1 farebbe una scelta sbagliata ed è per questo che MongoDB ha fatto molti progressi nell'opzione WiredTiger. Tuttavia, può ancora superare alcuni altri motori di archiviazione a seconda del caso d'uso, ad esempio quando è necessario eseguire solo carichi di lavoro di lettura o è necessario archiviare molte raccolte separate con documenti di grandi dimensioni per cui 1 o 2 campi vengono aggiornati frequentemente.
