Modifier

Partager via

Questions fréquentes sur Azure Cosmos DB for Table

  • FAQ

S’APPLIQUE À : Table

Comparaison d’Azure Cosmos DB for Table et de Stockage Table Azure

Quelles sont les différences de comportement entre l’API pour Table et le stockage Table Azure ?

Si vous avez déjà créé des tables dans le stockage Table Azure et que vous souhaitez passer à Azure Cosmos DB for Table, tenez compte des différences de comportement suivantes :

  • Azure Cosmos DB for Table utilise un modèle de capacité réservée pour garantir les performances. Que vous l’utilisez ou non, la capacité vous est donc facturée dès que la table est créée. Dans le cadre du stockage Table Azure, vous payez uniquement la capacité utilisée. Cela explique pourquoi l’API pour Table peut offrir un contrat de niveau de service (SLA) de 10 ms en lecture et de 15 ms en écriture au 99e centile, alors que le stockage Table Azure offre un SLA de 10 s. Même les tables vides sans requêtes des tables API pour Table engendrent donc des coûts pour assurer la disponibilité de la capacité et le traitement de toutes les requêtes selon les termes du SLA offert par Azure Cosmos DB.

  • Les résultats des requêtes retournés par l’API pour Table ne sont pas triés dans l’ordre des clés de ligne/partition, alors qu’ils le sont dans le stockage Table Azure.

  • Les clés de ligne ne peuvent pas dépasser 255 octets.

  • Les lots ne peuvent contenir que 2 Mo au maximum.

  • CORS n’est pas pris en charge.

  • Les noms des tables ne respectent pas la casse dans le Stockage Table Azure, alors qu’ils la respectent dans Azure Cosmos DB for Table.

  • Certains des formats internes Azure Cosmos DB pour les informations de codage, comme les champs binaires, ne sont actuellement pas aussi efficaces que souhaité. Par conséquent, des limitations inattendues sur la taille des données peuvent être observées. Par exemple, il n’est actuellement pas possible d’utiliser le méga-octet complet d’une entité de table pour stocker des données binaires, car l’encodage augmente la taille des données.

  • Les noms de propriétés d’entité ID, rid, etag et ResourceId sont réservés dans Azure Cosmos DB, et ils ne sont actuellement pas pris en charge.

  • TableQuery TakeCount n’est pas limité à 1 000.

  • En termes d’API REST, Stockage Table Azure (mais pas Azure Cosmos DB for Table) prend en charge les points de terminaison/options de requête suivants :

    Méthodes REST Option de point de terminaison/requête REST URL vers la documentation Explication Prises en charge dans le Stockage Table Pris en charge dans l’API pour Table
    GET, PUT /?Restype=service@comp=properties Définir les propriétés du service Table et Obtenir les propriétés du service Table Ce point de terminaison est utilisé pour définir les règles CORS, la configuration de Storage Analytics et les paramètres de journalisation. CORS n’est pas actuellement pris en charge, et l’analytique et la journalisation sont gérées différemment dans Azure Cosmos DB et dans les tables Stockage Azure. Oui Non
    OPTIONS /<table-resource-name> Requête de table CORS préliminaire Cette option fait partie de CORS, qui n’est pas pris en charge par Azure Cosmos DB pour l’instant. Oui Non
    GET /?Restype=service@comp=stats Obtenir les statistiques du service Table Fournit des informations sur la rapidité de la réplication des données entre un emplacement principal et un emplacement secondaire. Cette option est inutile dans Azure Cosmos DB puisque la réplication fait partie des écritures. Oui Non
    GET, PUT /mytable?comp=acl Obtenir la liste de contrôle d’accès de la table et Définir la liste de contrôle d’accès de la table Obtient et définit les stratégies d’accès stocké utilisées pour gérer les signatures d’accès partagé. Oui Non

  • Azure Cosmos DB for Table prend uniquement en charge le format JSON, pas le format ATOM.

  • Pour le kit SDK .NET en particulier, certaines classes et méthodes ne sont pas prises en charge par Azure Cosmos DB pour l’instant.

    • Classe CloudTableClient
      • \ServiceProperties
      • \ServiceStats
    • Classe CloudTable
      • SetPermissions
      • GetPermissions

Autres questions fréquentes

Ai-je besoin d’un nouveau kit SDK pour utiliser l’API pour Table ?

Non, les kits SDK de stockage existants doivent continuer de fonctionner. Toutefois, nous vous recommandons de vous procurer les derniers kits SDK pour optimiser la prise en charge et, dans de nombreux cas, améliorer les performances. Consultez la liste des langages disponibles dans Présentation d’Azure Cosmos DB for Table.

Quelle chaîne de connexion faut-il utiliser pour se connecter à l’API pour Table ?

La chaîne de connexion est :

DefaultEndpointsProtocol=https;AccountName=<AccountNamefromCosmosDB;AccountKey=<FromKeysPaneofCosmosDB>;TableEndpoint=https://<AccountName>.table.cosmosdb.azure.com

Vous pouvez obtenir la chaîne de connexion dans la page Chaîne de connexion du portail Azure.

Comment faire pour remplacer les paramètres de configuration des options de requête dans le kit SDK .NET pour l’API pour Table ?

Certains paramètres sont gérés sur la méthode de CreateCloudTableClient et d’autres par le biais du fichier app.config dans la section appSettings de l’application cliente. Pour plus d’informations sur les paramètres de configuration, voir Fonctionnalités d’Azure Cosmos DB.

Y a-t-il des changements pour les clients qui utilisent les kits SDK de stockage Table Azure existants ?

Aucun. Il n’y a aucune modification pour les clients existants ou nouveaux utilisant le Kit de développement logiciel (SDK) de stockage Table Azure existant.

Comment faire pour afficher les données de table qui sont stockées dans Azure Cosmos DB afin de les utiliser avec l’API pour Table ?

Vous pouvez utiliser le portail Azure pour parcourir les données. Vous pouvez également utiliser le code ou les outils de l’API pour Table mentionnés dans la réponse suivante.

Quels sont les outils qui fonctionnent avec l’API pour Table ?

Vous pouvez utiliser l’Explorateur Stockage Azure.

Les outils offrant la flexibilité nécessaire pour prendre une chaîne de connexion au format spécifié précédemment peuvent prendre en charge la nouvelle API pour Table. Vous trouverez une liste des outils de table dans la page Outils clients d’Azure Storage.

L’accès concurrentiel sur les opérations est-il contrôlé ?

Oui, l’accès concurrentiel optimiste est fourni via l’utilisation du mécanisme ETag.

Le modèle de requête OData est-il pris en charge pour les entités ?

Oui, l’API pour Table prend en charge les requêtes OData et LINQ.

Puis-je me connecter côte à côte au Stockage Table Azure et à Azure Cosmos DB for Table dans la même application ?

Oui, vous pouvez vous connecter en créant deux instances distinctes de CloudTableClient, chacune pointant vers son propre URI via la chaîne de connexion.

Comment faire pour migrer une application de stockage Table Azure existante vers cette offre ?

AzCopy est pris en charge.

Comment l’extension de la taille de stockage est-elle gérée pour ce service, par exemple, si je commence par « n » Go de données et que le volume de celles-ci passe à 1 To au fil du temps ?

Azure Cosmos DB est conçu pour offrir une capacité de stockage illimitée via l’utilisation de la mise à l’échelle horizontale. Le service peut surveiller votre stockage et en augmenter efficacement le volume.

Comment faire pour surveiller l’offre de l’API pour Table ?

Le volet Métriques de l’API pour Table permet de surveiller les requêtes et l’utilisation du stockage.

Comment calculer le débit dont j’ai besoin ?

Vous pouvez utiliser l’estimateur de capacité pour calculer le débit de table requis pour les opérations. Pour plus d’informations, voir Estimer les unités de requête et le stockage de données. En général, vous pouvez afficher votre entité au format JSON, et fournir les valeurs pour vos opérations.

Puis-je utiliser le kit SDK de l’API pour Table localement avec l’émulateur ?

Pas pour l'instant.

Mon application existante peut-elle fonctionner avec l’API pour Table ?

Oui, la même API est prise en charge.

Dois-je migrer mes applications de stockage Table Azure existantes vers le nouveau kit SDK si je ne souhaite pas utiliser les fonctionnalités de l’API pour Table ?

Non, vous pouvez créer et utiliser des ressources de stockage Table Azure existantes sans la moindre interruption. Cependant, si vous n’utilisez pas l’API pour Table, vous ne pouvez pas bénéficier de l’indexation automatique, de l’option de cohérence supplémentaire ou de la distribution mondiale.

Comment ajouter la réplication des données de l’API pour Table dans plusieurs régions Azure ?

Vous pouvez utiliser les paramètres de réplication globale du portail Azure Cosmos DB pour ajouter des régions appropriées pour votre application. Pour développer une application distribuée globalement, vous devez également ajouter votre application avec les informations PreferredLocation définies sur la région locale afin de bénéficier d’une faible latence de lecture.

Comment faire pour changer la région d’écriture principale du compte dans l’API pour Table ?

Vous pouvez utiliser le volet du portail de réplication globale d’Azure Cosmos DB pour ajouter une région, puis basculer vers la région requise. Pour des instructions, voir Développement avec des comptes Azure Cosmos DB multirégions.

Comment configurer mes régions de lecture préférées pour une faible latence lors de la distribution de mes données ?

Pour faciliter la lecture à partir de l’emplacement local, utilisez la clé PreferredLocation dans le fichier app.config. Pour les applications existantes, l’API pour Table génère une erreur si LocationMode est défini. Supprimez ce code, car l’API pour Table extrait ces informations du fichier app.config.

En quoi consistent les niveaux de cohérence dans l’API pour Table ?

Azure Cosmos DB adopte des compromis bien pensés entre cohérence, disponibilité et latence. Azure Cosmos DB offre cinq niveaux de cohérence aux développeurs de l’API pour Table. Vous pouvez donc choisir le modèle de cohérence approprié au niveau de la table, et effectuer des demandes individuelles lors de l’interrogation des données. Quand un client se connecte, il peut spécifier un niveau de cohérence. Vous pouvez changer le niveau à l’aide de l’argument consistencyLevel de CreateCloudTableClient.

L’API pour Table permet d’effectuer des lectures à faible latence avec l’option « Lire vos écritures » et le niveau de cohérence Obsolescence limitée par défaut. Pour plus d’informations, consultez Niveaux de cohérence.

Par défaut, Stockage de table Azure offre une Cohérence forte au sein d’une région et une Cohérence éventuelle dans les sites secondaires.

Azure Cosmos DB for Table offre-t-il davantage de niveaux de cohérence que le stockage Table Azure ?

Oui, pour plus d’informations sur la façon de tirer parti de la nature distribuée d’Azure Cosmos DB, voir Niveaux de cohérence. Des garanties étant fournies pour les niveaux de cohérence, vous pouvez utiliser ceux-ci en toute confiance.

Une fois la distribution globale activée, combien de temps faut-il pour répliquer les données ?

Azure Cosmos DB valide les données durablement dans la région locale, et envoie les données vers les autres régions immédiatement, en quelques millisecondes. Cette réplication dépend uniquement de la durée des boucles (RTT) du centre de données. Pour en savoir plus sur la fonctionnalité de distribution globale d’Azure Cosmos DB, voir Azure Cosmos DB : Un service de base de données mondialement distribué sur Azure.

Est-il possible de modifier le niveau cohérence des demandes de lecture ?

Azure Cosmos DB permet de définir le niveau de cohérence au niveau du conteneur (sur la table). Le kit SDK .NET vous permet de changer le niveau en fournissant la valeur de la clé TableConsistencyLevel dans le fichier app.config. Les valeurs possibles sont les suivantes : Forte, Obsolescence limitée, Session, Préfixe cohérent et Éventuelle. Pour plus d’informations, voir Niveaux de cohérence ajustables dans Azure Cosmos DB. L’idée clé est que vous ne pouvez pas définir un niveau de cohérence de requête HTTP supérieur à celui défini pour la table. Par exemple, vous ne pouvez pas définir le niveau de cohérence pour la table sur Éventuelle et le niveau de cohérence de requête sur Forte.

Comment l’API pour Table gère-t-elle le basculement en cas de défaillance d’une région ?

L’API pour Table utilise la plateforme mondialement distribuée d’Azure Cosmos DB. Pour vous assurer que votre application peut tolérer des temps d’arrêt de centre de données, activez au moins une région supplémentaire pour le compte dans le portail Azure Cosmos DB (voir Développement avec des comptes Azure Cosmos DB multirégions). Vous pouvez définir la priorité de la région à l’aide du portail (voir Developing with multi-region Azure Cosmos DB accounts (Développement avec des comptes Azure Cosmos DB multirégions)).

Vous pouvez ajouter autant de régions que vous le souhaitez pour le compte, et contrôler l’emplacement de basculement en indiquant une priorité. Pour utiliser la base de données, vous devez également fournir une application à cet emplacement. Si vous procédez de la sorte, vos clients ne subissent aucun temps d’arrêt. À la différence des autres kits SDK, la dernière version du kit SDK client .NET prend en charge l’hébergement automatique. Autrement dit, il peut détecter la région défaillante et basculer automatiquement vers la nouvelle région.

L’API pour Table prend-elle en charge les sauvegardes ?

Oui, l’API pour Table utilise la plateforme d’Azure Cosmos DB pour les sauvegardes. Les sauvegardes sont effectuées automatiquement. Pour plus d’informations, voir Sauvegarde et restauration en ligne automatiques avec Azure Cosmos DB.

L’API pour Table indexe-t-elle par défaut tous les attributs d’une entité ?

Oui, tous les attributs d’une entité sont indexés par défaut. Pour plus d’informations, voir Azure Cosmos DB : Stratégies d’indexation.

Cela signifie-t-il que je n’ai pas besoin de créer plusieurs index pour satisfaire les requêtes ?

Oui, Azure Cosmos DB for Table assure l’indexation automatique de tous les attributs sans aucune définition de schéma. Cette automatisation permet aux développeurs de se concentrer sur l’application plutôt que sur la création et la gestion d’index. Pour plus d’informations, voir Azure Cosmos DB : Stratégies d’indexation.

Puis-je modifier la stratégie d’indexation ?

Oui, vous pouvez modifier la stratégie d’indexation en fournissant la définition d’index. Vous devez correctement encoder et placer dans une séquence d’échappement les paramètres.

La stratégie d’indexation peut être définie seulement dans le portail dans l’Explorateur de données : accédez à la table spécifique que vous voulez modifier, puis accédez à Mise à l’échelle et paramètres–>Stratégie d’indexation, apportez les modifications souhaitées, puis sélectionnez Enregistrer.

Azure Cosmos DB en tant que plateforme semble avoir de nombreuses fonctionnalités, telles que le tri, l’agrégation, la hiérarchisation et autres. Allez-vous ajouter ces fonctionnalités à l’API pour Table ?

L’API pour Table offre les mêmes fonctionnalités de requête que le stockage Table Azure. Azure Cosmos DB prend également en charge le tri, les agrégats, les requêtes géospatiales, les hiérarchies et un large éventail de fonctions intégrées. Pour plus d’informations, consultez la section Requêtes SQL.

Quand dois-je changer le débit de table (TableThroughput) pour l’API pour Table ?

Vous devez modifier débit de table (TableThroughput) dans les situations suivantes :

  • Vous effectuez une opération d’extraction, transformation et chargement (ETL) de données, ou vous voulez charger une grande quantité de données dans un court laps de temps.
  • Vous avez besoin d’un débit supérieur du conteneur ou d’un ensemble de conteneurs sur le backend. Par exemple, vous voyez que le débit utilisé est supérieur au débit provisionné, et vous êtes limité. Pour plus d’informations, consultez Définir le débit des conteneurs Azure Cosmos DB.

Puis-je augmenter ou réduire le débit ma table d’API pour Table ?

Oui, vous pouvez utiliser le volet de mise à l’échelle du portail Azure Cosmos DB pour régler le débit. Pour plus d’informations, voir Définir le débit.

Un débit de table (TableThroughput) par défaut est-il défini pour les nouvelles tables approvisionnées ?

Oui, si vous ne remplacez pas TableThroughput dans le fichier app.config et que vous n’utilisez pas de conteneur précréé dans Azure Cosmos DB, le service crée une table avec un débit de 400.

Les prix varient-ils pour les clients existants du service de stockage Table Azure ?

Aucun. Le tarif reste inchangé pour les clients existants du stockage Table Azure.

Comment le prix est-il calculé pour l’API pour Table ?

Cela dépend du débit de table (TableThroughput) alloué.

Comment faire pour gérer les limitations de taux qui affectent les tables dans l’offre API pour Table ?

Si le taux de requêtes dépasse la capacité du débit provisionné pour le conteneur sous-jacent ou un ensemble de conteneurs, vous recevez une erreur et le SDK essaie de renouveler l’appel en appliquant la stratégie de nouvelle tentative.

Pourquoi dois-je choisir un débit en dehors de PartitionKey et de RowKey pour tirer parti de l’offre API pour Table d’Azure Cosmos DB ?

Si vous ne spécifiez pas de débit par défaut pour votre conteneur dans le fichier app.config ou par le biais du portail, Azure Cosmos DB en définit un.

Azure Cosmos DB fournit des garanties de performances et de latence avec des limites supérieures pour les opérations. Cette garantie est possible lorsque le moteur peut assurer la gouvernance des opérations du client. La définition du débit de table (TableThroughput) est pour vous l’assurance de bénéficier du débit et de la latence garantis, car la plateforme réserve cette capacité et garantit le succès des opérations.

La spécification du débit vous permet de modifier celui-ci en souplesse pour tirer parti du caractère saisonnier de votre application, répondre aux besoins de débit et réduire les coûts.

Le stockage Table Azure était peu onéreux pour moi, car je payais uniquement le stockage des données et n’effectuais que rarement des requêtes. Azure Cosmos DB for Table semble me facturer des frais alors que je n’ai pas effectué la moindre transaction ou stocké quoi que ce soit. Pouvez-vous m’expliquer pourquoi ?

Azure Cosmos DB est conçu pour être un système distribué globalement basé sur un contrat de niveau de service (SLA) offrant des garanties en matière de disponibilité, de latence et de débit. Le débit que vous réservez dans Azure Cosmos DB est garanti, à la différence du débit d’autres systèmes. Azure Cosmos DB offre des fonctionnalités supplémentaires qui ont été demandées par les clients, comme les index secondaires et la distribution mondiale.

Je ne reçois jamais de notification de « quota complet » (indiquant qu’une partition est pleine) lorsque j’ingère des données dans le stockage Table Azure. Avec l’API pour Table, je reçois ce message. Cette offre me limite-t-elle et m’oblige-t-elle à modifier mon application existante ?

Azure Cosmos DB est un système basé sur un contrat de niveau de service (SLA) permettant une mise à l’échelle illimitée, avec des garanties en matière de latence, de débit, de disponibilité et de cohérence. Pour être certain de bénéficier des performances premium garanties, assurez-vous que la taille de vos données et votre index sont gérables et extensibles. La limite de 20 Go appliquée au nombre d’entités ou d’éléments par clé de partition nous permet de garantir des performances de recherche et de requête exceptionnelles. Pour vous assurer que la mise à l’échelle de votre application fonctionne correctement, même pour le stockage Azure, nous vous recommandons de ne pas créer de partition sensible en stockant toutes les informations dans une seule partition et en interrogeant celle-ci.

Si je comprends bien, une clé de partition et une clé de ligne sont toujours exigées avec l’API pour Table ?

Oui. Comme la surface d’exposition de l’API pour Table est semblable à celle du kit SDK Stockage Table Azure, la clé de partition constitue un moyen efficace de distribuer les données. La clé de ligne est unique au sein de cette partition. La clé de ligne doit être présente et ne peut pas avoir la valeur null comme dans le Kit de développement logiciel (SDK) standard. La longueur de la clé de ligne est de 255 octets, et celle de la clé de partition de 1 kilo-octet.

Quels sont les messages d’erreur relatifs à l’API pour Table ?

Comme Stockage Table Azure et Azure Cosmos DB for Table utilisent les mêmes Kits de développement logiciel (SDK), la plupart des erreurs sont identiques.

Pourquoi suis-je limité quand je tente de créer successivement un grand nombre de tables dans l’API pour Table ?

Azure Cosmos DB est un système basé sur un contrat de niveau de service (SLA) qui offre des garanties en matière de latence, de débit, de disponibilité et de cohérence. Comme il s’agit d’un système provisionné, il réserve des ressources afin de garantir le respect de ces exigences. La vitesse de création des tables est détectée et limitée. Nous vous recommandons de consulter le taux de création de tables et de le réduire à moins de 5 par minute. N’oubliez pas que l’API pour Table est un système provisionné. Dès le moment où vous le provisionnez, vous commencez à payer pour celui-ci.

Comment formuler des commentaires sur le Kit de développement logiciel (SDK) ou des bogues ?

Vous pouvez partager vos commentaires par les biais suivants :

Sécurité

Qu’est-ce que le contrôle d’accès en fonction du rôle (RBAC) ?

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.

Comment activer le contrôle d’accès en fonction du rôle sur le plan des données pour Azure Cosmos DB for Table ?

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.

Contenu connexe

Étape suivante

Questions fréquentes (FAQ) sur Azure Cosmos DB