Check-list des performances et de la scalabilité pour le stockage Table
Microsoft a mis au point de nombreuses pratiques éprouvées en ce qui concerne le développement d’applications haute performance avec le stockage sur table. Cette check-list fournit des pratiques clés que les développeurs peuvent utiliser pour optimiser les performances. Gardez ces pratiques à l’esprit lorsque vous concevez votre application et tout au long du processus de développement.
Le stockage Azure a des objectifs de scalabilité et de performances pour la capacité, le taux de transactions et la bande passante. Pour plus d’informations sur les cibles de scalabilité de Stockage Azure, consultez Cibles de scalabilité et de performances pour les comptes de stockage standard et Cibles de scalabilité et de performances pour le stockage Table.
Liste de contrôle
Cet article organise les pratiques validées pour les performances dans une check-list que vous pouvez suivre lors du développement de votre application de stockage Table.
Objectifs de scalabilité
Si votre application s’approche de l’une des cibles de scalabilité, voire la dépasse, cela pourrait entraîner une limitation ou des latences de transactions accrues. Lorsque le stockage Azure limite votre application, le service commence à retourner les codes d’erreur 503 (Serveur occupé) ou 500 (Délai d’expiration de l’opération). Pour améliorer les performances de votre application, il est important d’éviter de telles erreurs en restant dans les limites des objectifs de scalabilité.
Pour plus d’informations sur les objectifs de scalabilité concernant le service de Table, consultez Objectifs de scalabilité et de performances pour le stockage de tables.
Nombre maximal de comptes de stockage
Si vous atteignez le nombre maximal de comptes de stockage autorisés pour une combinaison abonnement-région, utilisez-vous plusieurs comptes de stockage afin d’effectuer un partitionnement en vue d’augmenter les entrées, les sorties, les opérations d’E/S par seconde (IOPS) ou la capacité ? Dans ce scénario, Microsoft recommande, si possible, de tirer parti de l’augmentation du nombre maximal de comptes de stockage, afin de réduire le nombre de comptes de stockage nécessaires pour votre charge de travail. Contactez le support Azure pour demander l’augmentation des limites de votre compte de stockage.
Objectifs de capacité et de transaction
Si votre application s’approche des objectifs d’extensibilité d’un seul compte de stockage, pensez à appliquer l’une des méthodes suivantes :
- Réexaminez la charge de travail à cause de laquelle votre application s’approche de l’objectif d’extensibilité ou le dépasse. Est-il possible de la concevoir différemment pour qu’elle utilise moins de bande passante ou de capacité, ou moins de transactions ?
- Si votre application doit dépasser l’un des objectifs de scalabilité, vous devez créer plusieurs comptes de stockage et partitionner vos données d’application sur ces comptes de stockage. Si vous optez pour ce modèle, veillez à concevoir votre application de telle sorte que vous puissiez ajouter davantage de comptes de stockage à l’avenir en vue de l’équilibrage de la charge. Aucun coût autre que l’utilisation (données stockées, transactions effectuées, données transférées, etc.) n’est associé à ces comptes de stockage.
- Si votre application s’approche des objectifs de bande passante, pensez à compresser les données côté client afin de réduire la bande passante nécessaire à l’envoi des données au stockage Azure. Même si la compression des données peut réduire la bande passante et améliorer les performances du réseau, elle nuit aux performances. Évaluez l’impact sur les performances qu’entraînent les exigences de traitement supplémentaires liées à la compression et à la décompression des données côté client. Gardez à l’esprit que le stockage de données compressées peut compliquer la résolution des problèmes, car il peut être plus difficile de voir les données à l’aide d’outils standard.
- Si votre application s’approche des objectifs de scalabilité, vérifiez que vous utilisez bien un backoff exponentiel pour les nouvelles tentatives. Il est préférable d’éviter de s’approcher des objectifs de scalabilité en implémentant les recommandations fournies dans cet article. Toutefois, l’utilisation d’un backoff exponentiel pour les nouvelles tentatives va empêcher votre application d’effectuer une nouvelle tentative rapidement, ce qui pourrait compliquer la limitation. Pour plus d’informations, consultez la section intitulée Erreurs d’expiration de délai et de serveur occupé.
Cibles pour les opérations de données
Stockage Azure équilibre la charge à mesure que le trafic vers votre compte de stockage augmente, mais si le trafic présente des rafales soudaines, vous risquez de ne pas pouvoir récupérer ce volume de débit immédiatement. Attendez-vous à constater une limitation et/ou des délais d’expiration pendant la rafale, car Stockage Azure équilibre automatiquement la charge de votre table. Une accélération progressive procure généralement de meilleurs résultats, car le système a le temps d’équilibrer la charge de manière appropriée.
Entités par seconde (compte)
S’agissant de l’accès aux tables, la limite de scalabilité est de 20 000 entités (d’une taille individuelle de 1 Ko) par seconde pour un compte. En règle générale, chaque entité insérée, mise à jour, supprimée ou analysée est comptabilisée. Une insertion par lots composée de 100 entités compte donc pour 100 entités. De même, une requête qui analyse 1 000 entités et en renvoie 5 compte pour 1 000 entités.
Entités par seconde (partition)
Dans une partition unique, l’objectif de scalabilité pour l’accès aux tables est de 2 000 entités (d’une taille individuelle de 1 Ko) par seconde, en utilisant le même mode de calcul que celui décrit dans la section précédente.
Mise en réseau
Les contraintes de réseau physiques de l’application pourraient avoir un impact majeur sur les performances. Les sections suivantes abordent certaines des limitations auxquelles les utilisateurs pourraient être confrontés.
Fonctionnalités réseau du client
La bande passante et la qualité du lien réseau jouent un rôle important dans les performances de l’application, comme l’expliquent les sections suivantes.
Débit
Dans le cas de la bande passante, le problème est souvent dû aux capacités du client. Dans le cas des instances Azure plus importantes, les cartes réseau présentent une capacité supérieure. Si vous avez besoin de limites réseau plus élevées à partir d’un seul ordinateur, vous devez donc envisager d’utiliser une instance plus grande ou davantage de machines virtuelles. Si vous accédez au Stockage Azure à partir d’une application locale, alors la même règle s’applique : comprendre les capacités réseau de l’appareil client et la connectivité réseau à l’emplacement de Stockage Azure, et l’améliorer selon vos besoins ou concevoir votre application conformément à ses capacités.
Qualité du lien
Comme c’est le cas pour toute utilisation du réseau, n’oubliez pas que les conditions réseau qui génèrent des erreurs et une perte de paquets ralentissent le débit effectif. L’utilisation de WireShark ou de NetMon peut vous aider à diagnostiquer ce problème.
Emplacement
Dans un environnement distribué, le fait de placer le client à proximité du serveur se traduit par des performances optimales. Pour accéder à Azure Storage avec un minimum de latence, votre client doit idéalement se trouver dans la même région Azure. Par exemple, si vous disposez d’un site web Azure qui utilise le stockage Azure, tous deux doivent se trouver dans la même région (USA Ouest ou Asie Sud-Est, par exemple). Cela réduit à la fois la latence et les coûts, puisque l’utilisation de la bande passante dans une seule région était gratuite.
Si des applications clientes accéderont au stockage Azure sans être hébergées dans Azure (c’est le cas, par exemple, des applications pour appareil mobile ou des services d’entreprise locaux), le fait de placer le compte de stockage dans une région proche de ces appareils peut réduire la latence. Si vos clients sont distribués à grande échelle (par exemple, certains en Amérique du Nord et d’autres en Europe), il est conseillé d’utiliser un compte de stockage pour chaque région. Cette méthode est plus facile à implémenter si les données stockées par l’application sont propres à certains utilisateurs, et elle ne nécessite pas de réplication des données entre différents comptes de stockage.
SAP et CORS
Supposons que vous deviez autoriser du code, tel que du code JavaScript qui s’exécute dans le navigateur web d’un utilisateur ou dans une application de téléphone mobile, à accéder aux données du stockage Azure. L’une des méthodes possibles consiste à créer une application de service qui serve de proxy. L’appareil de l’utilisateur s’authentifie auprès du service, qui à son tour autorise l’accès aux ressources du stockage Azure. Vous évitez ainsi d’exposer vos clés de compte de stockage sur des appareils non sécurisés. Cependant, cette méthode entraîne une surcharge importante pour l’application du service, dans la mesure où toutes les données transférées entre l’appareil de l’utilisateur et le stockage Azure doivent transiter par l’application du service.
Vous pouvez éviter d’utiliser une application de service en tant que proxy pour le stockage Azure en utilisant des signatures d’accès partagé (SAS). Avec les signatures d’accès partagé, vous pouvez autoriser l’appareil de votre utilisateur à adresser directement des requêtes au stockage Azure par le biais d’un jeton à accès limité. Par exemple, si un utilisateur souhaite charger une photo vers votre application, votre application de service peut générer une signature d’accès partagé et l’envoyer à l’appareil de l’utilisateur. Le jeton SAS peut accorder l’autorisation d’écrire dans une ressource du stockage Azure pendant un intervalle de temps spécifié, au bout duquel le jeton SAS expire. Pour plus d’informations sur les SAS, consultez Accorder un accès limité aux ressources du Stockage Azure à l’aide des signatures d’accès partagé (SAS).
En règle générale, un navigateur web n’autorise pas le code JavaScript d’une page hébergée par un site web d’un domaine à effectuer certaines opérations, telles que les opérations d’écriture, sur un autre domaine. Connue sous le nom de stratégie de même origine, cette stratégie empêche un script malveillant d’une page d’obtenir l’accès aux données d’une autre page web. Toutefois, la stratégie de même origine peut représenter un obstacle lorsque vous créez une solution dans le cloud. Le partage des ressources cross-origin (CORS) est une fonctionnalité de navigateur qui autorise le domaine cible à indiquer au navigateur que vous approuvez les requêtes en provenance du domaine source.
Supposons, par exemple, qu’une application web exécutée dans Azure envoie une requête pour une ressource à un compte de stockage Azure. L’application web est le domaine source, et le compte de stockage est le domaine cible. Vous pouvez configurer le partage des ressources cross-origin pour l’un des services du stockage Azure afin d’indiquer au navigateur web que les requêtes provenant du domaine source sont approuvées par le stockage Azure. Pour plus d’informations sur le partage des ressources cross-origin, consultez Prise en charge du partage des ressources cross-origin (CORS) pour le stockage Azure.
Les signatures d’accès partagé et le partage des ressources cross-origin vous aident à éviter une charge inutile sur votre application web.
Transactions par lots
Le service de Table prend en charge les transactions par lots sur les entités qui se trouvent dans la même table et qui appartiennent au même groupe de partitions. Pour plus d’informations, consultez Effectuer des transactions de groupe d’entités.
Configuration .NET
Pour les projets utilisant .NET Framework, vous trouverez dans cette section plusieurs paramètres de configuration rapide que vous pouvez appliquer pour améliorer sensiblement les performances. Si vous utilisez un langage différent de .NET, vérifiez si des concepts similaires y sont associés.
Augmenter la limite de connexions par défaut
Notes
Cette section s’applique aux projets utilisant .NET Framework, car le regroupement de connexions est contrôlé par la classe ServicePointManager. .NET Core a introduit une modification significative de la gestion des pools de connexions, où le regroupement de connexions se produit au niveau de HttpClient et la taille du pool n’est pas limitée par défaut. Cela signifie que les connexions HTTP sont automatiquement mises à l’échelle pour satisfaire votre charge de travail. L’utilisation de la dernière version de .NET est recommandée, lorsque cela est possible, pour tirer parti des améliorations des performances.
Pour les projets utilisant .NET Framework, vous pouvez utiliser le code suivant pour augmenter à 100 la limite de connexion par défaut (qui est généralement de 2 dans un environnement client ou de 10 dans un environnement de serveur). En règle générale, vous devez définir la valeur sur environ le nombre de threads utilisés par votre application. Définissez la limite de connexions avant d’ouvrir une connexion.
ServicePointManager.DefaultConnectionLimit = 100; //(Or More)
Pour en savoir plus sur les limites du pool de connexions dans .NET Framework, consultez Limites du pool de connexions .NET Framework et le nouveau kit de développement logiciel (SDK) Azure pour .NET.
Pour les autres langages de programmation, voir la documentation pour savoir comment définir la limite de connexions.
Augmenter le nombre minimal de threads
Si vous utilisez des appels synchrones avec des tâches asynchrones, vous aurez peut-être besoin d’augmenter le nombre de threads dans le pool de threads :
ThreadPool.SetMinThreads(100,100); //(Determine the right number for your application)
Pour plus d’informations, consultez la méthode ThreadPool.SetMinThreads.
Parallélisme illimité
Même si le parallélisme peut être très utile pour les performances, soyez prudent lorsque vous utilisez le parallélisme illimité, car il n’existe aucune limite concernant le nombre de threads ou de requêtes parallèles. Veillez à limiter les requêtes parallèles pour charger ou télécharger des données, pour accéder à plusieurs partitions dans un même compte de stockage ou pour accéder à plusieurs éléments d’une même partition. Si vous optez pour un parallélisme illimité, votre application peut dépasser les capacités de l’appareil client ou les objectifs de scalabilité du compte de stockage, ce qui se traduit par des temps de latence plus importants et par une limitation.
Outils et bibliothèques clientes
Pour des performances optimales, utilisez toujours les bibliothèques clientes et les outils fournis par Microsoft les plus récents. Les bibliothèques clientes de Stockage Azure sont disponibles pour plusieurs langages. Le stockage Azure prend également en charge PowerShell et Azure CLI. Microsoft s’attelle au développement de ces outils et de ces bibliothèques clientes dans une optique de performances. Il veille à leur mise à jour continue avec les versions de service les plus récentes et s’assure qu’ils répondent, en interne, à la plupart des pratiques validées concernant les performances.
Gérer les erreurs de service
Le Stockage Azure retourne une erreur lorsque le service ne peut pas traiter une requête. La compréhension des erreurs retournées par le stockage Azure dans un scénario donné permet d’optimiser les performances.
Erreurs d’expiration de délai et de serveur occupé
Stockage Azure peut limiter votre application si celle-ci s’approche des limites de scalabilité. Dans certains cas, Stockage Azure pourrait ne pas être en mesure de traiter une requête en raison d’un problème temporaire. Dans les deux cas, le service peut retourner une erreur 503 (Serveur occupé) ou une erreur 500 (Délai expiré). Ces erreurs peuvent également se produire si le service rééquilibre les partitions de données pour permettre un débit plus élevé. L’application cliente doit généralement retenter l’opération qui provoque l’une de ces erreurs. Cependant, si Stockage Azure limite votre application en raison d’un dépassement des cibles de scalabilité ou si le service n’a pas été en mesure de répondre à la requête pour une autre raison, l’exécution de nouvelles tentatives agressives pourrait aggraver le problème. Il est recommandé d’utiliser une stratégie de nouvelle tentative de type backoff exponentiel. Les bibliothèques clientes adopteront par défaut ce comportement. Votre application pourrait, par exemple, effectuer une nouvelle tentative après 2 secondes, puis 4 secondes, puis 10 secondes, puis 30 secondes avant d’abandonner complètement. De cette façon, votre application réduit considérablement la charge sur le service, au lieu d’aggraver un comportement susceptible d’entraîner une limitation.
Les erreurs de connectivité ne sont pas dues à une limitation et sont généralement temporaires. Dès lors, de nouvelles tentatives peuvent être effectuées immédiatement.
Erreurs non renouvelables
Les bibliothèques clientes gèrent les nouvelles tentatives en sachant quelles erreurs peuvent être retentées et celles qui ne le peuvent pas. Toutefois, si vous appelez directement l’API REST du Stockage Azure, il y a des erreurs que vous ne devez pas renouveler. Par exemple, une erreur 400 (Requête incorrecte) indique que l’application cliente a envoyé une requête qui n’a pas pu être traitée, car elle n’était pas au format attendu. Le fait de renvoyer cette requête générera à chaque fois la même réponse, il ne sert donc à rien de la renvoyer. Si vous appelez directement l’API REST du Stockage Azure, tenez compte des erreurs potentielles et déterminez si elles doivent être retentées.
Pour plus d’informations sur les codes d’erreur du stockage Azure, consultez Codes d’état et d’erreur.
Configuration
Cette section décrit les paramètres de configuration rapide que vous pouvez utiliser pour améliorer sensiblement les performances du service de Table :
Avec JSON
Depuis la version 2013-08-15 du service de stockage, le service de Table prend en charge l’utilisation de JSON plutôt que le format AtomPub XML pour transférer des données de table. L’utilisation du format JSON permet de réduire la taille de la charge utile de quelque 75 % et d’améliorer sensiblement les performances de votre application.
Pour plus d’informations, consultez Tables Microsoft Azure : présentation de JSON et Format de charge utile pour les opérations du service de Table.
Désactiver Nagle
L’algorithme de Nagle est utilisé à grande échelle sur les réseaux TCP/IP en vue d’améliorer les performances du réseau. Cependant, elle n’est pas idéale dans toutes les situations (par exemple dans les environnements très interactifs). L’algorithme Nagle a un impact négatif sur les performances des requêtes adressées aux services Table et File d’attente Azure. Vous devez donc le désactiver si cela s’avère possible.
schéma
Le mode de représentation et d’interrogation de vos données constitue le principal facteur ayant une incidence sur les performances du service de Table. Bien que chaque application soit différente, cette section énumère quelques pratiques générales concernant les points suivants :
- Conception de tables
- Requêtes efficaces
- Mises à jour de données efficaces
Tables et partitions
Les tables sont divisées en partitions. Toutes les entités stockées dans une partition partagent la même clé de partition et sont associées à une clé de ligne pour les identifier dans cette partition. Les partitions offrent des avantages, mais elles s’accompagnent également de limites d’extensibilité.
- Avantages : vous pouvez mettre à jour des entités d’une même partition au cours d’une seule transaction atomique par lots pouvant contenir jusqu’à 100 opérations de stockage distinctes (taille totale limite de 4 Mo). En partant du principe que le même nombre d’entités doit être récupéré, vous pouvez également interroger plus efficacement les données d’une seule partition que celles qui couvrent plusieurs partitions (vous trouverez d’autres conseils sur l’interrogation des données de table dans la suite de ce document).
- Limite d’extensibilité : l’accès aux entités stockées dans une seule partition ne peut pas faire l’objet d’un équilibrage de la charge, car les partitions prennent en charge les transactions atomiques par lots. C’est pourquoi l’objectif de scalabilité d’une partition de table individuelle est inférieur à celui du service de Table dans son ensemble.
Compte tenu des caractéristiques des tables et des partitions, il est conseillé d’adopter les principes de conception suivants :
- Localisez les données que votre application cliente met à jour ou interroge fréquemment dans une même unité de travail logique au sein d’une même partition. Par exemple, localisez les données d’une même partition si votre application regroupe des écritures ou si vous effectuez des opérations de traitement par lots atomiques. Ajoutons encore que les données d’une seule partition peuvent être interrogées plus efficacement dans une seule requête que les données de plusieurs partitions.
- Localisez les données que votre application cliente n’insère pas, ne met pas à jour ou n’interroge pas dans une même unité de travail logique (requête unique ou mise à jour par lots) sur des partitions distinctes. N’oubliez pas que le nombre de clés de partition d’une même table n’est pas limité. Le fait qu’il y ait plusieurs millions de clés de partition ne constitue donc pas un problème et n’a aucune incidence sur les performances. Par exemple, si votre application est un site web populaire auquel les utilisateurs doivent se connecter, il peut être judicieux de choisir l’identifiant utilisateur comme clé de partition.
Partitions actives
On appelle « partition active » une partition qui reçoit un pourcentage disproportionné du trafic vers un compte et qui ne peut pas faire l’objet d’un équilibrage de la charge, car il s’agit d’une partition unique. En règle générale, la création des partitions actives s’effectue de l’une des façons suivantes :
Modèles « Ajouter après uniquement » et « Ajouter avant uniquement »
Avec le modèle « Ajouter après uniquement », l’intégralité (ou la grande majorité) du trafic à destination d’une clé de partition donnée augmente et diminue en fonction de l’heure. Par exemple, supposons que votre application utilise la date du jour comme clé de partition pour les données de journal. De cette façons, toutes les insertions sont placées dans la dernière partition de votre table et le système ne peut pas équilibrer la charge correctement. Si le trafic à destination de cette partition dépasse l’objectif d’extensibilité au niveau de la partition, cela se traduit par une limitation. Il est préférable de s’assurer que le trafic est envoyé vers plusieurs partitions, afin de permettre l’équilibrage de la charge des demandes sur votre table.
Données à trafic élevé
Si votre schéma de partitionnement donne lieu à une seule partition qui comporte simplement les données qui sont beaucoup plus utilisées que d’autres partitions, le phénomène de limitation risque également de se présenter à mesure que cette partition unique s’approche de son objectif d’extensibilité. Il est conseillé de faire en sorte que votre schéma de partitionnement ne génère pas une partition unique qui s’approche des objectifs d’extensibilité.
Interrogation
Cette section décrit les pratiques validées concernant l’interrogation du service de Table.
Étendue de requête
Pour spécifier la plage des entités à interroger, vous pouvez procéder de plusieurs façons. La liste ci-dessous décrit chaque option pour l’étendue de requête.
- Requêtes de point : une requête de point récupère exactement une entité en spécifiant à la fois la clé de partition et la clé de ligne de l’entité à récupérer. Ces requêtes sont efficaces et nous vous conseillons de les utiliser dans la mesure du possible.
- Requêtes de partition : Une requête de partition récupère un jeu de données qui partagent une clé de partition commune. En règle générale, cette requête spécifie une plage de valeurs de clé de ligne ou une plage de valeurs pour une propriété d’entité, en plus d’une clé de partition. ces requêtes sont moins efficaces que les requêtes de point et doivent être utilisées avec modération.
- Requêtes de table : Une requête de table récupère un jeu d’entités ne partageant pas une clé de partition commune. Les requêtes de ce type ne sont pas efficaces et il est conseillé de les éviter dans la mesure du possible.
En règle générale, il est conseillé d’éviter les analyses (requêtes d’une taille supérieure à une seule entité). Cependant, si vous devez procéder de la sorte, tâchez d’organiser vos données de façon à ce que les analyses les récupèrent sans qu’il faille examiner ou renvoyer de grandes quantités d’entités dont vous n’avez pas besoin.
Densité des requêtes
S’agissant de l’efficacité des requêtes, un autre facteur important est le nombre d’entités renvoyées par rapport au nombre d’entités analysées pour obtenir le jeu renvoyé. Si votre application effectue une requête de table avec un filtre pour une valeur de propriété partagée par seulement 1 % des données, la requête analyse 100 entités pour chaque entité renvoyée. Les objectifs de scalabilité de table abordés précédemment sont liés au nombre d’entités analysées et non au nombre d’entités retournées : une densité de requête faible peut facilement générer un service de Table qui limite votre application, car il convient d’analyser de nombreuses entités pour récupérer l’entité que vous recherchez. Pour savoir comment éviter la limitation, consultez la section intitulée Dénormalisation .
Limitation du volume de données renvoyé
Lorsque vous savez qu’une requête retourne des entités dont vous n’avez pas besoin dans l’application cliente, pensez à utiliser un filtre afin de réduire la taille du jeu retourné. Bien que les entités non renvoyées au client soient comptabilisées dans les limites d’extensibilité, les performances de votre application s’en trouvent améliorées, compte tenu de la taille réduite de charge utile du réseau et de la réduction du nombre d’entités traitées par votre application cliente. N’oubliez pas que les objectifs de scalabilité font référence au nombre d’entités analysées, et donc, qu’il se peut qu’une requête qui exclut de nombreuses entités donne toujours lieu à une limitation, même si le nombre d’entités retournées est faible. Pour plus d’informations sur l’efficacité des requêtes, consultez la section intitulée Densité des requêtes.
Si votre application cliente nécessite seulement un jeu limité de propriétés des entités de votre table, vous pouvez utiliser la projection pour limiter la taille du jeu de données renvoyé. Comme c’est le cas avec le filtrage, la projection permet de réduire la charge réseau et le traitement du client.
Dénormalisation
Contrairement à l’utilisation des bases de données relationnelles, les pratiques éprouvées pour interroger efficacement des données de table entraînent leur dénormalisation. Cette opération consiste à dupliquer les mêmes données dans plusieurs entités (une pour chaque clé utilisable pour rechercher les données) afin de réduire le nombre d’entités qu’une requête doit analyser pour rechercher les données dont le client a besoin, plutôt que d’analyser de grandes quantités d’entités pour rechercher les données dont votre application a besoin. Sur un site web de commerce électronique, par exemple, vous pouvez rechercher une commande en fonction de l’identifiant du client (rechercher les commandes de ce client) et de la date (rechercher les commandes passées à une date donnée). Dans Stockage Table, il est préférable de stocker l’entité (ou une référence à celle-ci) à deux reprises : une fois avec le nom de la table, la clé de partition et la clé de ligne afin de faciliter la recherche en fonction de l’identifiant de client, et une fois pour faciliter la recherche en fonction de la date.
Insérer, mettre à jour et supprimer
Cette section décrit les pratiques validées concernant la modification des entités stockées dans le service de Table.
Traitement par lot
Les transactions par lots sont appelées transactions de groupe d’entités dans le stockage Azure. Toutes les opérations d’une transaction de groupe d’entités doivent se trouver sur une même partition d’une même table. Lorsque cela s’avère possible, utilisez des transactions de groupe d’entités pour effectuer des opérations d’insertion, de mise à jour et de suppression par lots. L’utilisation de transactions de groupe d’entités réduit le nombre d’allers-retours entre votre application cliente et le serveur, ainsi que le nombre de transactions facturables (une transaction de groupe d’entités est comptabilisée comme une seule transaction à des fins de facturation et peut contenir 100 opérations de stockage), et autorise les mises à jour atomiques (dans une transaction de groupe d’entités, toutes les opérations réussissent ou échouent). L’utilisation des transactions de groupe d’entités peut apporter des avantages non négligeables dans les environnements où les temps de latence sont élevés, tels que les appareils mobiles.
Upsert
Lorsque cela s'avère possible, il est conseillé d'utiliser des opérations de table Upsert . Il existe deux types d’opération Upsert ; tous deux peuvent se révéler plus efficaces que les opérations Insert et Update classiques :
- InsertOrMerge : Utilisez cette opération lorsque vous souhaitez charger un sous-ensemble des propriétés de l’entité, mais ne savez pas si cette dernière existe déjà. Si elle existe, cet appel met à jour les propriétés incluses dans l’opération Upsert et laisse toutes les propriétés existantes en l’état. Si elle n’existe pas, cet appel insère la nouvelle entité. Cela revient à utiliser la projection dans une requête, en ce sens que vous devez simplement télécharger les propriétés qui sont modifiées.
- InsertOrReplace : Utilisez cette opération lorsque vous souhaitez charger une toute nouvelle entité, mais ne savez pas si cette dernière existe déjà. Utilisez cette opération lorsque vous n’avez aucun doute quant à la qualité de la nouvelle entité chargée, car celle-ci écrase complètement l’ancienne entité. Vous souhaitez, par exemple, mettre à jour l’entité qui stocke l’emplacement actuel d’un utilisateur et ce, que l’application ait déjà stocké ou non des données d’emplacement pour cet utilisateur ; la nouvelle entité d’emplacement est complète et vous n’avez besoin d’aucune information d’une entité précédente.
Stockage de séries de données dans une même entité
Parfois, une application stocke une série de données fréquemment nécessaires pour tout récupérer à la fois : par exemple, une application peut suivre l’utilisation du processeur au fil du temps pour tracer un graphique propagée des données à partir des dernières 24 heures. Une méthode consiste à disposer d’une entité de table par heure, chaque entité représentant alors une heure donnée et stockant l’utilisation du processeur au cours de cette période. Pour représenter ces données sur un graphique, l’application doit récupérer les entités qui contiennent les données des 24 dernières heures.
Sinon, votre application peut stocker l'utilisation du processeur pour chaque heure sous la forme d'une propriété distincte d'une entité unique : pour mettre à jour chaque heure, votre application peut utiliser un seul appel InsertOrMerge Upsert pour mettre à jour la valeur de la dernière heure. Pour représenter les données sur un graphique, l’application doit récupérer une seule entité au lieu de 24, générant ainsi une requête efficace. Pour plus d’informations sur l’efficacité des requêtes, consultez la section intitulée Étendue des requêtes.
Stockage de données structurées dans des objets blob
Si vous effectuez des insertions par lot, puis récupérez des plages d’entités, utilisez des objets blob plutôt que des tables. Un fichier journal constitue un parfait exemple. Vous pouvez regrouper plusieurs minutes de journalisation et les insérer, puis récupérer plusieurs minutes de journalisation à la fois. Dans ce cas, les performances sont meilleures si vous utilisez des objets blob plutôt que des tables, dans la mesure où vous pouvez réduire de manière significative le nombre d’objets écrits ou lus, ainsi que le nombre de requêtes qui doivent être effectuées.