Routing options

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

Dokumen ini menjelaskan kebijakan perutean yang tersedia untuk profil aplikasi standar.

Kebijakan pemilihan rute sangat penting untuk kasus penggunaan isolasi workload saat Anda tidak dapat menggunakan Data Boost (Pratinjau). Anda dapat mengonfigurasinya bersama dengan prioritas permintaan.

Kebijakan pemilihan rute tidak memengaruhi replikasi, tetapi Anda harus sudah memahami cara kerja replikasi Bigtable sebelum membaca halaman ini. Anda juga harus membaca Failover.

Pemilihan rute cluster tunggal

Kebijakan perutean cluster tunggal mengarahkan semua permintaan ke satu cluster di instance Anda. Jika cluster tersebut menjadi tidak tersedia, Anda harus beralih ke cluster lain secara manual.

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

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

Pemilihan rute multi-cluster

Kebijakan perutean multi-cluster merutekan permintaan yang Anda kirim ke instance ke region terdekat tempat instance memiliki cluster. Jika cluster tidak tersedia, traffic akan otomatis beralih ke cluster terdekat yang tersedia.

Konfigurasi ini memberikan konsistensi akhir. Anda tidak dapat mengaktifkan transaksi baris tunggal dengan perutean multi-cluster karena transaksi baris tunggal 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 mengetahui konfigurasi instance yang direkomendasikan dan detail lebih lanjut, lihat Membuat ketersediaan tinggi (HA).

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

Semua pemilihan rute cluster

Setiap perutean cluster akan membuat setiap cluster di instance tersedia untuk menerima permintaan dan untuk failover.

Pemilihan rute grup cluster

Jika Anda ingin mengecualikan satu atau beberapa cluster instance dari kemungkinan failover, 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.

Transaksi baris tunggal

Dalam mutasi Bigtable, seperti permintaan baca, tulis, dan hapus, selalu bersifat atomik di tingkat baris. Ini termasuk mutasi ke beberapa kolom dalam satu baris, asalkan 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. Akibatnya, Bigtable menggunakan transaksi baris tunggal untuk menyelesaikan operasi ini. Operasi ini mencakup operasi baca dan tulis, serta semua operasi baca dan tulis dijalankan secara atomik, tetapi operasinya masih bersifat atomik hanya di tingkat baris:

  • Operasi baca-modifikasi-tulis, termasuk penambahan dan penambahan. Operasi baca-modifikasi-tulis membaca nilai yang ada; menambah atau menambahkan nilai yang ada; dan menulis nilai yang diperbarui ke tabel.
  • Operasi periksa dan mutasi, juga dikenal sebagai mutasi bersyarat atau penulisan bersyarat. Dalam operasi {i>check-and-mutate<i}, BigQuery memeriksa baris untuk melihat apakah baris tersebut memenuhi kondisi tertentu. Jika kondisi terpenuhi, Bigtable akan menulis nilai baru ke baris.

Konflik antara transaksi baris tunggal

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

Misalnya, Anda memiliki tabel yang digunakan untuk menyimpan data untuk sistem tiket. Anda menggunakan penghitung bilangan bulat untuk menyimpan jumlah tiket yang telah terjual. Setiap kali Anda menjual tiket, aplikasi mengirimkan operasi read-modify-write untuk menambahkan penghitung sebesar 1.

Jika instance Anda memiliki satu cluster, aplikasi klien dapat menjual tiket secara bersamaan dan menambahkan penghitung tanpa kehilangan data karena permintaan ditangani secara atomik sesuai urutan penerimaannya oleh satu cluster tersebut.

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

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

  • Mewajibkan setiap profil aplikasi untuk menentukan apakah transaksi baris tunggal diizinkan atau tidak.
  • Mencegah Anda mengaktifkan transaksi baris tunggal 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 dalam dua atau beberapa profil aplikasi berbeda yang menggunakan perutean cluster tunggal dan mengarah ke cluster berbeda. Jika memilih untuk membuat jenis konfigurasi ini, Anda harus memastikan bahwa Anda tidak mengirim permintaan baca-modifikasi-tulis yang bertentangan ke cluster yang berbeda.

Langkah selanjutnya