Avec DocumentDB, Microsoft repense le NoSQL sur PostgreSQL

Pour cette version autonome de la couche de compatibilité MongoDB pour Azure Cosmos DB lancée récemment à l'échelle mondiale, Microsoft a repris l’ancien nom DocumentDB donné en 2018 à une version publique du moteur de base de données Project Florence qui alimente une grande partie d'Azure. Si cette dénomination originale de la base de données convenait bien à certains, sa prise en charge de nombreux documents autres que JSON a rapidement réorienté vers ce nom désormais plus familier. Cosmos DB a continué à évoluer, avec ses capacités de base de données documentaire offrant un ensemble familier d'API compatibles avec MongoDB. Une série de mises à jour récente a introduit la variante vCore d'Azure Cosmos DB, qui passe d'une architecture multi-tenant, interrégionale et basée sur des unités de ressources extensibles de manière transparente à une architecture alternative qui se comporte davantage comme des services Azure traditionnels, avec des machines virtuelles hôtes définies et un modèle de tarification plus prévisible. Les API de MongoDB basées sur vCore sont les mêmes que celles utilisées avec la version basée sur les unités de ressources à l'échelle du cloud, mais les technologies sous-jacentes sont très différentes et le passage d'une version à l'autre nécessite une migration complète de ses données.

La semaine dernière, Microsoft a révélé les différences entre les deux implémentations en dévoilant une version open source du moteur vCore Cosmos DB. Construit sur la plateforme familière PostgreSQL, ce projet public ajoute des fonctionnalités NoSQL avec les API MongoDB. Étant donné qu’il se concentre uniquement sur le stockage de contenu JSON, Microsoft a décidé de reprendre le nom DocumentDB original. Livrée avec une licence MIT, la version autonome DocumentDB est destinée à fournir un environnement NoSQL standard aux données afin de simplifier la migration d'une plateforme à l'autre. Le choix de travailler avec PostgreSQL s'explique en partie par le fait que cette plateforme, qui a connu une sorte de renaissance récente, est depuis longtemps populaire auprès des développeurs.

Une base de données NoSQL moderne avec des racines PostgreSQL

En livrant en open-source un outil déjà largement utilisé dans Azure, Microsoft permet aux développeurs d'utiliser quelque chose qui a déjà fait ses preuves. La plupart des fonctionnalités que l'on peut attendre d’un magasin NoSQL moderne sont déjà présentes, depuis les opérations CRUD (Create, read, update, delete/créer, lire, mettre à jour, supprimer) de base jusqu’aux outils de recherche vectorielle plus complexes et aux index nécessaires pour les prendre en charge. Tout cela garantit de pouvoir construire et d'étendre une base de données capable de prendre en charge la plupart des scénarios. DocumentDB s'appuie sur la plateforme PostgreSQL existante, qui gère le stockage, l'indexation et d'autres opérations clés de bas niveau. La mise en œuvre de DocumentDB repose donc sur deux composants : l'un qui ajoute la prise en charge des types de données BSON (Binary JavaScript Object Notation) et l'autre qui prend en charge les API de DocumentDB, en ajoutant les opérations CRUD, les requêtes et la gestion de l'index. BSON est le type de données fondamental utilisé dans MongoDB, mais avec des implémentations dans la plupart des langages courants. Si l’on souhaite créer un magasin NoSQL commun basé sur les API de MongoDB, BSON servira à représenter les structures de données NoSQL standard, comme les paires clé-valeur et les tableaux. Il est facile de créer des documents JSON, mais l'utilisation de BSON permet de stocker et de rechercher du contenu de manière plus efficace.

On peut considérer DocumentDB comme une pile, avec PostgreSQL au bas de l'échelle, avec l'extension DocumentDB indispensable à la base de données pour travailler avec des données BSON. Une fois installée, la pile permet d'analyser les données BSON et d'utiliser le moteur PostgreSQL pour construire des index, à l'aide non seulement des outils standard du moteur de base de données, mais aussi d'autres extensions. Le résultat est la capacité de fournir des index complexes qui supportent toutes sortes de requêtes. Une fonctionnalité utile est la possibilité d'utiliser les capacités d'indexation vectorielle de PostgreSQL pour construire ses données BSON dans une application de génération augmentée de récupération (RAG) ou d'utiliser les recherches des plus proches voisins pour construire des moteurs de recommandation ou identifier des schémas de fraude. Une base de données NoSQL avec de nombreuses options d'indexation différentes peut s’avérer très utile, car elle donne les bases nécessaires pour de nombreux types d'applications différentes, tout en travaillant sur le même ensemble de données.

Démarrer avec DocumentDB

Cette première version publique de DocumentDB hérite d'un code fonctionnant déjà dans Azure. Elle est donc prête à être construite et utilisée, hébergée sur GitHub. Les instructions du wiki du projet se concentrent sur l'utilisation de VS Code et de Docker pour construire sur WSL 2.0, même si l’on peut utiliser n'importe quel Linux via le moteur distant de VS Code. Tout commence par la construction du conteneur, suivie par la création, l’installation et le lancement des binaires. Le conteneur DocumentDB contient déjà PostgreSQL, donc une fois l'installation terminée, il est possible de se connecter à son shell et de commencer à expérimenter le support BSON.

Depuis l'interpréteur de commandes, il est possible d’intégrer des appels API dans des instructions select et d'expérimenter ainsi les opérations avant de les ajouter aux appels de code. Le shell permet de créer des collections, d'ajouter des éléments et d'expérimenter des opérations CRUD. D'autres opérations rendent possible l’application de filtres et la prise en charge des requêtes, ainsi que la création d’index sur un ou plusieurs champs d'une collection. Le wiki du projet inclut une longue liste de fonctions API documentées, regroupées en ensembles d'opérations communes. Pour l'instant, le wiki GitHub est la principale source de documentation pour DocumentDB. Il est un peu mince et pourrait contenir plus d'exemples. Cependant, DocumentDB est actuellement destiné aux développeurs qui cherchent une alternative à MongoDB, utilisable avec une licence open source plutôt qu'une licence dite source available au sens de source disponible. Pour l'instant, l’absence de SDK oblige à créer ses propres appels à l'API. Celles-ci étant basées sur MongoDB, le portage des applications ne devrait pas être trop complexe.