Udostępnij za pośrednictwem

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

  • Artykuł

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

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.

Uwaga

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ść.

Dodawanie instrukcji importu

Dodaj następujące instrukcje 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;

Autoryzacja

Mechanizm autoryzacji musi mieć niezbędne uprawnienia do ustawiania warstwy dostępu obiektu blob. Aby uzyskać autoryzację przy użyciu identyfikatora Entra firmy Microsoft (zalecane), potrzebujesz wbudowanej kontroli dostępu opartej na rolach platformy Azure współautora danych obiektów blob usługi Storage lub nowszego. 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 klasy BlobServiceClient.

W poniższym przykładzie użyto obiektu BlobServiceClientBuilder do skompilowania BlobServiceClient obiektu przy użyciu metody DefaultAzureCredentiali 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 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.

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 też

Powiązana zawartość

  • 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.