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

Artykuł
10/18/2023

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.

Wymagania wstępne

W tym artykule założono, że masz już skonfigurowany projekt do pracy z biblioteką klienta usługi Azure Blob Storage dla języka Java. Aby dowiedzieć się więcej na temat konfigurowania projektu, w tym instalacji pakietu, dodawania import dyrektyw i tworzenia autoryzowanego obiektu klienta, zobacz Rozpoczynanie pracy z usługami Azure Storage i Java.
Mechanizm autoryzacji musi mieć uprawnienia do ustawiania warstwy dostępu obiektu blob. Aby dowiedzieć się więcej, zobacz wskazówki dotyczące autoryzacji dla następującej operacji interfejsu API REST:
- Ustawianie warstwy obiektu blob

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 obiektów blob

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

Warstwa Gorąca — warstwa online zoptymalizowana pod kątem przechowywania danych, które są często używane lub modyfikowane. Warstwa Gorąca 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łodna powinny być przechowywane przez co najmniej 30 dni. Warstwa Chłodna ma niższe koszty magazynowania i wyższe koszty dostępu w porównaniu z warstwą Gorąca.
Warstwa zimna — warstwa online zoptymalizowana pod kątem przechowywania danych, do których dostęp jest rzadko używany lub modyfikowany. Dane w warstwie Zimna powinny być przechowywane przez co najmniej 90 dni. Warstwa dostępu Zimna ma niższe koszty magazynowania i wyższe koszty dostępu w porównaniu do warstwy Chłodna.
Warstwa Archiwum — warstwa offline zoptymalizowana pod kątem przechowywania rzadko używanych danych i ma elastyczne wymagania dotyczące opóźnień w godzinach. 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, jest uważany za offline i nie można go odczytać ani zmodyfikować. Aby odczytywać lub modyfikować dane w zarchiwizowanym obiekcie blob, należy najpierw przywrócić 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.

Ograniczenia

Ustawienie warstwy dostępu jest dozwolone tylko w blokowych obiektach blob. 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).

Uwaga

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

Ustawianie warstwy dostępu obiektu blob podczas przekazywania

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

Warstwę dostępu istniejącego obiektu blob blokowego można zmienić przy użyciu jednej z następujących metod:

W poniższym przykładzie kodu pokazano, jak zmienić warstwę dostępu na Chłodna dla istniejącego obiektu blob:

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

Jeśli przywracasz zarchiwizowany obiekt 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ść HIGH RehydratePriority 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 obiektu blob można zmienić, określając warstwę dostępu w ramach operacji 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 Archiwum 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 przywrócić zarchiwizowany obiekt blob do warstwy Gorąca 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.

Zasoby

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.

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:

Share via