Dokumen ini ditujukan untuk developer software dan administrator database yang ingin memigrasikan aplikasi yang sudah 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. Platform ini menerapkan penyimpanan nilai kunci multidimensi yang dapat mendukung puluhan ribu kueri per detik (QPS), penyimpanan yang meningkatkan skala data hingga petabyte, dan toleransi terhadap kegagalan node.
Meskipun set fitur database ini serupa pada tingkat tinggi, arsitektur dasar dan detail interaksinya berbeda dalam hal yang penting untuk dipahami. Dokumen ini menyoroti persamaan dan perbedaan antara kedua sistem {i>database<i}.
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 {i>database<i} yang matang bukanlah tugas yang mudah. Untuk mencapai tujuan tersebut, dokumen ini melakukan hal berikut:
- Membandingkan terminologi, yang mungkin berbeda di antara dua database.
- Memberikan gambaran umum tentang dua sistem {i>database<i}.
- Melihat bagaimana 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 mendekati ukuran cluster.
- Meninjau detail tentang pengelolaan, pemantauan, dan keamanan cluster.
Perbandingan istilah
Meskipun banyak konsep yang digunakan di Bigtable dan Cassandra serupa, setiap database memiliki konvensi penamaan yang sedikit berbeda dan sedikit perbedaan.
Salah satu elemen penyusun inti kedua database adalah tabel string yang diurutkan (SSTable). Di kedua arsitektur, SSTable 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 sejumlah besar key-value pair secara efisien sekaligus mengoptimalkan throughput tinggi, workload baca, atau tulis berurutan."
Tabel berikut menguraikan dan menjelaskan konsep bersama dan terminologi terkait yang digunakan setiap produk:
| Cassandra | Bigtable |
|---|---|
|
kunci utama: nilai kolom tunggal atau multi-kolom unik yang menentukan penempatan dan pengurutan data. kunci partisi: nilai satu atau multi-kolom yang menentukan penempatan data berdasarkan hash yang konsisten. kolom pengelompokan: nilai kolom tunggal atau multi-kolom yang menentukan pengurutan data leksikografis dalam partisi. |
kunci baris: string byte unik dan tunggal yang menentukan penempatan data menurut urutan leksikografis. Kunci gabungan ditiru dengan menggabungkan data 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 level blok yang terpasang 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 di lokasi yang sama dengan node komputasi. Sebaliknya, file tersebut disimpan di Colossus, sistem file terdistribusi Google. Node diberi tanggung jawab sementara untuk menyajikan berbagai rentang data berdasarkan beban operasi dan kondisi node lain dalam cluster. |
|
pusat data: mirip dengan cluster Bigtable, tetapi beberapa aspek topologi dan strategi replikasi dapat dikonfigurasi di Cassandra. rak: pengelompokan node di pusat data yang memengaruhi penempatan replika. |
cluster: sekelompok node dalam zona Google Cloud geografis yang sama, yang ditempatkan bersama untuk masalah latensi dan replikasi. |
| cluster: deployment Cassandra yang terdiri dari kumpulan pusat data. | instance: sekelompok cluster Bigtable di berbagai zona atau region Google Cloud tempat terjadinya replikasi dan perutean koneksi. |
| vnode: rentang nilai hash tetap yang ditetapkan ke node fisik tertentu. Data dalam vnode disimpan secara fisik di node Cassandra dalam serangkaian SSTables. | tablet: SSTable yang berisi semua data untuk rentang kunci baris yang berurutan secara leksikografis. Tablet tidak disimpan pada 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 tersebut. Replikasi dalam cluster zona ditangani oleh lapisan penyimpanan Colossus. |
| table (sebelumnya kelompok kolom): organisasi nilai logis yang diindeks oleh kunci utama unik. | table: organisasi nilai logis yang diindeks oleh kunci baris unik. |
| keyspace: namespace tabel logis yang menentukan faktor replikasi untuk tabel yang ada di dalamnya. | Tidak berlaku. Bigtable menangani masalah keyspace secara transparan. |
| Tidak berlaku | penentu kolom: label untuk nilai yang disimpan dalam tabel yang diindeks oleh kunci baris unik. |
| Tidak berlaku | kelompok kolom: namespace yang ditentukan pengguna yang mengelompokkan penentu kolom untuk pembacaan dan penulisan yang lebih efisien. |
| 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 perpotongan kunci utama dengan kolom. | cell: nilai stempel waktu dalam tabel yang terkait dengan perpotongan kunci baris dengan nama kolom. Beberapa versi dengan stempel waktu dapat disimpan dan diambil untuk setiap sel. |
| kebijakan load balancing: kebijakan yang Anda konfigurasi di logika aplikasi untuk mengarahkan operasi ke node yang sesuai di cluster. Kebijakan ini memperhitungkan topologi pusat data dan rentang token vnode. | application profile: setelan yang memerintahkan Bigtable cara merutekan panggilan API klien ke cluster yang sesuai dalam instance. Anda juga dapat menggunakan profil aplikasi sebagai tag untuk menyegmentasi metrik. Anda mengonfigurasi profil aplikasi dalam layanan. |
| CQL: Bahasa Kueri Cassandra, yaitu 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 kelompok tabel dan kolom, mutasi baris, dan kueri. |
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: Sistem Penyimpanan Terdistribusi untuk Data Terstruktur. 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 diberikan oleh replikasi tiga arah Hadoop Distributed File System (HDFS) standar.
Arsitektur ini menyediakan pembacaan dan penulisan yang konsisten dalam cluster, menaikkan dan menurunkan skala tanpa biaya mendistribusikan ulang penyimpanan, dan dapat menyeimbangkan kembali workload tanpa mengubah cluster atau skema. Jika ada node pemrosesan data yang mengalami gangguan, layanan Bigtable akan menggantinya secara transparan. Bigtable juga mendukung replikasi asinkron.
Selain gRPC dan library klien untuk berbagai bahasa pemrograman, Bigtable mempertahankan kompatibilitas dengan Apache open source HBase Java client library, implementasi mesin database open source alternatif untuk makalah Bigtable.
Diagram berikut menunjukkan bagaimana Bigtable memisahkan node pemrosesan secara fisik dari lapisan penyimpanan:
Pada diagram sebelumnya, node pemrosesan tengah hanya bertanggung jawab untuk melayani 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 dapat dengan mudah berubah karena lapisan penyimpanan terpisah dari lapisan pemrosesan.
Diagram berikut menunjukkan, dalam istilah yang disederhanakan, penyeimbangan ulang rentang kunci dan pengubahan ukuran cluster:
Gambar Keseimbangan Ulang mengilustrasikan status cluster Bigtable setelah node pemrosesan paling kiri menerima peningkatan jumlah permintaan untuk set data A. Setelah terjadi penyeimbangan ulang, node tengah, bukan node paling kiri, bertanggung jawab melayani permintaan data untuk set data B. Node paling kiri akan melanjutkan permintaan layanan untuk set data A.
Bigtable dapat mengatur ulang rentang kunci baris untuk menyeimbangkan rentang set data di semua node pemrosesan yang tersedia. Gambar Pengubahan Ukuran menunjukkan status cluster Bigtable setelah Anda menambahkan node.
Cassandra
Apache Cassandra adalah database open source yang sebagian dipengaruhi oleh konsep dari kertas Bigtable. Layanan ini menggunakan arsitektur node terdistribusi, tempat penyimpanan ditempatkan bersama dengan server yang merespons operasi data. Serangkaian node virtual (vnode) ditetapkan secara acak ke setiap server untuk melayani sebagian keyspace cluster.
Data disimpan di vnode berdasarkan kunci partisi. Biasanya, fungsi hash yang konsisten digunakan untuk menghasilkan token guna menentukan penempatan data. Seperti halnya Bigtable, Anda dapat menggunakan partisi yang menyimpan urutan untuk pembuatan token, dan juga untuk penempatan data. Namun, dokumentasi Cassandra mencegah pendekatan ini karena cluster kemungkinan akan menjadi tidak seimbang, dan ini adalah kondisi yang sulit diperbaiki. Karena alasan ini, dokumen ini mengasumsikan bahwa Anda menggunakan strategi hashing yang konsisten untuk menghasilkan token yang menghasilkan distribusi data di seluruh node.
Cassandra memberikan fault tolerance melalui tingkat ketersediaan yang berkorelasi 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 konfigurasi untuk setiap keyspace, menentukan jumlah replika data yang disimpan di setiap pusat data dalam cluster. Misalnya, biasanya
menggunakan nilai faktor replikasi 3 untuk memberikan keseimbangan praktis
antara ketahanan dan volume penyimpanan.
Diagram berikut menunjukkan secara sederhana cluster yang terdiri dari 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.
Pada 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 menurut abjad. Pada kenyataannya, token yang dihasilkan oleh hash
kunci utama adalah bilangan bulat yang ditandai yang sangat besar.
Dalam contoh ini, hash kuncinya 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 penulisan dapat diproses. Karena tingkat konsistensinya adalah QUORUM, dua replika (mayoritas) harus merespons node koordinator sebelum klien diberi tahu bahwa penulisan 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-region) 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 konfigurasi untuk menentukan cara distribusi replika vnode ke berbagai host di pusat data. Strategi ini mengungkapkan asal-usul Cassandra sebagai database yang awalnya di-deploy di pusat data fisik lokal. Konfigurasi ini juga menentukan faktor replikasi untuk setiap pusat data dalam cluster.
Cassandra menggunakan konfigurasi rak dan pusat data untuk meningkatkan fault tolerance 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 node replika tunggal (ONE), mayoritas node replika pusat data tunggal (LOCAL_QUORUM), atau sebagian besar dari 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 di kombinasi zona mana pun di region mana pun yang ditawarkan Google Cloud. Anda dapat menambahkan dan menghapus cluster dari instance yang tidak berdampak minimal terhadap cluster lain dalam instance tersebut.
Di Bigtable, penulisan dilakukan (dengan konsistensi read-your-write) pada satu cluster dan pada akhirnya akan konsisten di cluster instance lainnya. Karena setiap sel dibuat versi berdasarkan stempel waktu, tidak ada operasi tulis yang hilang, dan setiap cluster menyalurkan sel yang memiliki stempel waktu terbaru yang tersedia.
Layanan ini mengekspos status konsistensi cluster. Cloud Bigtable API menyediakan mekanisme untuk mendapatkan token konsistensi level tabel. Anda dapat menggunakan token ini untuk memastikan apakah semua perubahan yang dilakukan pada tabel tersebut sebelum token dibuat telah direplikasi sepenuhnya.
Dukungan transaksi
Meskipun tidak ada database yang mendukung transaksi multi-baris yang kompleks, masing-masing database memiliki dukungan transaksi.
Cassandra memiliki metode transaksi ringan (LWT) yang menyediakan atomicity untuk pembaruan nilai kolom dalam satu partisi. Cassandra juga memiliki semantik bandingkan dan tetapkan yang menyelesaikan operasi baca baris dan perbandingan nilai sebelum operasi tulis dimulai.
Bigtable mendukung penulisan baris tunggal yang sepenuhnya konsisten dalam cluster. Transaksi baris tunggal diaktifkan lebih lanjut melalui operasi baca-modifikasi-tulis serta periksa-dan-mutasi. Profil aplikasi pemilihan rute 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 ini 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 tata urutan dalam partisi. Saat membuat skema, Anda harus mengetahui potensi konsekuensi antara menjalankan pemindaian yang efisien dalam partisi tunggal dan biaya sistem yang terkait dengan pemeliharaan 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 nodal untuk rentang kunci, yang sering disebut sebagai tablet dan terkadang sebagai pemisahan. Kunci baris Bigtable sering 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 serupa dengan kolom kunci utama Cassandra.
Desain kunci baris
Di Bigtable, ID unik baris tabel adalah kunci baris. Baris kunci harus berupa satu nilai unik di seluruh tabel. Anda dapat membuat kunci multi-bagian dengan menyambungkan elemen berbeda yang dipisahkan oleh pembatas umum. Row key menentukan tata urutan data global dalam tabel. Layanan Bigtable secara dinamis menentukan rentang kunci yang ditetapkan ke setiap node.
Berbeda dengan Cassandra, jika hash kunci partisi menentukan penempatan baris dan kolom pengelompokan menentukan urutan, kunci baris Bigtable menyediakan penetapan dan pengurutan nodal. Seperti halnya Cassandra, Anda harus mendesain row key di Bigtable agar baris yang ingin diambil bersama disimpan bersama. Namun, di Bigtable, Anda tidak perlu mendesain row key 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 yang dienkode big-endian (bilangan bulat berenkode big-endian diperlukan untuk operasi pertambahan atomik).
Kelompok kolom
Di Bigtable, grup kolom menentukan kolom dalam tabel yang disimpan dan diambil bersama. Setiap tabel memerlukan setidaknya satu grup kolom, meskipun tabel sering memiliki lebih banyak kolom (batasnya adalah 100 grup kolom untuk setiap tabel). Anda harus membuat grup kolom secara eksplisit sebelum aplikasi dapat menggunakannya dalam operasi.
Penentu kolom
Setiap nilai yang disimpan dalam tabel di row key dikaitkan dengan label yang disebut penentu kolom. Karena penentu kolom hanya label, tidak ada batas praktis jumlah kolom yang dapat Anda miliki dalam suatu kelompok kolom. Penentu kolom sering kali digunakan di Bigtable untuk mewakili data aplikasi.
Sel
Di Bigtable, sel adalah titik potong dari row key dan nama kolom (kelompok kolom yang dikombinasikan dengan penentu kolom). Setiap sel berisi satu atau beberapa nilai dengan stempel waktu yang dapat diberikan oleh klien atau diterapkan secara otomatis oleh layanan. Nilai sel lama diperoleh kembali berdasarkan kebijakan pembersihan sampah memori yang dikonfigurasi pada tingkat grup kolom.
Indeks sekunder
Bigtable tidak mendukung indeks sekunder. Jika indeks diperlukan, sebaiknya gunakan desain tabel yang menggunakan tabel kedua dengan 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 ini menginformasikan kebijakan tentang pusat data yang terdekat dengan aplikasi, dan klien mengidentifikasi node dari pusat data tersebut untuk melayani suatu operasi.
Layanan Bigtable mengarahkan panggilan API ke cluster tujuan berdasarkan parameter (ID profil aplikasi) yang disediakan dengan setiap operasi. Profil aplikasi dikelola dalam layanan Bigtable; operasi klien yang tidak memilih profil akan 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 memiliki jarak yang sama dari perspektif router operasi. Jika node yang bertanggung jawab atas rentang kunci yang diminta kelebihan beban atau tidak tersedia untuk sementara dalam cluster, jenis profil ini akan memberikan failover otomatis.
Bagi Cassandra, kebijakan multi-cluster memberikan manfaat failover dari kebijakan load balancing yang mengenali pusat data.
Profil aplikasi yang memiliki perutean 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.
Kekurangan dari pendekatan cluster tunggal adalah bahwa dalam failover, aplikasi harus dapat mencoba lagi dengan menggunakan ID profil aplikasi alternatif, atau Anda harus secara manual melakukan failover secara manual untuk 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 kunci baris digunakan di Bigtable.
Di Cassandra, klien memeriksa kebijakan load balancing terlebih dahulu. Objek sisi klien ini menentukan pusat data yang menjadi tujuan perutean operasi.
Setelah pusat data diidentifikasi, Cassandra menghubungi node koordinator untuk mengelola operasi. Jika kebijakan mengenali token, koordinator adalah node yang menyalurkan 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 menjalankan operasi.
Di Bigtable, seperti yang dibahas sebelumnya, setiap operasi menyertakan ID profil aplikasi. Profil aplikasi ditentukan di tingkat layanan. Lapisan perutean Bigtable memeriksa profil untuk memilih cluster tujuan yang sesuai untuk operasi. Kemudian, lapisan perutean menyediakan jalur bagi operasi untuk mencapai node pemrosesan yang benar menggunakan tombol baris operasi.
Proses penulisan data
Kedua database dioptimalkan untuk penulisan yang cepat dan menggunakan proses serupa untuk menyelesaikan penulisan. Namun, langkah-langkah yang diambil database sedikit berbeda, terutama untuk Cassandra, di mana, 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 akan disimpan terlebih dahulu ke disk secara berurutan dalam log commit (Cassandra) atau log bersama (Bigtable). Selanjutnya, operasi tulis 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 penulisan telah selesai. Di BigQuery, karena setiap kunci baris hanya ditetapkan ke satu node kapan saja, hanya respons dari node yang diperlukan untuk mengonfirmasi bahwa penulisan berhasil.
Kemudian, jika perlu, Anda dapat mengosongkan memtable ke disk dalam bentuk SSTable baru. Di Cassandra, pengosongan terjadi saat log commit mencapai ukuran maksimum, atau saat memtable melebihi batas yang Anda konfigurasi. Di Bigtable, flush dimulai untuk membuat SSTable 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 serupa. Namun, Cassandra hanya mengizinkan satu nilai untuk setiap sel, sedangkan Bigtable dapat menyimpan sejumlah besar nilai berversi untuk setiap sel.
Jika nilai di persimpangan ID baris dan kolom unik diubah, pembaruan akan dipertahankan seperti yang dijelaskan sebelumnya di bagian proses penulisan data. Stempel waktu penulisan disimpan bersama nilai dalam struktur SSTable.
Jika belum menghapus sel yang telah diperbarui ke SSTable, Anda hanya dapat menyimpan nilai sel dalam memtable, tetapi database akan berbeda berdasarkan apa yang disimpan. Cassandra hanya menyimpan nilai terbaru dalam memtable, sedangkan Bigtable menyimpan semua versi dalam memtable.
Atau, jika Anda telah menghapus setidaknya satu versi nilai sel ke disk di SSTables terpisah, database akan menangani permintaan untuk data tersebut secara berbeda. Ketika sel diminta dari Cassandra, hanya nilai terbaru menurut stempel waktu yang akan ditampilkan; dengan kata lain, penulisan terakhir yang menang. Di Bigtable, Anda menggunakan filter untuk mengontrol versi sel mana yang ditampilkan oleh permintaan baca.
Penghapusan baris
Karena kedua database menggunakan file SSTable yang tidak dapat diubah untuk mempertahankan data ke disk, baris tidak dapat dihapus secara langsung. 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 akan berisi penanda dengan stempel waktu yang menunjukkan bahwa ID baris unik telah dihapus dan tidak boleh ditampilkan dalam hasil kueri.
Time to live (TTL)
Kemampuan time to live (TTL) pada kedua database serupa, kecuali untuk satu perbedaan. Di Cassandra, Anda dapat menetapkan TTL untuk kolom atau tabel, sedangkan di Bigtable, Anda hanya dapat menetapkan TTL untuk jenis kolom. Terdapat metode untuk Bigtable yang dapat menyimulasikan TTL level sel.
Pembersihan sampah memori
Karena pembaruan atau penghapusan data langsung tidak mungkin dilakukan dengan SSTable yang tidak dapat diubah, seperti yang dibahas sebelumnya, pembersihan sampah memori terjadi selama proses yang disebut pemadatan. Proses ini menghapus sel atau baris yang tidak seharusnya disajikan dalam hasil kueri.
Proses pembersihan sampah memori mengecualikan baris atau sel saat penggabungan SSTable terjadi. Jika ada penanda atau tombstone untuk sebuah 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 tersebut. Jika ada dua versi dengan stempel waktu untuk sel tertentu, Cassandra hanya menyertakan nilai terbaru dalam SSTable gabungan.
Jalur pembacaan data
Saat operasi baca mencapai node pemrosesan yang sesuai, proses baca untuk mendapatkan data guna memenuhi hasil kueri adalah sama untuk kedua database.
Untuk setiap SSTable pada 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 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 SSTable kandidat pada disk. Karena semua kunci diurutkan secara leksikografis, akan efisien untuk mendapatkan tampilan gabungan yang dipindai untuk mendapatkan hasil kueri.
Di Cassandra, sekumpulan node pemrosesan yang ditentukan oleh tingkat konsistensi operasi harus berpartisipasi dalam operasi. Di Bigtable, hanya node yang bertanggung jawab atas rentang kunci yang perlu diminta masukannya. Untuk Cassandra, Anda perlu mempertimbangkan implikasi ukuran komputasi karena kemungkinan beberapa node akan memproses setiap pembacaan.
Hasil baca dapat dibatasi pada node pemrosesan dengan cara yang sedikit berbeda.
Di Cassandra, klausa WHERE dalam kueri CQL membatasi baris yang ditampilkan. Batasannya adalah kolom dalam kunci utama atau kolom yang disertakan dalam indeks sekunder mungkin digunakan untuk membatasi hasil.
Bigtable menawarkan beragam filter filter yang beragam yang memengaruhi baris atau sel yang diambil oleh kueri baca.
Ada tiga kategori filter:
- Filter pembatasan, yang mengontrol baris atau sel yang tercakup dalam respons.
- Memodifikasi filter, yang mempengaruhi data atau metadata untuk setiap sel.
- Menulis filter, yang memungkinkan Anda menggabungkan beberapa filter menjadi satu filter.
Filter pembatasan adalah yang paling umum digunakan—misalnya, ekspresi reguler grup kolom dan ekspresi reguler penentu kolom.
Penyimpanan data fisik
Bigtable dan Cassandra menyimpan data di SSTables, yang digabungkan secara rutin selama fase pemadatan. Kompresi data SSTable menawarkan manfaat yang serupa untuk mengurangi ukuran penyimpanan. Namun, kompresi diterapkan secara otomatis di Bigtable dan merupakan opsi konfigurasi di Cassandra.
Saat membandingkan kedua database tersebut, Anda harus memahami bagaimana setiap database secara fisik menyimpan data 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 disalurkan oleh node cluster.
Bigtable menggunakan awalan variabel ke kunci baris lengkap untuk menempatkan data secara leksikografis di SSTable.
Versi sel
Cassandra hanya menyimpan satu versi nilai sel aktif. Jika dua penulisan dilakukan ke sel, kebijakan last-write-wins memastikan bahwa hanya satu nilai yang ditampilkan.
Bigtable tidak membatasi jumlah versi dengan stempel waktu untuk setiap sel. Batas ukuran baris lainnya mungkin berlaku. Jika tidak ditetapkan oleh permintaan klien, stempel waktu ditentukan oleh layanan Bigtable saat node pemrosesan menerima mutasi. Versi sel dapat dipangkas menggunakan kebijakan pembersihan sampah memori yang dapat berbeda untuk setiap grup kolom tabel, atau dapat difilter dari hasil kueri yang ditetapkan melalui API.
Penyimpanan disk
Cassandra menyimpan SSTables pada disk yang terpasang ke setiap node cluster. Untuk menyeimbangkan kembali data di Cassandra, file harus disalin secara fisik antar-server.
Bigtable menggunakan Colossus untuk menyimpan SSTable. Karena Bigtable menggunakan sistem file terdistribusi ini, layanan Bigtable dapat hampir langsung menetapkan ulang SSTables ke node yang berbeda.
Ketahanan dan replikasi data
Cassandra memberikan ketahanan data melalui setelan faktor replikasi. Faktor replikasi menentukan jumlah salinan SSTable yang disimpan di berbagai node 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 disediakan melalui replikasi yang disediakan Colossus.
Diagram berikut mengilustrasikan tata letak data fisik, node pemrosesan komputasi, dan lapisan perutean untuk Bigtable:
Di lapisan penyimpanan Colossus, setiap node ditetapkan untuk menyalurkan data yang disimpan dalam serangkaian SSTables. SSTable tersebut berisi data untuk rentang kunci baris yang ditetapkan secara dinamis ke setiap node. Meskipun diagram menunjukkan tiga SSTable untuk setiap node, kemungkinan akan ada lebih banyak lagi karena SSTables dibuat secara terus-menerus saat node menerima perubahan baru pada data.
Setiap node memiliki log bersama. Penulisan yang diproses oleh setiap node akan segera disimpan di log bersama sebelum klien menerima konfirmasi tulis. Karena penulisan ke Colossus direplikasi beberapa kali, ketahanan dijamin meskipun kegagalan hardware nodal terjadi sebelum data disimpan ke SSTable untuk rentang baris.
Antarmuka aplikasi
Awalnya, akses database Cassandra diekspos melalui Thrift API, tetapi metode akses ini tidak digunakan lagi. Interaksi klien yang direkomendasikan adalah melalui CQL.
Mirip dengan Thrift API asli dari 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 CLI cbt, dan library klien yang mendukung banyak bahasa pemrograman umum. Library ini di-build berdasarkan gRPC dan REST API. 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 sepenuhnya terintegrasi 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, yaitu setelan yang direkomendasikan dan paling umum, Anda harus menyediakan penyimpanan untuk menyimpan data tiga kali lipat dari jumlah data yang diharapkan untuk disimpan di cluster. Anda juga harus menentukan dan menetapkan konfigurasi untuk vnode, rak, dan replikasi.
Pemisahan komputasi dari penyimpanan di Bigtable menyederhanakan penskalaan cluster naik dan turun dibandingkan dengan Cassandra. Dalam cluster yang biasanya berjalan, Anda biasanya hanya memikirkan 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 penyediaan cluster 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 sebuah instance harus memiliki jenis penyimpanan yang sama.
Saat memperhitungkan kebutuhan penyimpanan dengan Bigtable, Anda tidak perlu memperhitungkan replika penyimpanan seperti saat mengubah ukuran cluster Cassandra. Tidak ada kehilangan kepadatan penyimpanan untuk mencapai fault tolerance seperti yang terlihat pada Cassandra. Selain itu, karena penyimpanan tidak perlu disediakan secara tersurat, Anda hanya 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 harus memperhitungkan tiga salinan data berdasarkan sebagian besar konfigurasi.
Meskipun QPS tulis untuk SSD hampir sama dengan HDD, SSD menyediakan QPS baca yang jauh lebih tinggi daripada HDD. Harga penyimpanan SSD 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. Konsekuensinya adalah pembacaan acak jauh lebih lambat, hanya mendukung pembacaan 500 baris per detik untuk setiap node. HDD lebih disarankan untuk beban kerja intensif operasi tulis, yang mana pembacaan diharapkan sebagai pemindaian rentang yang terkait dengan batch processing. Harga penyimpanan HDD sesuai dengan atau mendekati biaya Cloud Storage dan bervariasi menurut region.
Pertimbangan ukuran cluster
Saat Anda menentukan ukuran instance Bigtable untuk mempersiapkan migrasi beban kerja Cassandra, ada pertimbangan saat membandingkan cluster Cassandra pusat data tunggal dengan instance Bigtable satu cluster, dan cluster pusat beberapa data Cassandra terhadap 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 pusat data tunggal
Saat membandingkan cluster pusat data tunggal dengan instance Bigtable cluster tunggal, Anda harus mempertimbangkan persyaratan penyimpanan
terlebih dahulu. Anda dapat memperkirakan ukuran yang tidak direplikasi dari setiap keyspace menggunakan
perintah tablestats nodetool
dan membagi total ukuran penyimpanan yang dihapus permanen dengan faktor replikasi keyspace. Kemudian, Anda membagi jumlah penyimpanan yang tidak direplikasi dari semua keyspace dengan
3,5 TB
(5 TB * 0,70)
untuk menentukan jumlah node SSD yang disarankan untuk menangani penyimpanan saja. Seperti yang telah dibahas, Bigtable menangani replikasi dan ketahanan penyimpanan dalam tingkat terpisah yang transparan bagi pengguna.
Selanjutnya, Anda harus mempertimbangkan persyaratan komputasi untuk jumlah node. Anda dapat melihat metrik server dan aplikasi klien Cassandra untuk mendapatkan perkiraan jumlah pembacaan dan penulisan berkelanjutan yang telah dijalankan. Untuk memperkirakan jumlah minimum node SSD yang akan menjalankan beban kerja 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 kueri dan data representatif 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 dengan kebutuhan penyimpanan atau throughput, Anda dapat mencocokkan jumlah node Bigtable dengan jumlah mesin Cassandra standar. Anda dapat meningkatkan atau menurunkan skala cluster Bigtable agar sesuai dengan kebutuhan workload dengan upaya minimal dan tanpa periode nonaktif.
Cluster pusat data multi-data
Dengan beberapa cluster pusat data, lebih sulit untuk menentukan konfigurasi instance Bigtable. Idealnya, Anda harus memiliki cluster di instance untuk setiap pusat data dalam topologi Cassandra. Setiap cluster Bigtable dalam instance harus menyimpan semua data dalam instance dan harus mampu menangani total rasio penyisipan di seluruh cluster. Cluster dalam sebuah instance dapat dibuat di region cloud mana pun yang didukung di seluruh dunia.
Teknik untuk memperkirakan kebutuhan penyimpanan mirip dengan pendekatan untuk
cluster pusat data tunggal. Anda menggunakan nodetool untuk mengambil ukuran penyimpanan
setiap keyspace di cluster Cassandra, lalu membagi ukuran tersebut dengan jumlah
replika. Anda perlu mengingat bahwa keyspace tabel mungkin memiliki faktor replikasi
yang berbeda untuk setiap pusat data.
Jumlah node di setiap cluster dalam instance harus dapat menangani semua operasi tulis di seluruh cluster dan semua operasi baca ke setidaknya dua pusat data untuk mempertahankan tujuan tingkat layanan (SLO) selama penghentian cluster. Pendekatan umumnya 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 satu per satu untuk memenuhi kebutuhan workload tanpa periode nonaktif.
Administrasi
Bigtable menyediakan komponen yang terkelola sepenuhnya untuk fungsi administrasi umum yang dijalankan di Cassandra.
Pencadangan dan pemulihan
Bigtable menyediakan dua metode untuk memenuhi kebutuhan pencadangan umum: Pencadangan Bigtable dan ekspor data terkelola.
Cadangan Bigtable dapat disamakan dengan versi terkelola 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. Cadangan didesain untuk membuat
titik pemulihan jika terjadi kerusakan tingkat aplikasi. Cadangan yang Anda buat melalui utilitas ini tidak memakai resource node dan dikenakan harga yang 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 dengan menggunakan ekspor data terkelola ke Cloud Storage. Anda dapat mengekspor ke dalam format file Avro, Parquet, atau Hadoop Sequence. Dibandingkan cadangan Bigtable, ekspor memerlukan waktu lebih lama untuk dijalankan dan menimbulkan biaya komputasi tambahan karena ekspor menggunakan Dataflow. Namun, ekspor ini menghasilkan file data portabel yang dapat Anda 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 untuk menyeimbangkan kembali node (atau vnode) di seluruh mesin dalam cluster.
Anda dapat mengubah ukuran cluster secara manual di Google Cloud Console 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 seperti patching OS, pemulihan node, perbaikan node, pemantauan pemadatan penyimpanan, dan rotasi sertifikat SSL dengan lancar.
Monitoring
Menghubungkan Bigtable ke visualisasi atau pemberitahuan metrik tidak memerlukan upaya administrasi atau pengembangan. Halaman konsol Google Cloud Bigtable dilengkapi dengan dasbor bawaan untuk melacak metrik throughput dan pemanfaatan pada tingkat instance, cluster, dan tabel. Tampilan dan pemberitahuan kustom dapat dibuat di dasbor Cloud Monitoring, tempat metrik tersedia secara otomatis.
Key Visualizer Bigtable, yakni fitur pemantauan di Konsol Google Cloud, yang dapat Anda gunakan untuk melakukan penyesuaian performa lanjutan.
IAM dan keamanan
Di Bigtable, otorisasi terintegrasi sepenuhnya ke dalam framework IAM Google Cloud dan memerlukan penyiapan serta pemeliharaan minimal. Akun dan sandi pengguna lokal tidak dibagikan ke aplikasi klien. Sebagai gantinya, izin dan peran terperinci diberikan kepada pengguna dan akun layanan tingkat organisasi.
Bigtable secara otomatis mengenkripsi semua data dalam penyimpanan dan dalam pengiriman. Tidak ada opsi untuk menonaktifkan fitur ini. Semua akses administratif dicatat sepenuhnya ke dalam log. Anda dapat menggunakan Kontrol Layanan VPC untuk mengontrol akses ke instance Bigtable dari luar jaringan yang disetujui.
Langkah selanjutnya
- Baca Desain skema Bigtable.
- Coba codelab Bigtable untuk pengguna Cassandra.
- Pelajari emulator Bigtable.
- Pelajari arsitektur referensi, diagram, dan praktik terbaik tentang Google Cloud. Lihat Cloud Architecture Center kami.