Avec sa version 8.0, MongoDB sort le grand jeu

Un ensemble d’optimisations « sous le capot »

Commençons par évoquer les gains liés à la lecture. « Pendant le développement de MongoDB 8.0, j’ai demandé à l’équipe d’ingénieurs d’optimiser de manière drastique les chemins d’exécution de commandes », affirme Tyler Brock. « Cela permet de réduire le nombre d’instructions nécessaires à l’exécution des opérations sensibles à la latence », résume-t-il.

Les chemins d’exécution de commandes représentent « la section de code la plus exécutée au sein de la base de données », expliquait de son côté Cris Stauffer, directeur de la gestion produit chez MongoDB, lors de l’événement new-yorkais en mai. « Ils sont responsables de l’orchestration et de l’exécution des lectures et des écritures. Optimiser cela permet d’améliorer l’exécution de n’importe quelle commande dans le système ».

Les ingénieurs de MongoDB ont aussi travaillé à optimiser la mise en cache de certains éléments lors de la planification de l’exécution des commandes. Par ailleurs, ils ont réduit le nombre de scans et de récupérations (fetches) nécessaires lors de cette étape.

En outre, pour les opérations les plus simples, MongoDB a développé des requêtes spécifiques, nommées Express. Celles-ci permettent de n’exécuter qu’une partie du plan de la requête en utilisant une technique de balayage d’index optimisé.

MongoDB améliore sa prise en charge des données time series

Concernant les écritures, les améliorations sont davantage liées à des charges de travail spécifiques. La plus visible d’entre elles concerne les séries chronologiques. Pour rappel, MongoDB prend en charge les données time series depuis la version 5.0. « Dans les versions 6.0 et 7.0, nous nous sommes appuyés sur un format de stockage en colonne afin de les agréger et de les présenter », rappelle Cris Stauffer. La version 8.0 introduit ce que MongoDB appelle un traitement en bloc. « C’est une technique qui nous permet de travailler sur des lots de documents au lieu de les traiter individuellement. Ces traitements bulks permettent d’amortir le coût d’opérations coûteuses, comme le calcul d’une moyenne mobile ou l’actualisation d’informations au fil du temps ($group) », explique Tyler Brock.

Au passage, MongoDB a optimisé plusieurs requêtes expressives en vue de réduire le temps ou la quantité de ressources nécessaires à leur exécution. C’est le cas pour certaines opérations de lecture, tandis que la nouvelle commande d’écriture en bulk promet les gains présentés plus haut.

En ce qui concerne les écritures concurrentes, l’éditeur a dû aménager son protocole de réplication. « Par défaut, nous ne garantissons les écritures qu’une fois qu’elles ont été répliquées en toute sécurité à la majorité de votre cluster », relate Tyler Brock. « Dans MongoDB 8.0, nous sommes désormais en mesure de gérer certaines de ces opérations de réplication et de les exécuter en parallèle », ajoute-t-il. « Cette amélioration rend les opérations secondaires beaucoup plus efficaces et réduit la latence de la réplication. En conséquence, nous sommes maintenant en mesure de confirmer les écritures de la majorité beaucoup plus rapidement, ce qui améliore considérablement les performances totales du système ».

Cela demande tout de même un paramétrage spécifique et les développeurs doivent être attentifs à l’actualisation ou la perte de données, si leurs applications lisent des données depuis un membre secondaire d’un cluster.

L’éditeur dit également avoir revu la gestion de la mémoire. Il a implémenté une version mise à jour de l’allocateur de mémoire TCMalloc, développé à l’origine par Google. « Il utilise un système de cache par cœur au lieu de le faire par thread, ce qui permet de réduire la fragmentation de la mémoire de 18 % », affirme Tyler Brock. « Ce que cela veut dire, c’est qu’au moment des pics de charge, là où vous en aurez le plus besoin, vous allez constater une meilleure gestion de la mémoire », résume Cris Stauffer.

De plus, il ajoute un moyen de filtrer les requêtes correspondant à certaines formes pour autoriser ou refuser les opérations. Cela s’accompagne de la possibilité d’appliquer un seuil de fréquence d’exécution de certaines requêtes de lecture ciblant un cluster spécifique.

Une mise à l’échelle horizontale plus accessible et rapide

Encore faut-il que ces avantages soient accessibles à l’échelle. Et c’est étrangement la partie la plus limpide de la release note de MongoDB 8.0. Le SGBD NoSQL peut s’étendre verticalement et horizontalement sur des serveurs. Cette deuxième capacité est rendue possible par le sharding, c’est-à-dire une méthode de distribution des données à travers plusieurs machines. Elle implique de subdiviser des collections en « tessons » (shards) qui peuvent être distribués sur un ou plusieurs clusters. Or, elle est réputée pour sa complexité et son coût.

MongoDB 8.0 doit simplifier cette approche, en permettant de configurer un serveur qui stocke à la fois les données d’une application en sus des métadonnées nécessaires au fonctionnement du cluster shardé. « Cela permet de réduire le coût d’exécution des clusters “single shard” jusqu’à 50 % tout en simplifiant les opérations », vante Tyler Brock. « Cela rend le sharding plus accessible pour les environnements de test et de développement. Les clusters shardés sont aussi simples à manipuler que des sets de réplique ».

Selon Colby Ing, responsable produit chez MongoDB, il fallait auparavant un serveur dédié supplémentaire, ce qui représentait un surcoût d’environ 5 000 dollars par an à l’entrée. Pour autant, l’éditeur précise que la configuration embarquée est adaptée aux « petits » déploiements horizontaux.

Par ailleurs, il est possible de « désharder » une collection « shardée » pour déplacer les données sur un shard spécifique.

Il s’agit plus particulièrement d’éviter un scénario nommé « hot shard » où une machine est sur-sollicitée. Celui-ci intervient lorsque deux collections populaires ou plus résident dans un même shard. « Avant la version 8.0, déplacer des données était complexe et lent. Vous ne pouviez pas spécifier de déplacer une seule collection. Vous deviez déplacer toutes les collections ensemble sur une seule base de données », relate Colby Ing.

Aussi, depuis la version 7.2, l’éditeur a fait en sorte que le resharding soit bien plus rapide qu’auparavant. Pour ce faire, il n’est plus nécessaire d’avoir une clé de sharding différente. Ainsi quand la division en deux tessons d’une collection de données de 1 To avec 10 index et 1 milliard de documents prenait 220 heures (environ 9 jours…), l’opération ne réclame plus que 12 heures. Comme l’ensemble des gains de performance annoncés par l’entreprise, il reste à vérifier.

La grande nouveauté de MongoDB 7.0 mise en avant par l’éditeur tenait dans la mise à disposition d’un moyen d’interroger des données chiffrées sans les sortir de cet état. Ici, l’entreprise améliore légèrement cette solution. Il est possible d’exécuter des requêtes « range » sur des plages de dates ou des nombres. « Maintenant, une banque peut chercher toutes les transactions qui dépassent 1 000 livres. Ou une équipe de recherche dans un CHU peut chercher des patients atteints d’une certaine maladie dont l’âge est situé entre 30 et 45 ans », illustre le vice-président engineering. « Tout ce temps, les données personnelles et confidentielles demeurent totalement chiffrées ». Il faut pour cela déployer un schéma de chiffrement.

Enfin, en matière de sécurité encore, MongoDB adopte l’Open Cybersecurity Schema Framework (OCSF), une solution pour journaliser les pistes d’audit, portée (entre autres) par AWS et Splunk.