Compartir vía

Establecimiento o cambio del nivel de acceso de un blob en bloques con Java

  • Artículo

Este artículo muestra cómo establecer o cambiar el nivel de acceso de un blob en bloques con la biblioteca cliente de Azure Storage para Java.

Requisitos previos

Configurar el entorno

Si no tiene un proyecto existente, en esta sección, se muestra cómo configurar un proyecto para que funcione con la biblioteca cliente de Azure Blob Storage para Java. Para más información, consulte Introducción a Azure Blob Storage y Java.

Para trabajar con los ejemplos de código de este artículo, siga los pasos siguientes a fin de configurar el proyecto.

Nota:

En este artículo, se usa la herramienta de compilación de Maven para compilar y ejecutar el código de ejemplo. Otras herramientas de compilación, como Gradle, también funcionan con Azure SDK para Java.

Instalar paquetes

Abra el archivo pom.xml en el editor de texto. Instale los paquetes mediante la inclusión del archivo BOM o la inclusión de una dependencia directa.

Adición de instrucciones import

Agregue las instrucciones siguientes import :

import com.azure.core.util.polling.LongRunningOperationStatus;
import com.azure.core.util.polling.PollResponse;
import com.azure.core.util.polling.SyncPoller;
import com.azure.storage.blob.*;
import com.azure.storage.blob.models.*;
import com.azure.storage.blob.options.BlobBeginCopyOptions;

Authorization

El mecanismo de autorización debe tener los permisos necesarios para actualizar un blob. Para la autorización con Microsoft Entra ID (recomendado) se necesita el rol integrado de RBAC de Azure de Colaborador de datos de Storage Blob o superior. Para más información, consulte la guía de autorización para Set Blob Tier.

Creación de un objeto de cliente

Para conectar una aplicación a Blob Storage, cree una instancia de BlobServiceClient.

En el ejemplo siguiente, se usa BlobServiceClientBuilder para crear un objeto BlobServiceClient mediante DefaultAzureCredential, y se muestra cómo crear clientes de contenedores y blobs, si es necesario:

// Azure SDK client builders accept the credential as a parameter
// TODO: Replace <storage-account-name> with your actual storage account name
BlobServiceClient blobServiceClient = new BlobServiceClientBuilder()
        .endpoint("https://<storage-account-name>.blob.core.windows.net/")
        .credential(new DefaultAzureCredentialBuilder().build())
        .buildClient();

// If needed, you can create a BlobContainerClient object from the BlobServiceClient
BlobContainerClient containerClient = blobServiceClient
        .getBlobContainerClient("<container-name>");

// If needed, you can create a BlobClient object from the BlobContainerClient
BlobClient blobClient = containerClient
        .getBlobClient("<blob-name>");

Para obtener más información sobre cómo crear y administrar objetos de cliente, consulte Crear y administrar objetos de cliente que interactúan con los recursos de datos.

Acerca de los niveles de acceso de blobs en bloques

Para administrar los costes de las necesidades de almacenamiento, podría resultar útil organizar los datos en función de la frecuencia con la que se acceda a ellos y del tiempo que se conserven. Azure Storage ofrece diferentes niveles de acceso para que pueda almacenar los datos de blobs de la manera más rentable en función de cómo se usen.

Niveles de acceso frecuente, esporádico y de archivo para los datos de blobs

Los niveles de acceso de Azure Storage incluyen:

  • Nivel de acceso frecuente: nivel en línea optimizado para almacenar datos a los que se accede o se modifican con frecuencia. El nivel de acceso frecuente tiene los costos de almacenamiento más altos, pero los costos de acceso más bajos.
  • Nivel de acceso esporádico: nivel en línea optimizado para almacenar datos a los que se accede o se modifican con poca frecuencia. Los datos del nivel de acceso esporádico se deben almacenar durante un mínimo de 30 días. El nivel de acceso esporádico tiene menores costos de almacenamiento y mayores costos de acceso en comparación con el nivel de acceso frecuente.
  • Nivel de acceso esporádico: nivel en línea optimizado para almacenar datos a los que se accede o se modifican con poca frecuencia. Los datos del nivel de acceso esporádico se deben almacenar durante un mínimo de 90 días. El nivel de acceso esporádico tiene menores costes de almacenamiento y mayores costes de acceso en comparación con el nivel de acceso esporádico.
  • Nivel de acceso de archivo: nivel sin conexión optimizado para almacenar datos a los que se accede muy pocas veces y que tienen requisitos de latencia flexibles, p. ej., horas. Los datos del nivel de acceso de archivo se deben almacenar durante un mínimo de 180 días.

Si desea obtener más información sobre los niveles de acceso, consulte Niveles de acceso para los datos de blobs.

Mientras un blob se encuentra en el nivel de acceso de archivo, se considera que está sin conexión y no se puede leer ni modificar. Para leer o modificar los datos de un blob archivado, primero debe rehidratar el blob en un nivel en línea. Para obtener más información sobre la rehidratación de un blob del nivel de archivo a un nivel en línea, consulte Rehidratación de blobs desde el nivel de archivo.

Restricciones

Solo se permite establecer el nivel de acceso en los blobs en bloques. Para más información sobre las restricciones sobre cómo establecer el nivel de acceso de un blob en bloques, consulte Establecimiento del nivel de blob (API de REST).

Nota

Para establecer el nivel de acceso en Cold con Java, es necesario usar la versión mínima de la biblioteca cliente: versión 12.21.0.

Establecimiento del nivel de acceso de un blob durante la carga

Puede establecer el nivel de acceso de un blob en la carga mediante la clase BlobUploadFromFileOptions. En el ejemplo de código siguiente se muestra cómo establecer el nivel de acceso al cargar un 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());
    }
}

Para obtener más información sobre cómo cargar un blob con Java, consulte Carga de un blob con Java.

Cambio del nivel de acceso de un blob en bloques existente

Puede cambiar el nivel de acceso de un blob en bloques existente mediante uno de los siguientes métodos:

En el ejemplo de código siguiente se muestra cómo cambiar el nivel de acceso a Esporádico de un blob existente:

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

Si va a rehidratar un blob archivado, use el método setAccessTierWithResponse. Establezca el parámetro tier en un valor AccessTier válido de HOT, COOL, COLD o ARCHIVE. Opcionalmente, puede establecer el parámetro priority en un valor RehydratePriority válido HIGH o STANDARD.

En el ejemplo de código siguiente se muestra cómo rehidratar un blob archivado cambiando el nivel de acceso a Frecuente:

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);
}

El método setAccessTierWithResponse también puede aceptar un parámetro BlobSetAccessTierOptions para especificar las opciones de configuración.

Copia de un blob en otro nivel de acceso

Es posible cambiar el nivel de acceso de un blob en bloques existente especificando un nivel de acceso como parte de una operación de copia. Para cambiar el nivel de acceso durante una operación de copia, utilice la clase BlobBeginCopyOptions.

Puede usar el método setTier para especificar el valor de AccessTier como HOT, COOL, COLDo ARCHIVE. Si va a rehidratar un blob del nivel de archivo mediante una operación de copia, use el método setRehydratePriority para especificar el valor RehydratePriority como HIGH o STANDARD.

En el ejemplo de código siguiente se muestra cómo rehidratar un blob archivado en el nivel Frecuente mediante una operación de copia:

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);
}

Para más información sobre cómo copiar un blob con Java, consulte Copia de un blob con Java.

Recursos

Para obtener más información sobre cómo configurar niveles de acceso con la biblioteca cliente de Azure Blob Storage para Java, consulte los recursos siguientes.

Ejemplos de código

Operaciones de API REST

El SDK de Azure para Java contiene bibliotecas que se crean a partir de la API REST de Azure, lo que le permite interactuar con las operaciones de API REST a través de paradigmas conocidos de Java. Los métodos de la biblioteca cliente para configurar niveles de acceso usan esta operación de la API de REST:

Recursos de la biblioteca cliente

Consulte también

Contenido relacionado

  • Este artículo forma parte de la guía para desarrolladores de Blob Storage para Java. Para más información, consulte la lista completa de artículos de la guía para desarrolladores en Compilación de la aplicación Java.