Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Cette page contient un index des bonnes pratiques relatives à Cloud Storage. Les informations collectées ici vous offrent un aperçu rapide des éléments à prendre en compte lors de la création d'une application utilisant Cloud Storage.
Effectuez une estimation approximative de la quantité de trafic qui sera envoyé à Cloud Storage. Plus précisément, prenez en compte les éléments suivants :
Les opérations par seconde. Combien d'opérations par seconde prévoyez-vous, à la fois pour les buckets et pour les objets, ainsi que pour les opérations de création, de mise à jour et de suppression ?
La bande passante. Quel volume de données sera envoyé, et sur quelle période ? Pensez à utiliser un outil tel que Wolfram Alpha pour éviter les erreurs de calcul.
Le contrôle du cache. La spécification des métadonnées Cache-Control sur les objets accessibles au public sera bénéfique pour la latence de lecture des objets actifs ou fréquemment consultés.
Pour savoir comment configurer des métadonnées d'objets comme Cache-Control, consultez la page Afficher et modifier des métadonnées.
Concevez votre application de sorte à réduire le plus possible les pics de trafic. Si des clients de votre application effectuent des mises à jour, répartissez-les tout au long de la journée.
Lorsque vous concevez des applications pour des taux de requêtes élevés, tenez compte des limites de débit pour certaines opérations. Vous devez connaître les limites de bande passante pour certains types de sortie, et suivre les consignes concernant les taux de requêtes et la distribution des accès. Tenez particulièrement compte de l'autoscaling et de la nécessité d'augmenter progressivement les taux de requêtes afin d'optimiser les performances.
Lors du traitement des erreurs :
Assurez-vous que votre application utilise une stratégie de nouvelle tentative afin d'éviter les problèmes dus à des pics importants de trafic.
réessayez avec une nouvelle connexion, en tentant éventuellement de résoudre de nouveau le nom de domaine. Votre nouvelle tentative emprunte ainsi un chemin d'accès différent pour éviter de rencontrer le même composant défectueux que la requête initiale.
Si votre application est sensible au temps de latence, utilisez des requêtes couvertes (requêtes doublées). Les requêtes couvertes vous permettent d'effectuer de nouvelles tentatives plus rapidement et de réduire la latence de queue. Notez également qu'avec cette approche, le délai d'expiration des requêtes est préservé (sa réduction pourrait entraîner l'expiration prématurée des requêtes). Pour en savoir plus, consultez l'article The Tail at Scale (en anglais).
Déterminez le niveau de performances que vos clients attendent de votre application. Cela vous aide à choisir une option de stockage et une région lors de la création de buckets. Par exemple, envisagez de colocaliser vos ressources de calcul avec vos buckets Cloud Storage pour les applications d'analyse.
Les requêtes Cloud Storage désignent les buckets et les objets par leur nom. Par conséquent, même si les LCA empêchent les tiers non autorisés d'effectuer des opérations sur des buckets ou des objets, un tiers peut tenter d'envoyer des requêtes comportant des noms de buckets ou d'objets, et déterminer leur existence en observant les réponses d'erreur. Il est alors possible que des informations contenues dans des noms de buckets ou d'objets soient divulguées. Si la confidentialité de vos noms de buckets ou d'objets vous préoccupe, vous devez prendre les précautions appropriées, par exemple :
Choisissez des noms de buckets et d'objets difficiles à deviner. Par exemple, le nom de bucket mybucket-gtbytul3 est suffisamment aléatoire pour que des tiers non autorisés ne puissent pas le deviner ni en déduire d'autres noms.
Évitez d'indiquer des informations sensibles dans les noms de buckets ou d'objets. Par exemple, au lieu de nommer votre bucket mysecretproject-prodbucket, appelez-le somemeaninglesscodename-prod. Dans certaines applications, vous pouvez conserver des métadonnées sensibles dans des en-têtes Cloud Storage personnalisés tels que x-goog-meta, plutôt que de les encoder dans des noms d'objets.
L'utilisation de groupes est préférable à la liste explicite d'un grand nombre d'utilisateurs. Non seulement leur scaling est meilleur, mais ils constituent également un moyen très efficace pour mettre à jour le contrôle des accès pour un grand nombre d'objets simultanément. Enfin, le coût est plus avantageux, car vous n'avez pas besoin d'émettre une requête par objet pour modifier les LCA.
Le système de contrôle des accès de Cloud Storage permet de spécifier que les objets sont lisibles publiquement. Assurez-vous que tous les objets que vous écrivez avec cette autorisation sont publics. Une fois "publiées", les données sur Internet peuvent être copiées à de nombreux endroits. Il est donc impossible de reprendre le contrôle en lecture d'un objet écrit avec cette autorisation.
Le système de contrôle des accès de Cloud Storage permet de spécifier que les buckets sont publiquement accessibles en écriture. Bien qu'il puisse être pratique de configurer un bucket de cette manière pour diverses raisons, nous vous déconseillons d'utiliser cette autorisation. Elle peut être employée de manière abusive pour diffuser des contenus illégaux, des virus et d'autres logiciels malveillants. Le propriétaire du bucket est juridiquement et financièrement responsable du contenu stocké dans son bucket.
Si vous devez mettre du contenu à la disposition d'utilisateurs de manière sécurisée, et que ceux-ci ne possèdent pas de compte utilisateur, nous vous recommandons d'utiliser des URL signées. Ces dernières vous permettent par exemple de fournir un lien vers un objet. Les clients de votre application n'ont pas besoin de s'authentifier auprès de Cloud Storage pour accéder à l'objet. Lorsque vous créez une URL signée, vous contrôlez le type d'accès (lecture, écriture, suppression) et sa durée.
Importations de données
Si vous utilisez des rappels XMLHttpRequest (XHR) pour obtenir des informations sur la progression, évitez de fermer et de rouvrir la connexion si vous détectez que la progression a cessé.
Cela crée une mauvaise boucle de rétroaction positive pendant les périodes de congestion du réseau. Lorsque le réseau est encombré, les rappels XHR peuvent être mis en attente derrière l'activité d'acquittement (ACK/NACK) du flux d'importation. Le cas échéant, la fermeture et la réouverture de la connexion entraînent une utilisation plus importante de la capacité du réseau, précisément au moment où vous pouvez le moins vous le permettre.
Pour le trafic d'importation, nous vous recommandons de définir des délais avant expiration raisonnablement longs. Pour garantir une bonne expérience aux utilisateurs finaux, vous pouvez définir un minuteur côté client qui met à jour la fenêtre d'état du client avec un message (par exemple, "encombrement du réseau") lorsque votre application n'a pas reçu de rappel XHR depuis longtemps. Lorsque cela se produit, ne vous contentez pas de fermer la connexion et effectuez une nouvelle tentative.
La compression gzip est un moyen pratique et facile de réduire la bande passante requise pour chaque requête. Même si la décompression des résultats nécessite un temps CPU supplémentaire, la compression est généralement très avantageuse en termes de coûts de réseau.
Un objet importé au format gzip peut généralement être diffusé au format gzip également. Toutefois, évitez d'importer des contenus ayant à la fois content-encoding: gzip et un content-type compressé, car cela pourrait entraîner un comportement inattendu.
Nous vous recommandons d'utiliser des importations avec reprise, qui vous permettent de reprendre le transfert de données même lorsqu'un échec de communication a interrompu le flux de données. Vous pouvez également utiliser les importations en plusieurs parties de l'API XML pour importer des parties d'un fichier en parallèle, ce qui peut potentiellement réduire le temps nécessaire à l'importation globale.
Suppression de données
Consultez la page Supprimer des objets pour obtenir des instructions et des considérations sur la suppression de données.
Vous pouvez également utiliser des fonctionnalités de contrôle du cycle de vie des données pour éviter que vos données ne soient supprimés par erreur par votre logiciel d'application ou des utilisateurs.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/10 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/09/10 (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."]]
