Freigeben über


Festlegen oder Ändern der Zugriffsebene eines Blockblobs mit Java

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

Voraussetzungen

  • In diesem Artikel wird davon ausgegangen, dass Sie bereits ein Projekt für die Arbeit mit der Azure Blob Storage-Clientbibliothek für Java eingerichtet haben. Informationen zum Einrichten Ihres Projekts – einschließlich Paketinstallation, Hinzufügen von import-Anweisungen und Erstellen eines autorisierten Clientobjekts – finden Sie unter Erste Schritte mit Azure Storage und Java.
  • Der Autorisierungsmechanismus muss über Berechtigungen zum Festlegen der Zugriffsebene des Blobs verfügen. Weitere Informationen finden Sie im Autorisierungsleitfaden für die folgenden REST-API-Vorgänge:

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.

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

Codebeispiele

Siehe auch