Avec le moteur de stockage MMAPv1, les mises à jour sur place sont souvent mises en avant en tant que stratégie d'optimisation, car les index d'un document pointent directement vers les emplacements et les décalages de fichiers. Le déplacement d'un document vers un nouvel emplacement de stockage (en particulier s'il y a de nombreuses entrées d'index à mettre à jour) a plus de surcharge pour MMAPv1 qu'une mise à jour sur place qui n'a qu'à mettre à jour les champs modifiés. Voir :Caractéristiques de stockage des enregistrements dans MMAPv1.
WiredTiger ne prend pas en charge les mises à jour sur place car il utilise en interne MVCC (contrôle de concurrence multiversion), qui est couramment utilisé par les systèmes de gestion de base de données. Il s'agit d'une amélioration technique significative par rapport à la vue simpliste de MMAP, et permet de créer des fonctionnalités plus avancées telles que les niveaux d'isolement et les transactions. Les index de WiredTiger ont un niveau d'indirection (faisant référence à un RecordID interne au lieu de l'emplacement et du décalage du fichier), de sorte que les déplacements de documents au niveau du stockage ne sont pas un problème important.
Cependant, cet article indique également que "Même si [WiredTiger] n'autorise pas les mises à jour sur place, il pourrait toujours fonctionner mieux que MMAP pour de nombreuses charges de travail".
Cela signifie que bien que MMAPv1 puisse avoir un chemin plus efficace pour les mises à jour sur place, WiredTiger présente d'autres avantages tels que la compression et un meilleur contrôle de la concurrence. Vous pouvez peut-être créer une charge de travail composée uniquement de mises à jour sur place de quelques documents qui pourraient mieux fonctionner dans MMAPv1, mais les charges de travail réelles sont généralement plus variées. La seule façon de confirmer l'impact pour une charge de travail donnée serait de tester dans un environnement représentatif.
Cependant, le choix général de MMAPv1 contre WiredTiger est sans objet si vous voulez planifier pour l'avenir :WiredTiger est le moteur de stockage par défaut depuis MongoDB 3.2 et certaines nouvelles fonctionnalités du produit ne sont pas prises en charge par MMAPv1. Par exemple, MMAPv1 ne prend pas en charge Majority Read Concern, ce qui signifie qu'il ne peut pas être utilisé pour les serveurs de configuration d'ensemble de répliques (requis pour le partitionnement dans MongoDB 3.4+) ou Change Streams (MongoDB 3.6+). MMAPv1 sera obsolète dans la prochaine version majeure de MongoDB (4.0) et il est actuellement prévu qu'il soit supprimé dans MongoDB 4.2.
Quelles sont les implications exactes dont je dois être conscient lorsque j'utilise WiredTiger ? Par exemple, sans mises à jour sur place, la taille de la base de données augmentera-t-elle rapidement ?
Les résultats de stockage dépendent de plusieurs facteurs, notamment la conception de votre schéma, la charge de travail, la configuration et la version du serveur MongoDB. MMAPv1 et WiredTiger utilisent différentes stratégies d'allocation d'enregistrements, mais les deux essaieront d'utiliser l'espace préalloué qui est marqué comme libre/réutilisable. En général, WiredTiger est plus efficace avec l'utilisation de l'espace de stockage, et il a également l'avantage de la compression des données et des index. MMAPv1 alloue de l'espace de stockage supplémentaire pour tenter d'optimiser les mises à jour sur place et éviter les déplacements de documents, bien que vous puissiez choisir une stratégie "sans remplissage" pour les collections où la charge de travail ne modifie pas la taille du document au fil du temps.
Il y a eu des investissements importants dans l'amélioration et le réglage de WiredTiger pour différentes charges de travail depuis son introduction dans MongoDB 3.0, donc j'encourage fortement les tests avec la dernière série de versions de production pour le meilleur résultat. Si vous avez une question spécifique sur la conception du schéma et la croissance du stockage, je vous suggère de publier des détails sur DBA StackExchange pour discussion.
J'ai également appris que WiredTiger dans MongoDB 3.6 a ajouté la possibilité de stocker des deltas plutôt que de réécrire l'intégralité du document (https://jira.mongodb.org/browse/DOCS-11416). Qu'est-ce que cela signifie exactement ?
Il s'agit d'un détail d'implémentation qui améliore les structures de données internes de WiredTiger pour certains cas d'utilisation. En particulier, WiredTiger dans MongoDB 3.6+ peut être plus efficace pour travailler avec de petites modifications sur des documents volumineux (par rapport aux versions précédentes). Le cache WiredTiger doit pouvoir renvoyer plusieurs versions de documents tant qu'ils sont utilisés par des sessions internes ouvertes (MVCC, comme mentionné précédemment), donc pour les documents volumineux avec de petites mises à jour, il pourrait être plus efficace de stocker une liste de deltas. Cependant, si trop de deltas s'accumulent (ou si les deltas modifient la plupart des champs d'un document), cette approche peut être moins performante que la conservation de plusieurs copies du document complet.
Lorsque les données sont enregistrées sur le disque via un point de contrôle, une version complète du document doit encore être écrite. Si vous souhaitez en savoir plus sur certains éléments internes, il existe une série de vidéos MongoDB Path To Transactions suivant le développement de fonctionnalités pour prendre en charge les transactions multi-documents dans MongoDB 4.0.
De plus, ce que je ne comprends pas, c'est que de nos jours, la plupart des disques durs (sinon tous) ont une taille de secteur de 4096 octets, vous ne pouvez donc pas écrire sur le disque dur uniquement 4 octets (par exemple), mais vous devez plutôt écrire le bloc complet de 4096 octets (lisez-le donc d'abord, mettez à jour les 4 octets qu'il contient, puis écrivez-le). Comme la plupart des documents sont souvent <4096 octets, cela signifie que la réécriture du document entier est nécessaire dans tous les cas (même avec MMAP). Qu'est-ce que j'ai raté ?
Sans entrer trop loin dans les détails de l'implémentation et en essayant d'expliquer toutes les parties mobiles impliquées, réfléchissez à la manière dont les différentes approches s'appliquent aux charges de travail où de nombreux documents sont mis à jour (plutôt qu'au niveau d'un seul document) ainsi qu'à l'impact sur l'utilisation de la mémoire (avant les documents sont écrits sur le disque). En fonction de facteurs tels que la taille et la compression du document, un seul bloc d'E/S peut représenter n'importe où, d'une fraction d'un document (taille maximale de 16 Mo) à plusieurs documents.
Dans MongoDB, le flux général est que les documents sont mis à jour dans une vue en mémoire (par exemple, le cache WiredTiger) avec des modifications conservées sur le disque dans un format de journal rapide avec ajout uniquement avant d'être périodiquement vidées dans les fichiers de données. Si le système d'exploitation n'a qu'à écrire des blocs de données qui ont changé, toucher moins de blocs de données nécessite moins d'E/S globales.
