Opsi pemilihan rute

Saat mengirim permintaan dari aplikasi ke Bigtable, Anda menggunakan profil aplikasi yang memberi tahu Bigtable cara menangani permintaan. Profil aplikasi menentukan kebijakan perutean untuk permintaan. Untuk instance yang menggunakan replikasi, kebijakan perutean mengontrol cluster mana yang menerima permintaan dan cara penanganan failover.

Dokumen ini menjelaskan kebijakan pemilihan rute yang tersedia untuk profil aplikasi standar.

Kebijakan perutean sangat penting untuk kasus penggunaan isolasi beban kerja, saat Anda tidak dapat menggunakan Peningkatan Data. Anda dapat mengonfigurasinya bersama dengan prioritas permintaan.

Kebijakan perutean tidak memengaruhi replikasi, tetapi Anda harus memahami cara kerja replikasi Bigtable sebelum membaca halaman ini. Anda juga harus membaca Pengalihan.

Pemilihan rute cluster tunggal

Kebijakan perutean cluster tunggal merutekan semua permintaan ke satu cluster di instance Anda. Jika cluster tersebut tidak tersedia, Anda harus melakukan failover secara manual ke cluster lain.

Ini adalah satu-satunya kebijakan pemilihan rute yang memungkinkan Anda mengaktifkan transaksi baris tunggal.

Instance yang direplikasi biasanya memberikan konsistensi akhir. Namun, Anda dapat mencapai konsistensi baca-tulis Anda untuk beban kerja di instance yang direplikasi jika Anda mengonfigurasi profil aplikasi untuk beban kerja tersebut agar menggunakan perutean cluster tunggal untuk mengirim permintaan baca dan tulis ke cluster yang sama. Anda dapat merutekan traffic untuk workload tambahan pada instance yang direplikasi ke cluster lain dalam instance, bergantung pada persyaratan workload Anda.

Pemilihan rute multi-cluster

Kebijakan pemilihan rute multi-cluster merutekan permintaan yang Anda kirim ke instance ke region terdekat tempat instance memiliki cluster. Jika cluster menjadi tidak tersedia, traffic akan otomatis di-failover ke cluster terdekat yang tersedia.

Konfigurasi ini memberikan konsistensi tertunda. Anda tidak dapat mengaktifkan transaksi satu baris dengan perutean multi-cluster, karena transaksi satu baris dapat menyebabkan konflik data saat Anda menggunakan perutean multi-cluster. Untuk mengetahui detailnya, lihat Transaksi baris tunggal.

Gunakan perutean multi-cluster jika Anda menginginkan ketersediaan tinggi (HA). Untuk konfigurasi instance yang direkomendasikan dan detail lebih lanjut, lihat Membuat ketersediaan tinggi (HA).

Dua jenis perutean multi-kluster adalah kluster apa pun dan grup kluster.

Untuk mengetahui informasi selengkapnya tentang pertimbangan perutean terkait SQL, lihat bagian Merutekan dengan SQL dalam dokumen ini.

Pemilihan rute cluster apa pun

Perutean cluster apa pun membuat setiap cluster dalam instance tersedia untuk menerima permintaan dan untuk failover.

Pemilihan rute grup cluster

Jika ingin mengecualikan satu atau beberapa cluster instance dari kemungkinan pengalihan, Anda dapat menggunakan perutean grup cluster. Bentuk perutean multi-cluster ini memungkinkan Anda menentukan subset cluster yang dapat dikirimi traffic oleh profil aplikasi. Hal ini dapat berguna jika Anda ingin mencadangkan cluster untuk beban kerja terpisah.

Pemilihan rute afinitas baris

Perutean afinitas baris secara otomatis merutekan permintaan baca dan tulis baris tunggal ke cluster tertentu berdasarkan kunci baris permintaan.

Jika Anda ingin perutean multi-cluster mencapai tingkat konsistensi baca-tulis yang lebih tinggi, dan sebagian besar permintaan Anda adalah operasi satu baris, Anda dapat menggunakan perutean afinitas baris (perutean tetap). Untuk mengaktifkan pemilihan rute afinitas baris, gunakan profil aplikasi kustom dengan tanda --row-affinity yang diaktifkan. Bigtable menggunakan kunci baris permintaan untuk otomatis menentukan cluster mana yang akan dituju permintaan. Anda tidak dapat menetapkan pemetaan antara kunci baris dan cluster secara manual.

Perutean afinitas baris hanya dapat digunakan untuk permintaan baca atau tulis satu baris. Hal ini mencakup permintaan yang memanggil ReadRows dengan satu kunci yang ditentukan, MutateRow, dan MutateRows dengan satu kunci yang ditentukan, serta BulkMutateRow dengan satu kunci yang ditentukan.

Konsistensi read-your-write tidak sepenuhnya tercapai dengan perutean afinitas baris dalam kasus berikut:

  • Menambahkan cluster ke instance: Perutean afinitas baris menentukan cluster mana yang akan dirutekan berdasarkan kunci baris. Jika cluster baru ditambahkan atau dihapus ke instance saat perutean afinitas baris diaktifkan, penetapan kunci baris mungkin berubah. Untuk memastikan bahwa urutan failover cluster tetap sama meskipun ada perubahan pada daftar cluster instance, sebaiknya gunakan grup cluster dengan menyetel tanda --restrict-to.

    Dengan grup cluster, Anda tidak dapat menghapus cluster dalam instance saat cluster tersebut sedang digunakan oleh profil aplikasi. Selain itu, cluster baru yang ditambahkan ke instance tidak akan mulai menerima permintaan kecuali jika ditambahkan secara eksplisit ke grup cluster profil aplikasi.

  • Failover: Jika cluster tidak tersedia atau tidak responsif, permintaan ke cluster yang terpengaruh akan diarahkan ke cluster berikutnya sesuai dengan urutan failover. Pengalihan rute ini dapat memengaruhi konsistensi.

Untuk mengetahui informasi selengkapnya tentang failover, lihat Failover. Untuk mempelajari cara menyelesaikan failover, lihat Mengelola failover.

Pemilihan rute dengan SQL

Saat Anda menggunakan SQL untuk membuat kueri Bigtable, ada pertimbangan khusus tentang cara permintaan Anda dirutekan. Perilaku perutean untuk kueri SQL berbeda dengan jenis permintaan Bigtable lainnya dengan cara berikut:

  • Meskipun kebijakan pemilihan rute multi-cluster memberikan ketersediaan tinggi melalui failover otomatis untuk sebagian besar permintaan, perilaku ini tidak berlaku untuk kueri SQL. Jika permintaan SQL gagal, permintaan tersebut tidak akan di-failover ke cluster lain, meskipun profil aplikasi Anda dikonfigurasi untuk perutean multi-cluster.
  • Perutean afinitas baris mengarahkan pembacaan dan penulisan baris tunggal secara otomatis ke cluster tertentu berdasarkan kunci baris. Namun, Bigtable tidak mendukung kebijakan perutean ini untuk kueri SQL. Batasan ini berarti Anda tidak dapat menggunakan perutean afinitas baris dengan metode ExecuteQuery, meskipun kueri dirancang untuk membaca satu baris. Jika Anda mengirim permintaan ExecuteQuery menggunakan profil aplikasi dengan tanda --row-affinity diaktifkan, permintaan akan berhasil, tetapi afinitas baris tidak diterapkan.

Transaksi baris tunggal

Dalam mutasi Bigtable, seperti permintaan baca, tulis, dan hapus, selalu bersifat atomik di tingkat baris. Hal ini mencakup mutasi ke beberapa kolom dalam satu baris, selama kolom tersebut disertakan dalam operasi mutasi yang sama. Bigtable tidak mendukung transaksi yang memperbarui lebih dari satu baris secara atomik.

Namun, Bigtable mendukung beberapa operasi tulis yang memerlukan transaksi di database lain. Pada dasarnya, Bigtable menggunakan transaksi baris tunggal untuk menyelesaikan operasi ini. Operasi ini mencakup baca dan tulis, dan semua operasi baca dan tulis dieksekusi secara atomik, tetapi operasi tetap atomik hanya di tingkat baris:

  • Operasi baca-modifikasi-tulis, termasuk penambahan dan penyambungan. Operasi baca-modifikasi-tulis membaca nilai yang ada; menambah atau menambahkan ke nilai yang ada; dan menulis nilai yang diperbarui ke tabel.
  • Operasi periksa dan ubah, juga dikenal sebagai mutasi kondisional atau penulisan kondisional. Dalam operasi periksa dan ubah, Bigtable memeriksa baris untuk melihat apakah baris tersebut memenuhi kondisi yang ditentukan. Jika kondisi terpenuhi, Bigtable akan menulis nilai baru ke baris.

Konflik antar-transaksi baris tunggal

Setiap cluster dalam instance Bigtable adalah cluster utama yang menerima operasi baca dan tulis. Akibatnya, operasi yang memerlukan transaksi satu baris dapat menyebabkan masalah pada instance yang direplikasi.

Jika kasus penggunaan Anda memungkinkan, Anda dapat menghindari konflik ini dengan menggunakan agregat. Saat Anda mengirim permintaan penambahan ke kolom gabungan, nilai baru akan digabungkan dengan nilai yang ada. Agregat memungkinkan Anda menyimpan jumlah atau penghitung yang sedang berjalan. Untuk mengetahui informasi selengkapnya, lihat Menghitung nilai agregat saat penulisan.

Untuk menggambarkan masalah yang dapat muncul saat Anda tidak menggunakan agregasi, misalkan Anda memiliki tabel yang digunakan untuk menyimpan data sistem tiket. Anda menggunakan penghitung bilangan bulat untuk menyimpan jumlah tiket yang telah terjual. Setiap kali Anda menjual tiket, aplikasi Anda mengirimkan operasi baca-modifikasi-tulis untuk menaikkan penghitung sebesar 1.

Jika instance Anda memiliki satu cluster, aplikasi klien dapat menjual tiket secara bersamaan dan menaikkan penghitung tanpa kehilangan data karena permintaan ditangani secara atomik dalam urutan yang diterima oleh satu cluster tersebut.

Di sisi lain, jika instance Anda memiliki beberapa cluster dan profil aplikasi Anda mengizinkan perutean multi-cluster, permintaan serentak untuk menaikkan penghitung mungkin dikirim ke cluster yang berbeda, lalu direplikasi ke cluster lain dalam instance. Jika Anda mengirim dua permintaan penambahan secara bersamaan yang dirutekan ke cluster yang berbeda, setiap permintaan akan menyelesaikan transaksinya tanpa "mengetahui" permintaan lainnya. Penghitung di setiap cluster akan bertambah satu. Saat data direplikasi ke cluster lain, Bigtable tidak mungkin mengetahui bahwa Anda bermaksud menaikkan nilai sebesar 2.

Untuk membantu Anda menghindari hasil yang tidak diinginkan, Bigtable melakukan hal berikut:

  • Mewajibkan setiap profil aplikasi untuk menentukan apakah profil tersebut mengizinkan transaksi baris tunggal.
  • Mencegah Anda mengaktifkan transaksi satu baris di profil aplikasi yang menggunakan perutean multi-cluster, karena tidak ada cara yang aman untuk mengaktifkan kedua fitur ini sekaligus.
  • Memperingatkan Anda jika Anda mengaktifkan transaksi baris tunggal di dua atau lebih profil aplikasi berbeda yang menggunakan perutean cluster tunggal dan mengarah ke cluster yang berbeda. Jika Anda memilih untuk membuat jenis konfigurasi ini, Anda harus memastikan bahwa Anda tidak mengirim permintaan baca-ubah-tulis atau periksa-dan-ubah yang bertentangan ke cluster yang berbeda.

Langkah berikutnya