Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Diese Seite enthält einen Index der Best Practices für Cloud Storage. Sie können die hier erfassten Informationen als Kurzreferenz dafür verwenden, was beim Erstellen einer Anwendung, die Cloud Storage verwendet, zu beachten ist.
Führen Sie eine Überschlagsschätzung des Trafficaufkommens durch, das an Cloud Storage gesendet wird. Berücksichtigen Sie dabei insbesondere Folgendes:
Vorgänge pro Sekunde: Wie viele Vorgänge pro Sekunde erwarten Sie für Buckets und Objekte sowie für das Erstellen, Aktualisieren und Löschen?
Bandbreite: Wie viele Daten werden in welchem Zeitrahmen gesendet? Sie können ein Tool wie Wolfram Alpha verwenden, um Fehler bei Berechnungen zu vermeiden.
Cachesteuerung: Durch die Angabe von Cache-Control-Metadaten bei öffentlich zugänglichen Objekten verringert die Leselatenz bei häufig genutzten oder häufig aufgerufenen Objekten.
Eine Anleitung zum Festlegen von Objektmetadaten wie Cache-Control finden Sie unter Metadaten anzeigen und bearbeiten.
Entwickeln Sie Ihre Anwendung so, dass Trafficspitzen auf ein Minimum reduziert werden. Wenn es in der Anwendung Clients gibt, die Aktualisierungen durchführen, verteilen Sie diese über den Tag.
Beachten Sie beim Entwerfen von Anwendungen für hohe Anfrageraten die Ratenbegrenzungen für bestimmte Vorgänge. Beachten Sie die Bandbreitenlimits für bestimmte Arten von ausgehendem Traffic und folgen Sie den Richtlinien für die Anforderungsrate und Zugriffsverteilung. Achten Sie insbesondere auf Autoscaling und die Notwendigkeit, die Anforderungsraten schrittweise zu erhöhen, um eine optimale Leistung zu erzielen.
Bei der Fehlerbehandlung gilt Folgendes:
Achten Sie darauf, dass Ihre Anwendung eine Wiederholungsstrategie verwendet, um Probleme aufgrund hoher Trafficspitzen zu vermeiden.
Wiederholen Sie den Vorgang mit einer neuen Verbindung und lösen Sie den Domainnamen eventuell noch einmal auf. Dadurch wird eine "Server Stickiness" vermieden, bei der wiederholt versucht wird, über denselben Pfad zu laufen, und dieselbe fehlerhafte Komponente wie bei der ersten Anfrage durchlaufen wird.
Wenn Ihre Anwendung latenzabhängig ist, sollten Sie abgesicherte Anfragen verwenden. Mit abgesicherten Anfragen können Sie den Vorgang schneller wiederholen und die Extremwertlatenz verringern. Hierbei wird die Frist für Anfragen allerdings nicht verkürzt, was dazu führen kann, dass Anfragen vorzeitig ablaufen. Weitere Informationen finden Sie unter The Tail at Scale.
Bestimmen Sie das Leistungsniveau, das Nutzer von Ihrer Anwendung erwarten. Diese Informationen sind nützlich bei der Wahl einer Speicheroption und Region, wenn Sie neue Buckets erstellen. Beispiel: Es kann für Analyseanwendungen vorteilhaft sein, Rechenressourcen und Cloud Storage-Buckets am selben Standort zu platzieren.
Standorte und Datenspeicheroptionen
Informationen dazu, wie Sie Ihre Daten am besten speichern, finden Sie in den Themen Speicherklasse und Bucket-Standort.
ACLs und Zugriffssteuerung
Cloud Storage-Anfragen beziehen sich auf die Namen von Buckets und Objekten. Selbst wenn ACLs verhindern, dass nicht autorisierte Dritte auf Buckets oder Objekte zugreifen, könnten diese versuchen, Anfragen mit Bucket- oder Objektnamen zu senden, um anhand der Fehlermeldungen festzustellen, ob diese existieren. Auf diese Weise können Informationen in Bucket- oder Objektnamen bekannt werden. Wenn Sie Bedenken hinsichtlich der Vertraulichkeit Ihrer Bucket- oder Objektnamen haben, sollten Sie geeignete Vorkehrungen treffen, wie zum Beispiel:
Bucket- und Objektnamen wählen, die schwer zu erraten sind. Beispiel: Der Bucket-Name mybucket-gtbytul3 ist ausreichend willkürlich gewählt, sodass unbefugte Dritte ihn nicht so einfach erraten und keine anderen Bucket-Namen daraus ableiten können.
Keine vertraulichen Informationen als Bestandteile von Bucket- oder Objektnamen verwenden. Beispiel: Anstatt den Bucket mysecretproject-prodbucket zu nennen, nennen Sie ihn somemeaninglesscodename-prod. In manchen Anwendungen kann es sinnvoll sein, vertrauliche Metadaten in benutzerdefinierten Cloud Storage-Headern wie x-goog-meta beizubehalten, statt die Metadaten in Objektnamen zu codieren.
Es ist besser, Gruppen zu verwenden, statt eine große Anzahl an Nutzern explizit aufzulisten. Gruppen lassen sich nicht nur besser skalieren, sie bieten auch eine sehr effiziente Möglichkeit, die Zugriffssteuerung für eine große Anzahl von Objekten gleichzeitig zu aktualisieren. Außerdem ist diese Lösung wirtschaftlicher, da Sie nicht für jedes einzelne Objekt eine Anfrage senden müssen, um die ACLs zu ändern.
Das Zugriffssteuerungssystem von Cloud Storage bietet die Möglichkeit, bestimmte Objekte öffentlich lesbar zu machen. Sie sollten sich sehr sicher sein, dass Objekte, die Sie mit dieser Berechtigung schreiben, öffentlich verfügbar sein sollen. Sobald sie "veröffentlicht" wurden, können Daten im Internet an viele Orte kopiert werden. Daher ist es praktisch unmöglich, später die Kontrolle über den Lesezugriff auf ein Objekt wiederherzustellen, das mit dieser Berechtigung geschrieben wurde.
Das Zugriffssteuerungssystem von Cloud Storage bietet außerdem die Möglichkeit, für Buckets einen öffentlichen Schreibzugriff zu gewähren. Diese Bucket-Konfiguration kann zwar für verschiedene Zwecke nützlich sein, dennoch empfehlen wir, diese Berechtigung nicht zu verwenden. Sie kann missbraucht werden, um illegale Inhalte, Viren und andere Malware zu verbreiten. Der Bucket-Inhaber ist für die in seinen Buckets gespeicherten Inhalte rechtlich und finanziell verantwortlich.
Wenn Sie Inhalte auf sichere Weise Nutzern zur Verfügung stellen möchten, die kein Nutzerkonto haben, sollten Sie signierte URLs verwenden. Mit signierten URLs können Sie zum Beispiel einen Link zu einem Objekt zur Verfügung stellen und die Nutzer Ihrer Anwendung müssen sich für den Zugriff auf dieses Objekt nicht bei Cloud Storage authentifizieren. Wenn Sie eine signierte URL erstellen, bestimmen Sie die Art (Lesen, Schreiben, Löschen) und die Dauer der Zugriffs.
Datenuploads
Wenn Sie XHR-Rückrufe (XMLHttpRequest) verwenden, um Fortschrittsaktualisierungen zu erhalten, vermeiden Sie es, die Verbindung zu trennen und neu aufzubauen, wenn Sie feststellen, dass der Vorgang ins Stocken geraten ist.
Auf diese Weise wird bei Netzwerküberlastung ein falsch-positiver Feedback Loop generiert. Bei Netzwerküberlastung können XHR-Rückrufe hinter die Bestätigungsaktivität (ACK/NACK) aus dem Uploadstream zurückgestellt werden. Wird die Verbindung unter diesen Voraussetzungen getrennt und neu aufgebaut, wird genau in diesem Engpass noch mehr Netzwerkkapazität beansprucht.
Für Uploadtraffic wird empfohlen, ausreichende Zeitlimits einzurichten. Richten Sie für mehr Komfort für die Endnutzer einen clientseitigen Timer ein, der das Statusfenster des Clients mit einer Meldung aktualisiert (z. B. "Netzwerk überlastet"), wenn die Anwendung längere Zeit keinen XHR-Rückruf erhalten hat. Vermeiden Sie es, die Verbindung einfach zu trennen und es noch einmal zu versuchen, wenn dieses Problem auftritt.
Durch Aktivierung der gzip-Komprimierung kann die für jede Anfrage benötigte Bandbreite einfach und bequem reduziert werden. Auch wenn die Dekomprimierung der Ergebnisse zusätzliche CPU-Zeit kostet, lohnt sie sich verglichen mit den Netzwerkkosten durchaus.
Ein Objekt, das im gzip-Format hochgeladen wurde, kann im Allgemeinen auch im gzip-Format bereitgestellt werden. Vermeiden Sie jedoch den Upload von Inhalten, bei denen sowohl content-encoding: gzip als auch ein content-type komprimiert sind, da dies zu unerwartetem Verhalten führen kann.
Wir empfehlen die Verwendung von fortsetzbaren Uploads, mit denen Sie die Datenübertragung auch dann fortsetzen können, wenn ein Kommunikationsfehler den Datenfluss unterbrochen hat. Mit mehrteiligen XML-API-Uploads können Sie auch Teile einer Datei parallel hochladen und dadurch die Zeit für den Gesamtupload reduzieren.
Daten löschen
Richtlinien und Überlegungen zum Löschen von Daten finden Sie unter Objekte löschen.
Sie können auch Features zum Steuern von Datenlebenszyklen verwenden, um zu verhindern, dass Ihre Daten von Ihrer Anwendungssoftware oder von Nutzern fälschlicherweise gelöscht werden.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 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."]]
