Установка или изменение уровня доступа блочного BLOB-объекта с помощью Java

Статья
2024-09-01

В этой статье показано, как задать или изменить уровень доступа для блочного Blob-объекта с помощью клиентской библиотеки Azure Storage для Java.

Предварительные условия

Подписка Azure — создайте бесплатную учетную запись.
Учетная запись хранения Azure — создайте такую учетную запись.
Пакет средств разработки Java (JDK) версии 8 или более поздней версии (рекомендуется использовать версию 17 для оптимального взаимодействия)
Apache Maven используется для управления проектами в этом примере

Настройка среды

Если у вас нет существующего проекта, в этом разделе показано, как настроить проект для работы с клиентской библиотекой Хранилище BLOB-объектов Azure для Java. Дополнительные сведения см. в разделе "Начало работы с хранилищем объектов BLOB в Azure и Java".

Чтобы работать с примерами кода в этой статье, выполните следующие действия, чтобы настроить проект.

Примечание.

В этой статье используется средство сборки Maven для создания и запуска примера кода. Для работы с пакетами SDK Azure для Java есть и другие средства сборки, например Gradle.

Установка пакетов

Откройте файл pom.xml в текстовом редакторе. Установите пакеты, включив файл BOM или включив прямую зависимость.

Добавьте инструкции импорта

Добавьте следующие операторы 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;

Авторизация

Механизм авторизации должен иметь необходимые разрешения для задания уровня доступа большого двоичного объекта. Для авторизации с помощью идентификатора Microsoft Entra (рекомендуется), требуется встроенный участник данных хранилища BLOB-объектов хранилища ролей или более поздней версии. Дополнительные сведения см. в руководстве по авторизации для установки уровня Blob.

Создание клиентского объекта

Чтобы подключить приложение к хранилищу BLOB-объектов, создайте экземпляр BLOBServiceClient.

В следующем примере используется BLOBServiceClientBuilder для создания BlobServiceClient объекта с помощью DefaultAzureCredentialи показано, как создать клиенты контейнеров и BLOB-объектов при необходимости:

// 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>");

Дополнительные сведения о создании клиентских объектов и управлении ими см. в статье "Создание клиентских объектов и управление ими", взаимодействующих с ресурсами данных.

Сведения об уровнях доступа к блочным BLOB-объектам

Чтобы управлять затратами на хранение, можно упорядочить данные на основе частоты доступа к ней и длительности хранения. Хранилище Azure предоставляет различные уровни доступа, что позволяет наиболее экономично хранить данные объектов BLOB в зависимости от того, как они используются.

Уровни доступа к данным BLOB-объектов

Уровни доступа службы хранилища Azure:

Горячий уровень — сетевой уровень, оптимизированный для хранения часто используемых или изменяемых данных. Горячий уровень имеет самые высокие затраты на хранение, но самые низкие затраты на доступ.
Холодный уровень — сетевой уровень, оптимизированный для хранения редко используемых или изменяемых данных. Данные на холодном уровне должны храниться не менее 30 дней. Уровень "холодный" имеет более низкие затраты на хранение и более высокие затраты на доступ по сравнению с горячим уровнем.
Холодный уровень — сетевой уровень, оптимизированный для хранения данных, которые редко обращаются или изменяются. Данные на холодном уровне должны храниться не менее 90 дней. На холодном уровне хранилища данные хранить дешевле, зато доступ к ним стоит дороже по сравнению с горячим уровнем.
Архивный уровень — автономный уровень, оптимизированный для хранения данных, которые используются редко и имеют нестрогие требования к задержке (порядка нескольких часов). Данные на уровне архива должны храниться не менее 180 дней.

Дополнительные сведения о уровнях доступа см. в статье "Уровни доступа для BLOB-данных".

Хотя BLOB-объект находится на архивном уровне хранилища, он считается автономным элементом и не может быть считан или изменен. Чтобы считывать или изменять данные в архивном BLOB-объекте, необходимо сначала восстановить большой двоичный объект на онлайн-уровне. Дополнительные сведения о восстановлении BLOB-объекта с уровня "Архив" на онлайн-уровне см. в статье о повторном извлечении BLOB-объектов из архивного уровня.

Ограничения

Установка уровня доступа разрешена только для блочных BLOB-объектов. Дополнительные сведения об ограничениях на настройку уровня доступа блочного BLOB-объекта см. в разделе Set Blob Tier (REST API).

Примечание.

Чтобы задать уровень Cold доступа для использования Java, необходимо использовать минимальную версию клиентской библиотеки 12.21.0.

Установка уровня доступа объекта во время загрузки

Уровень доступа большого двоичного объекта можно задать при загрузке с помощью класса BlobUploadFromFileOptions. В следующем примере кода показано, как задать уровень доступа при отправке объекта 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());
    }
}

Дополнительные сведения о отправке большого двоичного объекта с помощью Java см. в статье "Отправка большого двоичного объекта с помощью Java".

Изменение уровня доступа для существующего блочного BLOB-объекта

Вы можете изменить уровень доступа к существующему блочному блоб-объекту с помощью одного из следующих методов:

В следующем примере кода показано, как установить уровень доступа 'Cool' для существующего блоба.

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

Если вы повторно выполняете архивацию большого двоичного объекта, используйте метод setAccessTierWithResponse . tier Установите параметр на допустимое значение AccessTier, HOT, COOL, COLD или ARCHIVE. При необходимости вы можете задать параметр priority в диапазоне до допустимого значения RehydratePriority или STANDARD.

В следующем примере кода показано, как разархивировать архивный BLOB, изменив уровень доступа на Hot.

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

Метод setAccessTierWithResponse также может принимать параметр BlobSetAccessTierOptions для указания параметров конфигурации.

Копирование BLOB на другой уровень доступа

Уровень доступа существующего блочного BLOB-объекта можно изменить, указав уровень доступа в рамках операции копирования. Чтобы изменить уровень доступа во время операции копирования, используйте класс BlobBeginCopyOptions .

Метод setTier можно использовать для указания значения AccessTier как HOT, COOL, COLD, или ARCHIVE. Если вы восстанавливаете большой двоичный объект из архивного уровня с помощью операции копирования, используйте метод setRehydratePriority, чтобы указать значение RehydratePriority как HIGH или STANDARD.

В следующем примере кода показано, как восстановить архивный объект BLOB в горячий уровень с помощью операции копирования.

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

Дополнительные сведения о копировании большого двоичного объекта с помощью Java см. в статье "Копирование большого двоичного объекта с помощью Java".

Ресурсы

Дополнительные сведения о настройке уровней доступа с помощью клиентской библиотеки Хранилище BLOB-объектов Azure для Java см. в следующих ресурсах.

Примеры кода

Просмотр примеров кода из этой статьи (GitHub)

Операции REST API

Пакет SDK Azure для Java содержит библиотеки, которые создаются на основе REST API Azure, что позволяет взаимодействовать с операциями REST API через знакомые парадигмы Java. Методы клиентской библиотеки для настройки уровней доступа используют следующую операцию REST API:

Настройка уровня BLOB-объектов (REST API)

Ресурсы клиентской библиотеки

См. также

Эта статья является частью руководства разработчика хранилища BLOB-объектов для Java. Дополнительные сведения см. в полном списке статей руководства разработчика по созданию приложения Java.