Konsistensi

Halaman ini menjelaskan operasi Cloud Storage mana yang sangat konsisten dan mana yang memiliki konsistensi tertunda. Dalam hal objek yang dapat di-cache dan dapat dibaca secara publik, Anda mengontrol seberapa konsisten operasi pada objek.

Operasi yang sangat konsisten

Cloud Storage memberikan konsistensi global yang kuat untuk operasi berikut:

  • Read-after-write
  • Read-after-metadata-update
  • Read-after-delete
  • Daftar bucket
  • Daftar objek

Saat Anda menulis objek ke Cloud Storage, misalnya saat mengupload, menulis, atau menyalin objek, objek tersebut segera tersedia untuk dibaca dan operasi metadata segera setelah Anda menerima respons sukses terhadap penulisan. Hal ini berlaku untuk semua bucket dan semua class penyimpanan, dan ini berlaku untuk pembuatan objek baru dan penggantian objek yang ada.

Karena penulisan sangat konsisten, Anda tidak akan pernah menerima respons 404 Not Found atau data yang tidak berlaku untuk operasi read-after-write atau read-after-metadata-update, bahkan untuk bucket yang terletak di dual-region atau multi-region. Dalam kasus yang jarang terjadi saat data Anda belum direplikasi di seluruh region, tetapi lokasi tempat objek Anda pertama kali ditulis menjadi tidak tersedia, upaya untuk mengakses objek akan menampilkan respons error 500 yang dapat dicoba lagi.

Konsistensi global yang kuat juga meluas ke operasi penghapusan pada objek. Jika permintaan penghapusan berhasil, upaya segera untuk mendownload objek atau metadatanya akan menghasilkan kode status 404 Not Found. Anda mendapatkan error 404 karena objek sudah tidak lagi ada setelah operasi penghapusan berhasil.

Daftar bucket dan daftar objek sangat konsisten: saat Anda membuat bucket atau objek, lalu segera menjalankan operasi list yang relevan, bucket atau objek yang baru dibuat akan muncul dalam daftar yang ditampilkan.

Untuk bucket, meskipun update metadata sangat konsisten untuk operasi baca setelah update metadata, perubahan konfigurasi yang dihasilkan mungkin memerlukan waktu untuk diterapkan. Misalnya, jika mengaktifkan pembuatan versi objek di bucket, Anda harus menunggu minimal 30 detik sebelum menghapus atau mengganti objek.

Demikian pula untuk kunci HMAC, ada penundaan hingga 3 menit antara saat Anda meminta untuk mengubah status kunci dan saat perubahan status diterapkan. Misalnya, jika menonaktifkan kunci HMAC, Anda harus menunggu setidaknya 3 menit sebelum membuat permintaan untuk menghapus kunci tersebut, karena upaya untuk melakukannya dalam 3 menit pertama dapat gagal.

Operasi yang konsistennya tertunda

Operasi berikut memiliki konsistensi yang tertunda:

  • Memberikan akses atau mencabut akses dari resource.

Biasanya perlu waktu sekitar satu menit hingga operasi ini diterapkan. Dalam beberapa kasus, mungkin diperlukan waktu beberapa menit lebih lama.

Sebagai contoh perilaku yang dapat muncul dari konsistensi yang tertunda, jika Anda menghapus akses pengguna ke bucket, perubahan ini akan langsung tercermin dalam metadata untuk bucket tersebut; namun, pengguna mungkin masih memiliki akses ke bucket selama waktu yang singkat.

Kontrol dan konsistensi cache

Objek dalam cache yang dapat dibaca secara publik mungkin tidak menunjukkan konsistensi yang kuat. Jika Anda mengizinkan objek untuk di-cache, dan objek tersebut berada dalam cache saat diperbarui atau dihapus, objek yang di-cache tidak akan diperbarui atau dihapus hingga masa aktif cache-nya berakhir.

Masa aktif cache objek ditentukan oleh metadata Cache-Control yang terkait dengan objek tersebut. Metadata Cache-Control dapat ditetapkan menggunakan header permintaan Cache-Control yang disertakan dalam upload awal objek, atau dalam pembaruan metadata objek berikutnya. Karena Anda mengontrol metadata Cache-Control, Anda juga mengontrol sejauh mana objek yang di-cache sudah konsisten. Selain itu, meskipun permintaan untuk objek dapat menyertakan header Cache-Control-nya sendiri, header ini diabaikan oleh Cloud Storage jika ditetapkan untuk menghindari konten yang disimpan dalam cache.

Operasi atomik

Cloud Storage memberikan jaminan atomitas untuk sebagian besar operasi yang melibatkan setiap objek, seperti mengupload objek (termasuk menimpa objek yang ada), memperbarui metadata objek, mengganti objek, dan menghapus objek.

Permintaan batch tidak dijamin bersifat atomik. Meskipun operasi tunggal dalam permintaan batch dapat bersifat atomik, semua operasi dalam permintaan batch tidak dapat dijamin bersifat atomik sebagai grup karena beberapa operasi mungkin berhasil, sementara yang lainnya gagal.

Dalam beberapa situasi, Anda mungkin akhirnya mengambil objek versi lama, seperti saat data yang di-cache menjadi usang atau saat Anda melakukan pembacaan rentang tanpa menentukan nomor generasi, dengan objek yang ingin Anda ambil menjadi ditulis ulang. Sebagai praktik terbaik, gunakan prasyarat untuk memastikan Anda mengambil versi objek yang benar.

Langkah selanjutnya