Share via

De toegangslaag van een blok-blob instellen of wijzigen met Java

In dit artikel wordt beschreven hoe u de toegangslaag voor een blok-blob instelt of wijzigt met behulp van de Azure Storage-clientbibliotheek voor Java.

Prerequisites

Uw omgeving instellen

Als u geen bestaand project hebt, ziet u in deze sectie hoe u een project instelt voor gebruik met de Azure Blob Storage-clientbibliotheek voor Java. Zie Aan de slag met Azure Blob Storage en Java voor meer informatie.

Als u wilt werken met de codevoorbeelden in dit artikel, volgt u deze stappen om uw project in te stellen.

Note

In dit artikel wordt het Maven-buildhulpprogramma gebruikt om de voorbeeldcode te bouwen en uit te voeren. Andere buildhulpprogramma's, zoals Gradle, werken ook met de Azure SDK voor Java.

Pakketten installeren

Open het pom.xml bestand in de teksteditor. Installeer de pakketten door het BOM-bestand op te slaan of door een directe afhankelijkheid op te slaan.

Importverklaringen toevoegen

Voeg de volgende import instructies toe:

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

Het autorisatiemechanisme moet over de benodigde machtigingen beschikken om de toegangslaag van een blob in te stellen. Voor autorisatie met Microsoft Entra ID (aanbevolen) heeft u de ingebouwde Azure RBAC-rol Storage Blob Data Contributor of hoger nodig. Voor meer informatie, zie de autorisatierichtlijnen voor bloblaag instellen.

Een clientobject maken

Als u een app wilt verbinden met Blob Storage, maakt u een exemplaar van BlobServiceClient.

In het volgende voorbeeld wordt BlobServiceClientBuilder gebruikt om een BlobServiceClient object te bouwen met behulp van DefaultAzureCredential, en ziet u hoe u indien nodig container- en blobclients maakt:

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

Zie Clientobjecten maken en beheren die interactie hebben met gegevensbronnen voor meer informatie over het maken en beheren van clientobjecten.

Over toegangsniveaus voor block blob

Voor het beheren van de kosten voor opslagbehoeften kan het handig zijn om uw gegevens te organiseren op basis van hoe vaak ze worden geopend en hoe lang deze moeten worden bewaard. Azure Storage biedt verschillende toegangslagen, zodat u uw blobgegevens op de meest rendabele manier kunt opslaan op basis van hoe deze worden gebruikt.

Toegangsniveaus voor blobgegevens

Azure Storage-toegangsniveaus omvatten:

  • Hot tier - een online laag die is geoptimaliseerd voor het opslaan van gegevens die vaak worden geopend of gewijzigd. De hete laag heeft de hoogste opslagkosten, maar de laagste toegangskosten.
  • Statische laag : een onlinelaag die is geoptimaliseerd voor het opslaan van gegevens die niet vaak worden geopend of gewijzigd. Gegevens in de statische laag moeten minimaal 30 dagen worden opgeslagen. De koele laag heeft lagere opslagkosten en hogere toegangskosten in vergelijking met de hete laag.
  • Koude laag : een onlinelaag die is geoptimaliseerd voor het opslaan van gegevens die niet vaak worden geopend of gewijzigd. Gegevens in de koude laag moeten minimaal 90 dagen worden opgeslagen. De koude laag heeft lagere opslagkosten en hogere toegangskosten dan de statische laag.
  • Archieflaag: een offlinelaag die is geoptimaliseerd voor het opslaan van gegevens die zelden worden geopend en die flexibele latentievereisten heeft, in de volgorde van uren. Gegevens in de archieflaag moeten minimaal 180 dagen worden opgeslagen.

Zie Toegangslagen voor blobgegevens voor meer informatie over toegangslagen.

Hoewel een blob zich in de archieftoegangslaag bevindt, wordt deze beschouwd als offline en kan deze niet worden gelezen of gewijzigd. Als u gegevens in een gearchiveerde blob wilt lezen of wijzigen, moet u de blob eerst reactiveren naar een onlinelaag. Zie Blob-rehydratatie vanuit de archieflaag voor meer informatie over het reactiveren van een blob vanuit de archieflaag naar een onlinelaag.

Restrictions

Het instellen van de toegangslaag is alleen toegestaan voor blok-blobs. Zie voor meer informatie over beperkingen voor het instellen van de toegangslaag van een blok-blob De Blob-laag instellen (REST API).

Note

Als u de toegangslaag wilt instellen voor Cold het gebruik van Java, moet u een minimale clientbibliotheekversie van 12.21.0 gebruiken.

De toegangslaag van een blob instellen tijdens het uploaden

U kunt de toegangslaag van een blob instellen bij uploaden met behulp van de klasse BlobUploadFromFileOptions . In het volgende codevoorbeeld ziet u hoe u de toegangslaag instelt bij het uploaden van een 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());
    }
}

Zie Een blob uploaden met Java voor meer informatie over het uploaden van een blob met Java.

De toegangslaag voor een bestaande blok-blob wijzigen

U kunt de toegangslaag van een bestaande blok-blob wijzigen met behulp van een van de volgende methoden:

In het volgende codevoorbeeld ziet u hoe u de toegangslaag wijzigt naar Cool voor een bestaande blob.

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

Als u een gearchiveerde blob wilt herstellen, gebruikt u de methode setAccessTierWithResponse. Stel de tier parameter in op een geldige AccessTier-waarde vanHOT, COOLof COLDARCHIVE. U kunt de priority parameter desgewenst instellen op een geldige RehydratePriority-waardeHIGH of STANDARD.

In het volgende codevoorbeeld ziet u hoe u een gearchiveerde blob kunt rehydrateren door de toegangslaag te wijzigen naar Heet:

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

De methode setAccessTierWithResponse kan ook een BlobSetAccessTierOptions-parameter accepteren om configuratieopties op te geven.

Een blob kopiëren naar een andere toegangslaag

U kunt de toegangslaag van een bestaande blok-blob wijzigen door een toegangslaag op te geven als onderdeel van een kopieerbewerking. Als u de toegangslaag tijdens een kopieerbewerking wilt wijzigen, gebruikt u de klasse BlobBeginCopyOptions .

U kunt de methode SetTier gebruiken om de AccessTier-waarde op te geven als HOT, COOL, COLDof ARCHIVE. Als u een blob rehydrateert vanuit de archieflaag met behulp van een kopieerbewerking, gebruikt u de methode setRehydratePriority om de waarde RehydratePriority op te geven als HIGH of STANDARD.

In het volgende codevoorbeeld ziet u hoe u een gearchiveerde blob rehydrateert naar de dynamische laag met behulp van een kopieerbewerking:

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

Zie Een blob kopiëren met Java voor meer informatie over het kopiëren van een blob met Java.

Resources

Zie de volgende resources voor meer informatie over het instellen van toegangslagen met behulp van de Azure Blob Storage-clientbibliotheek voor Java.

Codevoorbeelden

REST API-bewerkingen

De Azure SDK voor Java bevat bibliotheken die zijn gebaseerd op de Azure REST API, zodat u kunt communiceren met REST API-bewerkingen via bekende Java-paradigma's. De clientbibliotheekmethoden voor het instellen van toegangslagen maken gebruik van de volgende REST API-bewerking:

Bronnen van clientbibliotheken

Zie ook

Verwante inhoud

  • Dit artikel maakt deel uit van de ontwikkelaarshandleiding voor Blob Storage voor Java. Zie de volledige lijst met artikelen over ontwikkelaarshandleidingen in Uw Java-app bouwen voor meer informatie.