Warakorn - Fotolia
MongoDB pousse un cran plus loin l’analyse des séries chronologiques
Lors de son événement parisien du 5 avril, MongoDB a évoqué rapidement les nouveautés de la version 5.3 autour des données de séries chronologiques. L’éditeur entend faire mieux que ses concurrents spécialistes de ce sujet.
Pour mener à bien ses efforts technologiques (et aussi parce que c’est beaucoup plus lisible pour les actionnaires), l’éditeur a modifié son cycle de mise à jour en juillet 2021. Au lieu d’une publication annuelle, MongoDB propose une mise à jour par trimestre et une version majeure par an. Ce cycle qui a débuté avec MongoDB 5.0 à l’été dernier nous amène à la version 5.3, disponible ce 6 avril.
L’éditeur poursuit son travail en matière de support des données de séries chronologiques (time series). Outre l’introduction des opérateurs $top et $bottom, censés accélérer la recherche de données en début, et en fin de série et la conversion des tampons chronologiques en date, l’itération 5.2 a intégré un algorithme de compression des colonnes de séries temporelles qui ne doit ni affecter les performances, ni empêcher les requêtes. Cet ajout est consécutif à la disponibilité du système de schéma optimisé, embarqué dans la release 5.0 pour à la fois supporter et stocker les données time series dans un format compressé.
Au programme de la version 5.3, LeMagIT note la présence de nouveaux opérateurs d’agrégations pour faciliter la recherche par unité temporelle, mais surtout pour remplacer les valeurs Null et les champs vides dans les documents avec $fill et $linearfill (qui permet un remplissage par interpolation linéaire). Il s’agit de « remplir les blancs » quand une série de données n’est pas complète, par exemple lorsqu’un capteur IoT perd sa connexion.
L’éditeur mise également sur ses pipelines d’agrégations afin d’affiner la granularité des visualisations des données time series avec MongoDB Charts, un outil disponible depuis MongoDB Atlas, la DbaaS de l’éditeur.
Time series : les atouts de MongoDB, selon son CTO
Le support des données time series arrive tardivement sur MongoDB, mais le CTO Mark Porter est convaincu que l’architecture sous-jacente du SGBD permet d’égaler sinon dépasser des solutions telles InfluxDB et TimeScaleDB, dont les data store reposent sur le modèle relationnel. D’autre part, le support natif du format JSON permettrait d’éviter les problèmes de cardinalité de champs qu’un processeur de requêtes pourrait provoquer dans une base de données relationnelle. « Vous pouvez avoir vos documents avec trois versions différentes, toutes avec les mêmes champs clés, mais avec des capteurs ajoutant des choses différentes. Et puis vous pouvez appliquer ou non les modifications que vous souhaitez avec notre schéma JSON », assure Mark Porter auprès du MagIT.
En outre, les séries temporelles pourront être prochainement stockées dans Online Archive, le système d’archivage de MongoDB Atlas. Atlas peut automatiquement déplacer les collections ou les données qui ne sont pas fréquemment utilisées, pour les stocker sur un « Data Lake » managé par MongoDB, c’est-à-dire une instance en lecture seule sur un service de stockage objet (S3, Azure Blob Storage et Google Cloud Storage) où il est possible de requêter des données, si nécessaire.
Mark PorterCTO, MongoDB
Si ce Data Lake peut être une bonne base pour des traitements analytiques, Mark Porter indique auprès du MagIT qu’il y a encore du chemin à faire dans ce domaine. « Nous sommes au début du voyage avec l’analytique et nous écoutons les clients pour savoir ce dont ils ont besoin », affirme-t-il. « Nous avons compris que les développeurs souhaitent des fonctions d’analytique avancée dans leurs applications, par exemple pour la détection de fraudes ou pour animer des services de recommandation », poursuit le CTO. « Ce que nous ne voulons pas, c’est proposer un gros entrepôt de données fermé ».
Quelques optimisations de performance
Autre nouveauté de cette mouture 5.3, la possibilité de créer une collection de documents avec un index clusterisé. Cette méthode accélérerait les requêtes, puisque les collections occupent moins d’espace de stockage. Pour le maintien en condition opérationnelle, la commande fassertOnLockTimeoutForStepUpDown permet « à un serveur qui reçoit une demande de montée ou de descente en puissance de se terminer, s’il n’est pas en mesure de s’y conformer (par exemple en raison de disques défectueux) dans le délai imparti. Cela permet à un cluster d’élire avec succès un nouveau nœud primaire et de continuer à être disponible », peut-on lire dans la documentation.
La version intermédiaire 5.3, comme ses consœurs, est exclusive à MongoDB Atlas. Les utilisateurs des distributions on-premise ne peuvent qu’adopter la version majeure annuelle, et n’ont pas accès aux fonctionnalités directement liées à la DBaaS : les migrations « live », Atlas Search, Online Archive, MongoDB Charts, le sharding automatisé, la haute disponibilité ou encore le multicloud. La prochaine version majeure, la 6.0, est attendue en juin 2022.