Cosmo DB : Microsoft dope DocumentDB aux modèles graphes et clé-valeur
L’éditeur a présenté Cosmo DB, une base NoSQL dans le Cloud qui reprend les API de DocumentDB et MongoDB pour y adjoindre les modèles de graphes et Table Storage d’Azure. Microsoft y associe un modèle de cohérence de données plus granulaire.
D’un service de base NoSQL géo-répliqué vers un service NoSQL multi-modèles et multi-API. Microsoft a profité de sa conférence Build 2017, qui s’est tenue la semaine dernière à Seattle, pour présenter une extension majeure de DocumentDB, son service de base Azure NoSQL, lancé en 2014. A ce service, devenu populaire tant en interne que chez des développeurs, Microsoft y a désormais adjoint des API pour gérer les très tendances graphes ainsi que celles de Tables Storage, le modèle clé-valeur proposé depuis le portail Azure. Cet ensemble aura désormais pour nom Cosmo DB.
Avec Cosmo DB, Microsoft entend reprendre là où il s’était arrêté avec DocumentDB : une base de données NoSQL, qui absorbe de grands volumes de données sans schéma pré-définis et supporte logiquement JSON et Javascript pour cela. Le tout, reposant sur une architecture dite géo-répliquée, dont la vocation est de proposer des replicas de données au plus proche des utilisateurs.
Cette base avait certes projeté l’éditeur de Redmond dans ce monde NoSQL Cloud, alors que l’ensemble des acteurs du secteur épinglait à leur catalogue une référence, de préférence dans le Cloud.
Toutefois, avec l’émergence de bases de données 100% Cloud conçues pour motoriser ces applications Cloud Natives, certains fournisseurs de technologies ont perçu les limites d’un modèle unique. Ces applications nécessitent en effet d’avoir accès à toutes formes de données, quels que soient leurs modèles, leurs formats, leur stockage et leur géographie. Autre avantage : ne plus avoir à recourir à de nombreux ETL (Extract, Transform and Load) pour répondre à chaque cas d’usage.
Cosmo DB vient ainsi s’insérer dans cette approche et constitue une porte d’entrée pour stocker et requêter plusieurs modèles de données (clé-valeur, en colonnes, graphes et documents) via plusieurs types d’API : celles de MongoDB et de DocumentDB (avec SQL) et désormais avec Gremlin pour les graphes et Table Storage (clé-valeur) – ces deux derniers étant encore en mode Preview.
Gremlin est en fait un langage de requêtes standard, développé au sein de TinkerPop, un projet de traitement des graphes, hébergé par la fondation Apache. Celui-ci permet d’interroger directement les transactions modélisées dans des graphes (autrement dit en vertex – une entité- ; et en edge – qui relie deux vertex). Par exemple, Gremlin est aussi implémenté par DataStax dans sa base graphe, intégrée à DataStax Enterprise.
Table Storage correspond quant à lui au service de stockage clé-valeur d’Azure. Les API standard peuvent désormais être consommées depuis Cosmo DB, mais Microsoft travaille également à une option avancée et optimisée en termes de stockage et performances.
La cohérence de données : nouveau cheval de bataille des bases Cloud
L’autre point clé de Cosmo DB est sa capacité à pouvoir proposer une cohérence des données plus granulaire que traditionnellement. Cet aspect (le C du théorème de CAP) est la garantie que la donnée affichée est cohérente quelle qu’en soit son itération. Seulement avec le NoSQL, cette cohérence peut fluctuer en fonction des bases… et le développeur doit trouver ainsi un compromis entre cohérence, disponibilité et tolérance au partionnement des données, pour répondre au plus près des spécificités de son application.
Cosmo DB propose certes des possibilités de cohérence « forte » et « éventuelle », mais ajoute trois autres options intermédiaires : « Bounded-Staleness » ; « Session » ; « Consistent Prefix » - de la moins cohérente à la plus cohérente. Ces options ont été identifiées par Microsoft comme certaines des plus utilisées dans la réalité. Selon la documentation Microsoft, le modèle de cohérence est associé à un compte Cosmo DB et est donc fixé en amont des développements. Cette approche diffère par exemple de celle de Cassandra où cette notion est fixée dans le code, au travers de la requête.
