Bien que ce moteur de stockage soit obsolète depuis la version 4.0 de MongoDB, il contient certaines fonctionnalités importantes. MMAPv1 est le moteur de stockage d'origine de MongoDB et est basé sur des fichiers mappés. Seule l'architecture Intel 64 bits (x86_64) prend en charge ce moteur de stockage.
MMAPv1 offre d'excellentes performances sur les charges de travail avec...
- Mises à jour importantes
- Lectures à volume élevé
- Encarts à grand volume
- Utilisation élevée de la mémoire système
Architecture MMAPv1
MMAPv1 est un système basé sur B-tree qui alimente de nombreuses fonctions telles que l'interaction de stockage et la gestion de la mémoire pour le système d'exploitation.
C'était la base de données par défaut pour MongoDB pour les versions antérieures à 3.2 jusqu'à l'introduction du moteur de stockage WiredTiger. Son nom vient du fait qu'il utilise des fichiers mappés en mémoire pour accéder aux données. Pour ce faire, il charge et modifie directement le contenu du fichier, qui se trouve dans une mémoire virtuelle via une méthodologie d'appel système mmap().
Tous les enregistrements sont situés de manière contiguë sur le disque et dans le cas où un document devient plus grand que la taille d'enregistrement allouée, alors MongoDB alloue un nouvel enregistrement. Pour MMAPv1, cela est avantageux pour l'accès séquentiel aux données, mais en même temps une limitation car cela entraîne un coût en temps puisque tous les index de documents doivent être mis à jour, ce qui peut entraîner une fragmentation du stockage.
L'architecture de base du moteur de stockage MMAPv1 est illustrée ci-dessous.
Comme mentionné ci-dessus, si la taille d'un document dépasse la taille d'enregistrement allouée, cela entraînera une réallocation qui n'est pas une bonne chose. Pour éviter cela, le moteur MMAPv1 utilise une allocation de puissance de 2 afin que chaque document soit stocké dans un enregistrement contenant le document lui-même (y compris un espace supplémentaire appelé remplissage). Le rembourrage est ensuite utilisé pour permettre toute croissance de document pouvant résulter de mises à jour tout en réduisant les risques de réaffectation. Sinon, si des réallocations se produisent, vous risquez d'avoir une fragmentation du stockage. Le rembourrage échange de l'espace supplémentaire pour améliorer l'efficacité, réduisant ainsi la fragmentation. Pour les charges de travail avec des volumes élevés d'insertions, de mises à jour ou de suppressions, l'allocation de puissance de 2 doit être préférée, tandis que l'allocation d'ajustement exact est idéale pour les collections qui n'impliquent aucune mise à jour ou suppression de charges de travail.
Allocation de puissance de 2
Pour une croissance fluide des documents, cette stratégie est utilisée dans le moteur de stockage MMAPv1. Chaque enregistrement a une taille en octets qui est une puissance de 2, c'est-à-dire (32, 64, 128, 256, 512...2 Mo). 2 Mo étant la limite supérieure par défaut pour tout document dépassant cette limite, sa mémoire est arrondie au multiple de 2 Mo le plus proche. Par exemple, si un document fait 200 Mo, cette taille sera arrondie à 256 Mo et un échange d'espace de 56 Mo sera disponible pour toute croissance supplémentaire. Cela permet aux documents de croître au lieu de déclencher une réallocation que le système devra effectuer lorsque les documents atteindront leur limites de l'espace disponible.
Mérite des allocations de puissance 2
- Réutilisation des enregistrements libérés pour réduire la fragmentation : Avec ce concept, les enregistrements sont quantifiés en mémoire pour avoir une taille fixe suffisamment grande pour accueillir de nouveaux documents qui s'intégreraient dans l'espace alloué créé par une suppression ou un déplacement de document antérieur.
- Réduit les déplacements de documents : Comme mentionné précédemment, par défaut, les insertions et les mises à jour de MongoDB qui augmentent la taille du document par rapport à la taille d'enregistrement définie entraîneront également la mise à jour des index. Cela signifie simplement que les documents ont été déplacés. Cependant, lorsqu'il y a suffisamment d'espace pour la croissance dans un document, le document ne sera pas déplacé, d'où moins de mises à jour des index.
Utilisation de la mémoire
Toute la mémoire libre sur la machine dans le moteur de stockage MMAPv1 est utilisée comme cache. Des ensembles de travail correctement dimensionnés et des performances optimales sont obtenus grâce à un ensemble de travail qui tient dans la mémoire. En outre, toutes les 60 secondes, le MMAPv1 vide les modifications apportées aux données sur le disque, économisant ainsi sur la mémoire cache. Cette valeur peut être modifiée de manière à ce que le rinçage puisse être effectué fréquemment. Étant donné que toute la mémoire libre est utilisée comme cache, ne soyez pas choqué que les outils de surveillance des ressources système indiquent que MongoDB utilise beaucoup de mémoire puisque cette utilisation est dynamique.
Avantages du moteur de stockage MMAPv1
- Réduction de la fragmentation sur disque lors de l'utilisation de la stratégie de pré-allocation
- Lectures très efficaces lorsque le jeu de travail a été configuré pour tenir dans la mémoire.
- Les mises à jour sur place, c'est-à-dire les mises à jour de champs individuels, peuvent entraîner le stockage de plus de données, améliorant ainsi la mise à jour de documents volumineux avec un minimum d'auteurs simultanés.
- Avec un faible nombre d'enregistreurs simultanés, les performances d'écriture peuvent être améliorées grâce au concept de vidage fréquent des données sur le disque.
- Le verrouillage au niveau de la collection facilite les opérations d'écriture. Le schéma de verrouillage est l'un des facteurs les plus importants dans les performances de la base de données. Dans ce cas, un seul client peut accéder à la base de données à la fois. Cela crée un scénario tel que les opérations se déroulent plus rapidement que lorsqu'elles sont présentées en série par le moteur de stockage.
Limites du moteur de stockage MMAPv1
- Utilisation élevée de l'espace lors des itérations. MMAPv1 n'a pas de stratégie de compression pour le système de fichiers, ce qui entraîne une surallocation d'espace d'enregistrement.
- Restriction d'accès à la collection pour de nombreux clients lors d'une opération d'écriture. MMAPv1 utilise une stratégie de verrouillage au niveau de la collection, ce qui signifie que 2 clients ou plus ne peuvent pas accéder à la même collection en même temps. Par conséquent, une écriture bloque toutes les lectures dans cette collection. Cela conduit à une simultanéité grossière qui rend impossible la mise à l'échelle du moteur MMAPv1.
- Un plantage du système peut entraîner une perte de données si l'option de journalisation n'est pas activée. Cependant, même si c'est le cas, la fenêtre est trop petite mais peut au moins vous protéger d'un scénario de perte de données importante.
- Utilisation inefficace du stockage. Lors de l'utilisation de la stratégie de pré-allocation, certains documents occuperont plus d'espace sur le disque que les données elles-mêmes.
- Si la taille de l'ensemble de travail dépasse la mémoire allouée, les performances chutent dans une large mesure. En outre, documenter une croissance importante après le stockage initial peut déclencher des E/S supplémentaires et donc entraîner des problèmes de performances.
Comparaison des moteurs de stockage MMAPv1 et WiredTiger
| Fonctionnalité clé | MMAPv1 | Tigre filaire |
|---|---|---|
| Performances du processeur | Ajouter plus de cœurs de processeur n'améliore malheureusement pas les performances | Les performances s'améliorent avec les systèmes multicœurs |
| Cryptage | En raison de l'utilisation de fichiers mappés en mémoire, il ne prend en charge aucun chiffrement | Le chiffrement pour les données en transit et restantes est disponible à la fois dans l'entreprise MongoDB et dans l'installation bêta |
| Évolutivité | Les écritures simultanées résultant du verrouillage au niveau de la collection rendent impossible la montée en charge. | De fortes chances d'évoluer, car le niveau de verrouillage le plus bas est le document lui-même. |
| Réglage | Très peu de chances de régler ce moteur de stockage | De nombreux réglages peuvent être effectués autour de variables telles que la taille du cache, les intervalles de point de contrôle et les tickets de lecture/écriture |
| Compression des données | Aucune compression de données donc plus d'espace peut être utilisé | Méthodes de compression Snappy et zlib disponibles, les documents peuvent donc occuper moins d'espace que dans MMAPv1 |
| Transactions atomiques | Applicable uniquement pour un seul document | A partir de la version 4.0, la transaction atomique sur plusieurs documents est prise en charge. |
| Mémoire | Toute la mémoire libre sur la machine est utilisée comme cache | Le cache du système de fichiers et le cache interne sont utilisés |
| Mises à jour | Prend en charge les mises à jour sur place et excelle donc dans les charges de travail avec des insertions de volumes lourds, des lectures et des mises à jour sur place | Ne prend pas en charge les mises à jour sur place. L'ensemble du document doit être réécrit. |
Conclusion
Lorsqu'il s'agit de sélectionner un moteur de stockage pour une base de données, de nombreuses personnes ne savent pas lequel choisir. Le choix repose normalement sur la charge de travail à laquelle il sera soumis. D'une manière générale, le MMAPv1 ferait un mauvais choix et c'est pourquoi MongoDB a fait beaucoup d'avancées vers l'option WiredTiger. Cependant, il peut toujours surpasser certains autres moteurs de stockage en fonction du cas d'utilisation, par exemple lorsque vous devez effectuer uniquement des charges de travail en lecture ou devez stocker de nombreuses collections distinctes avec des documents volumineux dans lesquels 1 ou 2 champs sont fréquemment mis à jour.
