Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Questa pagina contiene un indice delle best practice per Cloud Storage. Puoi utilizzare
le informazioni raccolte qui come riferimento rapido di ciò che devi tenere presente quando
crei un'applicazione che utilizza Cloud Storage.
Esegui una stima approssimativa della quantità di traffico che verrà
inviata a Cloud Storage. Nello specifico, pensa a:
Operazioni al secondo. Quante operazioni al secondo prevedi, per
bucket e oggetti e per le operazioni di creazione, aggiornamento ed eliminazione.
Larghezza di banda. Quanti dati verranno inviati e in quale periodo di tempo? Valuta la possibilità di
utilizzare uno strumento come Wolfram Alpha
per evitare errori nei calcoli.
Controllo cache. La specifica dei metadati Cache-Control sugli oggetti accessibili pubblicamente migliorerà la latenza di lettura degli oggetti ad accesso frequente.
Consulta Visualizzazione e modifica dei metadati per istruzioni sulla configurazione dei metadati degli oggetti, ad esempio Cache-Control.
Progetta la tua applicazione in modo da ridurre al minimo i picchi di traffico. Se ci sono clienti della tua applicazione che eseguono aggiornamenti, distribuiscili nel corso della giornata.
Assicurati che la tua applicazione utilizzi una strategia di ripetizione per evitare problemi dovuti a picchi di traffico elevati.
Riprova a utilizzare una nuova connessione e, se necessario, risolvi di nuovo il nome di dominio. In questo modo si evita la "persistenza del server", in cui un nuovo tentativo segue lo stesso percorso e raggiunge lo stesso componente non integro della richiesta iniziale.
Se la tua applicazione è sensibile alla latenza, utilizza le richieste di copertura. Le richieste protette
ti consentono di riprovare più velocemente e ridurre la latenza di coda. senza ridurre la scadenza della richiesta, il che potrebbe causare la scadenza prematura delle richieste. Per ulteriori informazioni, consulta la sezione
The Tail at Scale.
Comprendere il livello di prestazioni che i clienti si aspettano dalla tua applicazione. Queste
informazioni ti aiutano a scegliere un'opzione di archiviazione e una regione quando crei nuovi
bucket. Ad esempio, valuta la possibilità di collocare le risorse di calcolo insieme ai bucket Cloud Storage per le applicazioni di analisi.
Le richieste Cloud Storage fanno riferimento a bucket e oggetti in base ai loro nomi. Di conseguenza, anche se gli ACL impediscono a terze parti non autorizzate di operare su bucket o oggetti, una terza parte può tentare richieste con nomi di bucket o oggetti e determinarne l'esistenza osservando le risposte di errore. In questo modo, le informazioni nei nomi dei bucket o degli oggetti potrebbero essere divulgate. Se ti
preoccupa la privacy dei nomi dei bucket o degli oggetti, devi prendere
le precauzioni appropriate, ad esempio:
Scegliere nomi difficili da indovinare per bucket e oggetti. Ad esempio, un bucket denominato mybucket-gtbytul3 è sufficientemente casuale da non poter essere indovinato o enumerato da terze parti non autorizzate.
Evitare l'uso di informazioni sensibili nei nomi di bucket o oggetti. Ad esempio, anziché chiamare il bucket
mysecretproject-prodbucket, chiamalo somemeaninglesscodename-prod. In
alcune applicazioni, potresti voler conservare i metadati sensibili nelle
intestazioni Cloud Storage personalizzate come x-goog-meta, anziché codificare
i metadati nei nomi degli oggetti.
L'utilizzo dei gruppi è preferibile all'elenco esplicito di un numero elevato di utenti. Non solo è più scalabile, ma fornisce anche un modo molto efficiente per aggiornare il controllo dell'accesso dell'accesso per un numero elevato di oggetti contemporaneamente. Infine, è
più economico perché non devi effettuare una richiesta per oggetto per modificare gli ACL.
Il sistema di controllo dell'accesso di Cloud Storage include la possibilità di specificare che gli oggetti siano leggibili pubblicamente. Assicurati che tutti gli oggetti che scrivi con questa autorizzazione siano pubblici. Una volta "pubblicati", i dati su
internet possono essere copiati in molti luoghi, quindi è praticamente impossibile
recuperare il controllo di lettura di un oggetto scritto con questa autorizzazione.
Il sistema di controllo dell'accesso a Cloud Storage include la possibilità di
specificare che i bucket sono scrivibili pubblicamente. Sebbene la configurazione di un bucket in questo modo possa essere utile per vari scopi, sconsigliamo di utilizzare questa autorizzazione, in quanto può essere utilizzata in modo improprio per distribuire contenuti illegali, virus e altri malware. Inoltre, il proprietario del bucket è legalmente e finanziariamente responsabile dei contenuti archiviati nei suoi bucket.
Se devi rendere disponibili in modo sicuro i contenuti agli utenti che non hanno account utente, ti consigliamo di utilizzare gli URL firmati. Ad esempio, con gli URL firmati puoi fornire un link a un oggetto e i clienti della tua applicazione non devono autenticarsi con Cloud Storage per accedere all'oggetto. Quando
crei un URL firmato, controlli il tipo (lettura, scrittura, eliminazione) e la durata
dell'accesso.
Caricamenti di dati
Se utilizzi i callback XMLHttpRequest (XHR) per ricevere aggiornamenti sullo stato di avanzamento, non
chiudere e riaprire la connessione se rilevi che l'avanzamento è bloccato.
In questo modo si crea un ciclo di feedback positivo negativo durante i periodi di congestione della rete. Quando la rete è congestionata, i callback XHR possono accumularsi
dietro l'attività di riconoscimento (ACK/NACK) del flusso di caricamento e
la chiusura e la riapertura della connessione in questo caso utilizzano più capacità di rete
esattamente nel momento in cui puoi permettertelo meno.
Per il traffico di caricamento, ti consigliamo di impostare timeout ragionevolmente lunghi. Per una buona
esperienza utente finale, puoi impostare un timer lato client che aggiorni la finestra di stato del client
con un messaggio (ad es. "congestione della rete") quando la tua
applicazione non ha ricevuto un callback XHR per molto tempo. Non chiudere
la connessione e riprova quando si verifica questo problema.
Un modo semplice e pratico per ridurre la larghezza di banda necessaria per ogni richiesta è
attivare la compressione gzip. Sebbene ciò richieda ulteriore tempo della CPU per
decomprimere i risultati, il compromesso con i costi di rete di solito lo rende
molto utile.
Un oggetto caricato in formato gzip può in genere essere pubblicato anche in formato gzip. Tuttavia, evita di caricare contenuti che presentano sia content-encoding: gzip sia un content-type compresso, in quanto ciò potrebbe comportare un comportamento imprevisto.
Ti consigliamo di utilizzare i caricamenti ripristinabili, che ti consentono di riprendere
il trasferimento dei dati anche quando un errore di comunicazione ha interrotto il flusso
dei dati. Puoi anche utilizzare i caricamenti multiparte dell'API XML per caricare le parti di un file
in parallelo, il che riduce potenzialmente il tempo necessario per completare il caricamento
complessivo.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-09-05 UTC."],[],[],null,["# Best practices for Cloud Storage\n\nThis page contains an index of best practices for Cloud Storage. You can use\nthe information collected here as a quick reference of what to keep in mind when\nbuilding an application that uses Cloud Storage.\n\nIf you are just starting out with Cloud Storage, this page may not be\nthe best place to start, because it does not teach you the basics of how to use\nCloud Storage. If you are a new user, we suggest that you start with\n[Discover object storage with the Google Cloud console](/storage/docs/discover-object-storage-console) or\n[Discover object storage with the gcloud tool](/storage/docs/discover-object-storage-gcloud).\n\nFor best practices for media workloads, see [Best practices for media workloads](/storage/docs/best-practices-media-workload).\n\nNaming\n------\n\nSee [Bucket naming](/storage/docs/buckets#naming) and [Object naming](/storage/docs/objects#naming) for name requirements\nand considerations.\n\nTraffic\n-------\n\n- Perform a back-of-the-envelope estimation of the amount of traffic that will\n be sent to Cloud Storage. Specifically, think about:\n\n - Operations per second. How many operations per second do you expect, for\n both buckets and objects, and for create, update, and delete operations.\n\n - Bandwidth. How much data will be sent, over what time frame? Consider\n using a tool like [Wolfram Alpha](https://www.wolframalpha.com/input?i=350GB+in+5+minutes)\n to avoid mistakes in your calculations.\n\n - Cache control. Specifying the [`Cache-Control` metadata](/storage/docs/metadata#cache-control) on publicly\n accessible objects will benefit read latency on hot or frequently accessed\n objects.\n See [Viewing and Editing Metadata](/storage/docs/viewing-editing-metadata#edit) for instructions for setting object\n metadata, such as `Cache-Control`.\n\n- Design your application to minimize spikes in traffic. If there are clients of\n your application doing updates, spread them out throughout the day.\n\n- When designing applications for high request rates, be aware of\n [rate limits](/storage/quotas) for certain operations. Know the [bandwidth limits](/storage/quotas#bandwidth) for\n certain types of egress and follow the\n [Request Rate and Access Distribution Guidelines](/storage/docs/request-rate). Be especially aware of\n autoscaling and the need to gradually ramp up request rates for the best\n performance.\n\n- When handling errors:\n\n - Make sure your application uses a [retry strategy](/storage/docs/retry-strategy) in order to\n avoid problems due to large traffic bursts.\n\n - Retry using a new connection and possibly re-resolve the domain name. This\n helps avoid \"server stickiness\", where a retry attempts to go through the\n same path and hits the same unhealthy component that the initial request\n hit.\n\n- If your application is latency sensitive, use hedged requests. Hedged requests\n allow you to retry faster and cut down on tail latency. They do this while not\n reducing your request deadline, which could cause requests to time out\n prematurely. For more information, see\n [The Tail at Scale](https://research.google/pubs/pub40801/).\n\n- Understand the performance level customers expect from your application. This\n information helps you choose a storage option and region when creating new\n buckets. For example, consider colocating your compute resources with your\n Cloud Storage buckets for analytics applications.\n\nLocations and data storage options\n----------------------------------\n\nSee the [Storage class](/storage/docs/storage-classes) and [Bucket location](/storage/docs/locations) topics for guidance on how\nto best store your data.\n\nACLs and access control\n-----------------------\n\n- Cloud Storage requests refer to buckets and objects by their names. As a\n result, even though ACLs prevent unauthorized third parties from operating on\n buckets or objects, a third party can attempt requests with bucket or object\n names and determine their existence by observing the error responses. It can\n then be possible for information in bucket or object names to be leaked. If you\n are concerned about the privacy of your bucket or object names, you should take\n appropriate precautions, such as:\n\n - **Choosing bucket and object names that are difficult to guess.** For\n example, a bucket named `mybucket-gtbytul3` is random enough that\n unauthorized third parties cannot feasibly guess it or enumerate other\n bucket names from it.\n\n - **Avoiding use of sensitive information as part of bucket or object\n names.** For example, instead of naming your bucket\n `mysecretproject-prodbucket`, name it `somemeaninglesscodename-prod`. In\n some applications, you may want to keep sensitive metadata in\n [custom Cloud Storage headers](/storage/docs/metadata#custom-metadata) such as `x-goog-meta`, rather than encoding\n the metadata in object names.\n\n- Using groups is preferable to explicitly listing large numbers of users. Not\n only does it scale better, it also provides a very efficient way to update\n the access control for a large number of objects all at once. Lastly, it's\n cheaper as you don't need to make a request per-object to change the ACLs.\n\n- Review and follow [access control best practices](/storage/docs/access-control/best-practices-access-control).\n\n- The Cloud Storage access control system includes the ability to\n specify that objects are publicly readable. Make sure you intend for any\n objects you write with this permission to be public. Once \"published\", data on\n the Internet can be copied to many places, so it's effectively impossible to\n regain read control over an object written with this permission.\n\n- The Cloud Storage access control system includes the ability to\n specify that buckets are publicly writable. While configuring a bucket this\n way can be convenient for various purposes, we recommend against using this\n permission - it can be abused for distributing illegal content, viruses, and\n other malware, and the bucket owner is legally and financially responsible for\n the content stored in their buckets.\n\n If you need to make content available securely to users who don't have user\n accounts, we recommend you use [signed URLs](/storage/docs/access-control/signed-urls). For example, with signed URLs\n you can provide a link to an object, and your application's customers don't\n need to authenticate with Cloud Storage to access the object. When you\n create a signed URL you control the type (read, write, delete) and duration of\n access.\n\nData uploads\n------------\n\n- If you use XMLHttpRequest (XHR) callbacks to get progress updates, do not\n close and re-open the connection if you detect that progress has stalled.\n Doing so creates a bad positive feedback loop during times of network\n congestion. When the network is congested, XHR callbacks can get backlogged\n behind the acknowledgement (ACK/NACK) activity from the upload stream, and\n closing and reopening the connection when this happens uses more network\n capacity at exactly the time when you can least afford it.\n\n- For upload traffic, we recommend setting reasonably long timeouts. For a good\n end-user experience, you can set a client-side timer that updates the client\n status window with a message (e.g., \"network congestion\") when your\n application hasn't received an XHR callback for a long time. Don't just\n close the connection and try again when this happens.\n\n- An easy and convenient way to reduce the bandwidth needed for each request is\n to enable gzip compression. Although this requires additional CPU time to\n uncompress the results, the trade-off with network costs usually makes it\n very worthwhile.\n\n An object that was uploaded in gzip format can generally be served in gzip\n format as well. However, avoid uploading content that has both\n `content-encoding: gzip` and a `content-type` that is compressed, as this\n may lead to [unexpected behavior](/storage/docs/transcoding#gzip-gzip).\n- We recommend using [resumable uploads](/storage/docs/resumable-uploads), which allow you to resume\n transferring data even when a communication failure has interrupted the flow\n of data. You can also use XML API multipart uploads to upload parts of a file\n in parallel, which potentially reduces the time to complete the overall\n upload.\n\nDeletion of data\n----------------\n\nSee [Delete objects](/storage/docs/deleting-objects) for guidelines and considerations on deleting data.\nYou can also use [features for controlling data lifecycles](/storage/docs/control-data-lifecycles) to help protect\nyour data from getting erroneously deleted by your application software or\nusers."]]