Relational Migrator : le plan de MongoDB pour convertir les entreprises au NoSQL

Si comme tous les éditeurs, MongoDB tente de surfer sur la vague de l’IA générative, c’est sa volonté d’accueillir toutes les charges de travail (ou presque) et son plan pour tenter de convertir les entreprises au NoSQL qui marque son événement new-yorkais.

Accueillir les charges de travail. Toutes les charges de travail. Sous toutes leurs formes. Telle est la volonté affichée de MongoDB lors de son événement MongoDB Local à New York.

Cela passe par la possibilité de déployer sa base de données NoSQL sur sa plateforme DBaaS MongoDB Atlas, en hybride et sur site. Surtout, l’éditeur a la prétention d’accueillir les traitements OLTP, OLAP, la recherche full-text, ou encore la gestion et des informations temps réel.

Adapter le streaming de données au modèle document

En ce sens, il poursuit son travail pour mieux lire et écrire les séries chronologiques, introduites à partir de la version 5.0 de son SGBD NoSQL. MongoDB peut ingérer un plus grand nombre de données time series et offre un moyen de les modifier après coup. En l’occurrence, dès cet été, MongoDB 7.0 prendra en charge nativement les opérations de suppression unitaire ou en bulk des séries, hormis dans le cadre de transactions multidocument.

 Dans cette même veine, le spécialiste a dévoilé Atlas Stream Processing. Ce service sera disponible en préversion privée plus tard cette année. Il s’agit d’offrir une interface unifiée pour traiter les données événementielles et batch. « C’est un service qui permet d’exécuter des requêtes en temps réel sur des données événementielles, comme des transformations ou des agrégations », décrit Andrew Davidson, SVP of Products chez MongoDB. « Les solutions existantes de traitements de flux présentent traditionnellement des limitations, la première étant qu’elles ont été conçues pour prendre en charge des schémas de données rigides et des formats de données tabulaires ».

Selon le responsable, le fait que ces solutions reposent généralement sur un système annexe (par exemple, une distribution d’Apache Kafka) et qu’elles soient coûteuses et difficiles à opérationnaliser justifierait l’engagement de MongoDB sur ce terrain. « Notre fonctionnalité de streaming est conçue pour traiter des documents, elle prend en charge nativement notre schéma flexible et permet d’exécuter des opérations complexes en continu sur les flux de données », vante-t-il.

Recherche sémantique et IA générative : MongoDB tente le doublé

Un autre terrain plus prospectif pour MongoDB n’est autre que l’IA générative. Quel rapport entre une base de données et ChatGPT ? Le stockage et le traitement des embeddings. Les embeddings sont des représentations vectorielles de textes, d’images, de fichiers audio et vidéo. À travers la technique du plongement lexical, ils permettent de mesurer la similarité cosinus, c’est-à-dire la distance entre des vecteurs représentant des mots ou des phrases. Visuellement, dans un plan ou dans un espace, les vecteurs qui représentent les mots « chien » et « chat » seront plus proches que ceux désignant les termes « chaussures » et « télévision ».

Ces représentations vectorielles sont directement interprétées par les grands modèles de langage (LLM) pour apporter la réponse la plus pertinente à une question. C’est en ce sens que MongoDB lance Atlas Vector Search en préversion publique. L’idée est de pouvoir stocker, traiter et chercher ces embeddings servant à affiner, à personnaliser, ou à limiter les réponses d’un modèle d’IA générative sur étagère, « sans la nécessité d’envoyer les données sources à un LLM tiers », promet l’éditeur.

Depuis la DBaaS, Vector Search peut s’intégrer à LangChain et LlamaIndex, deux boîtes à outils pour bâtir des applications par-dessus de grands modèles de langage. Les clients peuvent utiliser ces frameworks ainsi que la plateforme Atlas pour se connecter aux modèles disponibles sur le marché (OpenAI, Anthropic, HuggingFace) et aux services d’IA de ses partenaires (AWS, GCP, Azure, Databricks et MindsDB).

« La recherche sémantique est un moyen de comprendre l’intention derrière une recherche. »
Dev IttycheriaPrésident et CEO, MongoDB

Quoi qu’en dise MongoDB, Vector Search doit avant tout apporter une couche sémantique à Atlas Search, une implémentation propriétaire du moteur de recherche Apache Lucene dans sa DBaaS. Les cas d’usage les plus probants sont la recherche d’images, de vidéo ou de fichiers sonores annotés (très utile pour une plateforme SVOD), ainsi que la comparaison ou la recommandation de produits sur un site e-commerce. « Okta utilise la recherche vectorielle à l’aide de MongoDB pour aider ses clients à trouver des authentifiants », illustre Sahir Azam, Chief Product Officer chez MongoDB.

De manière générale, « la recherche sémantique est un moyen de comprendre l’intention derrière une recherche », avance Dev Ittycheria, président et CEO de MongoDB, lors de la conférence. « C’est l’une des capacités clés dans le domaine de l’intelligence artificielle et elle est essentielle pour les usages des entreprises, par exemple pour mieux comprendre leurs clients ».

D’ailleurs, MongoDB 7.0 introduira des méthodes programmatiques mongosh pour créer, effacer, mettre à jour les index de recherche liés à des collections spécifiques. Sur MongoDB Atlas, Atlas Search vient de gagner une fonction analytique pour « tracer » les termes inclus dans les recherches. Il s’agit de donner une idée du volume de recherche sur un mot clé et la réponse que le moteur effectue généralement. Enfin, Atlas Search aura le droit à des nœuds dédiés.

Que ce soit pour des usages de recherches avancées ou pour contraindre les générations de contenus à un domaine spécifique en évitant les hallucinations, d’autres acteurs ont déjà effectué des annonces pour prendre en charge les embeddings. C’est le cas d’Elasticsearch et d’Azure avec CosmosDB for MongoDB. D’autres acteurs dont le spécialiste des systèmes orientés graphes Neo4J.

Une base de données NoSQL est foncièrement bien née pour accueillir des vecteurs et des séries chronologiques. Pour autant, une majorité d’éditeurs de bases de données et de data warehouse vantent leurs capacités multimodèle. C’est le cas de MongoDB qui tente, sans l’exprimer dans ces termes, de rendre la monnaie de sa pièce à Oracle.

Relational Migrator : MongoDB répond indirectement à Oracle

Pour rappel, ces trois dernières années, Oracle a cherché à convaincre les clients de MongoDB de migrer vers sa base de données en assurant une compatibilité des applications bâties à l’origine sur MongoDB et améliorant la prise en charge des documents JSON.

En réponse, MongoDB a lancé officiellement une contre-offensive ciblant non seulement Oracle, mais également les SGBD d’AWS, de Sybase, de Microsoft et d’EDB. Rien que ça. MongoDB a annoncé la disponibilité générale de Relational Migrator, un outil et un programme pour migrer les données d’un SGBD relationnel vers MongoDB Enterprise Advanced ou MongoDB Atlas.

Relational Migrator permet de se connecter à un SGBD source Oracle, SQL Server, MySQL et PostgreSQL, d’analyser son schéma visuellement, de réaliser un mapping de ce schéma dans MongoDB et d’opérer effectivement la migration des données vers des clusters MongoDB. Cette migration peut être réalisée en une fois à partir d’un snapshot ou en continu, couplé à avec un système de change data capture. Du côté des applications, Relational Migrator permet de générer des artefacts de code pour « accélérer » la conversion des applications et, idéalement, les moderniser. Par ailleurs, il imagine utiliser l’IA générative pour convertir les requêtes SQL des applications en requêtes MQL (MongoDB Query Language).

Évidemment, un outil ne suffira pas à satisfaire tous les besoins des entreprises. MongoDB a annoncé d’ores et déjà des partenariats avec Capgemini, Accenture, Globant et Tech Mahindra pour les accompagner. 

Il n’est pas évident que les organisations quittent l’écosystème relationnel, si répandu, pour miser entièrement sur une base de données orientée documents.

Comme l’indiquait l’année dernière Carl Olofson, analyste chez IDC, MongoDB doit convaincre les grandes entreprises, plus seulement les développeurs. À la fin du mois d’avril, à la clôture de son premier trimestre fiscal 2024, l’éditeur revendiquait plus de 43 100 clients, dont plus de 41 600 utilisent Atlas. Dans un même temps, il dénombrait 1 761 clients générant plus de 100 000 dollars de revenu récurrent annuel chacun.

 Ainsi, MongoDB compte décliner cette stratégie de migration avec un programme d’accompagnement par industrie, en commençant par lancer une offre généraliste et une autre ciblant les services financiers.

Simplifier les opérations, accueillir toujours plus de développeurs

Pour autant, il n’oublie pas son public cible en dévoilant un ensemble d’ajouts en direction des développeurs, des DBA et des DevOps. De fait, ce sont les équipes de développement qui poussent l’adoption de plateforme comme Atlas.

Le premier d’entre eux n’est autre que l’intégration de MongoDB Atlas avec AWS CDK et AWS CloudFormation. À l’instar de ce que propose Pulumni ou Hashicorp, il s’agit de renforcer les options d’Infrastructure as Code en prenant non seulement en charge les templates JSON et YAML, mais aussi les configurations exprimées en JavaScript, TypeScript, Python, Java, C # et Go.

Toujours dans la volonté de simplifier l’orchestration de sa DBaaS, l’éditeur a intégré une commande dans son CLI pour installer rapidement son opérateur K8S, Atlas Kubernetes Operator. Celui-ci permet de créer des clusters, de gérer des CRD, des certificats X509, des points de terminaison privés, la connexion aux services de chiffrement, de backup ou encore d’audition.

MongoDB met aussi l’accent sur la prise en charge de Kotlin, qui ne sert plus uniquement à développer des applications côté client par-dessus la base de données mobile MongoDB Realm, mais aussi à concevoir des services côté serveur.

Enfin, pour les data scientists, la librairie PyMongoArrow entre en disponibilité générale. À l’aide du protocole Apache Arrow, celle-ci permet de traduire les requêtes MQL de MongoDB en arrays (NumPy ndarrays), tables (Panda DataFrames, tables Arrow) ou formats (Parquet, CSV, etc.) lisibles par les outils et les plateformes de data science compatibles avec Python.

Pour approfondir sur Base de données

Close