Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Halaman ini berisi indeks praktik terbaik untuk Cloud Storage. Anda dapat menggunakan informasi yang dikumpulkan di sini sebagai referensi cepat tentang hal-hal yang perlu diingat ketika membangun aplikasi yang menggunakan Cloud Storage.
Lakukan estimasi cepat terkait jumlah traffic yang akan dikirim ke Cloud Storage. Secara khusus, pikirkan tentang:
Operasi per detik. Jumlah operasi per detik yang Anda harapkan, untuk bucket dan objek, serta untuk operasi pembuatan, update, dan penghapusan.
Bandwidth. Berapa banyak data yang akan dikirim, dalam jangka waktu berapa? Pertimbangkan
untuk menggunakan alat seperti Wolfram Alpha
untuk menghindari kesalahan dalam perhitungan Anda.
Kontrol cache. Menentukan metadata Cache-Control pada objek yang dapat diakses secara publik akan menguntungkan latensi baca pada objek panas atau yang sering diakses.
Baca bagian Melihat dan Mengedit Metadata untuk mengetahui petunjuk cara menyetel metadata objek, seperti Cache-Control.
Desain aplikasi Anda untuk meminimalkan lonjakan traffic. Jika ada klien aplikasi Anda yang melakukan update, sebarkan aktivitas tersebut sepanjang hari.
Saat mendesain aplikasi untuk rasio permintaan yang tinggi, perhatikan pembatasan kapasitas untuk operasi tertentu. Ketahui batas bandwidth untuk jenis traffic keluar tertentu dan ikuti Panduan Distribusi Akses dan Rasio Permintaan. Perhatikan
penskalaan otomatis dan kebutuhan untuk meningkatkan rasio permintaan secara bertahap untuk mendapatkan performa
terbaik.
Saat menangani error:
Pastikan aplikasi Anda menggunakan strategi coba lagi untuk menghindari masalah akibat burst traffic yang besar.
Coba lagi menggunakan koneksi baru dan mungkin selesaikan ulang nama domain. Hal ini
membantu menghindari "kelekatan server", saat percobaan ulang mencoba melalui
jalur yang sama dan mencapai komponen tidak responsif yang sama dengan yang dicapai
permintaan awal.
Jika aplikasi Anda sensitif terhadap latensi, gunakan permintaan yang dilindungi. Dengan permintaan yang dilindungi,
Anda dapat mencoba ulang dengan lebih cepat dan mengurangi latensi tail. Hal ini dilakukan tanpa
mengurangi batas waktu permintaan, yang dapat menyebabkan waktu habis
lebih awal. Untuk informasi selengkapnya, lihat
Tail dalam Skala.
Pahami tingkat performa yang diharapkan pelanggan dari aplikasi Anda. Informasi ini membantu Anda memilih opsi penyimpanan dan region saat membuat bucket baru. Misalnya, pertimbangkan untuk menempatkan resource komputasi Anda dengan bucket Cloud Storage untuk aplikasi analisis.
Permintaan Cloud Storage merujuk pada bucket dan objek berdasarkan namanya. Akibatnya, meskipun ACL mencegah pihak ketiga yang tidak berwenang untuk beroperasi pada bucket atau objek, pihak ketiga dapat mencoba permintaan dengan nama bucket atau objek dan menentukan keberadaannya dengan mengamati respons error. Kemudian, ada kemungkinan informasi dalam bucket atau nama objek bocor. Jika khawatir dengan privasi nama bucket atau objek, Anda harus melakukan tindakan pencegahan yang sesuai, seperti:
Memilih nama bucket dan objek yang sulit ditebak. Misalnya, bucket bernama mybucket-gtbytul3 cukup acak sehingga pihak ketiga yang tidak memiliki otorisasi tidak dapat menebaknya dengan mudah atau menghitung nama bucket lain darinya.
Menghindari penggunaan informasi sensitif sebagai bagian dari nama bucket atau
objek. Misalnya, beri nama somemeaninglesscodename-prod pada bucket, bukan mysecretproject-prodbucket. Di beberapa aplikasi, Anda mungkin ingin menyimpan metadata sensitif di header Cloud Storage kustom seperti x-goog-meta, daripada mengenkode metadata dalam nama objek.
Sebaiknya gunakan grup untuk mencantumkan secara eksplisit pengguna dalam jumlah besar. Selain
skalanya lebih baik, juga memberikan cara yang sangat efisien untuk memperbarui
kontrol akses untuk sejumlah besar objek sekaligus. Terakhir, lebih murah karena Anda tidak perlu membuat permintaan per objek untuk mengubah ACL.
Sistem kontrol akses Cloud Storage mencakup kemampuan untuk menentukan bahwa objek dapat dibaca oleh publik. Pastikan Anda ingin agar objek apa pun yang Anda tulis dengan izin ini dapat dilihat oleh publik. Setelah "dipublikasikan", data di
Internet dapat disalin ke banyak tempat, sehingga secara efektif tidak mungkin untuk
mendapatkan kembali kontrol baca atas objek yang ditulis dengan izin ini.
Sistem kontrol akses Cloud Storage mencakup kemampuan untuk menentukan bahwa bucket dapat ditulis secara publik. Meskipun mengonfigurasi bucket dengan cara ini dapat digunakan untuk berbagai tujuan, sebaiknya jangan gunakan izin ini. Izin ini dapat disalahgunakan untuk mendistribusikan konten ilegal, virus, dan malware lainnya, serta pemilik bucket secara hukum dan bertanggung jawab secara finansial
atas konten yang disimpan di bucket mereka.
Jika Anda perlu menyediakan konten dengan aman bagi pengguna yang tidak memiliki akun pengguna, sebaiknya gunakan URL bertanda tangan. Misalnya, dengan URL bertanda tangan, Anda dapat memberikan link ke suatu objek, dan pelanggan aplikasi Anda tidak perlu melakukan autentikasi dengan Cloud Storage untuk mengakses objek tersebut. Saat membuat URL bertanda tangan, Anda mengontrol jenis (baca, tulis, hapus) dan durasi akses.
Upload data
Jika Anda menggunakan callback XMLHttpRequest (XHR) untuk mendapatkan update progres, jangan
menutup dan membuka kembali koneksi jika mendeteksi progres tersebut terhenti.
Tindakan ini akan menghasilkan feedback loop positif yang buruk selama periode kemacetan
jaringan. Ketika jaringan padat, callback XHR dapat terhambat
di balik aktivitas konfirmasi (ACK/NACK) dari aliran upload, serta
menutup dan membuka kembali koneksi saat hal ini terjadi akan menggunakan lebih banyak
kapasitas jaringan ketika Anda paling tidak mampu.
Untuk traffic upload, sebaiknya setel waktu tunggu yang cukup lama. Untuk pengalaman pengguna akhir yang baik, Anda dapat menyetel timer sisi klien yang memperbarui jendela status klien dengan pesan (misalnya, "kemacetan jaringan") saat
aplikasi belum menerima callback XHR untuk waktu yang lama. Jangan hanya
menutup koneksi dan coba lagi saat ini terjadi.
Cara yang mudah dan praktis untuk mengurangi bandwidth yang diperlukan untuk setiap permintaan adalah dengan mengaktifkan kompresi gzip. Meskipun penggunaan CPU tambahan memerlukan waktu untuk mengekstrak hasil, manfaatnya terhadap biaya jaringan biasanya sangat sepadan.
Objek yang diupload dalam format gzip umumnya juga dapat disajikan dalam format gzip. Namun, hindari mengupload konten yang memiliki
content-encoding: gzip dan content-type yang dikompresi karena dapat
menyebabkan perilaku yang tidak terduga.
Sebaiknya gunakan upload yang dapat dilanjutkan, yang memungkinkan Anda melanjutkan transfer data meskipun kegagalan komunikasi mengganggu aliran data. Anda juga dapat menggunakan upload multibagian XML API untuk mengupload bagian file
secara paralel, yang berpotensi mengurangi waktu untuk menyelesaikan upload
secara keseluruhan.
Penghapusan data
Lihat Menghapus objek untuk panduan dan pertimbangan dalam menghapus data.
Anda juga dapat menggunakan fitur untuk mengontrol siklus proses data guna membantu melindungi data Anda agar tidak dihapus secara keliru oleh pengguna atau software aplikasi.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 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."]]
