Retensi data dengan perjalanan waktu dan fail-safe

Dokumen ini menjelaskan periode retensi data perjalanan waktu dan fail-safe untuk set data. Selama periode perjalanan waktu dan fail-safe, data yang telah diubah atau dihapus dalam tabel mana pun dalam set data akan terus disimpan jika Anda perlu memulihkannya.

Perjalanan waktu dan retensi data

Anda dapat mengakses data yang diubah atau dihapus dari titik mana pun dalam periode perjalanan waktu, yang mencakup tujuh hari terakhir secara default. Perjalanan waktu memungkinkan Anda membuat kueri data yang diperbarui atau dihapus, memulihkan tabel atau set data yang telah dihapus, memulihkan tabel yang telah habis masa berlakunya, atau memulihkan tabel ke titik waktu tertentu.

Anda dapat menetapkan durasi periode perjalanan waktu, dari minimum dua hari hingga maksimum tujuh hari. Periode perjalanan waktu yang lebih lama berguna jika Anda perlu memulihkan data yang telah diperbarui atau dihapus. Dengan periode perjalanan waktu yang lebih singkat, Anda dapat menghemat biaya penyimpanan saat menggunakan model penagihan penyimpanan fisik. Penghematan ini tidak berlaku saat menggunakan model penagihan penyimpanan logis. Untuk mengetahui informasi selengkapnya tentang pengaruh model penagihan penyimpanan terhadap biaya, lihat Penagihan. Anda tidak dapat menetapkan durasi perjalanan waktu kurang dari 2 hari.

Mengonfigurasi periode perjalanan waktu

Anda menetapkan periode perjalanan waktu di tingkat set data atau project. Setelan ini kemudian berlaku untuk semua tabel yang terkait dengan set data atau project.

Menetapkan periode perjalanan waktu level project

Untuk menentukan periode perjalanan waktu default tingkat project, Anda dapat menggunakan pernyataan bahasa definisi data (DDL). Untuk mempelajari cara menetapkan periode perjalanan waktu tingkat project, lihat Mengelola setelan konfigurasi.

Menetapkan periode perjalanan waktu tingkat set data

Untuk menentukan atau mengubah periode perjalanan waktu bagi set data, Anda dapat menggunakanGoogle Cloud konsol, alat command line bq, atau BigQuery API.

Saat mengubah periode perjalanan waktu, jika stempel waktu menentukan waktu di luar periode perjalanan waktu, atau dari sebelum tabel dibuat, kueri akan gagal dan menampilkan error seperti berikut:

Table ID was created at time which is
before its allowed time travel interval timestamp. Creation
time: timestamp

Cara kerja perjalanan waktu

BigQuery menggunakan format penyimpanan berbasis kolom. Artinya, data diatur dan disimpan berdasarkan kolom, bukan baris. Jika Anda memiliki tabel dengan beberapa kolom, nilai untuk setiap kolom di semua baris disimpan bersama dalam blok penyimpanan.

Saat mengubah sel dalam tabel BigQuery, Anda mengubah nilai tertentu dalam baris dan kolom tertentu. Karena BigQuery menyimpan kolom bersama-sama, mengubah satu sel pun dalam kolom biasanya memerlukan pembacaan seluruh blok penyimpanan yang berisi data kolom tersebut untuk baris yang terpengaruh, menerapkan perubahan, lalu menulis versi baru blok penyimpanan tersebut.

Fitur perjalanan waktu berfungsi dengan melacak versi blok penyimpanan yang membentuk tabel Anda. Saat Anda memperbarui data, BigQuery tidak hanya memodifikasi blok penyimpanan yang ada. Sebagai gantinya, BigQuery akan membuat versi baru dari blok penyimpanan yang terpengaruh dengan data yang diperbarui. Versi sebelumnya kemudian dipertahankan untuk tujuan time travel.

BigQuery menggunakan ukuran file dan blok penyimpanan adaptif. Ukuran blok penyimpanan tidak tetap, tetapi dapat bervariasi bergantung pada faktor seperti ukuran tabel dan distribusi datanya. Mengubah satu sel dalam blok penyimpanan akan mengubah data untuk kolom tersebut, yang berpotensi memengaruhi banyak baris. Oleh karena itu, unit data yang diberi versi dan dikirim ke perjalanan waktu sering kali merupakan seluruh blok penyimpanan yang berisi data yang diubah dari kolom tersebut, bukan hanya satu sel.

Oleh karena itu, mengubah satu sel dapat menyebabkan lebih banyak data yang dikirim ke perjalanan waktu daripada hanya ukuran perubahan.

Pengaruh periode perjalanan waktu terhadap pemulihan tabel dan set data

Tabel atau set data yang dihapus menggunakan durasi periode perjalanan waktu yang berlaku pada saat penghapusan.

Misalnya, jika Anda memiliki durasi periode perjalanan waktu selama dua hari, lalu meningkatkan durasinya menjadi tujuh hari, tabel yang dihapus sebelum perubahan tersebut tetap hanya dapat dipulihkan selama dua hari. Demikian pula, jika Anda memiliki durasi periode perjalanan waktu lima hari dan Anda mengurangi durasi tersebut menjadi tiga hari, tabel apa pun yang dihapus sebelum perubahan tersebut akan tetap dapat dipulihkan selama lima hari.

Karena periode perjalanan waktu ditetapkan di tingkat set data, Anda tidak dapat mengubah periode perjalanan waktu set data yang dihapus hingga set data tersebut dipulihkan.

Jika Anda mengurangi durasi periode perjalanan waktu, menghapus tabel, dan kemudian menyadari bahwa Anda memerlukan periode pemulihan yang lebih panjang untuk data tersebut, Anda dapat membuat snapshot tabel dari titik waktu sebelum penghapusan tabel. Anda harus melakukannya saat tabel yang dihapus masih dapat dipulihkan. Untuk mengetahui informasi selengkapnya, lihat Membuat snapshot tabel menggunakan perjalanan waktu.

Perjalanan waktu dan akses tingkat baris

Jika tabel memiliki, atau telah memiliki, kebijakan akses tingkat baris, hanya akun utama yang diberi izin Identity and Access Management (IAM) berikut yang dapat mengakses data historis untuk tabel tersebut:

Izin Resource
bigquery.rowAccessPolicies.overrideTimeTravelRestrictions Tabel yang data historisnya sedang diakses

Peran IAM bawaan berikut memberikan izin bigquery.rowAccessPolicies.overrideTimeTravelRestrictions:

Peran Resource
roles/bigquery.admin Tabel yang data historisnya sedang diakses
roles/bigquery.studioAdmin Tabel yang data historisnya sedang diakses
roles/iam.databasesAdmin Tabel yang data historisnya sedang diakses

Anda juga dapat memberikan izin bigquery.rowAccessPolicies.overrideTimeTravelRestrictions menggunakan peran khusus.

  • Jalankan perintah berikut untuk mendapatkan waktu epoch Unix yang setara dengan meneruskan stempel waktu UTC:

    date -d '2023-08-04 16:00:34.456789Z' +%s000

  • Ganti waktu epoch UNIX 1691164834000 yang diterima dari perintah sebelumnya di alat command line bq. Jalankan perintah berikut untuk memulihkan salinan tabel deletedTableID yang dihapus di tabel restoredTable lain, dalam set data myDatasetID yang sama:

    bq cp myProjectID:myDatasetID.deletedTableID@1691164834000 myProjectID:myDatasetID.restoredTable

Fail-safe

BigQuery menyediakan periode fail-safe. Selama periode fail-safe, data yang dihapus akan otomatis disimpan selama tujuh hari lagi setelah periode perjalanan waktu usai, sehingga data tersedia untuk pemulihan darurat. Data dapat dipulihkan pada level tabel dari titik waktu yang diwakili oleh stempel waktu saat data tersebut dihapus.

Periode fail-safe tidak dapat dikonfigurasi dan tidak dapat diperpanjang. Anda harus memulai dan menyelesaikan pemulihan tabel sebelum periode fail-safe tujuh hari berakhir, sehingga memberikan waktu yang cukup bagi tugas penyalinan untuk selesai berdasarkan ukuran tabel Anda.

Saat Anda melakukan operasi berikut, data yang diganti atau dihapus dapat dipulihkan melalui periode perjalanan waktu. Setelah periode perjalanan waktu berakhir, data ini akan memasuki periode fail-safe untuk waktu pemulihan yang diperpanjang:

  • Penghapusan atau penggantian tabel: Saat tabel dihapus, atau saat datanya diganti sepenuhnya (misalnya, dengan menggunakan WRITE_TRUNCATE disposisi penulisan dalam tugas pemuatan atau dengan menggunakan pernyataan CREATE OR REPLACE TABLE ), konten tabel sebelumnya akan dipertahankan.
  • Penghapusan atau masa berlaku partisi: Jika partisi tertentu dihapus atau masa berlakunya habis dari tabel berpartisi, data yang termasuk dalam partisi tertentu tersebut akan dipertahankan. Partisi lain dalam tabel tidak terpengaruh. Karena Anda tidak dapat memulihkan partisi satu per satu, Anda harus memulihkan seluruh tabel dari stempel waktu sebelum partisi dihapus atau habis masa berlakunya. Jika tabel asli memiliki masa berlaku partisi, setelan tersebut akan disalin ke tabel yang dipulihkan. Untuk mengkueri partisi yang dipulihkan yang lebih lama dari waktu habis masa berlaku partisi, perbarui masa berlaku partisi pada tabel yang dipulihkan.

Memulihkan data dari penyimpanan fail-safe

Anda tidak dapat membuat kueri data di penyimpanan fail-safe secara langsung, dan Anda tidak dapat menyalin tabel dari penyimpanan fail-safe hingga Cloud Customer Care memberikan akses pemulihan fail-safe sementara pada set data. Untuk memulihkan tabel dari penyimpanan fail-safe, hubungi Cloud Customer Care untuk meminta akses pemulihan fail-safe untuk set data Anda, lalu pulihkan tabel sendiri dengan menjalankan tugas penyalinan tabel dengan dekorator stempel waktu @TIME.

Tidak seperti pemulihan perjalanan waktu, yang hanya memperbarui pointer metadata, pemulihan fail-safe harus memulihkan dan mereplikasi blok penyimpanan arsip secara fisik sebelum tugas penyalinan tabel selesai. Saat Anda memulihkan tabel besar atau yang dipartisi secara ketat dari penyimpanan fail-safe, perhatikan perilaku berikut:

  • Waktu dan waktu tunggu habis penyalinan yang lebih lama: Memulihkan tabel multi-terabyte atau tabel dengan banyak partisi dari penyimpanan fail-safe dapat memerlukan waktu yang jauh lebih lama daripada penyalinan tabel standar. Satu tugas penyalinan mungkin akan mengalami waktu tunggu habis atau gagal dengan error internal sementara sebelum semua blok penyimpanan dipulihkan.
  • Progres inkremental di seluruh percobaan ulang: Progres pemulihan fail-safe disimpan secara inkremental. Setiap blok penyimpanan yang dipulihkan sebelum tugas penyalinan kehabisan waktu atau gagal akan tetap dipulihkan. Jika perintah bq cp gagal, coba lagi perintah menggunakan tabel sumber yang sama persis dan dekorator stempel waktu @TIME. Setiap percobaan ulang akan melewati blok yang telah dipulihkan dan terus memulihkan data yang tersisa hingga tugas penyalinan berhasil.
  • Jangka waktu pemulihan yang mendesak: Hubungi Cloud Customer Care sesegera mungkin dalam periode fail-safe tujuh hari, terutama untuk tabel besar, sehingga Anda memiliki cukup waktu untuk menjalankan percobaan ulang sebelum periode fail-safe berakhir.

Penagihan

Jika Anda menetapkan model penagihan penyimpanan ke model penagihan byte fisik, Anda akan ditagih secara terpisah untuk byte yang digunakan untuk penyimpanan perjalanan waktu dan fail-safe. Penyimpanan perjalanan waktu dan fail-safe dikenai biaya sesuai tarif penyimpanan fisik aktif. Anda dapat mengonfigurasi periode perjalanan waktu untuk menyeimbangkan biaya penyimpanan dengan kebutuhan retensi data Anda.

Jika Anda menetapkan model penagihan penyimpanan ke model penagihan byte logis, total biaya penyimpanan untuk penyimpanan perjalanan waktu dan fail-safe disertakan dalam tarif dasar yang ditagihkan kepada Anda.

Tabel berikut menunjukkan perbandingan biaya penyimpanan fisik dan logis:

Model penagihan Apa yang Anda bayar?
Penyimpanan fisik (terkompresi)
  • Anda membayar untuk byte aktif
  • Anda membayar penyimpanan jangka panjang
  • Anda membayar penyimpanan perjalanan waktu
  • Anda membayar untuk penyimpanan yang aman dari kegagalan
Penyimpanan logis (tidak dikompresi) (setelan default)
  • Anda membayar untuk penyimpanan aktif
  • Anda membayar penyimpanan jangka panjang
  • Anda tidak perlu membayar untuk penyimpanan perjalanan waktu
  • Anda tidak perlu membayar untuk penyimpanan fail-safe

Jika menggunakan penyimpanan fisik, Anda dapat melihat byte yang digunakan oleh perjalanan waktu dan fail-safe dengan melihat kolom TIME_TRAVEL_PHYSICAL_BYTES dan FAIL_SAFE_PHYSICAL_BYTES di tabel virtual TABLE_STORAGE dan TABLE_STORAGE_BY_ORGANIZATION. Untuk contoh cara menggunakan salah satu tampilan ini untuk memperkirakan biaya, lihat Memperkirakan penagihan penyimpanan.

Biaya penyimpanan berlaku untuk data perjalanan waktu dan fail-safe, tetapi Anda hanya akan ditagih jika biaya penyimpanan data tidak berlaku di tempat lain di BigQuery. Detail berikut berlaku:

  • Saat tabel dibuat, tidak ada biaya penyimpanan perjalanan waktu atau fail-safe.
  • Jika data diubah atau dihapus, Anda akan dikenai biaya untuk penyimpanan data yang diubah atau dihapus yang disimpan oleh perjalanan waktu selama periode perjalanan waktu dan periode fail-safe. Hal ini mirip dengan harga penyimpanan untuk snapshot dan clone tabel.
  • Tabel sementara tidak ditagih untuk penyimpanan fail-safe.

Contoh retensi data

Tabel berikut menunjukkan cara data yang dihapus atau diubah berpindah di antara periode retensi penyimpanan. Contoh ini menunjukkan situasi saat total penyimpanan aktif adalah 200 GiB dan 50 GiB dihapus dengan periode perjalanan waktu tujuh hari:

Hari ke-0 Hari ke-1 Hari ke-2 Hari ke-3 Hari 4 Hari 5 Hari 6 Hari ke-7 Hari 8 Hari 9 Hari ke-10 Hari ke-11 Hari ke-12 Hari ke-13 Hari ke-14 Hari ke-15
Penyimpanan aktif 200 150 150 150 150 150 150 150 150 150 150 150 150 150 150 150
Penyimpanan perjalanan waktu 50 50 50 50 50 50 50
Penyimpanan fail-safe 50 50 50 50 50 50 50

Menghapus data dari penyimpanan fisik jangka panjang berfungsi dengan cara yang sama.

Batasan

Pengambilan data dengan perjalanan waktu tunduk pada batasan berikut:

Langkah berikutnya