Festlegen oder Ändern der Zugriffsebene eines Blockblobs mit Java

  • Artikel

In diesem Artikel wird beschrieben, wie die Zugriffsebene eines Blockblobs mithilfe der Azure Storage-Clientbibliothek für Java festgelegt oder geändert wird.

Voraussetzungen

Erstellen Ihrer Umgebung

Wenn Sie nicht über ein vorhandenes Projekt verfügen, wird in diesem Abschnitt gezeigt, wie Sie ein Projekt für die Arbeit mit der Azure Blob Storage-Clientbibliothek für Java einrichten. Weitere Informationen finden Sie unter Erste Schritte mit Azure Blob Storage mit Java.

Um die Codebeispiele in diesem Artikel zu verwenden, führen Sie die folgenden Schritte zum Einrichten Ihres Projekts aus.

Hinweis

In diesem Artikel wird das Maven-Buildtool verwendet, um den Beispielcode zu erstellen und auszuführen. Andere Buildtools (beispielsweise Gradle) können ebenfalls mit dem Azure SDK für Java verwendet werden.

Installieren von Paketen

Öffnen Sie die Datei pom.xml in Ihrem Text-Editor. Installieren Sie die Pakete durch Einbeziehen der BOM-Datei oder Einbeziehen einer direkten Abhängigkeit.

Hinzufügen von Importanweisungen

Fügen Sie die folgenden import -Anweisungen ein:

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;

Autorisierung

Der Autorisierungsmechanismus muss über die erforderlichen Berechtigungen verfügen, um die Zugriffsebene eines Blobs festzulegen. Für die Autorisierung mit Microsoft Entra ID (empfohlen) benötigen Sie mindestens die integrierte Azure RBAC-Rolle Mitwirkender an Storage-Blobdaten. Weitere Informationen finden Sie im Autorisierungsleitfaden für Set Blob Tier.

Erstellen eines Clientobjekts

Um eine App mit Blob Storage zu verbinden, erstellen Sie eine Instanz von BlobServiceClient.

Im folgenden Beispiel wird BlobServiceClientBuilder verwendet, um ein BlobServiceClient-Objekt mithilfe von DefaultAzureCredential zu erstellen, und zeigt, wie Container- und Blob-Clients erstellt werden, falls erforderlich:

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

Weitere Informationen zum Erstellen und Verwalten von Clientobjekten finden Sie unter Erstellen und Verwalten von Clientobjekten, die mit Datenressourcen interagieren.

Informationen zu Zugriffsebenen für Blockblobs

Um die Kosten für die Speicheranforderungen im Blick zu behalten, kann es hilfreich sein, die Daten anhand ihrer Zugriffshäufigkeit und Aufbewahrungsdauer zu organisieren. Azure Storage weist verschiedene Zugriffsebenen auf, sodass Sie Blobdaten basierend auf ihrer Verwendung auf die kostengünstigste Weise speichern können.

Zugriffsebenen für Blobdaten

Folgende Azure Storage-Zugriffsebenen stehen zur Verfügung:

  • Heiße Zugriffsebene: Onlineebene, die für die Speicherung von Daten optimiert ist, auf die häufig zugegriffen wird oder die häufig geändert werden. Die heiße Ebene hat die höchsten Speicherkosten, aber auch die niedrigsten Zugriffskosten.
  • Kalte Zugriffsebene: Onlineebene, die für die Speicherung von Daten optimiert ist, auf die nicht häufig zugegriffen wird oder die nicht häufig geändert werden. Daten auf der kalten Ebene sollten für mindestens 30 Tage gespeichert werden. Für die kalte Ebene fallen im Vergleich zur heißen Ebene niedrigere Speicherkosten, aber höhere Zugriffskosten an.
  • Ebene „Cold“ – Eine Onlineebene, die für die Speicherung von Daten optimiert ist, auf die nur selten zugegriffen wird oder die selten geändert werden. Daten auf der Ebene „Cold“ sollten für mindestens 90 Tage gespeichert werden. Für die Ebene „Cold“ fallen im Vergleich zur kalten Ebene niedrigere Speicherkosten und höhere Zugriffskosten an.
  • Archivebene – Eine Offline-Dienstebene, welche für die Speicherung von Daten optimiert ist, auf die nur selten zugegriffen wird und die flexible Wartezeitanforderungen in der Größenordnung von Stunden aufweist. Daten auf Archivzugriffsebene müssen mindestens 180 Tage lang gespeichert werden.

Weitere Informationen zu Zugriffsebenen finden Sie unter Zugriffsebenen für Blobdaten.

Während ein Blob sich auf der Archivebene befindet, wird es als offline betrachtet und kann nicht gelesen oder geändert werden. Wenn Daten in einem archivierten Blob gelesen oder geändert werden sollen, müssen Sie das Blob zuerst auf einer Onlineebene aktivieren. Weitere Informationen zum Aktivieren eines Blobs aus der Archivebene auf einer Onlineebene finden Sie unter Aktivierung von Blobs aus der Archivebene.

Beschränkungen

Das Festlegen der Zugriffsebene ist nur für Blockblobs gestattet. Weitere Informationen zu Einschränkungen beim Festlegen der Zugriffsebene eines Blockblobs finden Sie unter Festlegen der Blobebene (REST-API).

Hinweis

Zum Festlegen der Zugriffsebene auf Cold mithilfe von Java müssen Sie mindestens die Version 12.21.0 der Clientbibliothek verwenden.

Festlegen der Zugriffsebene eines Blobs während dem Upload

Beim Upload können Sie die Zugriffsebene eines Blobs festlegen, indem Sie die Klasse BlobUploadFromFileOptions verwenden. Im folgenden Codebeispiel wird gezeigt, wie die Zugriffsebene beim Upload eines Blobs festgelegt wird:

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

Weitere Informationen zum Hochladen eines Blobs mit Java finden Sie unter Hochladen eines Blobs mit Java.

Ändern der Zugriffsebene für einen vorhandenen Blockblob

Sie können die Zugriffsebene eines vorhandenen Blockblobs mithilfe einer der folgenden Methoden ändern:

Das folgende Codebeispiel zeigt, wie die Zugriffsebene für ein vorhandenes Blob auf „Kalt“ geändert wird:

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

Wenn Sie ein archiviertes Blob aktivieren, verwenden Sie die Methode setAccessTierWithResponse. Legen Sie den Parameter tier auf einen gültigen AccessTier-Wert von HOT, COOL, COLDoder ARCHIVE fest. Optional können Sie den Parameter priority auf einen gültigen RehydratePriority-Wert von HIGH oder STANDARD festlegen.

Das folgende Codebeispiel zeigt, wie ein archiviertes Blob durch Ändern der Zugriffsebene auf „Heiß“ aktiviert wird:

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

Die Methode setAccessTierWithResponse kann auch einen BlobSetAccessTierOptions-Parameter zur Angabe von Konfigurationsoptionen akzeptieren.

Kopieren eines Blobs in eine andere Zugriffsebene

Sie können die Zugriffsebene eines vorhandenen Blockblobs ändern, indem Sie im Rahmen eines Kopiervorgangs eine Zugriffsebene angeben. Zum Ändern der Zugriffsebene während eines Kopiervorgangs verwenden Sie die Klasse BlobBeginCopyOptions.

Sie können mithilfe der Methode setTier den Wert AccessTier als HOT, COOL, COLD oder ARCHIVEangeben. Wenn Sie ein Blob mithilfe eines Kopiervorgangs aus der Archivebene aktivieren, verwenden Sie die Methode setRehydratePriority zur Angabe des Werts RehydratePriority als HIGH oder STANDARD.

Im folgenden Codebeispiel wird gezeigt, wie ein archiviertes Blob mithilfe eines Kopiervorgangs auf die Ebene „Heiß“ aktiviert wird:

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

Weitere Informationen zum Kopieren eines Blobs mit Java finden Sie unter Kopieren eines Blobs mit Java.

Ressourcen

Weitere Informationen zum Festlegen von Zugriffsebenen mithilfe der Azure Blob Storage-Clientbibliothek für Java finden Sie in den folgenden Ressourcen.

Codebeispiele

REST-API-Vorgänge

Das SDK für Java enthält Bibliotheken, die auf der zugrunde liegenden Azure-REST-API basieren, und ermöglicht Ihnen dadurch die Interaktion mit REST-API-Vorgängen über vertraute Java-Paradigmen. Die Methoden der Clientbibliothek zum Festlegen von Zugriffsebenen verwenden den folgenden REST-API-Vorgang:

Ressourcen zur Clientbibliothek

Siehe auch

Zugehöriger Inhalt

  • Dieser Artikel ist Teil des Blob Storage-Entwicklerleitfadens für Java. Weitere Informationen finden Sie in der vollständigen Liste der Entwicklerleitfadenartikel unter Erstellen Ihrer Java-App.