Ringkasan replikasi

Replikasi untuk Bigtable memungkinkan Anda meningkatkan ketersediaan dan ketahanan data dengan menyalinnya di beberapa region atau beberapa zona dalam region yang sama. Anda juga dapat mengisolasi workload dengan merutekan berbagai jenis permintaan ke cluster yang berbeda.

Halaman ini menjelaskan cara kerja replikasi di Bigtable dan menjelaskan beberapa kasus penggunaan umum untuk replikasi. Panduan ini juga menjelaskan model konsistensi yang digunakan Bigtable saat replikasi diaktifkan dan menjelaskan apa yang terjadi saat satu cluster gagal di-failover ke cluster lain.

  • Untuk contoh setelan yang dapat Anda gunakan untuk menerapkan kasus penggunaan umum, lihat Contoh konfigurasi replikasi.
  • Untuk mempelajari cara membuat instance yang menggunakan replikasi, lihat Membuat instance.
  • Untuk mempelajari cara mengaktifkan replikasi untuk instance yang ada, lihat Menambahkan cluster.
  • Untuk memahami biaya yang terkait dengan replikasi, lihat Harga.

Sebelum membaca halaman ini, Anda harus sudah memahami ringkasan Bigtable.

Cara kerja replikasi

Untuk menggunakan replikasi di instance Bigtable, buat instance baru dengan lebih dari 1 cluster atau tambahkan cluster ke instance yang ada.

Instance Bigtable dapat memiliki cluster yang terletak di hingga delapan region Bigtable, dan di setiap delapan region tersebut, instance hanya dapat berisi satu cluster per zona. Misalnya, jika Anda membuat instance di 8 region yang masing-masing memiliki 3 zona, instance Anda dapat memiliki hingga 24 cluster.

Setiap zona dalam region hanya dapat berisi satu cluster. Dengan memiliki cluster di zona atau region yang berbeda, Anda dapat mengakses data instance meskipun satu zona atau region Google Cloud tidak tersedia.

Saat Anda membuat instance dengan lebih dari satu cluster, Bigtable akan segera mulai menyinkronkan data Anda antar-cluster, sehingga membuat salinan data yang terpisah dan independen di setiap zona tempat instance Anda memiliki cluster. Demikian pula, saat Anda menambahkan cluster baru ke instance yang ada, Bigtable akan menyalin data yang ada dari zona cluster asli ke zona cluster baru, lalu menyinkronkan perubahan pada data Anda di antara zona tersebut.

Bigtable mereplikasi setiap perubahan pada data Anda, termasuk semua jenis perubahan berikut:

  • Pembaruan pada data di tabel yang ada
  • Tabel baru dan yang dihapus
  • Menambahkan dan menghapus keluarga kolom
  • Perubahan pada kebijakan pembersihan sampah memori grup kolom

Replikasi memiliki beberapa latensi, dan konsistensi antar-cluster bersifat tertunda.

Bigtable memperlakukan setiap cluster dalam instance Anda sebagai cluster utama, sehingga Anda dapat melakukan operasi baca dan tulis di setiap cluster. Anda juga dapat menyiapkan instance sehingga permintaan dari berbagai jenis aplikasi dirutekan ke cluster yang berbeda.

Sebelum menambahkan cluster ke instance, Anda harus mengetahui batasan yang berlaku saat mengubah kebijakan pembersihan sampah untuk tabel yang direplikasi.

Performa

Penggunaan replikasi memiliki implikasi performa yang harus Anda rencanakan saat membuat instance yang direplikasi atau mengaktifkan replikasi dengan menambahkan cluster ke instance cluster tunggal. Misalnya, cluster yang direplikasi di region yang berbeda biasanya memiliki latensi replikasi yang lebih tinggi daripada cluster yang direplikasi di region yang sama. Selain itu, cluster dalam instance yang memiliki lebih dari satu cluster sering kali memerlukan lebih banyak node untuk menangani pekerjaan tambahan dalam menangani replikasi. Untuk mempelajari lebih lanjut, lihat Memahami performa.

Kasus penggunaan

Bagian ini menjelaskan beberapa kasus penggunaan umum untuk replikasi Bigtable. Untuk menemukan setelan konfigurasi terbaik untuk setiap kasus penggunaan, serta tips penerapan untuk kasus penggunaan lainnya, lihat Contoh Setelan Replikasi.

Mengisolasi aplikasi penyaluran dari pembacaan batch

Jika Anda menggunakan satu cluster untuk menjalankan tugas analisis batch yang melakukan banyak operasi baca besar bersama aplikasi yang melakukan campuran operasi baca dan tulis, tugas batch besar dapat memperlambat proses bagi pengguna aplikasi. Dengan replikasi, Anda dapat menggunakan profil aplikasi dengan pemilihan rute cluster tunggal untuk merutekan tugas analisis batch dan traffic aplikasi ke cluster yang berbeda, sehingga tugas batch tidak memengaruhi pengguna aplikasi Anda. Pelajari lebih lanjut cara menerapkan kasus penggunaan ini.

Meningkatkan ketersediaan

Jika instance hanya memiliki satu cluster, ketahanan dan ketersediaan data Anda terbatas pada zona tempat cluster tersebut berada. Replikasi dapat meningkatkan ketahanan dan ketersediaan dengan menyimpan salinan data Anda yang terpisah di beberapa zona atau region dan secara otomatis melakukan failover antar-cluster jika diperlukan. Pelajari lebih lanjut cara menerapkan kasus penggunaan ini.

Memberikan pencadangan hampir secara real-time

Dalam beberapa kasus—misalnya, jika Anda tidak dapat membaca data yang sudah tidak berlaku—Anda harus selalu merutekan permintaan ke satu cluster. Namun, Anda tetap dapat menggunakan replikasi dengan menangani permintaan dengan satu cluster dan menyimpan cluster lain sebagai pencadangan hampir real-time. Jika cluster penyaluran tidak tersedia, Anda dapat meminimalkan periode nonaktif dengan melakukan failover ke cluster cadangan secara manual. Pelajari lebih lanjut cara menerapkan kasus penggunaan ini.

Memastikan data Anda memiliki kehadiran global

Anda dapat menyiapkan replikasi di lokasi di seluruh dunia untuk menempatkan data lebih dekat kepada pelanggan. Misalnya, Anda dapat membuat instance dengan cluster yang direplikasi di Amerika Serikat, Eropa, dan Asia, serta menyiapkan profil aplikasi untuk merutekan traffic aplikasi ke cluster terdekat. Pelajari lebih lanjut cara menerapkan kasus penggunaan ini.

Model konsistensi

Secara default, replikasi untuk Bigtable memiliki konsistensi tertunda. Istilah ini berarti bahwa saat Anda menulis perubahan ke satu cluster, Anda pada akhirnya akan dapat membaca perubahan tersebut dari cluster lain dalam instance, tetapi hanya setelah perubahan direplikasi di antara cluster.

Jika instance Anda responsif, latensi untuk replikasi biasanya beberapa detik atau menit, bukan jam. Namun, jika Anda menulis data dalam jumlah besar ke cluster, atau jika cluster kelebihan beban atau tidak tersedia untuk sementara, perlu waktu agar replikasi dapat mengejar. Selain itu, replikasi dapat memerlukan waktu lebih lama jika cluster Anda berjauhan. Akibatnya, biasanya tidak aman untuk mengasumsikan bahwa Anda selalu membaca nilai terbaru yang ditulis, atau bahwa menunggu beberapa detik setelah operasi tulis memberi Bigtable cukup waktu untuk mereplikasi perubahan.

Jika Anda memerlukan jaminan konsistensi yang berbeda, Bigtable juga dapat memberikan konsistensi baca-tulis saat replikasi diaktifkan, yang memastikan bahwa aplikasi tidak akan pernah membaca data yang lebih lama dari penulisan terbarunya. Untuk mendapatkan konsistensi operasi baca-tulis untuk sekelompok aplikasi, setiap aplikasi dalam grup harus menggunakan profil aplikasi yang dikonfigurasi untuk rute cluster tunggal, dan semua profil aplikasi harus merutekan permintaan ke cluster yang sama. Anda dapat menggunakan cluster tambahan instance secara bersamaan untuk tujuan lain.

Untuk beberapa kasus penggunaan replikasi, Bigtable juga dapat memberikan konsistensi yang kuat, yang memastikan bahwa semua aplikasi Anda melihat data dalam status yang sama. Untuk mendapatkan konsistensi yang kuat, Anda menggunakan konfigurasi profil aplikasi rute cluster tunggal untuk konsistensi baca-tulis yang dijelaskan sebelumnya, tetapi Anda tidak boleh menggunakan cluster tambahan instance kecuali jika Anda perlu beralih ke cluster lain. Tinjau contoh setelan replikasi untuk melihat apakah hal ini memungkinkan untuk kasus penggunaan Anda.

Penyelesaian konflik

Setiap nilai sel dalam tabel Bigtable diidentifikasi secara unik oleh empat tuple (kunci baris, grup kolom, penentu kolom, stempel waktu). Lihat Model penyimpanan Bigtable untuk mengetahui detail selengkapnya tentang ID ini. Dalam kasus yang jarang terjadi, jika dua operasi tulis dengan empat tuple yang sama persis dikirim ke dua cluster yang berbeda, Bigtable akan otomatis menyelesaikan konflik menggunakan algoritma last write wins internal berdasarkan waktu sisi server. Implementasi "last write wins" Bigtable bersifat deterministik, dan saat replika mengejar, semua cluster memiliki nilai yang sama untuk empat tuple.

Profil aplikasi

Jika instance menggunakan replikasi, Anda menggunakan profil aplikasi, atau profil aplikasi, untuk menentukan kebijakan perutean. Profil aplikasi juga menentukan apakah Anda dapat melakukan transaksi baris tunggal, yang mencakup operasi baca-ubah-tulis (termasuk penambahan dan penambahan) dan operasi periksa-dan-ubah (juga dikenal sebagai mutasi bersyarat atau operasi tulis bersyarat).

Untuk mengetahui detailnya, lihat Profil Aplikasi. Untuk contoh setelan yang dapat Anda gunakan untuk menerapkan kasus penggunaan umum, lihat Contoh konfigurasi replikasi.

Kebijakan perutean

Setiap profil aplikasi memiliki kebijakan perutean yang mengontrol cluster mana yang menangani permintaan masuk dari aplikasi Anda. Opsi untuk kebijakan pemilihan rute mencakup hal berikut:

  • Pemilihan rute cluster tunggal: Mengirim semua permintaan ke satu cluster yang Anda tentukan.
  • Pemetaan multi-cluster ke cluster mana pun: Mengirim permintaan ke cluster terdekat yang tersedia di instance.
  • Pemilihan rute grup cluster: Mengirim permintaan ke cluster terdekat yang tersedia dalam grup cluster yang Anda tentukan di setelan profil aplikasi.

Failover

Jika cluster Bigtable menjadi tidak responsif, replikasi memungkinkan traffic masuk mengalami kegagalan ke cluster lain dalam instance yang sama. Failover dapat bersifat manual atau otomatis, bergantung pada profil aplikasi yang digunakan aplikasi dan cara profil aplikasi dikonfigurasi.

Untuk mengetahui detailnya, lihat Failover.

Menghapus rentang baris saat replikasi diaktifkan

Cloud Bigtable Admin API memungkinkan Anda menghapus rentang baris yang berdekatan dari tabel berdasarkan kunci barisnya. Dalam instance yang tidak menggunakan replikasi, Bigtable dapat menghapus rentang baris dengan cepat dan efisien. Namun, jika replikasi diaktifkan, menghapus rentang baris akan jauh lebih lambat dan jauh kurang efisien.

Langkah selanjutnya