Apache Cassandra Adalah: Cara Kerja, Versi & Kebutuhannya

Sebagian besar aplikasi memulai hidupnya dengan satu server database. Selama datanya masih wajar, cara itu bekerja dengan sangat baik. Saat kapasitasnya mulai sesak, jalan keluar yang pertama terpikir adalah membesarkan mesin tersebut: menambah RAM, mengganti prosesor, memindahkan data ke penyimpanan yang lebih cepat.

Cara itu punya dua batas yang keras. Pertama, harga mesin naik jauh lebih cepat daripada kemampuannya. Kedua, sebesar apa pun mesin itu, ia tetap satu titik kegagalan — ketika ia mati, seluruh layanan ikut berhenti.

Apache Cassandra adalah database yang lahir dari keputusan mengambil arah sebaliknya. Alih-alih satu mesin besar, ia memakai banyak mesin biasa. Dan yang membedakannya dari kebanyakan sistem terdistribusi lain, tidak ada satu pun di antara mesin itu yang berperan sebagai atasan.

Apache Cassandra Adalah Database Tanpa Node Pusat

Apache Cassandra adalah sistem basis data terdistribusi bertipe wide column store yang menyebarkan data ke banyak server tanpa memakai node pusat. Setiap node di dalam cluster menjalankan perangkat lunak yang persis sama dan memiliki kewenangan yang persis sama. Sifat ini disebut masterless (tanpa pemimpin).

Konsekuensinya langsung terasa. Permintaan baca maupun tulis boleh datang ke node mana pun, dan node yang menerimanya bertindak sebagai coordinator (juru antar). Tidak ada pemilihan pemimpin baru ketika sebuah node mati, karena memang tidak ada jabatan yang perlu diisi ulang.

Dari sisi bentuk data, Cassandra menyimpan baris yang setiap barisnya boleh memiliki kumpulan kolom berbeda. Ia termasuk keluarga database NoSQL, bersama MongoDB, Redis, dan Neo4j. Cassandra database — kerap disingkat Cassandra DB — dirancang khusus untuk beban tulis yang sangat besar dan tersebar.

Perangkat lunak ini pertama kali dibuat Avinash Lakshman dan Prashant Malik di Facebook, lalu dirilis sebagai proyek terbuka pada Juli 2008. Ia masuk Apache Incubator pada Maret 2009 dan menjadi proyek tingkat atas Apache Software Foundation pada 17 Februari 2010. Rancangannya menggabungkan teknik replikasi dari Dynamo milik Amazon dengan model penyimpanan Bigtable milik Google.

Apache Cassandra tidak ada hubungannya dengan Apache HTTP Server. Keduanya sama-sama bernaung di Apache Software Foundation, tetapi fungsinya berbeda total. Apache HTTP Server melayani halaman ke browser, sedangkan Cassandra menyimpan data di belakang layar.

Kenapa Menulis ke Cassandra Sangat Cepat

Mesin penyimpanan Cassandra berbasis LSM tree (Log Structured Merge tree), bukan B-tree seperti database relasional pada umumnya. Perbedaan ini yang menjelaskan kecepatan tulisnya.

Pada database relasional, menulis satu baris berarti mencari lebih dahulu letak halaman data yang harus diubah, dan pencarian itu membutuhkan pembacaan disk. Cassandra menghilangkan langkah tersebut: setiap penulisan hanya ditambahkan di ujung, tidak pernah menimpa di tengah.

Alurnya terdiri atas empat tahap. Data pertama dicatat di commit log, berkas yang hanya bisa ditambahi di ujung, sebagai jaminan agar penulisan tidak hilang bila listrik mati. Bersamaan dengan itu data disimpan di memtable, yaitu struktur di memori. Ketika memtable penuh, isinya dituangkan ke disk sebagai SSTable yang bersifat immutable alias tidak pernah diubah lagi.

Jalur tulis Cassandra: commit log di disk, memtable di memori, SSTable permanen, lalu compaction menggabungkannya.

Karena SSTable tidak pernah diubah, satu baris data bisa tersebar di beberapa SSTable sekaligus dengan versi berbeda. Di sinilah compaction bekerja: proses latar yang membaca beberapa SSTable, menggabungkannya, dan menulis ulang satu berkas baru yang lebih rapi. Dokumentasi resminya menyebut biaya ini dengan terus terang sebagai write amplification — setiap data yang Anda tulis pada akhirnya ditulis ulang berkali-kali.

Untuk sisi baca, Cassandra memakai bloom filter yang dengan cepat memastikan sebuah SSTable pasti tidak memuat data yang dicari, sehingga berkas tersebut tidak perlu dibuka.

Nilai bawaan commitlog_sync adalah periodic dengan periode 10.000 milidetik. Penulisan diakui lebih dahulu, lalu disinkronkan ke disk setiap 10 detik, sehingga penulisan dalam jendela itu dapat hilang bila server mati mendadak. Setelan batch menutup celah tersebut dengan bayaran kecepatan.

Ring, Token, dan Vnode: Cara Data Dibagi ke Banyak Mesin

Pertanyaan berikutnya adalah bagaimana Cassandra tahu baris tertentu harus disimpan di mesin yang mana. Jawabannya terletak pada bagian arsitektur Apache Cassandra yang paling khas: consistent hashing di atas sebuah lingkaran yang disebut token ring.

Setiap baris memiliki kunci partisi (partition key). Kunci itu dilewatkan ke fungsi hash — bawaannya Murmur3Partitioner — yang menghasilkan sebuah angka bernama token. Setiap node memiliki jatah rentang token, dan baris tersebut menjadi milik node yang rentangnya mencakup token itu. Tidak ada tabel pencarian pusat yang perlu ditanya.

Rancangan satu token per node punya kelemahan praktis. Ketika Anda menambah satu mesin ke cluster berisi delapan mesin, tidak ada posisi token baru yang membuat lingkaran itu tetap seimbang. Solusinya adalah virtual node atau vnode: satu mesin fisik memegang beberapa posisi token sekaligus. Dengan begitu mesin baru dapat mengambil potongan kecil dari banyak tetangga. Nilai bawaannya num_tokens: 16.

Token ring Cassandra: dua belas posisi token dibagi ke tiga node, tiap node memegang beberapa posisi sekaligus.

Dokumentasi Cassandra memakai empat istilah yang perlu Anda bedakan sejak awal:

1. Token: satu posisi di lingkaran hash.
2. Endpoint: satu alamat IP dan port fisik di jaringan.
3. Host ID: penanda unik sebuah node fisik.
4. Virtual node: sebuah token yang dimiliki node fisik yang sama.

Gossip: Cara Node Saling Mengabari Tanpa Koordinator

Membagi data ke banyak mesin hanya berguna kalau setiap mesin tahu tetangganya masih hidup atau tidak. Tanpa node pusat, informasi itu harus menyebar sendiri. Mekanismenya disebut gossip, dan cara kerjanya sederhana secara mengejutkan.

Setiap detik, setiap node melakukan empat hal. Ia memperbarui catatan denyutnya sendiri, lalu memilih satu node lain secara acak untuk bertukar kabar. Setelah itu ia mencoba menghubungi node yang sedang tidak terjangkau, dan menghubungi seed node bila langkah kedua belum menyentuhnya. Kabar yang dipertukarkan bukan hanya tentang dirinya, melainkan juga tentang node lain yang ia ketahui.

Setiap potong informasi diberi penanda versi berupa pasangan (generation, version). Penanda inilah yang membuat node dapat mengabaikan kabar usang tanpa perlu bertanya ke siapa pun.

Seed node sering disalahpahami sebagai node master. Sebenarnya tidak. Bedanya hanya satu: seed node boleh bergabung ke ring tanpa lebih dahulu melihat seed lain. Setelah cluster berjalan, ia hanya menjadi titik pertemuan gossip yang lebih ramai daripada node lain.

Ketika sebuah node ternyata sedang mati, node lain tidak membuang penulisan yang ditujukan kepadanya. Penulisan itu disimpan sementara sebagai hint dan dikirimkan ulang begitu node tersebut hidup kembali. Nilai bawaan max_hint_window adalah tiga jam; lewat dari itu hint dibuang, dan penyelarasan harus dilakukan lewat proses perbaikan.

Replikasi dan Consistency Level yang Bisa Anda Atur

Setiap partisi disalin ke beberapa node sesuai replication factor (RF). RF 3 berarti selalu ada tiga salinan data Anda di tiga node berbeda. Penentuan node mana yang menampung salinan diatur oleh strategi replikasi.

Ada dua strategi bawaan. Dokumentasi menyatakan SimpleStrategy hanya berguna untuk pengujian, sementara NetworkTopologyStrategy disarankan untuk produksi — bahkan ketika Anda baru memakai satu datacenter. Alasannya praktis: berpindah strategi di kemudian hari jauh lebih merepotkan daripada memakai yang benar sejak awal.

Bagian yang paling khas dari Cassandra adalah consistency level, yaitu berapa banyak replika yang harus menjawab sebelum sebuah operasi dinyatakan berhasil. Nilainya ditentukan per query, bukan sekali untuk seluruh cluster. Tersedia sembilan pilihan: ONE, TWO, THREE, QUORUM, ALL, LOCAL_QUORUM, EACH_QUORUM, LOCAL_ONE, dan ANY yang khusus untuk penulisan.

QUORUM berarti mayoritas, dengan rumus n/2 + 1. Pada RF 3, quorum berarti dua node. Aturan praktis untuk memastikan pembacaan selalu melihat penulisan terakhir adalah W + R > RF, dengan W sebagai consistency level tulis dan R sebagai consistency level baca. Memakai QUORUM untuk keduanya pada RF 3 menghasilkan 2 + 2 > 3, sehingga kedua kelompok node dijamin beririsan.

Koordinator Cassandra mengirim permintaan ke tiga replika, dan QUORUM cukup menunggu dua balasan saja.

Untuk cluster lintas lokasi, LOCAL_QUORUM memberi jaminan yang lebih longgar tetapi tetap berguna. Pembacaan dijamin melihat penulisan terakhir dari datacenter yang sama, tanpa menunggu balasan lintas benua.

Satu hal yang sering keliru dipahami: penulisan selalu dikirim ke semua replika, apa pun consistency level yang Anda pilih. Consistency level hanya menentukan berapa balasan yang ditunggu koordinator sebelum menjawab klien. Memilih ONE tidak membuat data hanya tersimpan di satu tempat.

CQL Mirip SQL, Tapi Tanpa JOIN

Cassandra diakses memakai CQL (Cassandra Query Language), bahasa yang bentuknya sangat mirip SQL. Membuat keyspace — padanan "database" di Cassandra — dan sebuah tabel terlihat seperti ini:

CREATE KEYSPACE IF NOT EXISTS store WITH REPLICATION =
{ 'class' : 'SimpleStrategy',
'replication_factor' : '1'
};

CREATE TABLE IF NOT EXISTS store.shopping_cart (
    userid text PRIMARY KEY,
    item_count int,
    last_update_timestamp timestamp
);

Kemiripan itu berhenti pada satu kalimat di dokumentasi resminya: CQL tidak mengeksekusi JOIN maupun sub-query, dan sebuah pernyataan SELECT hanya berlaku untuk satu tabel. Ini bukan fitur yang belum sempat dibuat, melainkan akibat langsung dari rancangan ring. Menggabungkan dua tabel berarti mengumpulkan data dari seluruh node, dan biayanya tidak bisa diperkirakan.

Batasan yang sama muncul pada query yang menyaring kolom di luar kunci. Perhatikan tabel users dengan indeks sekunder pada birth_year. Query berikut ditolak Cassandra:

SELECT * FROM users WHERE birth_year = 1981 AND country = 'FR';

Cassandra menolaknya karena tidak dapat menjamin berapa banyak data yang harus dipindai untuk menjawabnya. Anda bisa memaksanya berjalan dengan menambahkan satu kata kunci:

SELECT * FROM users WHERE birth_year = 1981 AND country = 'FR' ALLOW FILTERING;

Dokumentasi resminya memberi peringatan yang jelas: ALLOW FILTERING menjalankan pemindaian penuh, dan performa query menjadi tidak dapat diperkirakan. Pada tabel kecil hasilnya baik-baik saja; pada tabel produksi ia dapat menjatuhkan node.

Dari sini muncul satu aturan kerja yang membedakan Cassandra dari database relasional. Pada database relasional Anda merancang struktur dahulu, lalu menulis query apa pun sesudahnya. Pada Cassandra urutannya dibalik: petakan dahulu query yang akan dijalankan aplikasi, baru rancang tabel yang melayaninya. Satu data yang dibaca lewat tiga pola berbeda umumnya disimpan di tiga tabel berbeda.

Yang Baru di Cassandra 5.0: SAI dan Pencarian Vektor

Kewajiban menduplikasi tabel demi pola query baru itulah yang coba diringankan versi 5.0 lewat Storage-Attached Indexes (SAI). SAI memungkinkan beberapa indeks sekunder pada satu tabel, masing-masing pada kolom mana pun, dengan pemakaian ruang disk yang jauh lebih hemat daripada mekanisme indeks sebelumnya.

Di atas fondasi SAI itu, Cassandra 5.0 menambahkan tipe data vector beserta pencarian tetangga terdekat. Kemampuan ini menempatkan Cassandra sebagai vector database, yaitu penyimpan data yang bisa mencari berdasarkan kemiripan makna, bukan kecocokan huruf. Bentuknya di CQL cukup ringkas:

CREATE TABLE cycling.comments_vs (
  id uuid,
  comment text,
  comment_vector VECTOR <FLOAT, 5>,
  created_at timestamp,
  PRIMARY KEY (id, created_at)
);

CREATE INDEX IF NOT EXISTS ann_index
  ON cycling.comments_vs(comment_vector) USING 'sai';

SELECT * FROM cycling.comments_vs
    ORDER BY comment_vector ANN OF [0.15, 0.1, 0.1, 0.35, 0.55]
    LIMIT 3;

Klausa ANN OF mencari baris yang vektornya paling dekat dengan vektor yang Anda berikan. Dokumentasinya mencatat satu batas keras: LIMIT maksimal 1.000. Kemampuan inilah yang membuat Cassandra dapat dipakai sebagai penyimpan pada sistem RAG, tanpa menambah database terpisah.

Tiga perubahan lain di versi 5.0 layak Anda ketahui. Unified Compaction Strategy menyederhanakan pemilihan strategi compaction yang sebelumnya membingungkan. Trie memtable dan trie SSTable memperkecil pemakaian memori dan disk tanpa perubahan model data. Dan dynamic data masking menyamarkan isi kolom sensitif saat dibaca. Menurut pengumuman resminya, perpindahan ke JDK 17 sendiri membawa peningkatan performa hingga 20% pada sebagian kasus.

Peta Versi Cassandra dan Kebutuhan Java

Bagian ini sering dilewati, padahal ia menentukan apakah panduan yang sedang Anda ikuti masih berlaku. Tiga lini berikut sama-sama aktif, dan ketiganya dirilis serentak pada 7 Agustus 2026:

Perhatikan bentuk kebijakannya. Masa dukungan Cassandra tidak diikat pada tanggal kalender, melainkan pada rilis berikutnya: sebuah lini dipelihara sampai lini tiga tingkat di atasnya terbit. Karena versi 6.0 masih berstatus 6.0-alpha3, lini 4.0 secara resmi belum berhenti dipelihara — tetapi akan berhenti pada hari 6.0 dinyatakan siap. Versi di bawah 4.0 sudah masuk arsip, dan perbaikan celah keamanannya diputuskan kasus per kasus.

Soal Java, Cassandra 5.0 menerima JDK 11 dan JDK 17, dengan 11 sebagai bawaan, sementara Java 8 sudah dihapus sepenuhnya. Branch 6.0 dan branch pengembangan menambahkan JDK 21. Untuk cqlsh, alat baris perintahnya, dibutuhkan Python 3.8 sampai 3.13.

Berkas unduhan resminya tersedia di halaman download Apache Cassandra, baik sebagai arsip tar maupun lewat repositori paket. Bagi pengguna Debian dan Ubuntu, penanda seri untuk lini 5.0 adalah 50x; seri lama memakai 41x, 40x, 311, 30x, atau 22x.

Satu hal yang sedang ditunggu banyak orang adalah Accord, mekanisme transaksi yang diusulkan lewat CEP-15. Targetnya ambisius: transaksi ACID lintas partisi yang bersifat strict-serializable, tanpa node pemimpin, dan selesai dalam satu perjalanan bolak-balik. Statusnya sudah diterima sebagai rencana resmi, tetapi keterangannya sendiri menyebutnya belum siap produksi.

Kebutuhan Sistem: Kenapa Cassandra Tidak Bisa di Hosting Bersama

Dokumentasi Cassandra memberi angka yang cukup gamblang. Server produksi minimal membutuhkan 2 inti prosesor dan RAM 8 GB, sementara server produksi yang lazim dipakai memiliki 8 inti atau lebih dengan RAM minimal 32 GB. Untuk belajar, dokumentasinya menyebut Cassandra bahkan bisa dijalankan di Raspberry Pi.

Tiga ketentuan lain sebaiknya tidak diabaikan:

1. Heap JVM antara 2 GB dan setengah RAM sistem: di bawah 2 GB terlalu sempit, di atas 50% membuat sistem operasi kehabisan ruang untuk page cache.
2. Commit log di disk fisik terpisah: bila memakai hard disk berputar, commit log dan direktori data wajib berada di disk yang berbeda secara fisik, bukan sekadar partisi berbeda.
3. RAID0 atau JBOD, bukan RAID1 atau RAID5: replikasi sudah ditangani Cassandra sendiri, sehingga penggandaan di lapisan disk hanya membuang kapasitas. NFS dan SAN untuk direktori data disebut dokumentasinya sebagai antipattern.

Cassandra membuka empat port bawaan: 7000 untuk komunikasi antar-node, 7001 untuk versi terenkripsinya, 7199 untuk JMX yang dipakai nodetool, dan 9042 sebagai port klien CQL.

Angka dan daftar port itu menjelaskan kenapa Cassandra tidak mungkin dijalankan di hosting bersama. Anda membutuhkan akses root untuk membuka port non-standar dan menempatkan direktori pada disk berbeda. Untuk belajar, satu VPS Indonesia dengan RAM 8 GB sudah memadai bagi satu node. Untuk cluster produksi tiga node dengan disk terpisah, dedicated server menjadi pilihan yang lebih masuk akal secara biaya maupun performa.

Dukungan Windows dihapus sejak Cassandra 4.0, dengan alasan resmi kurangnya pemeliharaan dan pengujian. Pengguna Windows tetap bisa menjalankannya lewat WSL2, Docker, atau virtualisasi seperti Hyper-V dan VirtualBox. Panduan yang menyuruh Anda menjalankan cassandra.bat sudah tidak berlaku pada versi mana pun yang masih didukung.

Jalan lain tersedia bagi yang tidak ingin mengurus semua ini: layanan Apache Cassandra terkelola, tempat pemasangan, pemantauan, dan pemutakhiran ditangani penyedia. Sebelum memilih, ada satu pembedaan yang menentukan.

Sebagian layanan menjalankan Cassandra open source yang asli. Azure Managed Instance for Apache Cassandra menyebut dirinya layanan terkelola untuk pure open-source Apache Cassandra, mendukung versi sampai 5.0, dan tetap membiarkan Anda menimpa konfigurasi. Instaclustr dan DataStax Astra DB berdiri di jalur yang sama.

Sebagian lain hanya kompatibel dengan Cassandra. Amazon Keyspaces mendeskripsikan dirinya sebagai layanan basis data Cassandra–compatible yang bersifat serverless. Kode aplikasi dan driver Anda tetap berjalan karena bahasanya sama, tetapi yang bekerja di belakang bukan Cassandra. Akibatnya, perilaku pada kasus pinggiran bisa berbeda dan fitur baru Cassandra tidak otomatis ikut hadir.

Ketiga jalur itu menuntut hal berbeda. Memasang sendiri memberi kendali penuh dengan bayaran pekerjaan operasional. Layanan terkelola atas Cassandra asli memangkas pekerjaan itu tanpa mengubah mesinnya. Layanan kompatibel memangkas paling banyak, tetapi Anda tidak lagi menjalankan Cassandra.

Tiga jalur Cassandra: pasang sendiri berkendali penuh, terkelola bermesin Cassandra asli, kompatibel bermesin lain.

Perkakas Bawaan dan Cara Memantau Cluster

Satu hal yang sering mengejutkan pendatang baru: Cassandra tidak membawa antarmuka grafis apa pun. Setelah node menyala, yang Anda dapat hanyalah perkakas baris perintah di direktori bin — cassandra, cqlsh, nodetool, dan sederet alat SSTable seperti sstableloader serta sstableverify.

nodetool adalah pusat kendalinya. Ia berbicara ke node lewat JMX di port 7199, dan versi 5.0 menyediakan sekitar 149 subperintah. Empat di antaranya cukup untuk pekerjaan harian:

1. nodetool status: menampilkan seluruh node beserta keadaan hidup-matinya dan porsi data yang dipegang masing-masing. Ini perintah pertama saat ada yang terasa janggal.
2. nodetool repair: menyelaraskan salinan antar-replika. Perintah inilah yang wajib dijadwalkan rutin agar data zombie tidak muncul.
3. nodetool tablestats dan nodetool compactionstats: menunjukkan statistik per tabel dan compaction yang sedang berjalan, termasuk jumlah tombstone yang terbaca per query.
4. nodetool snapshot: membuat cadangan berupa salinan SSTable pada satu titik waktu.

Untuk pemantauan berkelanjutan, Cassandra memancarkan metriknya lewat JMX. Pola yang lazim adalah mengumpulkannya ke Prometheus lalu menampilkannya di Grafana, dengan perhatian utama pada latensi baca-tulis, antrean compaction, dan pemakaian heap.

Di luar perkakas bawaan, dua nama sering muncul dan keduanya berasal dari ekosistem sekitar, bukan dari proyek Cassandra sendiri. Reaper menjadwalkan serta memantau perbaikan supaya Anda tidak perlu menjalankan nodetool repair secara manual, sementara Medusa menangani pencadangan dan pemulihan ke penyimpanan objek. Proyek Cassandra sendiri merilis Cassandra Sidecar, yang versi 0.3.0-nya keluar pada 13 Maret 2026.

Kapan Cassandra Layak Dipakai

Cassandra menunjukkan kekuatannya pada empat pola beban. Pertama, volume tulis yang sangat besar dan berkelanjutan, seperti catatan aktivitas pengguna atau data sensor. Kedua, data bertanda waktu yang terus bertambah dan jarang diubah. Ketiga, layanan yang harus tetap menerima permintaan meski sebagian mesin sedang mati. Keempat, data yang perlu disalin ke beberapa lokasi geografis sekaligus.

Skalanya nyata, dan angkanya tersedia di studi kasus resmi. Apple menjalankan lebih dari 75.000 node Cassandra yang menyimpan lebih dari 10 petabyte data, dengan setidaknya satu cluster berisi lebih dari 1.000 node. Uber melayani jutaan query per detik. Intuit mencatat 42.000 transaksi per detik pada puncak musim pelaporan pajak. eBay memproses lebih dari 400 juta penulisan per hari di atas 200 TB penyimpanan.

Sama pentingnya adalah mengenali kapan Cassandra bukan jawabannya. Bila data Anda masih muat di satu mesin dan tidak menunjukkan tanda akan meledak, PostgreSQL akan jauh lebih hemat tenaga. Bila pola query belum ketahuan dan masih sering berubah, rancangan Cassandra yang menuntut tabel per pola justru menjadi beban. Bila yang Anda butuhkan hanya penyimpanan cepat untuk data sementara, Redis lebih tepat sasaran. Dan bila laporan ad-hoc dengan JOIN antartabel adalah kebutuhan utama, Cassandra akan melawan Anda di setiap langkah.

Cassandra cocok untuk volume tulis besar dan banyak lokasi; kurang cocok bila data muat satu mesin atau butuh JOIN.

Kelemahan dan Hal yang Perlu Anda Pertimbangkan

Cassandra menuntut bayaran yang nyata, dan sebagian besar bayarannya bersifat operasional.

1. Tidak ada JOIN, dan model data mengikuti query: satu data yang dibaca lewat beberapa pola disimpan berulang di beberapa tabel. Menjaga konsistensi salinan-salinan itu menjadi tanggung jawab aplikasi Anda.
2. Menghapus data justru berarti menulis data: penghapusan disimpan sebagai penanda bernama tombstone. Penanda itu baru benar-benar dibuang setelah gc_grace_seconds lewat, yang bawaannya 864.000 detik alias 10 hari. Tabel yang sering dihapus isinya menjadi lambat dibaca, dan Cassandra memperingatkan pada 1.000 tombstone per query lalu menggagalkan query pada 100.000.
3. Data yang sudah dihapus bisa muncul kembali: bila sebuah node mati lebih lama daripada masa gc_grace_seconds lalu dihidupkan lagi, data lama di dalamnya dianggap baru dan disebarkan ulang. Dokumentasinya menamai kejadian ini zombie, dan pencegahannya menuntut proses perbaikan yang dijadwalkan rutin.
4. Materialized view berstatus eksperimental: komunitas pengembangnya secara resmi tidak lagi menyarankan fitur ini untuk produksi, dan sebuah peringatan dicatat di log setiap kali sebuah view dibuat.
5. Instalasi baru sama sekali tidak meminta kata sandi: nilai bawaan authenticator adalah AllowAllAuthenticator, yang keterangannya sendiri berbunyi "tidak melakukan pemeriksaan apa pun". Pasangannya, AllowAllAuthorizer, mengizinkan tindakan apa pun oleh siapa pun. Node bersetelan bawaan dengan port 9042 terbuka ke internet dapat dibaca dan ditulis siapa saja. Mengaktifkan PasswordAuthenticator serta enkripsi antar-node adalah langkah pertama sebelum apa pun.
6. Beban pengelolaan cluster: Anda memelihara beberapa mesin, bukan satu proses, dan seluruh pekerjaan pada bagian perkakas di atas menjadi rutinitas.

Poin kedua dan ketiga paling mudah dipahami bila kedua alurnya dilihat berdampingan:

Alur hapus Cassandra: tombstone hilang setelah masa tunggu, tetapi node mati terlalu lama memunculkan data zombie.

Posisi Cassandra hari ini juga layak dilihat apa adanya. Per Agustus 2026, DB-Engines menempatkannya di peringkat pertama kategori wide column store dengan skor 99,98 — sekitar 4,8 kali skor Azure Cosmos DB di peringkat kedua. Namun dalam setahun terakhir skor itu turun 8,53, sementara ScyllaDB, alternatif yang kompatibel dengan protokolnya, naik 1,27. Cassandra tetap pilihan utama di kelasnya, tetapi kelas itu tidak lagi tumbuh secepat dulu.

Pertanyaan yang Sering Diajukan

Apa itu klaster Cassandra?

Klaster atau cluster Cassandra adalah kumpulan node yang bersama-sama membentuk satu token ring dan saling menyalin data. Semua node di dalamnya berkedudukan sama dan saling bertukar kabar lewat gossip setiap detik. Anda dapat menambah atau mengurangi node tanpa menghentikan layanan, karena tidak ada peran pusat yang perlu dipindahkan.

Cassandra untuk apa?

Cassandra dipakai untuk menyimpan data bervolume sangat besar yang lebih sering ditulis daripada diubah, dan yang harus tetap tersedia meski sebagian mesin mati. Penggunaan Apache Cassandra yang lazim mencakup catatan aktivitas pengguna, riwayat pesan, data sensor, deret waktu, serta katalog produk pada layanan berskala besar. Di luar daftar itu, kegunaannya menyempit dengan cepat.

Apakah database Cassandra gratis?

Perangkat lunaknya gratis. Apache Cassandra memakai lisensi Apache License 2.0 dan sepenuhnya open source, tanpa edisi berbayar dan tanpa batas jumlah node. Yang tidak gratis adalah biaya menjalankannya: cluster tiga node berarti tiga server aktif sepanjang waktu, ditambah waktu kerja untuk pemantauan dan perbaikan berkala. Bila biaya tenaga itu yang ingin Anda hindari, layanan Cassandra terkelola memindahkannya menjadi tagihan bulanan.

Apakah Cassandra termasuk SQL atau NoSQL?

Cassandra DB adalah database NoSQL, lebih tepatnya wide column store. Kebingungan biasanya muncul karena bahasa aksesnya, CQL, sangat menyerupai SQL — lengkap dengan SELECT, INSERT, dan definisi tabel. Kemiripan itu sengaja dibuat agar mudah dipelajari, tetapi tidak mengubah sifatnya: tidak ada JOIN, tidak ada sub-query, dan tidak ada skema relasional di belakangnya.

Kenapa namanya Cassandra?

Cassandra artinya nama seorang peramal Troya dalam mitologi Yunani. Menurut kisahnya ia dikaruniai kemampuan meramal dengan tepat, tetapi dikutuk sehingga ramalannya tidak pernah dipercaya siapa pun.

Apa bedanya Cassandra dan MongoDB?

Keduanya sama-sama NoSQL, tetapi bentuk simpanannya berbeda. MongoDB menyimpan dokumen mirip JSON dan membolehkan query yang cukup leluasa atas isi dokumen. Cassandra menyimpan baris berkolom lebar, menuntut Anda merancang tabel mengikuti pola query, dan sebagai gantinya menerima volume tulis jauh lebih besar tanpa node pusat.

Kesimpulan

Apache Cassandra adalah database NoSQL terdistribusi yang membuang konsep node pusat. Seluruh rancangannya diturunkan dari keputusan itu: jalur tulis yang hanya menambah di ujung, ring token yang membagi data sendiri, gossip yang menggantikan koordinator, dan consistency level per query. Yang Anda dapat adalah kemampuan tumbuh dengan menambah mesin biasa, serta layanan yang tetap hidup saat sebagian mesin mati. Yang Anda serahkan adalah JOIN, keleluasaan mengubah pola query, dan waktu untuk mengurus cluster.

Pakailah Cassandra ketika volume tulis Anda melewati kemampuan satu mesin, ketika pola aksesnya sudah jelas, atau ketika layanan tidak boleh berhenti meski satu datacenter padam. Tunda dahulu selama data Anda masih muat di satu server dengan RAM 32 GB.

Bila Anda memulai hari ini, langsung saja ke lini 5.0 dengan JDK 17, aktifkan PasswordAuthenticator sebelum apa pun, dan abaikan panduan yang masih mengajarkan pemasangan di Windows. Kalau pekerjaan operasionalnya terasa terlalu berat, layanan Cassandra database terkelola tetap menjadi jalan yang sah. Semoga artikel ini membantu.