Objectifs de scalabilité et de performances pour le stockage Blob

Cette référence détaille les objectifs d’extensibilité et de performances des stockage Azure. Les cibles de scalabilité et de performances répertoriées ici sont des cibles haut de gamme, mais elles sont réalisables. Dans tous les cas, le taux de requête et la bande passante que votre compte de stockage obtient dépendent de la taille des objets stockés, des modèles d’accès utilisés et du type de charge de travail que votre application effectue.

Testez votre service pour déterminer si ses performances répondent à vos besoins. Dans la mesure du possible, évitez les pics soudains de trafic et assurez-vous que le trafic est bien réparti sur toutes les partitions.

Lorsque votre application atteint la limite de gestion d’une partition pour votre charge de travail, stockage Azure commence à retourner le code d’erreur 503 (Serveur occupé) ou le code d’erreur 500 (Délai d’expiration de l’opération). Si des erreurs 503 se produisent, envisagez de modifier votre application pour utiliser une stratégie d’interruption exponentielle pour les nouvelles tentatives. Le délai d’attente exponentiel réduit la charge sur la partition et atténue les pics de trafic sur cette partition.

Pour l’accord de niveau de service (SLA) des comptes stockage Azure, voir SLA pour les comptes de stockage.

Objectifs de mise à l’échelle pour Stockage Blob

Ressource Cible
Taille maximale du conteneur d’objets blob unique Identique à la capacité maximale du compte de stockage
Nombre maximal de blocs dans un objet blob de blocs ou ajouter des objets blob 50 000 blocs
Taille maximale d’un bloc dans un objet blob de blocs 4 000 MiB
Taille maximale d’un objet blob de blocs 50 000 x 4 000 Mio (environ 190,7 Tio)
Taille maximale d’un bloc dans un objet blob d’ajout 4 Mio
Taille maximale d’un objet blob d’ajout 50 000 x 4 Mio (environ 195 Gio)
Taille maximale d’un objet blob de pages 8 Tio2
Nombre maximal de stratégies d’accès stockées par conteneur d’objets blob 5
Taux de requête cible pour un blob unique Jusqu’à 3 000 requêtes par seconde
Taux de requête cible pour un page blob unique Jusqu’à 500 requêtes par seconde
Débit cible pour un blob de page unique Jusqu’à 60 Mio par seconde2
Débit cible pour un objet blob de blocs unique Jusqu’à la limite d’entrée/sortie du compte de stockage1

1 Le débit pour un seul objet blob dépend de plusieurs facteurs. Ces facteurs incluent, mais ne sont pas limités à la concurrence, à la taille des demandes, au niveau de performances, à la vitesse de la source pour les chargements et à la destination des téléchargements. Pour tirer parti des améliorations des performances des objets blob de blocs à haut débit, chargez des objets blob ou des blocs plus volumineux. Plus précisément, appelez l’opération Put Blob ou Put Block avec une taille d’objet blob ou de bloc supérieure à 256 KiB.

2 Les objets blob de pages ne sont pas encore pris en charge dans les comptes qui ont un espace de noms hiérarchique activé.

Le tableau suivant décrit les tailles maximales de blocs et d’objets blob autorisées par la version du service.

Version du service Taille de bloc maximale (via Put Block) Taille de blob maximale (via Put Block List) Taille de blob maximale via une seule opération d’écriture (via Put Blob)
Version 2019-12-12 et ultérieure 4 000 MiB Environ 190,7 Tio (4 000 Mio X 50 000 blocs) 5 000 MiB
De la version 2016-05-31 à la version 2019-07-07 100 Mio Environ 4,75 Tio (100 Mio X 50 000 blocs) 256 Mio
Versions antérieures à 2016-05-31 4 Mio Environ 195 Gio (4 Mio X 50 000 blocs) 64 Mio

Partitions chaudes : détection, surveillance et atténuation

Stockage Blob Azure distribue les données et requêtes entre partitions pour aider à faire évoluer les charges de travail. Un compte de stockage peut disposer d’une capacité disponible et d’un débit disponible, tandis que des charges de travail qui concentrent le trafic sur un ensemble restreint de clés de partition subissent des limitations de débit au niveau des partitions.

Lorsqu’une partition reçoit beaucoup plus de trafic que d’autres partitions, elle devient une partition chaude. La clé de partition d’un blob combine le nom du compte de stockage, le nom du conteneur et le nom du blob, de sorte que les schémas de nommage séquentiel ou uniquement à ajout peuvent concentrer le trafic sur une seule partition.

Lorsqu’une partition devient chaude, votre application peut observer une latence accrue et recevoir des réponses HTTP 503 (serveur occupé) ou HTTP 500 (délai d’expiration) avant que le compte de stockage n’atteigne ses limites de scalabilité documentées.

Pour atténuer les partitions surchargées :

  • Évitez les schémas de nommage de blobs séquentiels ou en ajout seul qui concentrent le trafic sur une seule partition.

  • Utilisez une stratégie de nouvelle tentative avec backoff exponentiel lorsque des erreurs de limitation du débit se produisent.

  • Augmentez progressivement les taux de demandes lorsque vous introduisez de nouvelles charges de travail.

Pour détecter la limitation du débit et identifier la source d’une sollicitation excessive, utilisez les métriques et les journaux de ressources d’Azure Monitor.

Pour plus d’informations, voir Atténuer les partitions chaudes dans Stockage Blob Azure.

Voir aussi

  • Last updated on