Optimiser les coûts en gérant automatiquement le cycle de vie des données
La gestion de cycle de vie de Stockage Blob Azure offre une stratégie basée sur des règles que vous pouvez utiliser pour faire passer les données blob aux niveaux d’accès appropriés ou faire expirer les données à la fin de leur cycle de vie.
Grâce à la stratégie de gestion de cycle de vie, vous pouvez effectuer les opération suivantes :
- Transférer des objets blob du niveau froid au niveau chaud dès qu’ils sont consultés afin d’optimiser les performances.
- Transférez les versions actuelles, les versions précédentes et les instantanés d’un objet blob vers un niveau de stockage plus froid si ces objets n’ont pas été consultés ni modifiés pendant un certain temps afin d’optimiser les coûts.
- Supprimez les versions actuelles, les versions précédentes et les instantanés d’un objet blob à la fin du cycle de vie.
- Appliquez des règles à l’ensemble d’un compte de stockage, à certains conteneurs ou à un sous-ensemble de d’objets blob en utilisant des préfixes de noms ou des étiquettes d’index de blobs en tant que filtres.
Conseil
Bien que la gestion du cycle de vie vous aide à déplacer les données entre les niveaux dans un seul compte, vous pouvez utiliser une tâche de stockage pour accomplir cette tâche à grande échelle sur plusieurs comptes. Une tâche de stockage est une ressource disponible dans Azure Storage Actions; infrastructure serverless que vous pouvez utiliser pour effectuer des opérations de données courantes sur des millions d’objets sur plusieurs comptes de stockage. Pour plus d’informations, consultez Qu’est-ce qu’Azure Storage Actions ?.
Les stratégies de gestion de cycle de vie sont prises en charge pour les objets blob de blocs et d’ajout dans les comptes v2 universels, les objets blob de blocs premium et les comptes Stockage Blob. La gestion de cycle de vie ne concerne pas les conteneurs système comme les conteneurs $logs ou $web.
Important
Si un jeu de données doit être lisible, ne définissez pas de stratégie pour déplacer les blobs vers le niveau archive. Les blobs du niveau archive ne peuvent pas être lus s’ils ne sont pas d’abord réhydratés, un processus qui peut être long et coûteux. Pour plus d’informations, voir Vue d’ensemble de la réactivation d’objets blob à partir du niveau Archive. Si un ensemble de données doit être lu souvent, ne définissez pas de stratégie pour déplacer les blobs vers les niveaux froid ou froid, car cela pourrait entraîner des coûts de transaction plus élevés.
Optimisation des coûts en gérant le cycle de vie des données
Les jeux de données ont des cycles de vie différents. Tôt dans le cycle de vie, les utilisateurs accèdent souvent à certaines données. Mais la nécessité d’y accéder diminue souvent de façon spectaculaire à mesure que les données vieillissent. Certaines données restent inactives dans le cloud et sont rarement utilisées une fois stockées. Certains jeux de données expirent plusieurs jours ou mois après leur création, tandis que d’autres jeux de données sont activement lus et modifiés tout au long de leur vie.
Considérez un scénario où des données sont sollicitées fréquemment durant les premières étapes du cycle de vie, mais seulement occasionnellement après deux semaines. Au-delà du premier mois, le jeu de données est rarement sollicité. Dans ce scénario, le stockage chaud est préférable durant les premiers temps. Un stockage froid est plus approprié pour un accès occasionnel. L’option Stockage archive est la meilleure une fois que les données ont plus d’un mois. En déplaçant les données vers le niveau de stockage approprié en fonction de leur ancienneté grâce aux règles de stratégie de gestion de cycle de vie, vous pouvez concevoir la solution la moins coûteuse correspondant à vos besoins.
Définition d’une stratégie de gestion de cycle de vie
Une stratégie de gestion de cycle de vie est une collection de règles dans un document JSON. L’exemple JSON suivant montre une définition de règle complète :
{
"rules": [
{
"name": "rule1",
"enabled": true,
"type": "Lifecycle",
"definition": {...}
},
{
"name": "rule2",
"type": "Lifecycle",
"definition": {...}
}
]
}
Une stratégie est une collection de règles, comme décrit dans le tableau suivant :
| Nom du paramètre | Type de paramètre | Notes |
|---|---|---|
rules |
Un ensemble d’objets de règle | Une stratégie requiert au moins une règle. Vous pouvez définir jusqu’à 100 règles dans une stratégie. |
Chaque règle de la stratégie a plusieurs paramètres, décrits dans le tableau suivant :
| Nom du paramètre | Type de paramètre | Notes | Obligatoire |
|---|---|---|---|
name |
String | Un nom de règle peut compter jusqu’à 256 caractères alphanumériques. Les noms de règle respectent la casse. Ils doivent être uniques dans la stratégie. | True |
enabled |
Boolean | Valeur booléenne facultative pour permettre la désactivation temporaire d’une règle. La valeur par défaut est true. | False |
type |
Une valeur enum | Le type valide actuel est Lifecycle. |
True |
definition |
Un objet qui définit la règle du cycle de vie | Chaque définition se compose d’un jeu de filtres et d’un jeu d’actions. | True |
Définition d’une règle de gestion de cycle de vie
Chaque définition de règle dans une stratégie se compose d’un ensemble de filtres et d’un ensemble d’actions. Le jeu de filtres limite les actions de règle à un certain ensemble d’objets dans un conteneur ou des noms d’objets. L’ensemble d’actions applique les actions de niveau ou de suppression à l’ensemble d’objets filtré.
Exemple de règle
L’exemple de règle suivant filtre le compte pour exécuter les actions sur des objets existant à l’intérieur de sample-container et commençant par blob1.
- Niveau objet blob sur accès froid 30 jours après la dernière modification
- Niveau objet blob sur accès archive 90 jours après la dernière modification
- Supprimer l’objet blob 2 555 jours (sept ans) après la dernière modification
- Supprimer les versions précédentes 90 jours après la création
{
"rules": [
{
"enabled": true,
"name": "sample-rule",
"type": "Lifecycle",
"definition": {
"actions": {
"version": {
"delete": {
"daysAfterCreationGreaterThan": 90
}
},
"baseBlob": {
"tierToCool": {
"daysAfterModificationGreaterThan": 30
},
"tierToArchive": {
"daysAfterModificationGreaterThan": 90,
"daysAfterLastTierChangeGreaterThan": 7
},
"delete": {
"daysAfterModificationGreaterThan": 2555
}
}
},
"filters": {
"blobTypes": [
"blockBlob"
],
"prefixMatch": [
"sample-container/blob1"
]
}
}
}
]
}
Notes
L’élément baseBlob dans une stratégie de gestion de cycle de vie fait référence à la version actuelle d’un objet blob. L’élément version fait référence à une version précédente.
Filtres de règle
Les filtres limitent les actions des règles à un sous-ensemble d’objets blob dans le compte de stockage. Si plusieurs filtres sont définis, une opération logique AND est exécutée sur tous les filtres. Vous pouvez utiliser un filtre pour spécifier les blobs à inclure. Un filtre ne fournit aucun moyen de spécifier les blobs à exclure.
Les filtres sont les suivants :
| Nom du filtre | Type de filtre | Notes | Est obligatoire |
|---|---|---|---|
| blobTypes | Un ensemble de valeurs enum prédéfinies. | La version actuelle prend en charge blockBlob et appendBlob. Seule l’action Supprimer est prise en charge pour appendBlob; Le niveau défini n’est pas pris en charge. |
Oui |
| prefixMatch | Un ensemble de chaînes pour les préfixes à mettre en correspondance. Chaque règle peut définir jusqu’à 10 préfixes qui respectent la casse. Une chaîne de préfixe doit commencer par un nom de conteneur. Par exemple, si vous souhaitez faire correspondre tous les blobs sous https://myaccount.blob.core.windows.net/sample-container/blob1/..., spécifiez prefixMatch comme sample-container/blob1. Ce filtre correspondra à tous les blobs du conteneur d'échantillons dont les noms commencent par blob1.. |
Si vous ne définissez pas prefixMatch, la règle s'applique à tous les blobs du compte de stockage. Les chaînes de préfixe ne prennent pas en charge la correspondance des caractères génériques. Les caractères tels que * et ? sont traités comme des littéraux de chaîne. |
Non |
| blobIndexMatch | Un tableau de valeurs de dictionnaire composé de conditions de clé et de valeur de balise d’index de blob à mettre en correspondance. Chaque règle peut définir jusqu’à 10 conditions de balise d’index de blob. Par exemple, si vous souhaitez mettre en correspondre tous les objets blob avec Project = Contoso sous https://myaccount.blob.core.windows.net/ pour une règle, le blobIndexMatch est {"name": "Project","op": "==","value": "Contoso"}. |
Si vous ne définissez pas blobIndexMatch, la règle s’applique à tous les objets blob au sein du compte de stockage. | Non |
Pour en savoir plus sur la fonctionnalité d’index de blob ainsi que sur les problèmes et les limites connus, consultez Gérer et rechercher des données dans Stockage Blob Azure avec un index de blob.
Actions de règle
Des actions sont appliquées aux objets blob filtrés lorsque la condition d’exécution est remplie.
La gestion de cycle de vie prend en charge la hiérarchisation et la suppression des versions actuelles, des versions antérieures et des instantanés d’objets blob. Définissez au moins une action pour chaque règle.
Notes
La hiérarchisation n’est pas encore prise en charge dans un compte de stockage d’objets blob de blocs Premium. Pour tous les autres comptes, la hiérarchisation est autorisée uniquement sur les objets blob de blocs et non pour les objets blob d’ajout et de page.
| Action | Version actuelle | Instantané | Versions précédentes |
|---|---|---|---|
| tierToCool | Prise en charge pour blockBlob |
Prise en charge | Pris en charge |
| tierToCold | Prise en charge pour blockBlob |
Prise en charge | Prise en charge |
| enableAutoTierToHotFromCool1 | Prise en charge pour blockBlob |
Non pris en charge | Non pris en charge |
| tierToArchive4 | Prise en charge pour blockBlob |
Prise en charge | Prise en charge |
| Supprimer 2,3 | Pris en charge pour blockBlob et appendBlob |
Prise en charge | Prise en charge |
1 L’action enableAutoTierToHotFromCool est disponible uniquement lorsqu’elle est utilisée avec la condition d’exécution daysAfterLastAccessTimeGreaterThan. Cette condition est décrite dans la table suivante.
2 Quand elle est appliquée à un compte avec un espace de noms hiérarchique activé, une action de suppression supprime les répertoires vides. Si le répertoire n’est pas vide, l’action de suppression supprime les objets qui répondent aux conditions de la stratégie au cours du premier cycle d’exécution de la stratégie de cycle de vie. Si cette action entraîne un répertoire vide qui répond également aux conditions de la stratégie, ce répertoire est supprimé pendant le cycle d’exécution suivant, et ainsi de suite.
3 Une stratégie de gestion du cycle de vie ne supprimera pas la version actuelle d’un objet blob tant que les versions précédentes ou les instantanés associés à cet objet blob n’auront pas été supprimés. Si les objets blob de votre compte de stockage ont des versions ou des instantanés antérieurs, vous devez inclure des versions et des instantanés précédents lorsque vous spécifiez une action de suppression dans le cadre de la stratégie.
4 Seuls les comptes de stockage configurés pour LRS, GRS ou RA-GRS prennent en charge le déplacement d’objets blob vers le niveau de stockage archive. Le niveau de stockage archive n’est pas pris en charge sur les comptes ZRS, GZRS et RA-GZRS. Cette action est répertoriée en fonction de la redondance configurée pour le compte.
Notes
Si vous définissez plusieurs actions sur le même objet blob, la gestion du cycle de vie applique l’action la moins coûteuse à l’objet blob. Par exemple, l’action delete est moins coûteuse que l’action tierToArchive. L’action tierToArchive est moins coûteuse que l’action tierToCool.
Les conditions d’exécution sont basées sur l’âge. Les versions actuelles utilisent l’heure de la dernière modification ou du dernier accès, les versions précédentes utilisent l’heure de création de la version et les instantanés d’objets blob utilisent l’heure de création des instantanés pour suivre l’ancienneté.
| Condition d’exécution d’action | Valeur de la condition | Description |
|---|---|---|
| daysAfterModificationGreaterThan | Nombre entier indiquant l’âge en jours | Condition des actions sur une version actuelle d’un objet blob |
| daysAfterCreationGreaterThan | Nombre entier indiquant l’âge en jours | Condition pour les actions sur la version actuelle ou une version antérieure d’un objet blob ou d’un instantané d’objet blob |
| daysAfterLastAccessTimeGreaterThan1 | Nombre entier indiquant l’âge en jours | Condition pour une version actuelle d’un objet blob quand le suivi d’accès est activé |
| daysAfterLastTierChangeGreaterThan | Valeur entière indiquant le nombre de jours écoulés depuis le dernier changement du niveau d’objet blob | La durée minimale en jours pendant laquelle un objet blob réhydraté est conservé dans des niveaux d’accès chaud, sporadiques ou froids avant d’être retourné au niveau archive. Cette condition s’applique uniquement aux actions tierToArchive. |
1 Si le suivi de l’heure du dernier accès n’est pas activé, daysAfterLastAccessTimeGreaterThan utilise la date à laquelle la stratégie de cycle de vie a été activée au lieu de la propriété LastAccessTime de l’objet blob. Cette date est également utilisée quand la propriété LastAccessTime a une valeur Null. Pour plus d’informations sur l’utilisation du suivi de l’heure du dernier accès, consultez Déplacer des données en fonction de l’heure du dernier accès.
La politique de cycle de vie s'exécute
Lorsque vous configurez ou modifiez une stratégie de cycle de vie, la prise d’effet des modifications et le démarrage de la première exécution peuvent prendre jusqu’à 24 heures. Le temps nécessaire à l’exécution des actions de stratégie dépend du nombre d’objets blob évalués et exploités.
Si vous désactivez une stratégie, aucune nouvelle exécution de stratégie ne sera planifiée, mais si une exécution est déjà en cours, cette exécution se poursuivra jusqu’à ce qu’elle soit terminée et vous serez facturé pour toutes les actions requises pour achever l’exécution. Consultez Disponibilité régionale et tarification.
Événement terminé de la stratégie de cycle de vie
L’événement LifecyclePolicyCompleted est généré lorsque les actions définies par une stratégie de gestion du cycle de vie sont exécutées. Une section récapitulative s’affiche pour chaque action incluse dans la définition de stratégie. Le JSON suivant montre un exemple d’événement LifecyclePolicyCompleted pour une stratégie. Étant donné que la définition de stratégie inclut les actions delete, tierToCool, tierToCold et tierToArchive, une section récapitulative s’affiche pour chacune d’elles.
{
"topic": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/contosoresourcegroup/providers/Microsoft.Storage/storageAccounts/contosostorageaccount",
"subject": "BlobDataManagement/LifeCycleManagement/SummaryReport",
"eventType": "Microsoft.Storage.LifecyclePolicyCompleted",
"eventTime": "2022-05-26T00:00:40.1880331",
"id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"data": {
"scheduleTime": "2022/05/24 22:57:29.3260160",
"deleteSummary": {
"totalObjectsCount": 16,
"successCount": 14,
"errorList": ""
},
"tierToCoolSummary": {
"totalObjectsCount": 0,
"successCount": 0,
"errorList": ""
},
"tierToColdSummary": {
"totalObjectsCount": 0,
"successCount": 0,
"errorList": ""
},
"tierToArchiveSummary": {
"totalObjectsCount": 0,
"successCount": 0,
"errorList": ""
}
},
"dataVersion": "1",
"metadataVersion": "1"
}
Le tableau suivant décrit le schéma de l’événement LifecyclePolicyCompleted.
| Champ | Type | Description |
|---|---|---|
| scheduleTime | string | Heure à laquelle la stratégie de cycle de vie a été planifiée |
| deleteSummary | vector<byte> | Résumé des résultats des objets blob planifiés pour l’opération de suppression |
| tierToCoolSummary | vector<byte> | Résumé des résultats des objets blob planifiés pour l’opération de passage du niveau à froid |
| tierToColdSummary | vector<byte> | Résumé des résultats des objets blob planifiés pour l’opération de passage du niveau à froid |
| tierToArchiveSummary | vector<byte> | Résumé des résultats des objets blob planifiés pour l’opération de passage du niveau à archive |
Exemples de stratégies de cycle de vie
Les exemples suivants expliquent comment résoudre des scénarios courants avec les règles de stratégie du cycle de vie.
Déplacer les données vieillissantes vers un niveau plus froid
Cet exemple montre comment déplacer des objets blob de blocs ayant le préfixe sample-container/blob1 ou container2/blob2. La stratégie déplace les objets blob qui n’ont pas été modifiés depuis plus de 30 jours vers le stockage froid et les objets blob non modifiés depuis 90 jours vers le niveau archive :
{
"rules": [
{
"name": "agingRule",
"enabled": true,
"type": "Lifecycle",
"definition": {
"filters": {
"blobTypes": [ "blockBlob" ],
"prefixMatch": [ "sample-container/blob1", "container2/blob2" ]
},
"actions": {
"baseBlob": {
"tierToCool": { "daysAfterModificationGreaterThan": 30 },
"tierToArchive": { "daysAfterModificationGreaterThan": 90 }
}
}
}
}
]
}
Déplacer des données en fonction de l’heure du dernier accès
Vous pouvez activer le suivi de l’heure du dernier accès pour conserver un enregistrement de la dernière lecture ou écriture de votre blob et en tant que filtre pour gérer la hiérarchisation et la conservation de vos données BLOB. Pour savoir comment activer le suivi de l’heure du dernier accès, consultez Activer le suivi de l’heure d’accès (facultatif).
Lorsque le suivi de l’heure du dernier accès est activé, la propriété d’objet blob appelée LastAccessTime est mise à jour lors de la lecture ou de l’écriture d’un objet blob. Une opération Obtenir un objet blob est considérée comme une opération d’accès. Get Blob Properties, Get Blob Metadata et Get Blob Tags ne sont pas des opérations d’accès et ne mettent donc pas à jour l’heure du dernier accès.
Si le suivi de l’heure du dernier accès est activé, la gestion du cycle de vie utilise LastAccessTime pour déterminer si la condition d’exécution daysAfterLastAccessTimeGreaterThan est remplie. La gestion du cycle de vie utilise la date à laquelle la stratégie de cycle de vie a été activée au lieu de LastAccessTime dans les cas suivants :
La valeur de la propriété
LastAccessTimede l’objet blob est une valeur Null.Notes
La propriété
lastAccessedOnde l’objet blob a une valeur Null si un objet blob n’a pas fait l’objet d’un accès depuis que le suivi de l’heure du dernier accès a été activé.Le suivi de l’heure du dernier accès n’est pas activé.
Pour réduire l’effet sur la latence d’accès en lecture, seule la première lecture des dernières 24 heures met à jour l’heure du dernier accès. Les lectures suivantes dans la même période de 24 heures ne mettent pas à jour l’heure du dernier accès. Si un objet blob est modifié entre des lectures, l’heure du dernier accès est la plus récente des deux valeurs.
Dans l’exemple suivant, les objets BLOB sont déplacés vers le stockage froid s’ils n’ont pas fait l’objet d’accès depuis 30 jours. La propriété enableAutoTierToHotFromCool est une valeur booléenne qui indique si un blob doit être automatiquement reclassé de froid à chaud s’il fait l’objet d’un nouvel accès après avoir été déplacé dans le niveau froid.
Conseil
Si un objet blob est déplacé vers le niveau de stockage sporadique, puis qu’il est automatiquement déplacé à nouveau avant l’expiration d’un délai de 30 jours, des frais de suppression anticipée sont facturés. Avant de définir la propriété enablAutoTierToHotFromCool, veillez à analyser les modèles d’accès de vos données afin de réduire les frais inattendus.
{
"enabled": true,
"name": "last-accessed-thirty-days-ago",
"type": "Lifecycle",
"definition": {
"actions": {
"baseBlob": {
"enableAutoTierToHotFromCool": true,
"tierToCool": {
"daysAfterLastAccessTimeGreaterThan": 30
}
}
},
"filters": {
"blobTypes": [
"blockBlob"
],
"prefixMatch": [
"mylifecyclecontainer/log"
]
}
}
}
Archiver les données après leur ingestion
Certaines données restent inactives dans le cloud et sont rarement, voire jamais, consultées. La stratégie du cycle de vie suivante est configurée pour archiver les données peu après leur ingestion. Cet exemple déplace les objets blob de blocs d’un conteneur nommé archivecontainer à un niveau archive. Le déplacement est accompli en agissant sur les objets blob zéro (0) jour après l’heure de la dernière modification.
{
"rules": [
{
"name": "archiveRule",
"enabled": true,
"type": "Lifecycle",
"definition": {
"filters": {
"blobTypes": [ "blockBlob" ],
"prefixMatch": [ "archivecontainer" ]
},
"actions": {
"baseBlob": {
"tierToArchive": {
"daysAfterModificationGreaterThan": 0
}
}
}
}
}
]
}
Notes
Pour plus d’efficacité, Microsoft vous recommande de charger vos objets blob directement dans le niveau archive. Vous pouvez spécifier le niveau archive dans l’en-tête x-ms-access-tier sur l’opération Put Blob ou Put Block List. L’en-tête x-ms-access-tier est pris en charge avec REST 2018-11-09 et versions ultérieures ou les dernières bibliothèques de client de Stockage Blob.
Faire expirer les données selon l’âge
Certaines données sont supposées expirer un certain nombre de jours ou de mois après leur création. Vous pouvez configurer une stratégie de gestion du cycle de vie afin de faire expirer les données en les supprimant en fonction de leur ancienneté. L’exemple suivant montre une stratégie qui supprime tous les objets blob de blocs qui n’ont pas été modifiés au cours des 365 derniers jours.
{
"rules": [
{
"name": "expirationRule",
"enabled": true,
"type": "Lifecycle",
"definition": {
"filters": {
"blobTypes": [ "blockBlob" ]
},
"actions": {
"baseBlob": {
"delete": { "daysAfterModificationGreaterThan": 365 }
}
}
}
}
]
}
Supprimer des données avec des balises d’index de blobs
Certaines données ne doivent expirer que si elles sont marquées explicitement pour suppression. Vous pouvez configurer une stratégie de gestion du cycle de vie pour faire expirer les données qui sont marquées avec des attributs clé/valeur d’index d’objets blob. L’exemple suivant présente une stratégie qui supprime tous les objets blob de bloc balisés avec Project = Contoso. Pour en savoir plus sur un index d’objets blob, consultez Gérer et rechercher des données sur le Stockage Blob Azure avec un index d’objets blob.
{
"rules": [
{
"enabled": true,
"name": "DeleteContosoData",
"type": "Lifecycle",
"definition": {
"actions": {
"baseBlob": {
"delete": {
"daysAfterModificationGreaterThan": 0
}
}
},
"filters": {
"blobIndexMatch": [
{
"name": "Project",
"op": "==",
"value": "Contoso"
}
],
"blobTypes": [
"blockBlob"
]
}
}
}
]
}
Gérer les versions précédentes
Pour les données modifiées et consultées régulièrement pendant toute leur durée de vie, vous pouvez activer la gestion de versions du stockage Blob afin de gérer automatiquement les versions précédentes d’un objet. Vous pouvez créer une stratégie pour hiérarchiser ou supprimer les versions précédentes. L’âge de la version est déterminé en regardant l’heure de création de cette dernière. Cette règle de stratégie déplace les versions précédentes du conteneur activedata qui datent de 90 jours ou plus après la création de la version vers le niveau froid, et supprime les versions antérieures datant de 365 jours ou plus.
{
"rules": [
{
"enabled": true,
"name": "versionrule",
"type": "Lifecycle",
"definition": {
"actions": {
"version": {
"tierToCool": {
"daysAfterCreationGreaterThan": 90
},
"delete": {
"daysAfterCreationGreaterThan": 365
}
}
},
"filters": {
"blobTypes": [
"blockBlob"
],
"prefixMatch": [
"activedata/"
]
}
}
}
]
}
Disponibilité régionale et tarification
La fonctionnalité de gestion du cycle de vie est disponible dans toutes les régions Azure.
Les stratégies de gestion de cycle de vie sont gratuites. Les clients sont facturés au coût de fonctionnement normal pour les appels d’API Set Blob Tier. Les opérations de suppression sont gratuites. Toutefois, d’autres services et utilitaires Azure tels que Microsoft Defender pour Stockage peuvent facturer des opérations gérées par le biais d’une stratégie de cycle de vie.
Chaque mise à jour de l’heure du dernier accès d’un blob est facturée dans la catégorie Autres opérations. Chaque mise à jour de l’heure du dernier accès est facturée en tant qu’« autre transaction » au plus une fois toutes les 24 heures par objet, même s’il est consulté plusieurs milliers de fois par jour. Cette facturation est distincte des frais de transactions de lecture.
Pour plus d’informations sur les prix, consultez Tarification Objets blob de blocs.
Problèmes connus et limitations
La hiérarchisation n’est pas encore prise en charge dans un compte de stockage d’objets blob de blocs Premium. Pour tous les autres comptes, la hiérarchisation est autorisée uniquement sur les objets blob de blocs et non pour les objets blob d’ajout et de page.
Une stratégie de gestion de cycle de vie doit être lue ou écrite dans son intégralité. Les mises à jour partielles ne sont pas prises en charge.
Chaque règle peut avoir jusqu’à 10 préfixes sensibles à la casse et jusqu’à 10 conditions de balise d’index d’objet blob.
Une stratégie de gestion de cycle de vie ne peut pas modifier le niveau d’un objet blob qui utilise une étendue de chiffrement.
L’action de suppression d’une stratégie de gestion du cycle de vie ne fonctionnera avec aucun objet blob dans un conteneur immuable. Avec une stratégie immuable, des objets peuvent être créés et lus, mais ils ne peuvent être ni modifiés ni supprimés. Pour plus d’informations, consultez Stocker des données blob critiques pour l’entreprise avec un stockage immuable.
Forum aux questions (FAQ)
Consultez FAQ sur la gestion du cycle de vie.