Bigtable untuk pengguna Cassandra

Dokumen ini ditujukan untuk developer software dan administrator database yang ingin memigrasikan aplikasi yang ada atau mendesain aplikasi baru untuk digunakan dengan Bigtable sebagai datastore. Dokumen ini menerapkan pengetahuan Anda tentang Apache Cassandra untuk menggunakan Bigtable.

Bigtable dan Cassandra adalah database terdistribusi. Redis dan Cassandra menerapkan penyimpanan nilai kunci multidimensional yang dapat mendukung puluhan ribu kueri per detik (QPS), penyimpanan yang diskalakan hingga petabyte data, dan toleransi untuk kegagalan node.

Meskipun set fitur database ini serupa pada tingkat tinggi, arsitektur dan detail interaksi yang mendasarinya berbeda dengan cara yang penting untuk dipahami. Dokumen ini menyoroti persamaan dan perbedaan antara kedua sistem database.

Kapan Bigtable menjadi tujuan yang baik untuk workload Cassandra

Layanan Google Cloud terbaik untuk workload Cassandra Anda bergantung pada tujuan migrasi dan fungsi Cassandra yang Anda perlukan setelah migrasi.

Bigtable akan optimal jika throughput dan latensi sama pentingnya untuk operasi tulis dan baca. Konsistensi akhir Bigtable, penulisan lokal yang cepat, kemampuan untuk menggunakan stempel waktu kustom, skema fleksibel (seperti jenis koleksi yang dapat diperbarui), dan berbagai topologi cluster memungkinkan Bigtable mendukung aplikasi yang berkembang dan memberikan latensi rendah dengan biaya yang efektif.

Untuk memigrasikan aplikasi tanpa perubahan kode, Anda dapat memilih untuk mengelola Cassandra sendiri di GKE atau menggunakan partner Google Cloud seperti DataStax atau ScyllaDB. Jika aplikasi Anda banyak melakukan operasi baca dan Anda bersedia memfaktorkan ulang kode untuk mendapatkan kemampuan database relasional dan konsistensi yang kuat, Anda dapat mempertimbangkan Spanner.

Dokumen ini memberikan tips tentang hal-hal yang perlu dipertimbangkan saat memfaktorkan ulang aplikasi, jika Anda memilih Bigtable sebagai target migrasi untuk workload Cassandra.

Cara menggunakan dokumen ini

Anda tidak perlu membaca dokumen ini dari awal hingga akhir. Meskipun dokumen ini memberikan perbandingan antara kedua database tersebut, Anda juga dapat berfokus pada topik yang berlaku untuk kasus penggunaan atau minat Anda.

Membandingkan dua database yang sudah matang bukanlah tugas yang mudah. Untuk mencapai tujuan ini, dokumen ini melakukan hal berikut:

  • Membandingkan terminologi, yang dapat berbeda antara kedua database.
  • Memberikan ringkasan tentang kedua sistem database.
  • Melihat cara setiap database menangani pemodelan data untuk memahami berbagai pertimbangan desain.
  • Membandingkan jalur yang diambil oleh data selama operasi tulis dan baca.
  • Memeriksa tata letak data fisik untuk memahami aspek arsitektur database.
  • Menjelaskan cara mengonfigurasi replikasi geografis untuk memenuhi persyaratan Anda, dan cara menentukan ukuran cluster.
  • Meninjau detail tentang pengelolaan, pemantauan, dan keamanan cluster.

Perbandingan terminologi

Meskipun banyak konsep yang digunakan di Bigtable dan Cassandra serupa, setiap database memiliki konvensi penamaan yang sedikit berbeda dan perbedaan halus.

Salah satu elemen penyusun inti dari kedua database tersebut adalah tabel string yang diurutkan (SSTable). Dalam kedua arsitektur, SSTables dibuat untuk mempertahankan data yang digunakan untuk merespons kueri baca.

Dalam postingan blog (2012), Ilya Grigorik menulis hal berikut: "SSTable adalah abstraksi sederhana untuk menyimpan pasangan nilai kunci dalam jumlah besar secara efisien sekaligus mengoptimalkan throughput tinggi, beban kerja baca atau tulis berurutan."

Tabel berikut menguraikan dan menjelaskan konsep bersama serta terminologi terkait yang digunakan setiap produk:

Cassandra Bigtable

kunci utama: nilai unik satu atau beberapa kolom yang menentukan penempatan dan pengurutan data.

kunci partisi: nilai satu atau beberapa kolom yang menentukan penempatan data dengan hash yang konsisten.

kolom pengelompokan: nilai tunggal atau multi-kolom yang menentukan pengurutan data leksikografis dalam partisi.

 kunci baris: string byte tunggal yang unik dan menentukan penempatan data menurut pengurutan leksikal. Kunci gabungan ditiru dengan menggabungkan data dari beberapa kolom menggunakan pemisah umum—misalnya, simbol hash (#) atau persen (%).
node: mesin yang bertanggung jawab untuk membaca dan menulis data yang terkait dengan serangkaian rentang hash partisi kunci utama. Di Cassandra, data disimpan di penyimpanan tingkat blok yang dilampirkan ke server node. node: resource komputasi virtual yang bertanggung jawab untuk membaca dan menulis data yang terkait dengan serangkaian rentang kunci baris. Di Bigtable, data tidak ditempatkan bersama dengan node komputasi. Sebagai gantinya, data disimpan di Colossus, sistem file terdistribusi Google. Node diberi tanggung jawab sementara untuk menayangkan berbagai rentang data berdasarkan beban operasi dan kesehatan node lain dalam cluster.

data center: mirip dengan cluster Bigtable, kecuali beberapa aspek topologi dan strategi replikasi dapat dikonfigurasi di Cassandra.

rack: pengelompokan node di pusat data yang memengaruhi penempatan replika.

 cluster: sekelompok node di zona geografis Google Cloud yang sama, yang ditempatkan berdekatan untuk mengatasi masalah latensi dan replikasi.
cluster: deployment Cassandra yang terdiri dari kumpulan pusat data. instance: sekelompok cluster Bigtable di zona atau region Google Cloud yang berbeda tempat replikasi dan pemilihan rute koneksi terjadi.
vnode: rentang nilai hash tetap yang ditetapkan ke node fisik tertentu. Data dalam vnode secara fisik disimpan di node Cassandra dalam serangkaian SSTables. tablet: SSTable yang berisi semua data untuk rentang berurutan kunci baris yang diurutkan secara leksikografis. Tablet tidak disimpan di node di Bigtable, tetapi disimpan dalam serangkaian SSTable di Colossus.
faktor replikasi: jumlah replika vnode yang dipertahankan di semua node di pusat data. Faktor replikasi dikonfigurasi secara independen untuk setiap pusat data. replikasi: proses mereplikasi data yang disimpan di Bigtable ke semua cluster dalam instance. Replikasi dalam cluster zona ditangani oleh lapisan penyimpanan Colossus.
tabel (sebelumnya grup kolom): pengaturan nilai yang logis dan diindeks oleh kunci utama yang unik. tabel: pengaturan nilai yang logis dan diindeks oleh kunci baris unik.
keyspace: namespace tabel logis yang menentukan faktor replikasi untuk tabel yang dikandungnya. Tidak berlaku. Bigtable menangani masalah ruang kunci secara transparan.
map: jenis koleksi Cassandra yang menyimpan key-value pair. keluarga kolom: namespace yang ditentukan pengguna yang mengelompokkan penentu kolom untuk pembacaan dan penulisan yang lebih efisien. Saat membuat kueri Bigtable menggunakan SQL, keluarga kolom diperlakukan seperti peta Cassandra.
kunci peta: kunci yang mengidentifikasi entri nilai kunci secara unik dalam peta Cassandra penentu kolom: label untuk nilai yang disimpan dalam tabel yang diindeks oleh kunci baris unik. Saat membuat kueri Bigtable menggunakan SQL, kolom diperlakukan seperti kunci peta.
kolom: label untuk nilai yang disimpan dalam tabel yang diindeks oleh kunci utama unik. kolom: label untuk nilai yang disimpan dalam tabel yang diindeks oleh kunci baris unik. Nama kolom dibuat dengan menggabungkan grup kolom dengan penentu kolom.
cell: nilai stempel waktu dalam tabel yang terkait dengan titik temu kunci utama dengan kolom. sel: nilai stempel waktu dalam tabel yang dikaitkan dengan titik temu kunci baris dengan nama kolom. Beberapa versi dengan stempel waktu dapat disimpan dan diambil untuk setiap sel.
counter: jenis kolom yang dapat bertambah dan dioptimalkan untuk operasi jumlah bilangan bulat. penghitung: sel yang menggunakan jenis data khusus untuk operasi jumlah bilangan bulat. Untuk informasi selengkapnya, lihat Membuat dan memperbarui penghitung.
kebijakan load balancing: kebijakan yang Anda konfigurasikan dalam logika aplikasi untuk merutekan operasi ke node yang sesuai dalam cluster. Kebijakan ini mempertimbangkan topologi pusat data dan rentang token vnode. profil aplikasi: setelan yang menginstruksikan Bigtable cara merutekan panggilan API klien ke cluster yang sesuai dalam instance. Anda juga dapat menggunakan profil aplikasi sebagai tag untuk mengelompokkan metrik. Anda mengonfigurasi profil aplikasi di layanan.
CQL: Cassandra Query Language, bahasa seperti SQL yang digunakan untuk pembuatan tabel, perubahan skema, mutasi baris, dan kueri. Bigtable API: library klien dan gRPC API yang digunakan untuk pembuatan instance dan cluster, pembuatan tabel dan keluarga kolom, mutasi baris, dan kueri. SQL API Bigtable akan dikenal oleh pengguna CQL.

Ringkasan Produk

Bagian berikut memberikan ringkasan filosofi desain dan atribut utama Bigtable dan Cassandra.

Bigtable

Bigtable menyediakan banyak fitur inti yang dijelaskan dalam makalah Bigtable: A Distributed Storage System for Structured Data. Bigtable memisahkan node komputasi, yang melayani permintaan klien, dari pengelolaan penyimpanan yang mendasarinya. Data disimpan di Colossus. Lapisan penyimpanan secara otomatis mereplikasi data untuk memberikan ketahanan yang melebihi level yang disediakan oleh replikasi tiga arah Hadoop Distributed File System (HDFS) standar.

Arsitektur ini memberikan operasi baca dan tulis yang konsisten dalam cluster, menskalakan ke atas dan ke bawah tanpa biaya redistribusi penyimpanan, dan dapat menyeimbangkan kembali workload tanpa mengubah cluster atau skema. Jika node pemrosesan data menjadi terganggu, layanan Bigtable akan menggantinya secara transparan. Bigtable juga mendukung replikasi asinkron.

Selain gRPC dan library klien untuk berbagai bahasa pemrograman, Bigtable mempertahankan kompatibilitas dengan library klien Java HBase Apache open source, implementasi mesin database open source alternatif dari makalah Bigtable.

Diagram berikut menunjukkan cara Bigtable secara fisik memisahkan node pemrosesan dari lapisan penyimpanan:

Klien berkomunikasi melalui lapisan pemilihan rute ke node pemrosesan, yang pada gilirannya berkomunikasi dengan lapisan penyimpanan.

Pada diagram sebelumnya, node pemrosesan tengah hanya bertanggung jawab untuk menayangkan permintaan data untuk set data C di lapisan penyimpanan. Jika Bigtable mengidentifikasi bahwa penyeimbangan ulang penetapan rentang diperlukan untuk set data, rentang data untuk node pemrosesan mudah diubah karena lapisan penyimpanan dipisahkan dari lapisan pemrosesan.

Diagram berikut menunjukkan, dalam istilah yang disederhanakan, penyeimbangan ulang rentang kunci dan penyesuaian ukuran cluster:

Penyeimbangan ulang akan menyebarkan pemrosesan ke beberapa node, dan mengubah ukuran akan menambahkan node pemrosesan.

Gambar Penyesuaian Kembali mengilustrasikan status cluster Bigtable setelah node pemrosesan paling kiri menerima peningkatan jumlah permintaan untuk set data A. Setelah penyeimbangan ulang terjadi, node tengah, bukan node paling kiri, bertanggung jawab untuk menayangkan permintaan data untuk set data B. Node paling kiri terus melayani permintaan untuk set data A.

Bigtable dapat mengatur ulang rentang kunci baris untuk menyeimbangkan rentang set data di seluruh peningkatan jumlah node pemrosesan yang tersedia. Gambar Mengubah Ukuran menunjukkan status cluster Bigtable setelah Anda menambahkan node.

Cassandra

Apache Cassandra adalah database open source yang sebagian dipengaruhi oleh konsep dari makalah Bigtable. Sistem ini menggunakan arsitektur node terdistribusi, dengan penyimpanan yang ditempatkan bersama server yang merespons operasi data. Serangkaian node virtual (vnode) ditetapkan secara acak ke setiap server untuk menayangkan sebagian ruang kunci cluster.

Data disimpan di vnode berdasarkan kunci partisi. Biasanya, fungsi hash yang konsisten digunakan untuk membuat token guna menentukan penempatan data. Seperti Bigtable, Anda dapat menggunakan partisi yang mempertahankan urutan untuk pembuatan token, sehingga juga untuk penempatan data. Namun, dokumentasi Cassandra tidak menyarankan pendekatan ini karena cluster kemungkinan akan menjadi tidak seimbang, yaitu kondisi yang sulit diperbaiki. Oleh karena itu, dokumen ini menganggap bahwa Anda menggunakan strategi hashing yang konsisten untuk menghasilkan token yang menghasilkan distribusi data di seluruh node.

Cassandra menyediakan fault tolerance melalui tingkat ketersediaan yang dikorelasi dengan tingkat konsistensi yang dapat disesuaikan, sehingga cluster dapat melayani klien saat satu atau beberapa node mengalami gangguan. Anda menentukan replikasi geografis melalui strategi topologi replikasi data yang dapat dikonfigurasi.

Anda menentukan tingkat konsistensi untuk setiap operasi. Setelan umumnya adalah QUORUM (atau LOCAL_QUORUM dalam topologi beberapa pusat data tertentu). Setelan tingkat konsistensi ini memerlukan mayoritas node replika untuk merespons node koordinator agar operasi dianggap berhasil. Faktor replikasi, yang Anda konfigurasikan untuk setiap ruang kunci, menentukan jumlah replika data yang disimpan di setiap pusat data dalam cluster. Misalnya, nilai faktor replika 3 biasanya digunakan untuk memberikan keseimbangan praktis antara ketahanan dan volume penyimpanan.

Diagram berikut menunjukkan dalam istilah sederhana cluster enam node dengan rentang kunci setiap node dibagi menjadi lima vnode. Dalam praktiknya, Anda dapat memiliki lebih banyak node, dan kemungkinan akan memiliki lebih banyak vnode.

Arsitektur yang mencakup node koordinator, penyimpanan node lokal, dan node lainnya, masing-masing dengan vnode.

Dalam diagram sebelumnya, Anda dapat melihat jalur operasi tulis, dengan tingkat konsistensi QUORUM, yang berasal dari aplikasi atau layanan klien (Klien). Untuk tujuan diagram ini, rentang kunci ditampilkan sebagai rentang alfabet. Pada kenyataannya, token yang dihasilkan oleh hash kunci utama adalah bilangan bulat bertanda tangan yang sangat besar.

Dalam contoh ini, hash kunci adalah M, dan vnode untuk M berada di node 2, 4, dan 6. Koordinator harus menghubungi setiap node tempat rentang hash kunci disimpan secara lokal sehingga operasi tulis dapat diproses. Karena tingkat konsistensi adalah QUORUM, dua replika (mayoritas) harus merespons node koordinator sebelum klien diberi tahu bahwa operasi tulis telah selesai.

Berbeda dengan Bigtable, memindahkan atau mengubah rentang kunci di Cassandra mengharuskan Anda menyalin data secara fisik dari satu node ke node lainnya. Jika satu node kelebihan beban dengan permintaan untuk rentang hash token tertentu, menambahkan pemrosesan untuk rentang token tersebut akan lebih kompleks di Cassandra dibandingkan dengan Bigtable.

Replikasi dan konsistensi geografis

Bigtable dan Cassandra menangani replikasi dan konsistensi geografis (juga dikenal sebagai multi-wilayah) secara berbeda. Cluster Cassandra terdiri dari node pemrosesan yang dikelompokkan ke dalam rak, dan rak dikelompokkan ke dalam pusat data. Cassandra menggunakan strategi topologi jaringan yang Anda konfigurasikan untuk menentukan cara replika vnode didistribusikan di seluruh host di pusat data. Strategi ini menunjukkan akar Cassandra sebagai database yang awalnya di-deploy di pusat data fisik on-premise. Konfigurasi ini juga menentukan faktor replika untuk setiap pusat data dalam cluster.

Cassandra menggunakan konfigurasi data center dan rak untuk meningkatkan toleransi error replika data. Selama operasi baca dan tulis, topologi menentukan node peserta yang diperlukan untuk memberikan jaminan konsistensi. Anda harus mengonfigurasi node, rak, dan pusat data secara manual saat membuat atau memperluas cluster. Dalam lingkungan cloud, deployment Cassandra standar memperlakukan zona cloud sebagai rak dan region cloud sebagai pusat data.

Anda dapat menggunakan kontrol kuorum Cassandra untuk menyesuaikan jaminan konsistensi untuk setiap operasi baca atau tulis. Tingkat kekuatan konsistensi akhir dapat bervariasi, termasuk opsi yang memerlukan satu node replika (ONE), mayoritas node replika satu pusat data (LOCAL_QUORUM), atau mayoritas semua node replika di semua pusat data (QUORUM).

Di Bigtable, cluster adalah resource zona. Instance Bigtable dapat berisi satu cluster, atau dapat berupa grup cluster yang direplikasi sepenuhnya. Anda dapat menempatkan cluster instance dalam kombinasi zona di seluruh region yang ditawarkan Google Cloud. Anda dapat menambahkan dan menghapus cluster dari instance dengan dampak minimal terhadap cluster lain dalam instance.

Di Bigtable, operasi tulis dilakukan (dengan konsistensi baca-tulis) di satu cluster dan pada akhirnya akan konsisten di cluster instance lainnya. Karena setiap sel diberi versi berdasarkan stempel waktu, tidak ada penulisan yang hilang, dan setiap cluster menayangkan sel yang memiliki stempel waktu terbaru yang tersedia.

Layanan ini menampilkan status konsistensi cluster. Cloud Bigtable API menyediakan mekanisme untuk mendapatkan token konsistensi tingkat tabel. Anda dapat menggunakan token ini untuk memastikan apakah semua perubahan yang dilakukan pada tabel tersebut sebelum token dibuat direplikasi sepenuhnya.

Dukungan transaksi

Meskipun tidak ada database yang mendukung transaksi multi-baris yang kompleks, masing-masing memiliki beberapa dukungan transaksi.

Cassandra memiliki metode transaksi ringan (LWT) yang menyediakan atomitas untuk pembaruan pada nilai kolom dalam satu partisi. Cassandra juga memiliki semantik compare and set yang menyelesaikan operasi baca baris dan perbandingan nilai sebelum operasi tulis dimulai.

Bigtable mendukung operasi tulis baris tunggal yang sepenuhnya konsisten dalam cluster. Transaksi baris tunggal diaktifkan lebih lanjut melalui operasi baca-ubah-tulis dan periksa-dan-ubah. Profil aplikasi perutean multi-cluster tidak mendukung transaksi baris tunggal.

Model data

Bigtable dan Cassandra mengatur data ke dalam tabel yang mendukung pencarian dan pemindaian rentang menggunakan ID unik baris. Kedua sistem tersebut diklasifikasikan sebagai penyimpanan kolom lebar NoSQL.

Di Cassandra, Anda harus menggunakan CQL untuk membuat skema tabel lengkap terlebih dahulu, termasuk definisi kunci utama beserta nama kolom dan jenisnya. Kunci utama di Cassandra adalah nilai gabungan unik yang terdiri dari kunci partisi wajib dan kunci cluster opsional. Kunci partisi menentukan penempatan node baris, dan kunci cluster menentukan urutan pengurutan dalam partisi. Saat membuat skema, Anda harus mengetahui potensi kompromi antara menjalankan pemindaian yang efisien dalam satu partisi dan biaya sistem yang terkait dengan memelihara partisi besar.

Di Bigtable, Anda hanya perlu membuat tabel dan menentukan grup kolomnya terlebih dahulu. Kolom tidak dideklarasikan saat tabel dibuat, tetapi dibuat saat panggilan API aplikasi menambahkan sel ke baris tabel.

Kunci baris diurutkan secara leksikografis di seluruh cluster Bigtable. Node dalam Bigtable secara otomatis menyeimbangkan tanggung jawab node untuk rentang kunci, yang sering disebut sebagai tablet dan terkadang sebagai pemisahan. Kunci baris Bigtable sering kali terdiri dari beberapa nilai kolom yang digabungkan menggunakan karakter pemisah yang biasa digunakan yang Anda pilih (seperti tanda persen). Jika dipisahkan, setiap komponen string akan analog dengan kolom kunci utama Cassandra.

Desain kunci baris

Di Bigtable, ID unik baris tabel adalah kunci baris. Kunci baris harus berupa satu nilai unik di seluruh tabel. Anda dapat membuat kunci multi-bagian dengan menggabungkan elemen yang berbeda yang dipisahkan oleh pemisah umum. Kunci baris menentukan urutan pengurutan data global dalam tabel. Layanan Bigtable secara dinamis menentukan rentang kunci yang ditetapkan ke setiap node.

Berbeda dengan Cassandra, yang hash kunci partisi menentukan penempatan baris dan kolom pengelompokan menentukan pengurutan, kunci baris Bigtable memberikan penetapan dan pengurutan node. Seperti halnya Cassandra, Anda harus mendesain kunci baris di Bigtable sehingga baris yang ingin Anda ambil bersama disimpan bersama. Namun, di Bigtable, Anda tidak perlu mendesain kunci baris untuk penempatan dan pengurutan sebelum menggunakan tabel.

Jenis data

Layanan Bigtable tidak menerapkan jenis data kolom yang dikirim klien. Library klien menyediakan metode bantuan untuk menulis nilai sel sebagai byte, string berenkode UTF-8, dan bilangan bulat 64-bit berenkode big-endian (bilangan bulat berenkode big-endian diperlukan untuk operasi penambahan atomik).

Grup kolom

Di Bigtable, grup kolom menentukan kolom mana dalam tabel yang disimpan dan diambil bersama. Setiap tabel memerlukan minimal satu grup kolom, walaupun tabel sering kali memiliki lebih banyak (batasnya adalah 100 grup kolom untuk setiap tabel). Anda harus membuat keluarga kolom secara eksplisit sebelum aplikasi dapat menggunakannya dalam operasi.

Penentu kolom

Setiap nilai yang disimpan dalam tabel pada kunci baris dikaitkan dengan label yang disebut penentu kolom. Karena penentu kolom hanyalah label, tidak ada batas praktis untuk jumlah kolom yang dapat Anda miliki dalam keluarga kolom. Penentu kolom sering digunakan di Bigtable untuk mewakili data aplikasi.

Sel

Di Bigtable, sel adalah persimpangan kunci baris dan nama kolom (grup kolom yang digabungkan dengan penentu kolom). Setiap sel berisi satu atau beberapa nilai stempel waktu yang dapat disediakan oleh klien atau diterapkan secara otomatis oleh layanan. Nilai sel lama diklaim kembali berdasarkan kebijakan pembersihan sampah yang dikonfigurasi di tingkat grup kolom.

Indeks sekunder

Bigtable tidak mendukung indeks sekunder. Jika indeks diperlukan, sebaiknya gunakan desain tabel yang menggunakan tabel kedua dengan kunci baris yang berbeda.

Load balancing dan failover klien

Di Cassandra, klien mengontrol load balancing permintaan. Driver klien menetapkan kebijakan yang ditentukan sebagai bagian dari konfigurasi atau secara terprogram selama pembuatan sesi. Cluster memberi tahu kebijakan tentang pusat data yang paling dekat dengan aplikasi, dan klien mengidentifikasi node dari pusat data tersebut untuk melayani operasi.

Layanan Bigtable merutekan panggilan API ke cluster tujuan berdasarkan parameter (ID profil aplikasi) yang disediakan dengan setiap operasi. Profil aplikasi dipertahankan dalam layanan Bigtable; operasi klien yang tidak memilih profil menggunakan profil default.

Bigtable memiliki dua jenis kebijakan perutean profil aplikasi: cluster tunggal dan multi-cluster. Profil multi-cluster merutekan operasi ke cluster terdekat yang tersedia. Cluster di region yang sama dianggap sama jauhnya dari perspektif router operasi. Jika node yang bertanggung jawab atas rentang kunci yang diminta kelebihan beban atau tidak tersedia untuk sementara di cluster, jenis profil ini akan menyediakan failover otomatis.

Dalam hal Cassandra, kebijakan multi-cluster memberikan manfaat failover dari kebijakan load balancing yang mengetahui pusat data.

Profil aplikasi yang memiliki pemilihan rute cluster tunggal akan mengarahkan semua traffic ke satu cluster. Konsistensi baris yang kuat dan transaksi baris tunggal hanya tersedia di profil yang memiliki perutean cluster tunggal.

Kelemahan pendekatan cluster tunggal adalah dalam failover, aplikasi harus dapat mencoba lagi dengan menggunakan ID profil aplikasi alternatif, atau Anda harus melakukan failover secara manual pada profil perutean cluster tunggal yang terpengaruh.

Pemilihan rute operasi

Cassandra dan Bigtable menggunakan metode yang berbeda untuk memilih node pemrosesan untuk operasi baca dan tulis. Di Cassandra, kunci partisi diidentifikasi, sedangkan di Bigtable, kunci baris digunakan.

Di Cassandra, klien pertama-tama memeriksa kebijakan load balancing. Objek sisi klien ini menentukan pusat data tujuan operasi.

Setelah pusat data diidentifikasi, Cassandra akan menghubungi node koordinator untuk mengelola operasi. Jika kebijakan mengenali token, koordinator adalah node yang menayangkan data dari partisi vnode target; jika tidak, koordinator adalah node acak. Node koordinator mengidentifikasi node tempat replika data untuk kunci partisi operasi berada, lalu menginstruksikan node tersebut untuk melakukan operasi.

Di Bigtable, seperti yang telah dibahas sebelumnya, setiap operasi menyertakan ID profil aplikasi. Profil aplikasi ditentukan di tingkat layanan. Lapisan pemilihan rute Bigtable memeriksa profil untuk memilih cluster tujuan yang sesuai untuk operasi. Lapisan pemilihan rute kemudian menyediakan jalur bagi operasi untuk mencapai node pemrosesan yang benar dengan menggunakan kunci baris operasi.

Proses penulisan data

Kedua database dioptimalkan untuk penulisan cepat dan menggunakan proses yang serupa untuk menyelesaikan penulisan. Namun, langkah-langkah yang dilakukan database sedikit bervariasi, terutama untuk Cassandra, yang, bergantung pada tingkat konsistensi operasi, komunikasi dengan node peserta tambahan mungkin diperlukan.

Setelah permintaan tulis dirutekan ke node yang sesuai (Cassandra) atau node (Bigtable), operasi tulis pertama kali dipertahankan ke disk secara berurutan dalam log commit (Cassandra) atau log bersama (Bigtable). Selanjutnya, penulisan disisipkan ke dalam tabel dalam memori (juga dikenal sebagai memtable) yang diurutkan seperti SSTables.

Setelah dua langkah ini, node akan merespons untuk menunjukkan bahwa penulisan telah selesai. Di Cassandra, beberapa replika (bergantung pada tingkat konsistensi yang ditentukan untuk setiap operasi) harus merespons sebelum koordinator memberi tahu klien bahwa operasi tulis telah selesai. Di Bigtable, karena setiap kunci baris hanya ditetapkan ke satu node pada waktu tertentu, respons dari node adalah satu-satunya yang diperlukan untuk mengonfirmasi bahwa operasi tulis berhasil.

Kemudian, jika perlu, Anda dapat menghapus memtable ke disk dalam bentuk SSTable baru. Di Cassandra, penghapusan terjadi saat log commit mencapai ukuran maksimum, atau saat memtable melebihi nilai minimum yang Anda konfigurasikan. Di Bigtable, penghapusan dimulai untuk membuat SSTable baru yang tidak dapat diubah saat memtable mencapai ukuran maksimum yang ditentukan oleh layanan. Secara berkala, proses pemadatan menggabungkan SSTable untuk rentang kunci tertentu ke dalam satu SSTable.

Pembaruan data

Kedua database menangani pembaruan data dengan cara yang sama. Namun, Cassandra hanya mengizinkan satu nilai untuk setiap sel, sedangkan Bigtable dapat menyimpan sejumlah besar nilai berversi untuk setiap sel.

Saat nilai di persimpangan kolom dan ID baris unik diubah, pembaruan akan dipertahankan seperti yang dijelaskan sebelumnya di bagian proses penulisan data. Stempel waktu tulis disimpan bersama nilai dalam struktur SSTable.

Jika belum menghapus sel yang diperbarui ke SSTable, Anda hanya dapat menyimpan nilai sel di memtable, tetapi database berbeda dengan yang disimpan. Cassandra hanya menyimpan nilai terbaru di memtable, sedangkan Bigtable menyimpan semua versi di memtable.

Atau, jika Anda telah menghapus setidaknya satu versi nilai sel ke disk dalam SSTables terpisah, database akan menangani permintaan untuk data tersebut secara berbeda. Saat sel diminta dari Cassandra, hanya nilai terbaru sesuai stempel waktu yang ditampilkan; dengan kata lain, penulisan terakhir yang menang. Di Bigtable, Anda menggunakan filter untuk mengontrol versi sel yang ditampilkan oleh permintaan baca.

Penghapusan baris

Karena kedua database menggunakan file SSTable yang tidak dapat diubah untuk mempertahankan data ke disk, Anda tidak dapat langsung menghapus baris. Untuk memastikan kueri menampilkan hasil yang benar setelah baris dihapus, kedua database menangani penghapusan menggunakan mekanisme yang sama. Penanda (disebut tombstone di Cassandra) ditambahkan terlebih dahulu ke memtable. Pada akhirnya, SSTable yang baru ditulis berisi penanda berstempel waktu yang menunjukkan bahwa ID baris unik dihapus dan tidak boleh ditampilkan dalam hasil kueri.

Time to live (TTL)

Kemampuan time to live (TTL) di kedua database serupa, kecuali satu perbedaan. Di Cassandra, Anda dapat menetapkan TTL untuk kolom atau tabel, sedangkan di Bigtable, Anda hanya dapat menetapkan TTL untuk grup kolom. Ada metode untuk Bigtable yang dapat menyimulasikan TTL tingkat sel.

Pembersihan sampah memori

Karena pembaruan atau penghapusan data langsung tidak dapat dilakukan dengan SSTable yang tidak dapat diubah, seperti yang telah dibahas sebelumnya, pembersihan sampah terjadi selama proses yang disebut pengompresian. Proses ini menghapus sel atau baris yang tidak seharusnya ditayangkan dalam hasil kueri.

Proses pembersihan sampah memori mengecualikan baris atau sel saat penggabungan SSTable terjadi. Jika penanda atau tombstone ada untuk baris, baris tersebut tidak akan disertakan dalam SSTable yang dihasilkan. Kedua database dapat mengecualikan sel dari SSTable yang digabungkan. Jika stempel waktu sel melebihi kualifikasi TTL, database akan mengecualikan sel. Jika ada dua versi dengan stempel waktu untuk sel tertentu, Cassandra hanya menyertakan nilai terbaru dalam SSTable yang digabungkan.

Jalur pembacaan data

Saat operasi baca mencapai node pemrosesan yang sesuai, proses baca untuk mendapatkan data guna memenuhi hasil kueri akan sama untuk kedua database.

Untuk setiap SSTable di disk yang mungkin berisi hasil kueri, filter Bloom diperiksa untuk menentukan apakah setiap file berisi baris yang akan ditampilkan. Karena filter Bloom dijamin tidak akan pernah memberikan hasil negatif palsu, semua SSTable yang memenuhi syarat akan ditambahkan ke daftar kandidat untuk disertakan dalam pemrosesan hasil baca lebih lanjut.

Operasi baca dilakukan menggunakan tampilan gabungan yang dibuat dari memtable dan SSTables kandidat di disk. Karena semua kunci diurutkan secara leksikografis, mendapatkan tampilan gabungan yang dipindai untuk mendapatkan hasil kueri akan lebih efisien.

Di Cassandra, serangkaian node pemrosesan yang ditentukan oleh tingkat konsistensi operasi harus berpartisipasi dalam operasi. Di Bigtable, hanya node yang bertanggung jawab atas rentang kunci yang perlu dikonsultasikan. Untuk Cassandra, Anda perlu mempertimbangkan implikasi untuk ukuran komputasi karena kemungkinan beberapa node akan memproses setiap operasi baca.

Hasil baca dapat dibatasi di node pemrosesan dengan cara yang sedikit berbeda. Di Cassandra, klausa WHERE dalam kueri CQL membatasi baris yang ditampilkan. Batasan adalah kolom dalam kunci utama atau kolom yang disertakan dalam indeks sekunder dapat digunakan untuk membatasi hasil.

Bigtable menawarkan berbagai filter yang memengaruhi baris atau sel yang diambil kueri baca.

Ada tiga kategori filter:

  • Filter pembatasan, yang mengontrol baris atau sel yang disertakan dalam respons.
  • Mengubah filter, yang memengaruhi data atau metadata untuk setiap sel.
  • Filter komposisi, yang memungkinkan Anda menggabungkan beberapa filter menjadi satu filter.

Filter pembatas adalah filter yang paling umum digunakan—misalnya, ekspresi reguler keluarga kolom dan ekspresi reguler penentu kolom.

Penyimpanan data fisik

Bigtable dan Cassandra menyimpan data dalam SSTables, yang digabungkan secara berkala selama fase pemadatan. Kompresi data SSTable menawarkan manfaat serupa untuk mengurangi ukuran penyimpanan. Namun, kompresi diterapkan secara otomatis di Bigtable dan merupakan opsi konfigurasi di Cassandra.

Saat membandingkan kedua database, Anda harus memahami cara setiap database menyimpan data secara fisik secara berbeda dalam aspek berikut:

  • Strategi distribusi data
  • Jumlah versi sel yang tersedia
  • Jenis disk penyimpanan
  • Mekanisme replikasi dan ketahanan data

Distribusi data

Di Cassandra, hash yang konsisten dari kolom partisi kunci utama adalah metode yang direkomendasikan untuk menentukan distribusi data di berbagai SSTable yang ditayangkan oleh node cluster.

Bigtable menggunakan awalan variabel ke kunci baris lengkap untuk menempatkan data secara leksikografis di SSTables.

Versi sel

Cassandra hanya menyimpan satu versi nilai sel aktif. Jika dua operasi tulis dilakukan ke sel, kebijakan last-write-wins akan memastikan bahwa hanya satu nilai yang ditampilkan.

Bigtable tidak membatasi jumlah versi berstempel waktu untuk setiap sel. Batas ukuran baris lainnya mungkin berlaku. Jika tidak ditetapkan oleh permintaan klien, stempel waktu ditentukan oleh layanan Bigtable pada saat node pemrosesan menerima mutasi. Versi sel dapat dipangkas menggunakan kebijakan pembersihan sampah yang dapat berbeda untuk setiap keluarga kolom tabel, atau dapat difilter dari kumpulan hasil kueri melalui API.

Penyimpanan disk

Cassandra menyimpan SSTables di disk yang dilampirkan ke setiap node cluster. Untuk menyeimbangi kembali data di Cassandra, file harus disalin secara fisik di antara server.

Bigtable menggunakan Colossus untuk menyimpan SSTable. Karena Bigtable menggunakan sistem file terdistribusi ini, layanan Bigtable dapat hampir langsung menetapkan ulang SSTable ke node yang berbeda.

Ketahanan dan replikasi data

Cassandra memberikan ketahanan data melalui setelan faktor replikasi. Faktor replika menentukan jumlah salinan SSTable yang disimpan di node yang berbeda dalam cluster. Setelan umum untuk faktor replikasi adalah 3, yang masih memungkinkan jaminan konsistensi yang lebih kuat dengan QUORUM atau LOCAL_QUORUM meskipun terjadi kegagalan node.

Dengan Bigtable, jaminan ketahanan data yang tinggi diberikan melalui replikasi yang disediakan Colossus.

Diagram berikut mengilustrasikan tata letak data fisik, node pemrosesan komputasi, dan lapisan pemilihan rute untuk Bigtable:

Arsitektur untuk replikasi data mencakup frontend, cluster Bigtable, dan Colossus.

Di lapisan penyimpanan Colossus, setiap node ditetapkan untuk menayangkan data yang disimpan dalam serangkaian SSTable. SSTable tersebut berisi data untuk rentang kunci baris yang ditetapkan secara dinamis ke setiap node. Meskipun diagram menunjukkan tiga SSTable untuk setiap node, kemungkinan ada lebih banyak karena SSTable terus dibuat saat node menerima perubahan baru pada data.

Setiap node memiliki log bersama. Tindakan tulis yang diproses oleh setiap node akan segera dipertahankan ke log bersama sebelum klien menerima konfirmasi tindakan tulis. Karena operasi tulis ke Colossus direplikasi beberapa kali, ketahanannya terjamin meskipun kegagalan hardware node terjadi sebelum data dipertahankan ke SSTable untuk rentang baris.

Antarmuka aplikasi

Awalnya, akses database Cassandra diekspos melalui API Thrift, tetapi metode akses ini tidak digunakan lagi. Interaksi klien yang direkomendasikan adalah melalui CQL.

Serupa dengan Thrift API asli Cassandra, akses database Bigtable disediakan melalui API yang membaca dan menulis data berdasarkan kunci baris yang disediakan.

Seperti Cassandra, Bigtable memiliki antarmuka command line, yang disebut cbt CLI , dan library klien yang mendukung banyak bahasa pemrograman umum. Library ini dibuat di atas API gRPC dan REST. Aplikasi yang ditulis untuk Hadoop dan mengandalkan library Apache HBase open source untuk Java dapat terhubung tanpa perubahan signifikan ke Bigtable. Untuk aplikasi yang tidak memerlukan kompatibilitas HBase, sebaiknya gunakan klien Java Bigtable bawaan.

Kontrol Identity and Access Management (IAM) Bigtable terintegrasi sepenuhnya dengan Google Cloud, dan tabel juga dapat digunakan sebagai sumber data eksternal dari BigQuery.

Penyiapan database

Saat menyiapkan cluster Cassandra, Anda memiliki beberapa keputusan konfigurasi yang harus dibuat dan langkah-langkah yang harus diselesaikan. Pertama, Anda harus mengonfigurasi node server untuk menyediakan kapasitas komputasi dan menyediakan penyimpanan lokal. Jika menggunakan faktor replikasi tiga, setelan yang direkomendasikan dan paling umum, Anda harus menyediakan penyimpanan untuk menyimpan tiga kali jumlah data yang ingin disimpan di cluster. Anda juga harus menentukan dan menetapkan konfigurasi untuk vnode, rak, dan replikasi.

Pemisahan komputasi dari penyimpanan di Bigtable menyederhanakan penskalaan cluster ke atas dan ke bawah dibandingkan dengan Cassandra. Dalam cluster yang berjalan normal, Anda biasanya hanya memperhatikan total penyimpanan yang digunakan oleh tabel terkelola, yang menentukan jumlah minimum node, dan memiliki cukup node untuk mempertahankan QPS saat ini.

Anda dapat menyesuaikan ukuran cluster Bigtable dengan cepat jika cluster tersebut disediakan secara berlebihan atau kurang berdasarkan beban produksi.

Penyimpanan Bigtable

Selain lokasi geografis cluster awal, satu-satunya pilihan yang perlu Anda buat saat membuat instance Bigtable adalah jenis penyimpanan. Bigtable menawarkan dua opsi untuk penyimpanan: solid-state drive (SSD) atau hard disk drive (HDD). Semua cluster dalam instance harus memiliki jenis penyimpanan yang sama.

Saat memperhitungkan kebutuhan penyimpanan dengan Bigtable, Anda tidak perlu memperhitungkan replika penyimpanan seperti yang Anda lakukan saat menentukan ukuran cluster Cassandra. Tidak ada penurunan kepadatan penyimpanan untuk mencapai fault tolerance seperti yang terlihat di Cassandra. Selain itu, karena penyimpanan tidak perlu disediakan secara eksplisit, Anda hanya akan ditagih untuk penyimpanan yang digunakan.

SSD

Kapasitas node SSD sebesar 5 TB, yang lebih disukai untuk sebagian besar beban kerja, memberikan kepadatan penyimpanan yang lebih tinggi dibandingkan dengan konfigurasi yang direkomendasikan untuk mesin Cassandra, yang memiliki kepadatan penyimpanan maksimum praktis kurang dari 2 TB untuk setiap node. Saat Anda menilai kebutuhan kapasitas penyimpanan, ingat bahwa Bigtable hanya menghitung satu salinan data; sebagai perbandingan, Cassandra perlu memperhitungkan tiga salinan data dalam sebagian besar konfigurasi.

Meskipun QPS tulis untuk SSD hampir sama dengan HDD, SSD memberikan QPS baca yang jauh lebih tinggi daripada HDD. Penyimpanan SSD dihargai sama dengan atau mendekati biaya persistent disk SSD yang disediakan dan bervariasi menurut region.

HDD

Jenis penyimpanan HDD memungkinkan kepadatan penyimpanan yang cukup besar—16 TB untuk setiap node. Namun, konsekuensinya adalah operasi baca acak menjadi jauh lebih lambat, hanya mendukung 500 baris yang dibaca per detik untuk setiap node. HDD lebih disukai untuk beban kerja yang intensif penulisan, dengan pembacaan diharapkan berupa pemindaian rentang yang terkait dengan pemrosesan batch. Penyimpanan HDD harganya sama atau mendekati biaya yang terkait dengan Cloud Storage dan bervariasi menurut region.

Pertimbangan ukuran cluster

Saat Anda menentukan ukuran instance Bigtable untuk bersiap memigrasikan workload Cassandra, ada beberapa pertimbangan saat Anda membandingkan cluster Cassandra dengan satu pusat data ke instance Bigtable dengan satu cluster, dan cluster Cassandra dengan beberapa pusat data ke instance Bigtable multi-cluster. Panduan di bagian berikut mengasumsikan bahwa tidak ada perubahan model data yang signifikan yang diperlukan untuk melakukan migrasi, dan bahwa ada kompresi penyimpanan yang setara antara Cassandra dan Bigtable.

Cluster satu pusat data

Saat membandingkan cluster satu pusat data dengan instance Bigtable satu cluster, Anda harus mempertimbangkan persyaratan penyimpanan terlebih dahulu. Anda dapat memperkirakan ukuran setiap ruang kunci yang tidak direplikasi menggunakan perintah tablestats nodetool dan membagi total ukuran penyimpanan yang dihapus dengan faktor replikasi ruang kunci. Kemudian, bagi jumlah penyimpanan yang tidak direplikasi dari semua ruang kunci dengan 3,5 TB (5 TB * .70) untuk menentukan jumlah node SSD yang disarankan untuk menangani penyimpanan saja. Seperti yang telah dibahas, Bigtable menangani replika dan ketahanan penyimpanan dalam tingkat terpisah yang transparan bagi pengguna.

Selanjutnya, Anda harus mempertimbangkan persyaratan komputasi untuk jumlah node. Anda dapat melihat metrik aplikasi klien dan server Cassandra untuk mendapatkan perkiraan jumlah pembacaan dan penulisan berkelanjutan yang telah dijalankan. Untuk memperkirakan jumlah node SSD minimum guna menjalankan workload Anda, bagi metrik tersebut dengan 10.000. Anda mungkin memerlukan lebih banyak node untuk aplikasi yang memerlukan hasil kueri latensi rendah. Google merekomendasikan agar Anda menguji performa Bigtable dengan data dan kueri perwakilan untuk menetapkan metrik QPS per node yang dapat dicapai untuk beban kerja Anda.

Jumlah node yang diperlukan untuk cluster harus sama dengan kebutuhan penyimpanan dan komputasi yang lebih besar. Jika ragu tentang kebutuhan throughput atau penyimpanan, Anda dapat mencocokkan jumlah node Bigtable dengan jumlah mesin Cassandra standar. Anda dapat menskalakan cluster Bigtable ke atas atau ke bawah agar sesuai dengan kebutuhan beban kerja dengan upaya minimal dan tanpa periode nonaktif.

Cluster beberapa pusat data

Dengan cluster multi-pusat data, akan lebih sulit untuk menentukan konfigurasi instance Bigtable. Idealnya, Anda harus memiliki cluster dalam instance untuk setiap pusat data dalam topologi Cassandra. Setiap cluster Bigtable dalam instance harus menyimpan semua data dalam instance dan harus dapat menangani total rasio penyisipan di seluruh cluster. Cluster dalam instance dapat dibuat di region cloud mana pun yang didukung di seluruh dunia.

Teknik untuk memperkirakan kebutuhan penyimpanan mirip dengan pendekatan untuk cluster satu pusat data. Anda menggunakan nodetool untuk mengambil ukuran penyimpanan setiap ruang kunci di cluster Cassandra, lalu membagi ukuran tersebut dengan jumlah replika. Anda perlu mengingat bahwa ruang kunci tabel mungkin memiliki faktor replika yang berbeda untuk setiap pusat data.

Jumlah node di setiap cluster dalam instance harus dapat menangani semua penulisan di seluruh cluster dan semua pembacaan ke setidaknya dua pusat data untuk mempertahankan tujuan tingkat layanan (SLO) selama pemadaman cluster. Pendekatan umum adalah memulai dengan semua cluster yang memiliki kapasitas node yang setara dengan pusat data tersibuk di cluster Cassandra. Cluster Bigtable dalam instance dapat ditingkatkan atau diturunkan skalanya secara individual untuk menyesuaikan kebutuhan beban kerja tanpa periode nonaktif.

Administrasi

Bigtable menyediakan komponen yang dikelola sepenuhnya untuk fungsi administrasi umum yang dilakukan di Cassandra.

Pencadangan dan pemulihan

Bigtable menyediakan dua metode untuk memenuhi kebutuhan pencadangan umum: pencadangan Bigtable dan ekspor data terkelola.

Anda dapat menganggap pencadangan Bigtable sebagai analog dengan versi dikelola dari fitur snapshot nodetool Cassandra. Cadangan Bigtable membuat salinan tabel yang dapat dipulihkan, yang disimpan sebagai objek anggota cluster. Anda dapat memulihkan cadangan sebagai tabel baru di cluster yang memulai pencadangan. Pencadangan dirancang untuk membuat titik pemulihan jika terjadi kerusakan tingkat aplikasi. Pencadangan yang Anda buat melalui utilitas ini tidak menggunakan resource node dan harganya sama dengan atau mendekati harga Cloud Storage. Anda dapat memanggil cadangan Bigtable secara terprogram atau melalui konsol Google Cloud untuk Bigtable.

Cara lain untuk mencadangkan Bigtable adalah menggunakan ekspor data terkelola ke Cloud Storage. Anda dapat mengekspor ke dalam format file Avro, Parquet, atau Hadoop Sequence. Dibandingkan dengan pencadangan Bigtable, ekspor memerlukan waktu lebih lama untuk dieksekusi dan menimbulkan biaya komputasi tambahan karena ekspor menggunakan Dataflow. Namun, ekspor ini membuat file data portabel yang dapat Anda buat kueri secara offline atau impor ke sistem lain.

Pengubahan ukuran

Karena Bigtable memisahkan penyimpanan dan komputasi, Anda dapat menambahkan atau menghapus node Bigtable sebagai respons terhadap permintaan kueri dengan lebih lancar daripada di Cassandra. Arsitektur homogen Cassandra mengharuskan Anda menyeimbangi node (atau vnode) di seluruh mesin dalam cluster.

Anda dapat mengubah ukuran cluster secara manual di konsol Google Cloud atau secara terprogram menggunakan Cloud Bigtable API. Menambahkan node ke cluster dapat menghasilkan peningkatan performa yang signifikan dalam hitungan menit. Beberapa pelanggan telah berhasil menggunakan autoscaler open source yang dikembangkan oleh Spotify.

Pemeliharaan internal

Layanan Bigtable menangani tugas pemeliharaan internal Cassandra yang umum dengan lancar seperti patching OS, pemulihan node, perbaikan node, pemantauan pengompresian penyimpanan, dan rotasi sertifikat SSL.

Pemantauan

Menghubungkan Bigtable ke visualisasi atau pemberitahuan metrik tidak memerlukan upaya pengelolaan atau pengembangan. Halaman konsol Google Cloud Bigtable dilengkapi dengan dasbor bawaan untuk melacak throughput dan metrik penggunaan di tingkat instance, cluster, dan tabel. Tampilan dan pemberitahuan kustom dapat dibuat di dasbor Cloud Monitoring, tempat metrik tersedia secara otomatis.

Key Visualizer Bigtable, fitur pemantauan di konsol Google Cloud, memungkinkan Anda melakukan penyesuaian performa lanjutan.

IAM dan keamanan

Di Bigtable, otorisasi terintegrasi sepenuhnya ke dalam framework IAM Google Cloud dan memerlukan penyiapan dan pemeliharaan minimal. Akun dan sandi pengguna lokal tidak dibagikan ke aplikasi klien; sebagai gantinya, izin dan peran terperinci diberikan kepada pengguna tingkat organisasi dan akun layanan.

Bigtable otomatis mengenkripsi semua data saat dalam penyimpanan dan saat transit. Tidak ada opsi untuk menonaktifkan fitur ini. Semua akses administratif dicatat sepenuhnya. Anda dapat menggunakan Kontrol Layanan VPC untuk mengontrol akses ke instance Bigtable dari luar jaringan yang disetujui.

Langkah selanjutnya