Antarmuka Cassandra

Halaman ini membandingkan arsitektur Apache Cassandra dan Spanner, serta membantu Anda memahami kemampuan dan batasan antarmuka Cassandra Spanner. Panduan ini mengasumsikan bahwa Anda sudah terbiasa dengan Cassandra dan ingin memigrasikan aplikasi yang ada atau mendesain aplikasi baru sambil menggunakan Spanner sebagai database Anda.

Cassandra dan Spanner adalah database terdistribusi berskala besar yang dibuat untuk aplikasi yang memerlukan skalabilitas tinggi dan latensi rendah. Meskipun kedua database dapat mendukung workload NoSQL yang berat, Spanner menyediakan fitur canggih untuk pemodelan data, kueri, dan operasi transaksional. Untuk mengetahui informasi selengkapnya tentang cara Spanner memenuhi kriteria database NoSQL, lihat Spanner untuk workload non-relasional.

Konsep inti

Bagian ini membandingkan konsep utama Cassandra dan Spanner.

Terminologi

Cassandra Spanner
Cluster Instance

Cluster Cassandra setara dengan instance Spanner - kumpulan server dan resource penyimpanan. Karena Spanner adalah layanan terkelola, Anda tidak perlu mengonfigurasi hardware atau software yang mendasarinya. Anda hanya perlu menentukan jumlah node yang ingin Anda cadangkan untuk instance atau menggunakan penskalaan otomatis untuk menskalakan instance secara otomatis. Instance berfungsi seperti penampung untuk database Anda. Anda juga memilih topologi replikasi data (regional, dual-region, atau multi-region) di tingkat instance.
Keyspace Database

Keyspace Cassandra setara dengan database Spanner, yang merupakan kumpulan tabel dan elemen skema lainnya (misalnya, indeks dan peran). Tidak seperti keyspace, Anda tidak perlu mengonfigurasi lokasi replikasi. Spanner otomatis mereplikasi data Anda ke region yang ditetapkan di instance Anda.
Tabel Tabel

Di Cassandra dan Spanner, tabel adalah kumpulan baris yang diidentifikasi oleh kunci utama yang ditentukan dalam skema tabel.
Partisi Pemisahan

Cassandra dan Spanner dapat diskalakan dengan memisahkan data. Di Cassandra, setiap shard disebut partisi, sedangkan di Spanner, setiap shard disebut split. Cassandra menggunakan partisi hash, yang berarti setiap baris ditetapkan secara independen ke node penyimpanan berdasarkan hash kunci utama. Spanner di-shard berdasarkan rentang, yang berarti bahwa baris yang berdekatan di ruang kunci kunci utama juga berdekatan dalam penyimpanan (kecuali di batas pemisahan). Spanner menangani pemisahan dan penggabungan berdasarkan beban dan penyimpanan, dan hal ini transparan bagi aplikasi. Implikasi utamanya adalah bahwa tidak seperti Cassandra, pemindaian rentang melalui awalan kunci utama adalah operasi yang efisien di Spanner.
Baris Baris

Di Cassandra dan Spanner, baris adalah kumpulan kolom yang diidentifikasi secara unik oleh kunci utama. Seperti Cassandra, Spanner mendukung kunci utama gabungan. Tidak seperti Cassandra, Spanner tidak membedakan kunci partisi dan kolom pengelompokan, karena data di-shard berdasarkan rentang. Anda dapat menganggap Spanner hanya memiliki kolom pengelompokan, dengan partisi dikelola di balik layar.
Kolom Kolom

Di Cassandra dan Spanner, kolom adalah sekumpulan nilai data yang memiliki jenis yang sama. Ada satu nilai untuk setiap baris tabel. Untuk mengetahui informasi selengkapnya tentang membandingkan jenis kolom Cassandra dengan Spanner, lihat Jenis data.

Arsitektur

Cluster Cassandra terdiri dari serangkaian server dan penyimpanan yang ditempatkan bersama dengan server tersebut. Fungsi hash memetakan baris dari keyspace partisi ke node virtual (vnode). Kemudian, sekumpulan vnode ditetapkan secara acak ke setiap server untuk melayani sebagian keyspace cluster. Penyimpanan untuk vnode terpasang secara lokal ke node penayangan. Driver klien terhubung langsung ke node penayangan dan menangani load balancing serta perutean kueri.

Instance Spanner terdiri dari serangkaian server dalam topologi replikasi. Spanner secara dinamis membagi setiap tabel menjadi rentang baris berdasarkan penggunaan CPU dan disk. Shard ditetapkan ke node komputasi untuk penayangan. Data disimpan secara fisik di Colossus, sistem file terdistribusi Google, terpisah dari node komputasi. Driver klien terhubung ke server frontend Spanner yang melakukan perutean permintaan dan load balancing. Untuk mempelajari lebih lanjut, lihat Laporan resmi tentang proses baca dan tulis Spanner.

Secara umum, kedua arsitektur ini dapat diskalakan saat resource ditambahkan ke cluster yang mendasarinya. Pemisahan komputasi dan penyimpanan Spanner memungkinkan beban di antara node komputasi diseimbangkan kembali lebih cepat sebagai respons terhadap perubahan workload. Tidak seperti Cassandra, pemindahan partisi tidak melibatkan pemindahan data karena data tetap berada di Colossus. Selain itu, partisi berbasis rentang Spanner mungkin lebih alami untuk aplikasi yang mengharapkan data diurutkan berdasarkan kunci partisi. Sisi lain partisi berbasis rentang adalah bahwa workload yang menulis ke satu ujung keyspace (misalnya, tabel yang dikunci oleh stempel waktu saat ini) mungkin memiliki hotspot jika desain skema tambahan tidak dipertimbangkan. Untuk mengetahui informasi selengkapnya tentang teknik mengatasi hotspot, lihat Praktik terbaik desain skema.

Konsistensi

Dengan Cassandra, Anda harus menentukan tingkat konsistensi untuk setiap operasi. Jika Anda menggunakan tingkat konsistensi kuorum, sebagian besar node replika harus merespons node koordinator agar operasi dianggap berhasil. Jika Anda menggunakan tingkat konsistensi satu, Cassandra memerlukan satu node replika untuk merespons agar operasi dianggap berhasil.

Spanner memberikan konsistensi yang kuat. Spanner API tidak mengekspos replika ke klien. Klien Spanner berinteraksi dengan Spanner seolah-olah Spanner adalah database satu mesin. Penulisan selalu ditulis ke sebagian besar replika sebelum Spanner melaporkan keberhasilannya kepada pengguna. Setiap pembacaan berikutnya akan mencerminkan data yang baru ditulis. Aplikasi dapat memilih untuk membaca snapshot database pada waktu di masa lalu, yang mungkin memiliki manfaat performa dibandingkan pembacaan yang kuat. Untuk mengetahui informasi selengkapnya tentang properti konsistensi Spanner, lihat Ringkasan transaksi.

Spanner dibuat untuk mendukung konsistensi dan ketersediaan yang diperlukan dalam aplikasi berskala besar. Spanner memberikan konsistensi kuat dalam skala besar dan dengan performa tinggi. Untuk kasus penggunaan yang memerlukannya, Spanner mendukung pembacaan snapshot (tidak terbaru) yang mengurangi persyaratan keaktualan.

Antarmuka Cassandra

Antarmuka Cassandra memungkinkan Anda memanfaatkan infrastruktur Spanner yang terkelola sepenuhnya, skalabel, dan memiliki ketersediaan tinggi menggunakan alat dan sintaksis Cassandra yang sudah dikenal. Halaman ini membantu Anda memahami kemampuan dan batasan antarmuka Cassandra.

Manfaat antarmuka Cassandra

  • Portabilitas: antarmuka Cassandra menyediakan akses ke berbagai fitur Spanner, menggunakan skema, kueri, dan klien yang kompatibel dengan Cassandra. Hal ini menyederhanakan pemindahan aplikasi yang dibangun di Spanner ke lingkungan Cassandra lain atau sebaliknya. Portabilitas ini memberikan fleksibilitas deployment dan mendukung skenario pemulihan dari bencana, seperti keluar paksa.
  • Keakraban: jika sudah menggunakan Cassandra, Anda dapat mulai menggunakan Spanner dengan cepat menggunakan banyak pernyataan dan jenis CQL yang sama.
  • Spanner yang tidak berkompromi: karena dibangun di atas fondasi Spanner yang ada, antarmuka Cassandra memberikan semua manfaat ketersediaan, konsistensi, dan rasio harga-performa Spanner yang ada tanpa harus mengorbankan kemampuan apa pun yang tersedia di ekosistem GoogleSQL yang saling melengkapi.

Kompatibilitas CQL

  • Dukungan dialek CQL: Spanner menyediakan subset dialek CQL, termasuk Bahasa Kueri Data (DQL), Bahasa Pengolahan Data (DML), transaksi ringan (LWT), fungsi agregat dan tanggal/waktu.

  • Fungsi Cassandra yang didukung: antarmuka Cassandra mendukung banyak fitur Cassandra yang paling umum digunakan. Ini mencakup bagian inti skema dan sistem jenis, banyak bentuk kueri umum, berbagai fungsi dan operator, serta aspek utama katalog sistem Cassandra. Aplikasi dapat menggunakan banyak klien atau driver Cassandra dengan terhubung melalui penerapan protokol wire Cassandra di Spanner.

  • Dukungan protokol klien dan wire: Spanner mendukung kemampuan kueri inti protokol wire Cassandra v4 menggunakan Cassandra Adapter, klien ringan yang berjalan bersama aplikasi Anda. Hal ini memungkinkan banyak klien Cassandra berfungsi sebagaimana adanya dengan database antarmuka Spanner Cassandra, sekaligus memanfaatkan pengelolaan koneksi dan endpoint global serta autentikasi IAM Spanner.

Jenis data Cassandra yang didukung

Tabel berikut menunjukkan jenis data Cassandra yang didukung dan memetakan setiap jenis data ke jenis data GoogleSQL Spanner yang setara.

Jenis data Cassandra yang didukung Jenis data GoogleSQL Spanner
Jenis numerik tinyint (bilangan bulat 8-bit yang telah ditandai) INT64 (bilangan bulat 64-bit yang telah ditandai)

Spanner mendukung satu jenis data lebar 64-bit untuk bilangan bulat bertanda.
smallint (bilangan bulat 16-bit yang telah ditandai)
int (bilangan bulat 32-bit yang telah ditandai)
bigint (bilangan bulat 64-bit yang telah ditandai)
float (floating point IEEE-754 32-bit) FLOAT32 (floating point IEEE-754 32-bit)
double (floating point IEEE-754 64-bit) FLOAT64 (floating point IEEE-754 64-bit)
decimal Untuk angka desimal presisi tetap, gunakan jenis data NUMERIC (presisi 38 skala 9).
varint (bilangan bulat presisi variabel)
Jenis string text STRING(MAX)

text dan varchar menyimpan dan memvalidasi string UTF-8. Di Spanner, kolom STRING harus menentukan panjang maksimumnya. Tidak ada dampak pada penyimpanan; ini untuk tujuan validasi.
varchar
ascii STRING(MAX)
uuid STRING(MAX)
inet STRING(MAX)
blob BYTES(MAX)

Untuk menyimpan data biner, gunakan jenis data BYTES.
Jenis tanggal dan waktu date DATE
time INT64

Spanner tidak mendukung jenis data waktu khusus. Gunakan INT64 untuk menyimpan durasi nanodetik.
timestamp TIMESTAMP
timeuuid STRING(MAX)
Jenis penampung set ARRAY

Spanner tidak mendukung jenis data set khusus. Gunakan kolom ARRAY untuk merepresentasikan set.
list ARRAY

Gunakan ARRAY untuk menyimpan daftar objek yang diketik.
map JSON

Spanner tidak mendukung jenis peta khusus. Gunakan kolom JSON untuk merepresentasikan peta.
Jenis lainnya boolean BOOL
counter INT64

Anotasi jenis data

Opsi kolom cassandra_type memungkinkan Anda menentukan pemetaan antara jenis data Cassandra dan Spanner. Saat membuat tabel di Spanner yang ingin Anda ajak berinteraksi menggunakan kueri yang kompatibel dengan Cassandra, Anda dapat menggunakan opsi cassandra_type untuk menentukan jenis data Cassandra yang sesuai untuk setiap kolom. Pemetaan ini kemudian digunakan oleh Spanner untuk menafsirkan dan mengonversi data dengan benar saat mentransfernya di antara dua sistem database.

Misalnya, jika ada tabel di Cassandra dengan skema berikut:

CREATE TABLE Albums (
  albumId uuid,
  title varchar,
  artists set<varchar>,
  tags  map<varchar, varchar>,
  numberOfSongs tinyint,
  releaseDate date,
  copiesSold bigint,
  score frozen<set<int>>
  ....
  PRIMARY KEY(albumId)
)

Di Spanner, Anda menggunakan anotasi jenis untuk memetakan ke jenis data Cassandra, seperti yang ditunjukkan berikut:

CREATE TABLE Albums (
  albumId       STRING(MAX) OPTIONS (cassandra_type = 'uuid'),
  title         STRING(MAX) OPTIONS (cassandra_type = 'varchar'),
  artists       ARRAY<STRING(max)> OPTIONS (cassandra_type = 'set<varchar>'),
  tags          JSON OPTIONS (cassandra_type = 'map<varchar, varchar>'),
  numberOfSongs INT64 OPTIONS (cassandra_type = 'tinyint'),
  releaseDate   DATE OPTIONS (cassandra_type = 'date'),
  copiesSold    INT64 OPTIONS (cassandra_type = 'bigint'),
  score         ARRAY<INT64> OPTIONS (cassandra_type = 'frozen<set<int>>')
  ...
) PRIMARY KEY (albumId);

Pada contoh sebelumnya, klausa OPTIONS memetakan jenis data Spanner kolom ke jenis data Cassandra yang sesuai.

  • albumId (Spanner STRING(MAX)) dipetakan ke uuid di Cassandra.
  • title (Spanner STRING(MAX)) dipetakan ke varchar di Cassandra.
  • artists (Spanner ARRAY<STRING(MAX)>) dipetakan ke set<varchar> di Cassandra.
  • tags (Spanner JSON) dipetakan ke map<varchar,varchar> di Cassandra.
  • numberOfSongs (Spanner INT64) dipetakan ke tinyint di Cassandra.
  • releaseDate (Spanner DATE) dipetakan ke date di Cassandra.
  • copiesSold (Spanner INT64) dipetakan ke bigint di Cassandra.
  • score (Spanner ARRAY<INT64>) dipetakan ke frozen<set<int>> di Cassandra.
Mengubah opsi cassandra_type

Anda dapat menggunakan pernyataan ALTER TABLE untuk menambahkan atau mengubah opsi cassandra_type pada kolom yang ada.

Untuk menambahkan opsi cassandra_type ke kolom yang belum memilikinya, gunakan pernyataan berikut:

ALTER TABLE Albums ALTER COLUMN uuid SET OPTIONS (cassandra_type='uuid');

Dalam contoh ini, kolom uuid di tabel Album diperbarui dengan opsi cassandra_type yang ditetapkan ke uuid.

Untuk mengubah opsi cassandra_type yang ada, gunakan pernyataan ALTER TABLE dengan nilai cassandra_type baru. Misalnya, untuk mengubah cassandra_type kolom numberOfSongs di tabel Album dari tinyint menjadi bigint, gunakan pernyataan berikut:

ALTER TABLE Albums ALTER COLUMN numberOfSongs SET OPTIONS (cassandra_type='bigint');

Anda hanya diizinkan untuk mengubah jenis berikut:

Dari Ke
tinyint smallint, int, bigint
smallint int, bigint
int bigint
float double
teks biasa varchar
ascii varchar, text
Pemetaan langsung dan bernuansa

Dalam banyak kasus, pemetaan antara jenis data Spanner dan Cassandra cukup mudah. Misalnya, STRING(MAX) Spanner dipetakan ke varchar Cassandra, dan INT64 Spanner dipetakan ke bigint Cassandra.

Namun, ada situasi saat pemetaan memerlukan lebih banyak pertimbangan dan penyesuaian. Misalnya, Anda mungkin perlu memetakan smallint Cassandra ke INT64 Spanner.

Fungsi Cassandra yang didukung

Bagian ini mencantumkan fungsi Cassandra yang didukung di Spanner.

Daftar berikut menunjukkan dukungan Spanner untuk fungsi Cassandra.

Time to live (TTL)

Saat bermigrasi dari Cassandra, tambahkan kebijakan penghapusan baris ke tabel Spanner Anda untuk menggunakan opsi USING TTL dalam pernyataan INSERT atau UPDATE atau TTL Spanner.

Logika TTL Spanner beroperasi di tingkat baris, berbeda dengan Cassandra, yang logika TTL-nya dapat diterapkan di tingkat sel. Untuk menggunakan TTL Spanner, Anda harus menyertakan kolom stempel waktu dan interval waktu dalam kebijakan penghapusan baris. Spanner menghapus baris setelah baris melampaui durasi yang ditentukan relatif terhadap stempel waktu.

Penghapusan TTL Spanner tidak instan. Proses latar belakang asinkron menghapus baris yang sudah tidak berlaku, dan penghapusan dapat memerlukan waktu hingga 72 jam.

Untuk mengetahui informasi selengkapnya, lihat Mengaktifkan TTL pada data Cassandra.

Fitur Cassandra yang tidak didukung di Spanner

Penting untuk dipahami bahwa antarmuka Cassandra menyediakan kemampuan Spanner melalui skema, jenis, kueri, dan klien yang kompatibel dengan Cassandra. Fitur ini tidak mendukung semua fitur Cassandra. Memigrasikan aplikasi Cassandra yang ada ke Spanner, meskipun menggunakan antarmuka Cassandra, kemungkinan memerlukan beberapa pengerjaan ulang untuk mengakomodasi kemampuan Cassandra yang tidak didukung atau perbedaan perilaku, seperti pengoptimalan kueri atau desain kunci utama. Namun, setelah dimigrasikan, workload Anda dapat memanfaatkan keandalan Spanner dan kemampuan multi-model yang unik.

Daftar berikut memberikan informasi selengkapnya tentang fitur Cassandra yang tidak didukung:

  • Beberapa fitur bahasa CQL tidak didukung: jenis dan fungsi yang ditentukan pengguna, stempel waktu penulisan.
  • Spanner dan Google Cloud control plane: database dengan antarmuka Cassandra menggunakan Spanner dan alat Google Cloud untuk menyediakan, mengamankan, memantau, dan mengoptimalkan instance. Spanner tidak mendukung alat, seperti nodetool untuk aktivitas administratif.

Dukungan DDL

Pernyataan DDL CQL tidak didukung secara langsung menggunakan antarmuka Cassandra. Untuk perubahan DDL, Anda harus menggunakan konsol Google Cloud Spanner, perintah gcloud, atau library klien.

Konektivitas

  • Dukungan klien Cassandra

    Spanner memungkinkan Anda terhubung ke database dari berbagai klien:

Kontrol akses dengan Identity and Access Management

Anda harus memiliki izin spanner.databases.adapt, spanner.databases.select, dan spanner.databases.write untuk melakukan operasi baca dan tulis terhadap endpoint Cassandra. Untuk mengetahui informasi selengkapnya, lihat Ringkasan IAM.

Untuk mengetahui informasi selengkapnya tentang cara memberikan izin IAM Spanner, lihat Menerapkan peran IAM.

Pemantauan

Spanner menyediakan metrik berikut untuk membantu Anda memantau Cassandra Adapter:

  • spanner.googleapis.com/api/adapter_request_count: mencatat dan mengekspos jumlah permintaan adaptor yang dilakukan Spanner per detik, atau jumlah error yang terjadi di server Spanner per detik.
  • spanner.googleapis.com/api/adapter_request_latencies: mencatat dan mengekspos jumlah waktu yang diperlukan Spanner untuk menangani permintaan adaptor.

Anda dapat membuat dasbor Cloud Monitoring kustom untuk menampilkan dan memantau metrik untuk Cassandra Adapter. Dasbor kustom berisi diagram berikut:

  • Latensi Permintaan P99: Distribusi persentil ke-99 latensi permintaan server per message_type untuk database Anda.

  • Latensi Permintaan P50: Distribusi persentil ke-50 latensi permintaan server per message_type untuk database Anda.

  • Jumlah Permintaan API menurut Jenis Pesan: Jumlah permintaan API per message_type untuk database Anda.

  • Jumlah Permintaan API menurut Jenis Operasi: Jumlah permintaan API per op_type untuk database Anda.

  • Tingkat Error: Tingkat error API untuk database Anda.

Google Cloud console

  1. Download file cassandra-adapter-dashboard.json. File ini memiliki informasi yang diperlukan untuk mengisi dasbor kustom di Monitoring.

  2. Di konsol Google Cloud , buka halaman  Dashboards:

    Buka Dasbor

    Jika Anda menggunakan kotak penelusuran untuk menemukan halaman ini, pilih hasil yang subjudulnya adalah Monitoring.

  3. Di halaman Dashboards Overview, klik Create Custom Dashboard.
  4. Di toolbar dasbor, klik ikon Setelan dasbor. Kemudian pilih JSON, lalu Editor JSON.
  5. Di panel JSON Editor, salin konten file cassandra-adapter-dashboard.json yang Anda download dan tempelkan di editor.
  6. Untuk menerapkan perubahan pada dasbor, klik Terapkan perubahan. Jika Anda tidak ingin menggunakan dasbor ini, kembali ke halaman Ringkasan Dasbor.
  7. Setelah dasbor dibuat, klik Tambahkan Filter. Kemudian, pilih project_id atau instance_id untuk memantau Cassandra Adapter.

gcloud CLI

  1. Download file cassandra-adapter-dashboard.json. File ini memiliki informasi yang diperlukan untuk mengisi dasbor kustom di Monitoring.

  2. Untuk membuat dasbor dalam project, gunakan perintah gcloud monitoring dashboards create:

    gcloud monitoring dashboards create --config-from-file=cassandra-adapter-dashboard.json

    Untuk informasi selengkapnya, lihat referensi gcloud monitoring dashboards create.

Selain itu, metrik Spanner berikut berguna untuk memantau Cassandra Adapter:

  • Metrik pemakaian CPU memberikan informasi tentang penggunaan CPU untuk tugas pengguna dan sistem dengan perincian menurut prioritas dan jenis operasi.
  • Metrik penggunaan penyimpanan memberikan informasi tentang penyimpanan database dan cadangan.
  • Tabel statistik bawaan Spanner memberikan insight tentang kueri, transaksi, dan pembacaan untuk membantu Anda menemukan masalah dalam database Anda.

Untuk mengetahui daftar lengkap insight sistem, lihat Memantau instance dengan insight sistem. Untuk mempelajari lebih lanjut cara memantau resource Spanner, lihat Memantau instance dengan Cloud Monitoring.

Harga

Tidak ada biaya tambahan untuk menggunakan endpoint Cassandra. Anda akan dikenai biaya sesuai harga Spanner standar untuk jumlah kapasitas komputasi yang digunakan instance Anda dan jumlah penyimpanan yang digunakan database Anda.

Untuk mengetahui informasi selengkapnya, lihat Harga Spanner.

Langkah berikutnya