Ringkasan replikasi

Replikasi untuk Bigtable memungkinkan Anda meningkatkan ketersediaan dan ketahanan data dengan menyalinnya ke 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. Dokumen ini juga menjelaskan model konsistensi yang digunakan Bigtable saat replikasi diaktifkan dan menjelaskan apa yang terjadi saat satu cluster melakukan 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 memahami ringkasan Bigtable.

Cara kerja replikasi

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

Instance Bigtable dapat memiliki cluster yang berlokasi di hingga 8 region Bigtable, dan di setiap 8 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 Anda meskipun satu zona atau region tidak tersedia. Google Cloud

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 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 dalam tabel yang ada
  • Tabel baru dan yang dihapus
  • Menambahkan dan menghapus grup 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 agar permintaan dari berbagai jenis aplikasi dirutekan ke berbagai cluster.

Sebelum menambahkan cluster ke instance, Anda harus mengetahui batasan yang berlaku saat mengubah kebijakan pengumpulan 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 satu cluster. Misalnya, cluster yang direplikasi di berbagai region 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 penayangan dari pembacaan batch

Saat Anda menggunakan satu cluster untuk menjalankan tugas analisis batch yang melakukan banyak operasi baca besar bersama dengan aplikasi yang melakukan campuran operasi baca dan tulis, tugas batch besar dapat memperlambat kinerja aplikasi bagi pengguna. Dengan replikasi, Anda dapat menggunakan profil aplikasi dengan pemilihan rute satu cluster 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 sebuah instance hanya memiliki satu cluster, ketahanan dan ketersediaan data Anda akan dibatasi pada zona tempat cluster tersebut berada. Replikasi dapat meningkatkan ketahanan dan ketersediaan dengan menyimpan salinan data terpisah di beberapa zona atau region dan melakukan failover otomatis antar-cluster jika diperlukan. Pelajari lebih lanjut cara menerapkan kasus penggunaan ini.

Menyediakan pencadangan hampir real-time

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

Pastikan data Anda memiliki kehadiran global

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

Model konsistensi

Bagian ini menjelaskan model konsistensi yang dapat disediakan Bigtable untuk replikasi, bergantung pada kebijakan perutean yang Anda gunakan.

Konsistensi tertunda

Secara default, replikasi untuk Bigtable memiliki konsistensi tertunda. Istilah ini berarti bahwa ketika Anda menulis perubahan ke satu cluster, Anda pada akhirnya 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, replikasi mungkin memerlukan waktu untuk mengejar ketertinggalan. 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 penulisan memberi Bigtable cukup waktu untuk mereplikasi perubahan.

Konsistensi read-your-write

Anda dapat mencapai konsistensi read-your-writes dengan perutean cluster tunggal, dan Anda dapat mencapai tingkat konsistensi read-your-writes yang tinggi dengan menggunakan perutean multi-cluster dengan perutean afinitas baris atau saat cluster instance Anda masing-masing berada di region yang berbeda.

Pemilihan rute cluster tunggal

Jika Anda menggunakan perutean satu cluster, Bigtable dapat memberikan konsistensi read-your-writes saat replikasi diaktifkan. Model konsistensi ini memastikan bahwa aplikasi tidak pernah membaca data yang lebih lama daripada penulisan terbarunya.

Setiap profil aplikasi yang Anda gunakan harus dikonfigurasi untuk perutean cluster tunggal, dan semua profil aplikasi harus merutekan permintaan ke cluster yang sama. Anda dapat menggunakan cluster tambahan instance secara bersamaan untuk tujuan lain.

Pemilihan rute multi-cluster dengan satu cluster per region

Dengan pemilihan rute multi-cluster, Bigtable selalu merutekan permintaan ke cluster terdekat. Jika setiap cluster di instance Anda berada di region Bigtable yang berbeda, dan Anda menggunakan profil aplikasi yang dikonfigurasi untuk perutean multi-cluster, maka data Anda memiliki konsistensi read-your-writes dalam region sumber kecuali jika terjadi failover.

Pemilihan rute afinitas baris

Untuk mencapai tingkat konsistensi baca-tulis yang lebih tinggi dengan perutean multi-cluster ke instance yang memiliki lebih dari satu cluster dalam suatu region, Anda dapat menggunakan profil aplikasi yang dikonfigurasi untuk perutean afinitas baris (perutean tetap).

Dengan perutean afinitas baris, Bigtable secara otomatis merutekan permintaan baca dan tulis baris tunggal Anda ke cluster tertentu berdasarkan kunci baris permintaan. Anda tidak dapat menetapkan pemetaan antara kunci baris dan cluster secara manual. Konsistensi tidak dijamin karena permintaan masih dapat gagal karena berbagai alasan, termasuk saat cluster tidak berfungsi dengan baik, ada masalah jaringan, atau cluster telah menerima terlalu banyak permintaan.

Konsistensi kuat

Untuk beberapa kasus penggunaan replikasi, Bigtable juga dapat memberikan konsistensi kuat, yang memastikan bahwa semua aplikasi Anda melihat data Anda dalam status yang sama. Untuk mendapatkan konsistensi yang kuat, Anda menggunakan konfigurasi profil aplikasi perutean satu cluster untuk konsistensi baca-tulis yang dijelaskan sebelumnya, tetapi Anda tidak boleh menggunakan cluster tambahan instance kecuali jika Anda perlu melakukan pengalihan 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. Jika dua operasi tulis dengan empat tuple yang sama persis dikirim ke dua cluster yang berbeda, Bigtable akan otomatis menyelesaikan konflik menggunakan algoritma penulisan terakhir menang internal berdasarkan waktu sisi server. Implementasi "penulisan terakhir menang" Bigtable bersifat deterministik, dan saat replikasi selesai, semua cluster akan 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 satu baris, yang mencakup operasi baca-ubah-tulis (termasuk penambahan dan penyisipan) serta operasi periksa dan ubah (juga dikenal sebagai mutasi bersyarat atau penulisan 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 perutean meliputi hal berikut:

  • Perutean cluster tunggal: Mengirim semua permintaan ke satu cluster yang Anda tentukan.
  • Perutean multi-cluster:
    • Perutean cluster apa pun: Mengirim permintaan ke cluster terdekat di instance.
    • Perutean grup cluster: Membatasi semua permintaan ke cluster yang Anda tentukan.
    • Perutean afinitas baris: Mengirim permintaan baca atau tulis satu baris ke cluster tertentu berdasarkan kunci baris permintaan. Untuk mengetahui informasi selengkapnya, lihat Perutean afinitas baris.

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 konfigurasi profil aplikasi. Untuk mengetahui detailnya, lihat Failover.

Menjatuhkan 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, penghapusan rentang baris akan jauh lebih lambat dan kurang efisien.

Langkah berikutnya