Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Nesta página, você verá um índice de práticas recomendadas do Cloud Storage. É possível usar
as informações coletadas aqui como uma referência rápida do que precisa ser lembrado ao
criar um aplicativo que usa o Cloud Storage.
Faça uma estimativa do valor do tráfego que será enviado para o Cloud Storage. Pense especificamente em:
Operações por segundo. Quantas operações por segundo você espera, tanto para buckets e objetos, quanto para operações de criação, atualização e exclusão.
Largura de banda. Quantos dados serão enviados, em que período de tempo? Considere
usar uma ferramenta como a Wolfram Alpha
para evitar erros nos seus cálculos.
Controle de cache. Especificar os metadados Cache-Control em objetos acessíveis publicamente
beneficiará a latência de leitura em objetos quentes ou acessados
com frequência.
Consulte a Como visualizar e editar metadados para instruções sobre como configurar
metadados de objeto, como Cache-Control.
Projete seu aplicativo para minimizar picos no tráfego. Se houver clientes do
seu aplicativo fazendo atualizações, distribua-os ao longo do dia.
Ao projetar aplicativos para altas taxas de solicitação, lembre-se dos
limites de taxa para determinadas operações. Conheça os limites de largura de banda para
determinados tipos de saída e siga as
Diretrizes de taxa de solicitação e distribuição de acesso. Esteja ciente principalmente do
escalonamento automático e da necessidade de aumentar gradualmente as taxas de solicitações para ter o melhor
desempenho.
Ao lidar com erros:
Verifique se o aplicativo usa uma estratégia de repetição para
evitar problemas devido a grandes bursts de tráfego.
Tente novamente usando uma nova conexão e, se possível, resolva novamente o nome do domínio. Isso
ajuda a evitar a "aderência do servidor", em que uma nova tentativa tenta passar pelo
mesmo caminho e atinge o mesmo componente não íntegro que a solicitação inicial
atingiu.
Se seu aplicativo for sensível à latência, use solicitações protegidas. As solicitações protegidas permitem que você repita mais rapidamente e reduza a latência de cauda. Elas fazem isso sem
reduzir o prazo da solicitação, o que pode fazer com que as solicitações expirem
prematuramente. Para mais informações, consulte
The Tail at Scale (em inglês).
Entenda o nível de desempenho que os clientes esperam do seu aplicativo. Essas
informações ajudarão você a escolher uma opção de armazenamento e região ao criar novos
buckets. Por exemplo, considere a possibilidade de colocar seus recursos
de computação nos buckets do Cloud Storage para aplicativos de análise.
As solicitações do Cloud Storage se referem a buckets e objetos pelos nomes deles. Como resultado, mesmo que as ACLs impeçam a operação não autorizada de terceiros em buckets ou objetos, um terceiro pode tentar solicitações com nomes de bucket ou de objeto e determinar a existência deles observando as respostas de erro. Dessa forma, é possível que as informações em nomes de bucket ou de objeto vazem. Se você estiver preocupado com a privacidade de seus nomes de bucket ou de objeto, tome as precauções adequadas, como:
Escolher nomes de bucket e de objeto difíceis de adivinhar. Por exemplo, um bucket chamado mybucket-gtbytul3 é aleatório o suficiente, de modo que terceiros não autorizados não possam adivinhá-lo ou enumerar outros nomes de bucket a partir dele.
Evitar usar informações confidenciais como parte de nomes de intervalos ou objetos. Por exemplo, em vez de nomear seu bucket como mysecretproject-prodbucket, uso o nome somemeaninglesscodename-prod. Em alguns aplicativos, convém manter metadados confidenciais em cabeçalhos personalizados do Cloud Storage, como x-goog-meta, em vez de codificá-los nos nomes de objetos.
É preferível usar grupos para listar explicitamente um grande número de usuários. Isso não só torna o escalonamento melhor, mas também fornece uma maneira muito eficiente de atualizar o controle de acesso para um número grande de objetos de uma só vez. Por fim, é mais barato porque você não precisa fazer uma solicitação por objeto para alterar as ACLs.
O sistema de controle de acesso do Cloud Storage inclui a capacidade de especificar
se os objetos serão legíveis publicamente. Confirme se você pretende conceder
acesso público a todos os objetos gravados. Uma vez "publicados", os
dados na Internet podem ser copiados para muitos lugares, por isso é efetivamente impossível
recuperar o controle de leitura sobre um objeto gravado com essa permissão.
O sistema de controle de acesso do Cloud Storage inclui a capacidade de
especificar se os buckets serão graváveis publicamente. Mesmo que configurar um bucket público
seja conveniente para vários fins, recomendamos não usar essa permissão. Ela pode
propagar conteúdo ilegal, vírus e outros malwares, e o proprietário do bucket é legal e
financeiramente responsável
pelo conteúdo armazenado nos seus buckets.
Se você precisar disponibilizar o conteúdo com segurança para usuários que não têm contas de usuário, recomendamos que você use URLs assinados. Por exemplo, com URLs assinados, você pode fornecer um link para um objeto e os clientes do seu aplicativo não precisam se autenticar com o Cloud Storage para acessá-lo. Quando você cria um URL assinado, controla o tipo (leitura, gravação, exclusão) e a duração do acesso.
Uploads de dados
Se você usa callbacks XMLHttpRequest (XHR) para receber atualizações de progresso, não feche e reabra a conexão se detectar que o progresso parou.
Isso cria um loop de feedback positivo inválido durante os períodos de congestionamento da rede. Quando a rede está congestionada, os callbacks XHR podem ficar atrasados em relação à atividade de confirmação (ACK/NACK) do fluxo de upload, e fechar e reabrir a conexão quando isso acontece usa mais capacidade de rede exatamente no momento em que você menos pode arcar com isso.
Para o tráfego de upload, recomendamos a configuração de tempos limite razoavelmente longos. Para uma boa experiência do usuário final, é possível definir um timer do lado do cliente que atualiza a janela de status do cliente com uma mensagem (por exemplo, "congestionamento de rede") quando seu aplicativo não recebe um callback XHR por muito tempo. Não feche a conexão e tente novamente quando isso acontecer.
Uma maneira fácil e conveniente de reduzir a largura de banda necessária para cada solicitação é
ativar a compactação no formato gzip. Embora isso exija mais Tempo de CPU para
descompactar os resultados, a redução dos custos de rede normalmente faz com que esse método
valha muito a pena.
Um objeto que foi enviado em gzip geralmente também pode ser exibido
nesse formato. No entanto, evite fazer upload de conteúdo que tenha
content-encoding: gzip e um content-type compactado, porque isso
pode levar a um comportamento inesperado.
Recomendamos o uso de uploads retomáveis, que permitem retomar
a transferência de dados, mesmo quando uma falha de comunicação interrompe o fluxo
de dados. Você também pode usar uploads de várias partes da API XML para fazer upload de partes de um arquivo
em paralelo, o que pode reduzir o tempo para concluir o upload
geral.
Exclusão de dados
Consulte Excluir objetos para ver diretrizes e considerações sobre a exclusão de dados.
Também é possível usar recursos para controlar os ciclos de vida dos dados a fim de evitar que eles sejam excluídos por engano pelo software ou pelos usuários do seu aplicativo.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-08-18 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."]]
