Qu'est-ce que cela signifie que Azure Cosmos DB est multi-modèle?
En regardant la nouvelle base de données Azure Cosmos, je suis un peu confus quant à sa nature multi-modèle. Plus précisément, cela signifie-t-il:
a) Que la même base de données/magasin sous-jacente puisse être interrogée de plusieurs manières simultanément afin que je puisse utiliser à la fois les requêtes de graphes gremlin et les API mongodb sur les mêmes collections.
- ou -
b) Cela signifie-t-il que vous pouvez choisir un modèle différent (graphique, valeur de clé, colonne, document) au moment de la mise en service de votre base de données Cosmos et que les données seront ensuite stockées?
La brochure donne l’impression d’un a), mais si vous utilisez le tableau de bord Azure pour créer une instance de cosmos, c’est comme si vous deviez choisir b) puisque vous devez choisir un type de modèle lors de la création.
De plus, la littérature fait référence à des données en colonnes, mais je ne vois pas l'option pour cela au moment de la création.
Cosmos DB est un moteur de données NoSQL unique, une évolution de Document DB. Lorsque vous créez un conteneur ("instance de base de données"), vous choisissez l'API la plus pertinente pour votre cas d'utilisation, ce qui optimise la façon dont vous interagissez avec le magasin de données sous-jacent et la façon dont les données sont conservées dans ce magasin.
Ainsi, selon l’API choisie, le modèle souhaité (graphique, colonne, valeur de clé ou document) est projeté sur le magasin sous-jacent.
Vous ne pouvez utiliser qu'une seule API par conteneur, plusieurs ne sont pas possibles en raison du mode de stockage et de récupération des données. L'API dicte le modèle de stockage - graphique, valeur de clé, colonne, etc., mais ils correspondent tous à la même technologie sous le capot.
Grâce au commentaire de @ Jesse Carter ci-dessous, il semble que vous puissiez mélanger et faire correspondre le graphique et les API DocumentSQL.
Prise en charge de plusieurs modèles et de plusieurs API
Azure Cosmos DB prend en charge de manière native plusieurs modèles de données, notamment des documents, des valeurs-clés, des graphiques et des familles de colonnes. Le modèle de contenu principal du moteur de base de données de Cosmos DB est basé sur la séquence atom-record-sequence (ARS). Les atomes consistent en un petit ensemble de types primitifs tels que string, bool et number. Les enregistrements sont des structures composées de ces types. Les séquences sont des tableaux constitués d'atomes, d'enregistrements ou de séquences . Le moteur de base de données peut efficacement traduire et projeter différents modèles de données sur le modèle de données basé sur ARS. Le modèle de données de base de Cosmos DB est nativement accessible à partir de langages de programmation à typage dynamique et peut être exposé tel quel en JSON.
Le service prend également en charge les API de base de données populaires pour l’accès aux données et les requêtes. Le moteur de base de données de Cosmos DB prend actuellement en charge DocumentDB SQL, MongoDB, les tables Azure (prévisualisation) et Gremlin (prévisualisation). Vous pouvez continuer à créer des applications à l'aide des API OSS populaires et bénéficier de tous les avantages d'un service de base de données réparti à l'échelle mondiale, entièrement géré et testé.
Cosmos DB est une base de données géographiquement distribuée avec son propre moteur de stockage Atom-Record-Sequence et son index. En plus de cette infrastructure, nous sommes en mesure d'implémenter de nombreux types de magasins, de SQL à l'API SQL en passant par Mongo, Cassandra, Gremlin, une implémentation du stockage Azure Table, etc.
Chaque type de magasin a son propre type de données (par exemple, une manière de coder des nombres, des dates, etc.) et est codé dans notre couche de stockage et notre couche d’index à leur manière. Avec le temps, nous nous attendons à ce que la plupart de ces types de données soient pris en charge de manière native par notre API SQL. Mais pour l'instant, chacun de nos types de base de données utilise ses propres conventions de codage. Lors de la création d'un compte dans Cosmos DB (il s'agit d'une unité d'organisation, les utilisateurs peuvent avoir plusieurs comptes), le "type" de la base de données est spécifié sur le compte. Donc, on peut avoir un compte API Table ou un compte Mongo ou ce que vous avez.
Dans certains cas, il est possible d'accéder à un compte avec le type de données X à l'aide de l'API Y. Par exemple, il est possible d'utiliser l'API SQL pour parler aux tables d'un compte API de table. Mais en dehors du graphique, ce n'est généralement pas une bonne idée. À l'heure actuelle, nous codons les informations relatives à chaque API dans un format spécial et les différents types de données ne parlent pas les formats les uns des autres. Donc, si vous deviez écrire dans une API de table à l'aide de l'API SQL, le résultat final serait très probablement des données corrompues.
L'exception est le graphique sur lequel nous travaillons fort pour nous assurer que nous travaillons raisonnablement bien avec tous les types de bases de données, et nous aurons plus à dire à ce sujet à l'avenir.
Donc, si vous voulez jouer avec l'accès multi-API, nous vous encourageons vivement à le faire en mode "lecture seule" uniquement lorsque vous n'utilisez pas l'API "native" pour le compte donné. En d'autres termes, bien entendu, jouez avec l'API SQL lue à partir d'une API Table, veuillez simplement ne pas écrire sur un compte API Table utilisant un client API SQL.
La réponse acceptée manque sur certains points.
Cosmos DB est une base de données NoSQL, mais elle est très distribuée et son format de stockage est Atom-Record-Sequence.
Pourquoi est-ce important? Nous savons qu'il accepte JSON comme formats d'entrée et de sortie. Cela ne signifie pas que Cosmos stocke ses données au format JSON, il pourrait s'agir de n'importe quel format. Cela nous aide à raisonner sur le caractère multimodal de Cosmos: ce que vous obtenez lorsque vous exécutez une requête selon un certain modèle est probablement une projection ou une vue de vos données.
@JesseCarter a déjà expliqué que nous pouvons utiliser indifféremment l'API Document et l'API Graph. La semaine dernière, l’API Table a été annoncée publiquement et cette API n’est probablement pas si différente non plus.
Les gars de Spectologic ont écrit un article sur Nice sur l'utilisation de Cosmos par plusieurs API et ont également souligné que le multimodalisme est plus cosmétique que interne, la seule exception réelle semble être celle de Mongo. La partie intéressante est soulignée dans le chapitre "Changer l'expérience du portail" ici: https://blog.spectologic.com/2017/06/30/digging-into-cosmosdb-storage/
Alors peut-être qu’en fin de compte, cela revient à GlobalDocumentDb contre MongoDb
Si vous êtes intéressé par les détails d'implémentation de CosmosDB, vous pouvez lire ce livre blanc depuis longtemps (à condition que l'implémentation n'ait pas changé). http://www.vldb.org/pvldb/vol8/p1668-shukla.pdf
TLDR:
- En bas, CosmosDB stocke les données dans ARS et les expose au format JSON.
- Le moteur de base de données indexe TOUS les champs de TOUS les documents par défaut, permettant ainsi une requête très flexible.
- Le moteur de base de données exécute un langage intermédiaire similaire à JavaScript, reliant le stockage de bas niveau et les API exposés par la base de données.
- En raison de ce pontage, davantage d'API de base de données peuvent être ajoutées pour prendre en charge différents mécanismes de requête (par exemple, SQL, document, colonne).
Moi aussi, je suis intrigué par cela, je veux en savoir plus du point de vue de l’audit de l’utilisation des API et en avoir appris plus en lisant ces réponses.
Après l'expérimentation, il semble que les choses ont progressé plus loin que les réponses originales, ajoutons donc une touche contemporaine ...
J'ai réussi à créer un compte de base de données Cosmos en choisissant l'API SQL, créé un document dans le portail, puis extrait le document via l'API MongoDB.
Les réponses originales suggéraient que MongoDB était un périphérique impair et ne pouvait pas interagir avec les données créées avec d'autres API.
Déterminez si, avec les tests plus complets, les documents sont corrompus en raison des différences de types de données évoquées par Yaron ( https://stackoverflow.com/a/48286729/141022 ) et si les différences de stockage entraînent de mauvaises performances toujours comme allusion à cela doit être vu.
Pour ce qui est de mon propos, je voudrais savoir si l'audit d'une API est suffisant. Dans ce cas, ce ne sont pas des données créées dans l'une qui peuvent être récupérées par une autre. Je n'ai donc pas effectué de tests approfondis.
Notamment, le modèle ARM ne se déploie ni de type GlobalDocumentDB ni MongoDB. Toutefois, l'exportation du modèle ARM à partir du portail génère GlobalDocumentDB si cela fait une différence.
Multimodel signifie vos données peuvent être stockées de différentes manières . Actuellement, CosmosDB stocke 4 types de données différents et vous permet de l'intégrer à une API et de créer une expérience utilisateur autour de ces types de stockage de base de données. Les 4 types sont Base de données de documents ou base de données Mongo, base de données de graphes, valeur de clé clé et colonne large ou famille de colonnes .