Udostępnij za pomocą

Ustawianie lub zmienianie warstwy dostępu blokowego obiektu blob za pomocą języka Java

W tym artykule pokazano, jak ustawić lub zmienić warstwę dostępu dla blokowego obiektu blob przy użyciu biblioteki klienta usługi Azure Storage dla języka Java.

Prerequisites

Konfigurowanie środowiska

Jeśli nie masz istniejącego projektu, w tej sekcji pokazano, jak skonfigurować projekt do pracy z biblioteką klienta usługi Azure Blob Storage dla języka Java. Aby uzyskać więcej informacji, zobacz Rozpoczynanie pracy z usługami Azure Blob Storage i Java.

Aby pracować z przykładami kodu w tym artykule, wykonaj następujące kroki, aby skonfigurować projekt.

Note

W tym artykule użyto narzędzia kompilacji maven do skompilowania i uruchomienia przykładowego kodu. Inne narzędzia kompilacji, takie jak Gradle, współpracują również z zestawem Azure SDK dla języka Java.

Instalowanie pakietów

pom.xml Otwórz plik w edytorze tekstów. Zainstaluj pakiety, dołączając plik BOM lub uwzględniając bezpośrednią zależność.

Dodaj instrukcje importu

Dodaj następujące import wyrażenia:

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

Mechanizm autoryzacji musi mieć niezbędne uprawnienia do ustawiania poziomu dostępu obiektu blob. Aby uzyskać autoryzację przy użyciu Microsoft Entra ID (zalecane), potrzebujesz wbudowanej roli Współautor danych Blob Storage w Azure RBAC lub wyższej. Aby dowiedzieć się więcej, zobacz wskazówki dotyczące autoryzacji dotyczące ustawiania warstwy obiektu blob.

Tworzenie obiektu klienta

Aby połączyć aplikację z usługą Blob Storage, utwórz wystąpienie BlobServiceClient.

W poniższym przykładzie użyto obiektu BlobServiceClientBuilder do zbudowania obiektu BlobServiceClient przy użyciu DefaultAzureCredential, i pokazano, jak utworzyć klientów kontenerów i obiektów blob, w razie potrzeby.

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

Aby dowiedzieć się więcej na temat tworzenia obiektów klienta i zarządzania nimi, zobacz Tworzenie obiektów klienta korzystających z zasobów danych i zarządzanie nimi.

Informacje o warstwach dostępu blokowych obiektów blob

Aby zarządzać kosztami magazynu, warto zorganizować dane na podstawie tego, jak często jest uzyskiwany dostęp i jak długo należy je przechowywać. Usługa Azure Storage oferuje różne warstwy dostępu, dzięki czemu można przechowywać dane obiektów blob w najbardziej ekonomiczny sposób na podstawie sposobu ich użycia.

Warstwy dostępu dla danych blob

Warstwy dostępu usługi Azure Storage obejmują:

  • Hot tier - warstwa online zoptymalizowana do przechowywania danych, które są często używane lub modyfikowane. Gorąca warstwa ma najwyższe koszty magazynowania, ale najniższe koszty dostępu.
  • Warstwa Chłodna — warstwa online zoptymalizowana pod kątem przechowywania danych, które są rzadko używane lub modyfikowane. Dane w warstwie chłodnej powinny być przechowywane przez co najmniej 30 dni. Poziom chłodny ma niższe koszty magazynowania i wyższe koszty dostępu w porównaniu z poziomem gorącym.
  • Warstwa zimna — warstwa online zoptymalizowana pod kątem przechowywania danych, do których dostęp jest rzadko używany lub modyfikowany. Dane w warstwie zimnej powinny być przechowywane przez co najmniej 90 dni. Warstwa zimna ma niższe koszty magazynowania i wyższe koszty dostępu w porównaniu do warstwy chłodnej.
  • Warstwa archiwalna — wersja offline zoptymalizowana do przechowywania danych rzadko używanych, które mają elastyczne wymagania dotyczące opóźnień, rzędu godzin. Dane w warstwie Archiwum powinny być przechowywane przez co najmniej 180 dni.

Aby dowiedzieć się więcej na temat warstw dostępu, zobacz Warstwy dostępu dla danych obiektów blob.

Chociaż obiekt blob znajduje się w warstwie dostępu Archiwum, uznaje się go za niedostępny i nie można go odczytać ani zmodyfikować. Aby odczytywać lub modyfikować dane w zarchiwizowanym obiekcie blob, należy najpierw odtworzyć obiekt blob do warstwy online. Aby dowiedzieć się więcej na temat ponownego wypełniania obiektu blob z warstwy Archiwum do warstwy online, zobacz Ponowne wypełnianie obiektów blob z warstwy Archiwum.

Restrictions

Ustawienie warstwy dostępu jest dozwolone tylko w obiektach blob typu block. Aby dowiedzieć się więcej na temat ograniczeń dotyczących ustawiania warstwy dostępu blokowego obiektu blob, zobacz Ustawianie warstwy obiektu blob (interfejs API REST).

Note

Aby ustawić warstwę dostępu na Cold przy użyciu Java, należy użyć minimalnej wersji biblioteki klienta 12.21.0.

Ustaw warstwę dostępu obiektu blob podczas przesyłania

Warstwę dostępu obiektu blob można ustawić przy przesyłaniu przy użyciu klasy BlobUploadFromFileOptions. W poniższym przykładzie kodu pokazano, jak ustawić warstwę dostępu podczas ładowania obiektu 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());
    }
}

Aby dowiedzieć się więcej na temat przekazywania obiektu blob za pomocą języka Java, zobacz Przekazywanie obiektu blob przy użyciu języka Java.

Zmienianie warstwy dostępu dla istniejącego bloba blokowego

Warstwę dostępu dla istniejącego obiektu blob blokowego można zmienić, używając jednej z następujących metod:

W poniższym przykładzie kodu pokazano, jak zmienić poziom dostępu na Cool dla istniejącego obiektu blob.

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

Jeśli odzyskujesz zarchiwizowany blob, użyj metody setAccessTierWithResponse. tier Ustaw parametr na prawidłową wartość AccessTier wartości HOT, COOL, COLDlub ARCHIVE. Opcjonalnie można ustawić priority parametr na prawidłową wartość RehydratePriorityHIGH lub STANDARD.

Poniższy przykład kodu przedstawia sposób ponownego wypełniania zarchiwizowanego obiektu blob przez zmianę warstwy dostępu na Gorąca:

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

Metoda setAccessTierWithResponse może również akceptować parametr BlobSetAccessTierOptions w celu określenia opcji konfiguracji.

Kopiowanie obiektu blob do innej warstwy dostępu

Warstwę dostępu istniejącego bloku blob można zmienić, określając warstwę dostępu w ramach procesu kopiowania. Aby zmienić warstwę dostępu podczas operacji kopiowania, użyj klasy BlobBeginCopyOptions .

Możesz użyć metody setTier , aby określić wartość AccessTier jako HOT, COOL, COLDlub ARCHIVE. Jeśli przywracasz obiekt blob z warstwy archiwalnej przy użyciu operacji kopiowania, użyj metody setRehydratePriority, aby określić wartość RehydratePriority jako HIGH lub STANDARD.

W poniższym przykładzie kodu pokazano, jak przeprowadzić rehydratację zarchiwizowanego obiektu blob do warstwy gorącej przy użyciu operacji kopiowania:

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

Aby dowiedzieć się więcej na temat kopiowania obiektu blob za pomocą języka Java, zobacz Kopiowanie obiektu blob przy użyciu języka Java.

Resources

Aby dowiedzieć się więcej na temat ustawiania warstw dostępu przy użyciu biblioteki klienta usługi Azure Blob Storage dla języka Java, zobacz następujące zasoby.

Przykłady kodu

Operacje interfejsu API REST

Zestaw Azure SDK dla języka Java zawiera biblioteki, które bazują na interfejsie API REST platformy Azure, co umożliwia interakcję z operacjami interfejsu API REST za pomocą znanych paradygmatów języka Java. Metody biblioteki klienta do ustawiania warstw dostępu używają następującej operacji interfejsu API REST:

Zasoby biblioteki klienta

Zobacz także

Treści powiązane

  • Ten artykuł jest częścią przewodnika dla deweloperów usługi Blob Storage dla języka Java. Aby dowiedzieć się więcej, zobacz pełną listę artykułów z przewodnika dla deweloperów w temacie Tworzenie aplikacji Java.
  • Last updated on