Forum Aux Questions sur Azure Cosmos DB

Azure Cosmos DB convient particulièrement aux cas d’usage suivants : web, mobile, gaming et IoT. Dans ces cas d’usage, la mise à l’échelle automatique, les performances prévisibles, les temps de réponse rapides de l’ordre d’une milliseconde et la capacité à exécuter des requêtes sur des données sans schéma sont importants. Azure Cosmos DB permet un développement rapide et prend en charge l’itération continue des modèles de données d’application. Les applications qui gèrent du contenu et des données générés par l’utilisateur figurent souvent parmi les cas d’usage courants d’Azure Cosmos DB.

Dans Azure Cosmos DB, la mesure du débit est exprimée en unités de requête (RU). Un débit d’une unité de requête correspond au débit de l’action HTTP GET pour un document de 1 kilo-octet. Chaque opération dans Azure Cosmos DB, y compris les lectures, écritures, requêtes et exécutions de procédures stockées, comporte une valeur d’unité de requête déterministe basée sur le débit nécessaire à l’exécution de l’opération. Au lieu d’être obligé de mettre en relation le processeur, les E/S et la mémoire avec le débit de votre application, vous pouvez réfléchir en termes d’unités de requête.

Vous pouvez configurer chaque conteneur Azure Cosmos DB avec un débit approvisionné en termes d’unités de requête par seconde (RU/s). Vous pouvez évaluer des requêtes individuelles en les mesurant en unités de requête et créer un conteneur pour gérer la somme des unités de requête sur l’ensemble des requêtes pour ce conteneur en une seconde. Vous pouvez également mettre à l’échelle le débit de votre conteneur à mesure de l’évolution des besoins de votre application. Pour plus d’informations sur la façon de mesurer les unités de requête, consultez la calculatrice de débit.

Les modèles de données clé/valeur (table), en colonnes, document et graphe sont tous pris en charge de manière native en raison de la conception ARS (atomes, enregistrements et séquences) sur laquelle repose Azure Cosmos DB. Les atomes, enregistrements et séquences peuvent facilement être mappés et projetés vers différents modèles de données. Les API d’un sous-ensemble de modèles sont disponibles à l’aide de la conception ARS (MongoDB, NoSQL, Table, Apache Cassandra et Apache Gremlin). Azure Cosmos DB prend également en charge d’autres API.

Un conteneur est un groupe d’éléments. Les conteneurs peuvent s’étendre sur une ou plusieurs partitions et peuvent être mis à l’échelle pour gérer des volumes de stockage ou de débit pratiquement illimités.

Un conteneur est une entité facturable dont le débit et le stockage utilisé déterminent le coût. Chaque conteneur est facturé à l’heure, sur la base du débit provisionné et de l’espace de stockage utilisé. Pour plus d’informations, consultez la Tarification d’Azure Cosmos DB.

Azure Cosmos DB est le service de base de données multi-modèle de Microsoft distribué à l’échelle mondiale. Le terme « multimodèle » fait référence au fait qu’Azure Cosmos DB prend en charge plusieurs API et modèles de données. Dans ce paradigme, différentes API utilisent des formats de données différents pour le stockage et le protocole filaire. Par exemple, NoSQL utilise JSON, MongoDB utilise JSON avec codage binaire (BSON), Table utilise Entity Data Model (EDM), Cassandra utilise Cassandra Query Language (CQL) et Gremlin utilise le format JSON. Par conséquent, nous vous recommandons d’utiliser la même API pour tous les accès aux données d’un compte spécifique.

Oui. Les API Azure Cosmos DB permettent une intégration directe. Par exemple, les API REST Azure Cosmos DB peuvent être intégrées à la Gestion des API Azure pour les opérations CRUD, ce qui évite d’avoir à utiliser des services intermédiaires comme Azure Functions.

Oui, Azure Cosmos DB est conforme à la loi HIPAA. HIPAA établit les conditions requises pour l’utilisation, la divulgation et la protection des informations de santé identifiables de façon individuelle. Pour plus d’informations, consultez le Centre de gestion de la confidentialité de Microsoft.

Il n’existe aucune limite à la quantité totale de données qu’un conteneur peut stocker dans Azure Cosmos DB.

Il n’existe aucune limite au débit total qu’un conteneur peut prendre en charge dans Azure Cosmos DB. L’idée centrale est de répartir votre charge de travail à peu près uniformément entre un nombre suffisant de clés de partition.

Oui, les deux modes sont toujours entièrement chiffrés.

Le nombre de conteneurs approvisionnés, le nombre d’heures pendant lesquelles les conteneurs sont en ligne et le débit approvisionné pour chaque conteneur déterminent les frais d’utilisation d’Azure Cosmos DB. Pour plus d’informations sur les prix, consultez Tarification Azure Cosmos DB.

Pour poser une question technique, connectez-vous à l’un de ces forums de questions-réponses :

• Microsoft Q&A (questions et réponses)
• Stack Overflow. Consultez Stack Overflow pour les questions sur la programmation. Fournissez autant de détails que possible, ce qui rend la question claire et accessible.

Pour résoudre un problème relatif à votre compte, enregistrez une demande de support sur le portail Azure.

Vous devez d’abord souscrire un abonnement Microsoft Azure. Après avoir souscrit un abonnement Azure, vous pouvez ajouter un conteneur d’API NoSQL à votre abonnement Azure.

Des kits de développement logiciel (SDK) sont disponibles pour .NET, Python, Node.js, JavaScript, Go et Java. Les développeurs peuvent également utiliser les API REST pour interagir avec les ressources Azure Cosmos DB sur un plus grand nombre de plateformes et dans un plus grand nombre de langages.

Consultez ces exemples de code et modèles de démarrage rapide pour l’API NoSQL :

• .NET
• Python
• Node.js / JavaScript
• Java/Spring
• Allez

Oui, l’API NoSQL permet aux applications de stocker des documents JSON arbitraires sous forme d’éléments sans définitions de schéma ni indicateurs. Les données peuvent être interrogées immédiatement avec le langage de requête Azure Cosmos DB for NoSQL.

Oui, l’API NoSQL prend en charge les transactions entre documents exprimées à l’aide de lots dans les SDK ou sous forme de déclencheurs et de procédures stockées JavaScript. Les transactions sont étendues à une seule partition au sein de chaque conteneur, et exécutées en mode « Tout ou rien » avec des sémantiques ACID, isolément d’autres codes et requêtes utilisateur s’exécutant simultanément. Si des exceptions surviennent, l’ensemble de la transaction est annulée.

Vous pouvez créer des bases de données à l’aide de l’un de ces outils :

• portail Azure
• SDK (plan de données) clients de l’API NoSQL
  • .NET
  • Python
  • JavaScript
  • Java
  • Allez
• SDK (plan de contrôle) de gestion de l’API NoSQL
  • .NET
  • Python
  • JavaScript
  • Java
  • Allez
• Azure Resource Manager
  • Modèle JSON
  • Bicep
  • Terraform
• REST API

Yes! Azure Cosmos DB prend en charge l’authentification Microsoft Entra pour gérer le service et ses ressources (plan de contrôle) et exécuter des données, des opérations et des requêtes (plan de données). L’authentification pour le plan de contrôle s’effectue à l’aide de la fonctionnalité de contrôle d’accès en fonction du rôle d’Azure. Vous pouvez utiliser un rôle intégré préconfiguré](.. /.. /role-based-access-control/built-in-roles.md) ou créer un rôle personnalisé. Avec le contrôle d’accès en fonction du rôle Azure, vous pouvez gérer des comptes, des bases de données, des conteneurs et des métadonnées. Le plan de contrôle inclut notamment les exemples suivants d’opérations, sans s’y limiter.

• Création, remplacement ou suppression de bases de données – Création, remplacement ou suppression de conteneurs – Lecture ou remplacement de débit de base de données – Lecture ou remplacement de débit de conteneur. L’authentification de plan de données utilise une API personnalisée pour l’implémentation du contrôle d’accès en fonction du rôle natif NoSQL. Avec cette implémentation native, vous pouvez également utiliser des rôles préconfigurés ou personnalisés. Avec le contrôle d’accès en fonction du rôle natif, vous pouvez exécuter des requêtes, gérer des éléments ou effectuer d’autres opérations courantes. Le plan de données inclut notamment les exemples suivants d’opérations, sans s’y limiter.
• Création, remplacement, mise à jour ou suppression d’éléments – Mise à jour corrective d’éléments – Exécution de requêtes

Le langage SQL (Structured Query Language) est généralement utilisé pour interroger des données relationnelles. L’API NoSQL propose un langage de requête NoSQL personnalisé, dérivé de SQL. Le langage de requête NoSQL comprend un sous-ensemble du langage de requête SQL généralement associé à SQL Server ainsi que diverses améliorations propres à NoSQL. Le langage de requête NoSQL fournit des opérateurs relationnels et hiérarchiques enrichis ainsi qu’une extensibilité par le biais de fonctions JavaScript définies par l’utilisateur. La grammaire JSON permet de modéliser des documents JSON en tant qu’arborescences comprenant des nœuds étiquetés qui sont utilisés par les techniques d’indexation automatique et le langage de requête SQL d’Azure Cosmos DB. Pour savoir comment utiliser ce langage de requête, consultez Requête NoSQL.

L’API NoSQL prend en charge l’agrégation via des fonctions d’agrégation telles que : COUNT, MAX, AVG et SUM via le langage de requête NoSQL.

L’API NoSQL prend en charge le contrôle d’accès concurrentiel optimiste par le biais des balises d’entité HTTP, ou ETags. Chaque ressource de l’API NoSQL est dotée d’une ETag qui est définie sur le serveur à chaque mise à jour d’un document. L’en-tête et la valeur actuelle ETag sont inclus dans tous les messages de réponse. Les ETag peuvent être utilisées avec l’en-tête If-Match pour permettre au serveur de déterminer si une ressource nécessite une mise à jour. La valeur If-Match est la valeur ETag utilisée pour la vérification. Si la valeur ETag correspond à la valeur ETag du serveur, la ressource est mise à jour. Si l’ETag n’est plus actuelle, le serveur rejette l’opération en retournant un code de réponse « HTTP 412 Échec de la condition préalable ». Dans ce cas, le client extrait à nouveau la ressource afin d’obtenir la valeur ETag actuelle pour la ressource. De plus, les ETags peuvent être utilisés avec l’en-tête If-None-Match pour déterminer si la nouvelle extraction d’une ressource est nécessaire.

La plupart des SDK de l’API NoSQL comportent des classes destinées à gérer le contrôle d’accès concurrentiel optimiste.

Utilisez la fonctionnalité d’importation en bloc qui se trouve dans le SDK .NET ou le SDK Java pour l’API NoSQL pour importer des jeux de données volumineux. Cette fonctionnalité optimise le débit approvisionné pour importer des jeux de données volumineux.

Vous pouvez également utiliser Apache Spark pour importer des données à grande échelle à l’aide de Python ou Scala.

Oui. Azure Cosmos DB for NoSQL étant un service RESTful, les liens de ressource sont immuables et peuvent être mis en cache. Les clients de l’API NoSQL peuvent spécifier un en-tête « If-None-Match » pour des lectures effectuées en comparaison avec des documents ou conteneurs de type ressource, puis mettre à jour leurs copies locales après modifications de la version du serveur.

Oui. L’émulateur Azure Cosmos DB fournit une émulation haute fidélité du service Azure Cosmos DB. Il prend en charge des fonctionnalités identiques à Azure Cosmos DB dans différentes API. Parmi ces fonctionnalités figurent la prise en charge de la création et de l’interrogation d’éléments et celle de l’approvisionnement et de la mise à l’échelle de conteneurs. Vous pouvez développer et tester des applications en utilisant les points de terminaison de l’émulateur. Vous pouvez ensuite déployer les applications sur Azure à une échelle globale en modifiant la chaîne de connexion de l’émulateur vers le service en direct.

Cette limitation de l’Explorateur de données est une limitation de JavaScript. JavaScript utilise des nombres à virgule flottante double précision comme spécifié dans la norme 754 de l’IEEE (Electrical and Electronics Engineers). Ce type de données peut contenir sans risque des nombres compris entre -(2⁵³ - 1) et 2⁵³-1 (autrement dit, 9007199254740991) uniquement.

Le contrôle d’accès en fonction du rôle (RBAC) est une méthode de régulation de l’accès aux ressources informatiques ou réseau en fonction des rôles des utilisateurs individuels au sein d’une entreprise. Dans Azure Cosmos DB, le RBAC est utilisé pour accorder l’accès au plan de données aux utilisateurs et aux applications. Pour en savoir plus sur les différents termes dans le contrôle d’accès en fonction du rôle, consultez le glossaire de sécurité.

Utilisez la fonctionnalité de contrôle d’accès en fonction du rôle natif (RBAC) Azure Cosmos DB pour accorder l’accès au plan de données aux utilisateurs et aux applications. Pour plus d’informations, consultez Octroi d’accès en fonction du rôle au plan de données.

À partir de maintenant, seule l’API NoSQL est prise en charge.

La prise en charge de la gestion du rôle par le portail Azure n’est pas encore disponible.

Les SDK .NET V3, Java V4, JavaScript V3 et Python V4.3+ sont actuellement pris en charge.

Oui.

Oui. Pour plus d’informations, consultez Désactiver l’authentification par clé.

Les instructions générales pour migrer un compte Cosmos DB vers un autre groupe de ressources ou un autre abonnement sont décrites dans le déplacement des ressources Azure vers un nouveau groupe de ressources ou un nouvel article d’abonnement .

Une fois que vous avez correctement déplacé le compte Azure Cosmos DB conformément aux instructions générales, toutes les identités (System-Assigned ou User-Assigned) associées au compte doivent être réaffectées. Cette réaffectation est requise pour garantir que ces identités continuent d’avoir les autorisations nécessaires pour accéder à la clé Key Vault.

Si votre compte Cosmos DB a les clés CMK d’activées, vous ne pouvez migrer le compte que s’il s’agit d’un compte de clé géré par le client entre locataires. Pour plus d’informations, consultez le guide sur la configuration des clés gérées par le client entre locataires pour votre compte Azure Cosmos DB avec Azure Key Vault.

Lors de la migration du mode périodique vers le mode continu, vous ne pouvez pas exécuter d’opérations de plan de contrôle qui effectuent des mises à jour ou des suppressions au niveau du compte. Par exemple, les opérations telles que l’ajout ou la suppression de régions, le basculement de compte, la mise à jour de la stratégie de sauvegarde, etc. ne peuvent pas être exécutées pendant la migration. Le temps de migration dépend de la taille des données et du nombre de régions de votre compte. L’action de restauration sur les comptes migrés réussit uniquement à partir du moment où la migration se termine correctement.

Vous pouvez restaurer votre compte une fois la migration terminée. Si la migration se termine à 13h00 PST, vous pouvez effectuer une restauration à un point dans le temps à partir de 1:00 PST.

Oui.

Les comptes d’API pour NoSQL, d’API pour Table, d’API Gremlin et d’API pour MongoDB qui utilisent un débit partagé, approvisionné ou approvisionné avec mise à l’échelle automatique prennent en charge la migration vers la sauvegarde continue.

Les comptes avec Azure Synapse Link activés ou qui ont désactivé Azure Synapse Link pour une ou plusieurs collections ne peuvent pas migrer vers une sauvegarde continue.

La migration prend un temps variable qui dépend en grande partie de la taille des données et du nombre de régions de votre compte. Vous pouvez obtenir l’état de la migration à l’aide d’Azure CLI ou de commandes PowerShell. Pour les comptes volumineux avec des dizaines de téraoctets de données, la migration peut prendre jusqu’à quelques jours.

Oui, cette migration prend du temps qui dépend en grande partie de la nécessité d’attendre que toutes les anciennes écritures provisoires se vident pendant la migration de sauvegarde continue. Vous pouvez obtenir l’état de la migration à l’aide d’Azure CLI ou de commandes PowerShell. Pour les comptes volumineux avec des dizaines de téraoctets de données, la migration peut prendre jusqu’à quelques jours.

Non, l’opération de migration a lieu en arrière-plan. Par conséquent, les demandes clientes ne sont pas affectées. Toutefois, nous devons effectuer certaines opérations back-end pendant la migration, et cela peut prendre du temps supplémentaire si le compte est soumis à une charge importante.

Une fois le processus de migration démarré, le compte est activé en mode continu. Si la migration échoue, vous devez relancer la migration jusqu’à ce qu’elle réussisse.

Supposons que vous avez démarré la migration à t1 et terminé à l’étape t5, vous ne pouvez pas utiliser d’horodatage de restauration entre t1 et t5. Supposons également que votre compte est désormais en mode continu. Pour effectuer une restauration à un moment après t5, effectuez la restauration à l’aide du portail Azure, de l’interface CLI ou de PowerShell comme normalement avec un compte continu. Cette demande de restauration en libre-service ne peut être effectuée qu’une fois la migration terminée. Pour effectuer une restauration à une heure antérieure t1, vous pouvez ouvrir un ticket de support comme vous le feriez normalement avec un compte de sauvegarde périodique. Après la migration, vous avez jusqu’à 30 jours pour effectuer la restauration périodique. Au cours de ces 30 jours, vous pouvez effectuer une restauration en fonction de la rétention/intervalle de sauvegarde de votre compte avant la migration. Par exemple, si la sauvegarde a été configurée pour conserver 24 copies à intervalles d’une heure, vous pouvez restaurer à tout moment entre (t1 – 24 hours) et t1.

Les opérations telles que l’ajout/suppression de région, le basculement, la modification de la stratégie de sauvegarde et les modifications de débit résultant du déplacement des données sont bloquées lors de la migration.

La migration défaillante ne bloque aucune opération du plan de contrôle. En cas d’échec de la migration, réessayez jusqu’à ce qu’elle réussisse avant d’effectuer d’autres opérations de plan de contrôle.

Il n’est pas possible d’annuler la migration, car les migrations ne sont pas une opération réversible. L’équipe peut annuler temporairement et laisser les opérations hors connexion continuer, par le biais d’un appel d’assistance. Mais on ne peut pas revenir à l’état de sauvegarde périodique.

Il n’existe pas d’outil pour estimer le temps. Nos exécutions de test et d’échelle indiquent qu’un compte avec 1 To de données prend environ 90 minutes. Pour les comptes multirégions, calculez la taille totale des données en tant que Number_of_regions * Data_in_single_region.

Testez la fonctionnalité de mode de sauvegarde continue pour vérifier qu’elle fonctionne comme prévu avant de migrer des comptes de production. La migration est une opération unidirectionnelle et ne peut pas être inversée.

Oui, vous pouvez vous inscrire à un compte de base de données gratuit avec 1 000 RU/s et 25 Go gratuitement.

Si vous débutez avec Azure, vous pouvez vous inscrire pour bénéficier d’un compte Azure gratuit, qui vous donne 30 jours et un crédit pour essayer tous les services Azure. Si vous avez un abonnement Visual Studio, vous pouvez aussi bénéficier de crédits Azure gratuits à utiliser sur n’importe quel service Azure.

Vous pouvez également utiliser l’émulateur Azure Cosmos DB pour développer et tester votre application localement, sans créer d’abonnement Azure et sans frais. Lorsque vous êtes satisfait du fonctionnement de votre application dans l’émulateur Azure Cosmos DB, vous pouvez commencer à utiliser un compte Azure Cosmos DB dans le cloud.

Azure Cosmos DB est disponible dans le portail Azure. Tout d’abord, souscrivez un abonnement Azure. Une fois que vous êtes inscrit, ajoutez un compte Azure Cosmos DB à votre abonnement Azure.

Utilisez l’ID Microsoft Entra pour vous authentifier auprès d’Azure Cosmos DB pour toutes les API qui prennent en charge cette méthode d’authentification. Pour les API qui ne prennent pas en charge l’authentification Microsoft Entra ID, utilisez les clés avec précaution. Vérifiez que les clés des comptes de production sont stockées en toute sécurité, comme dans Azure Key Vault.

Pour plus d’informations sur la disponibilité régionale d’Azure Cosmos DB, consultez Disponibilité des produits Azure par région. Vous pouvez connecter votre base de données à une ou plusieurs de ces régions.

Les Kits de développement logiciel (SDK) pour Azure Cosmos DB autorisent la configuration des régions qu’ils utilisent pour les connexions. Dans la plupart des SDK, la valeur « PreferredLocations » est définie sur l’une des régions Azure dans lesquelles Azure Cosmos DB est disponible.

Azure Cosmos DB est présent dans toutes les régions Azure, comme l’indique la page Régions Azure. Comme il s’agit d’un service Azure principal, chaque nouveau centre de données a une présence Azure Cosmos DB.

Lorsque vous définissez une région, n’oubliez pas qu’Azure Cosmos DB respecte les clouds souverains et du secteur public. Par exemple, vous ne pouvez pas répliquer de données hors d’une région souveraine. De même, vous ne pouvez pas activer la réplication dans d’autres emplacements souverains à partir d’un compte externe.

Le provisionnement de débit au niveau du conteneur et de la base de données est des offres distinctes et le basculement entre l’une de ces offres nécessite la migration des données de la source vers la destination. Vous devez créer une base de données ou un conteneur, puis migrer les données avec la bibliothèque de l’exécuteur en bloc ou Azure Data Factory.

Oui, Azure Cosmos DB prend en charge l’analyse des séries chronologiques. Vous pouvez utiliser le flux de modification pour créer des vues agrégées sur les données de séries chronologiques. Vous pouvez étendre cette approche à l’aide d’Apache Spark Streaming ou d’un autre processeur de données de flux.

Pour obtenir des informations, consultez les quotas de service et les limites de débit.

Contenu connexe

• Questions fréquentes sur Azure Cosmos DB for NoSQL
• Questions fréquentes sur Azure Cosmos DB for MongoDB
• Questions fréquentes sur Azure Cosmos DB for Apache Gremlin
• Questions fréquentes sur Azure Cosmos DB for Apache Cassandra
• Questions fréquentes sur Azure Cosmos DB for Table