Partager via

Définir ou modifier le niveau d’accès d’un objet blob de blocs avec Java.

  • Article

Cet article montre comment utiliser le niveau d’accès des objets blob de blocs avec la bibliothèque de client Stockage Azure pour Java.

Prérequis

  • Cet article suppose que vous disposez déjà d'un projet configuré pour fonctionner avec la bibliothèque client Stockage Blob Azure pour Java. Pour en savoir plus sur la configuration de votre projet, y compris l’installation de packages, l’ajout de directives import et la création d’un objet client autorisé, consultez Prise en main du Stockage Azure et de Java.
  • Le mécanisme d’autorisation doit disposer des autorisations nécessaires pour définir le niveau d’accès des objets blob. Pour en savoir plus, consultez les conseils d’autorisation pour l’opération d’API REST suivante :

Comprendre les niveaux d’accès aux objets blob de blocs

Pour gérer les coûts liés à vos besoins en matière de stockage, il peut être utile d’organiser vos données en fonction de la fréquence à laquelle elles sont accessibles et de la durée pendant laquelle elles devront conservées. Le Stockage Azure offre différents niveaux d’accès afin que vous puissiez stocker vos données d’objet blob de la manière la plus économique en fonction de la façon dont elles sont utilisées.

Niveaux d’accès pour les données d’objets blob

Les niveaux d’accès Stockage Azure comprennent les suivants :

  • Niveau chaud : niveau en ligne optimisé pour le stockage des données qui sont fréquemment consultées ou modifiées. Le niveau chaud offre les coûts de stockage les plus élevés, mais les coûts d’accès les plus faibles.
  • Niveau froid : niveau en ligne optimisé pour le stockage des données rarement consultées ou modifiées. Les données dans le niveau d’accès froid doivent être stockées pendant un minimum de 30 jours. Le niveau d’accès froid possède des coûts de stockage plus faibles et des coûts d’accès plus élevés que le niveau chaud.
  • Niveau froid : niveau en ligne optimisé pour le stockage des données rarement consultées ou modifiées. Les données dans le niveau d’accès froid doivent être stockées pendant un minimum de 90 jours. Le niveau d’accès froid possède des coûts de stockage plus faibles et des coûts d’accès plus élevés que le niveau sporadique.
  • Niveau Archive : un niveau hors connexion optimisé pour le stockage des données rarement sollicitées, sous des conditions de latence flexibles, de l’ordre de quelques heures. Les données dans le niveau Archive doivent être stockées pendant un minimum de 180 jours.

Pour en savoir plus sur les niveaux d’accès, consultez Niveaux d’accès pour les données blob.

Lorsqu’un objet blob se trouve dans le niveau d’accès Archive, il est considéré comme hors connexion et ne peut être ni lu ni modifié. Pour lire ou modifier les données d'un blob archivé, vous devez d'abord réhydrater le blob à un niveau en ligne. Pour en savoir plus sur la réactivation d’objets blob à partir du niveau archive vers un niveau en ligne, consultez Réhydratation d’objets blob à partir du niveau archive.

Restrictions

La définition du niveau d’accès est autorisée seulement sur les objets blob de blocs. Pour en savoir plus sur les restrictions relatives à la définition du niveau d’accès d’un objet blob de blocs, consultez Définir le niveau d’objet blob (API REST).

Notes

Pour définir le niveau d’accès sur Cold à l’aide de Java, vous devez utiliser une version minimale de la bibliothèque cliente de la version 12.21.0.

Définir le niveau d’accès d’un objet blob pendant le chargement

Vous pouvez définir le niveau d’accès d’un objet blob lors du chargement en utilisant la classe BlobUploadFromFileOptions. L’exemple de code suivant montre comment définir le niveau d’accès lors du chargement d’un objet blob :

public void uploadBlobWithAccessTier(BlobContainerClient blobContainerClient, Path filePath) {
    String fileName = filePath.getFileName().toString();
    BlobClient blobClient = blobContainerClient.getBlobClient(fileName);

    BlobUploadFromFileOptions options = new BlobUploadFromFileOptions(filePath.toString())
            .setTier(AccessTier.COOL);

    try {
        Response<BlockBlobItem> blockBlob = blobClient.uploadFromFileWithResponse(options, null, null);
    } catch (UncheckedIOException ex) {
        System.err.printf("Failed to upload from file: %s%n", ex.getMessage());
    }
}

Pour en savoir plus sur le chargement d’un objet blob avec Java, consultez Charger un objet blob avec Java.

Modifier le niveau d’accès d’un objet blob de blocs existant

Vous pouvez modifier le niveau d’accès d’un objet blob de blocs existant à l’aide de l’une des méthodes suivantes :

L’exemple de code suivant montre comment modifier le niveau d’accès d’un objet blob existant :

public void changeBlobAccessTier(BlobClient blobClient) {
    // Change the blob's access tier to cool
    blobClient.setAccessTier(AccessTier.COOL);
}

Si vous réhydratez un objet blob archivé, utilisez la méthode setAccessTierWithResponse. Définissez le tier paramètre sur une valeur AccessTier valide de HOT, COOL, COLDou ARCHIVE. Vous pouvez éventuellement définir le priority paramètre sur une valeur RehydratePriorityHIGH valide ou STANDARD.

L’exemple de code suivant montre comment réhydrater un objet blob archivé en modifiant le niveau d’accès par Chaud :

public void rehydrateBlobSetAccessTier(BlobClient blobClient) {
    // Rehydrate the blob to hot tier using a standard rehydrate priority
    blobClient.setAccessTierWithResponse(
        AccessTier.HOT,
        RehydratePriority.STANDARD,
        null, 
        null, 
        null);
}

La méthode setAccessTierWithResponse peut également accepter un paramètre BlobSetAccessTierOptions pour spécifier des options de configuration.

Copier un objet blob dans un niveau d’accès différent

Vous pouvez modifier le niveau d’accès d’un objet blob de blocs existant en spécifiant un niveau d’accès dans le cadre d’une opération de copie. Pour modifier le niveau d'accès pendant une opération de copie, utilisez la classe BlobBeginCopyOptions.

Vous pouvez utiliser la méthode setTier pour spécifier la valeur AccessTier comme HOT, COOL, COLDou ARCHIVE. Si vous réhydratez un objet blob à partir du niveau archive à l’aide d’une opération de copie, utilisez la méthode setRehydratePriority pour spécifier la valeur RehydratePriority comme HIGH ou STANDARD.

L’exemple de code suivant montre comment réhydrater un objet blob archivé au niveau Chaud à l’aide d’une opération de copie :

public void rehydrateBlobUsingCopy(
    BlobClient sourceArchiveBlob,
    BlobClient destinationRehydratedBlob) {
    // Note: the destination blob must have a different name than the archived source blob

    // Start the copy operation and wait for it to complete
    final SyncPoller<BlobCopyInfo, Void> poller = destinationRehydratedBlob.beginCopy(
            new BlobBeginCopyOptions(sourceArchiveBlob.getBlobUrl())
                    .setTier(AccessTier.HOT)
                    .setRehydratePriority(RehydratePriority.STANDARD));
                    
    PollResponse<BlobCopyInfo> response = poller
            .waitUntil(LongRunningOperationStatus.SUCCESSFULLY_COMPLETED);
}

Pour en savoir plus sur la copie d’un objet blob avec Java, consultez Copier un objet blob avec Java.

Ressources

Pour en savoir plus sur la définition de niveaux d’accès à l’aide de la bibliothèque de client Stockage Blob Azure pour Java, consultez les ressources suivantes.

Opérations de l'API REST

Le Kit de développement logiciel (SDK) Azure pour Java contient des bibliothèques qui s'appuient sur l'API REST Azure, vous permettant d’interagir avec les opérations de l’API REST par le biais de paradigmes Java familiers. Les méthodes de bibliothèque de client pour la définition de niveaux d’accès utilisent l’opération d’API REST suivante :

Ressources de bibliothèque cliente

Exemples de code

Voir aussi