Share via

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

  • Artikel

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.

Vereisten

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.

Notitie

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.

Importinstructies 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;

Autorisatie

Het autorisatiemechanisme moet over de benodigde machtigingen beschikken om de toegangslaag van een blob in te stellen. Voor autorisatie met Microsoft Entra ID (aanbevolen) hebt u ingebouwde Azure RBAC-rol Opslagblobgegevensbijdrager of hoger nodig. Zie de autorisatierichtlijnen voor De bloblaag instellen voor meer informatie.

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 vanDefaultAzureCredential, 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 blok-blob-toegangslagen

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.

Toegangslagen voor blobgegevens

Azure Storage-toegangslagen zijn onder andere:

  • Dynamische laag : een onlinelaag die is geoptimaliseerd voor het opslaan van gegevens die regelmatig worden geopend of gewijzigd. De dynamische 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 statische laag heeft lagere opslagkosten en hogere toegangskosten in vergelijking met de dynamische 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.

Beperkingen

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

Notitie

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 in Statisch 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 reactiveren, 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-waarde HIGH of STANDARD.

In het volgende codevoorbeeld ziet u hoe u een gearchiveerde blob rehydrateert door de toegangslaag te wijzigen in Dynamisch:

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:

Clientbibliotheekbronnen

Zie ook

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