Apa Itu Apache Cassandra? Database NoSQL Terdistribusi

Asal-usul Apache Cassandra

Cassandra diciptakan di Facebook sekitar tahun 2008 oleh Avinash Lakshman—yang sebelumnya pernah mengerjakan sistem Dynamo milik Amazon—bersama dengan Prashant Malik. Facebook membutuhkan sistem penyimpanan untuk mendukung fitur pencarian kotak masuk (inbox search), sebuah fitur yang menuntut penanganan volume penulisan data yang sangat tinggi, sekaligus harus tetap tersedia di berbagai pusat data. Rancangan yang dihasilkan secara sengaja menggabungkan gagasan dari dua sistem yang berpengaruh, yaitu arsitektur terdistribusi peer-to-peer dari Dynamo milik Amazon dan model data berorientasi kolom (column-oriented) dari Bigtable milik Google.

Facebook merilis Cassandra sebagai software open source pada tahun 2008. Sistem ini kemudian masuk ke dalam inkubator Apache Software Foundation pada tahun 2009, sebelum akhirnya menjadi proyek tingkat atas di Apache pada tahun 2010. Sejak saat itu, Cassandra terus dikembangkan oleh komunitas kontributor global dari berbagai perusahaan dan didistribusikan di bawah lisensi Apache License 2.0. Ekosistem komersial pun tumbuh di sekitarnya, termasuk DataStax dan beberapa layanan cloud terkelola, meskipun database intinya tetap sepenuhnya bersifat open source. Organisasi seperti Netflix, Apple, dan Uber dikenal luas sebagai pengguna dalam skala besar, yang turut memperkuat reputasi Cassandra dalam menangani beban kerja produksi yang berat.

Arsitektur Tanpa Master yang Dirancang untuk Ketersediaan

Karakteristik utama Cassandra adalah desainnya yang bersifat peer-to-peer dan tanpa master (pusat kendali). Pada banyak database, satu node ditetapkan sebagai primary (utama), sehingga jika terjadi kegagalan, diperlukan proses promosi node lain yang dapat menyebabkan penundaan atau waktu henti (downtime). Di Cassandra, setiap node dalam klaster memiliki peran yang setara dan dapat menangani operasi baca maupun tulis. Antar-node berkomunikasi menggunakan protokol gossip, yaitu sebuah mekanisme ringan yang memungkinkan pertukaran informasi secara berkelanjutan mengenai status node (apakah aktif atau tidak) serta kondisi klaster secara keseluruhan.

Cassandra mendistribusikan data ke seluruh klaster menggunakan teknik yang didasarkan pada consistent hashing. Secara konseptual, klaster disusun menyerupai sebuah cincin, di mana setiap node bertanggung jawab atas rentang nilai hash tertentu. Saat data ditulis, Cassandra melakukan hashing pada bagian dari rekaman yang disebut partition key untuk menentukan node mana yang menyimpan data tersebut. Karena fungsi hash menyebarkan data secara merata, penambahan node baru ke dalam cincin akan membuat node tersebut secara otomatis mengambil alih sebagian data yang ada, tanpa perlu melakukan reorganisasi menyeluruh. Inilah alasan mengapa Cassandra dikatakan memiliki skalabilitas linear, yaitu menggandakan jumlah node akan meningkatkan kapasitas penyimpanan dan throughput (kapasitas pemrosesan) hingga kurang lebih dua kali lipat.

Data juga direplikasi untuk menjamin ketahanan. Pengaturan yang disebut replication factor menentukan berapa banyak salinan dari setiap data yang disimpan di node yang berbeda. Cassandra memahami tata letak fisik infrastruktur—termasuk rak dan pusat data (data center)—sehingga dapat menempatkan replika di lokasi yang berbeda. Dengan demikian, kegagalan pada satu server, satu rak, atau bahkan satu pusat data sekalipun tidak akan menyebabkan hilangnya data maupun gangguan layanan. Dukungan bawaan untuk berbagai pusat data (multi-data-center) ini merupakan salah satu fitur yang paling sering diunggulkan oleh organisasi yang melayani pengguna di seluruh dunia.

Memahami Model Data Cassandra

Cassandra menyimpan data dalam tabel yang diatur di dalam wadah yang disebut keyspace. Sistem ini menggunakan bahasa kueri bernama CQL (Cassandra Query Language), yang sangat mirip dengan SQL sehingga terasa familier. Namun, kemiripan ini bisa menyesatkan karena model dasarnya sangat berbeda dari database relasional; menganggapnya sama dengan database relasional sering kali menjadi sumber masalah bagi pengguna baru.

Konsep utamanya adalah primary key, yang terdiri dari dua bagian. Partition key menentukan simpul (node) mana yang menyimpan suatu baris, yang dengan demikian menentukan bagaimana data didistribusikan di seluruh klaster. Sementara itu, clustering column—yang bersifat opsional—menentukan bagaimana baris-baris dalam satu partisi diurutkan di dalam disk. Baris-baris yang memiliki partition key yang sama akan disimpan bersama-sama. Hal ini memungkinkan pembacaan seluruh partisi secara sekaligus dengan sangat cepat—seperti mengambil semua data dari sensor tertentu pada hari tertentu, atau semua pesan dalam percakapan tertentu.

Desain ini melahirkan filosofi pemodelan data yang hampir berkebalikan dengan praktik dalam database relasional. Pada database relasional, kita biasanya memodelkan entitas terlebih dahulu, kemudian menyusun kueri yang diperlukan dengan mengandalkan operasi join untuk menggabungkan tabel. Cassandra tidak mendukung join dalam pengertian tradisional, dan kueri yang efisien harus didasarkan pada partition key. Akibatnya, developer Cassandra yang berpengalaman akan memulai dengan pertanyaan-pertanyaan yang harus dijawab oleh aplikasi, lalu merancang tabel khusus untuk setiap pola kueri—sering kali dengan menduplikasi data ke dalam beberapa tabel. Proses denormalisasi ini menukar ruang penyimpanan (yang relatif murah) demi kecepatan dan prediktabilitas pembacaan data (yang sangat berharga). Pendekatan ini menuntut perencanaan yang matang sejak awal, karena mengubah model data di kemudian hari bisa memakan biaya yang besar.

Konsistensi yang Dapat Disesuaikan

Pendekatan Cassandra terhadap konsistensi merupakan salah satu fitur yang paling khas sekaligus paling sering disalahpahami. Berdasarkan teorema CAP, sistem terdistribusi yang harus mampu menangani pemisahan jaringan harus memilih antara konsistensi ketat (strict consistency) dan ketersediaan (availability) saat terjadi kegagalan. Cassandra pada umumnya lebih mengutamakan ketersediaan, namun sistem ini tidak memaksakan satu pilihan kompromi yang tetap. Sebaliknya, Cassandra memungkinkan developer untuk menentukan tingkat konsistensi bagi setiap operasi baca atau tulis secara individual.

Tingkat konsistensi menentukan berapa banyak replika yang harus memberikan respons agar suatu operasi dianggap berhasil. Memilih tingkat yang rendah—misalnya hanya memerlukan satu replika—akan menghasilkan respons tercepat dan ketersediaan tertinggi, namun dengan risiko lebih besar untuk membaca data yang mungkin sudah tidak mutakhir (stale data). Memilih tingkat yang lebih tinggi, seperti quorum (yang berarti mayoritas replika), memberikan jaminan yang lebih kuat dengan konsekuensi latensi yang sedikit lebih tinggi. Jika operasi baca maupun tulis menggunakan quorum, sistem dapat menjamin bahwa operasi baca akan mendapatkan data dari operasi tulis sukses yang paling baru. Terdapat pula tingkat konsistensi yang mempertimbangkan lokasi pusat data, yang membatasi respons yang diperlukan hanya dari replika di pusat data lokal, sehingga menghindari komunikasi antarwilayah yang lambat.

Fleksibilitas ini memungkinkan sebuah aplikasi untuk memperlakukan data yang berbeda dengan cara yang berbeda pula; misalnya, menggunakan konsistensi yang lebih longgar untuk penghitung jumlah tampilan halaman, dan menggunakan pengaturan yang lebih ketat untuk data seperti saldo akun. Cassandra juga menyediakan transaksi ringan (lightweight transactions) yang memanfaatkan protokol konsensus Paxos untuk menerapkan mekanisme compare-and-set. Mekanisme ini digunakan dalam situasi di mana suatu operasi hanya boleh berhasil jika kondisi tertentu terpenuhi—contohnya, memastikan bahwa nama pengguna belum digunakan oleh pihak lain. Operasi jenis ini lebih lambat dibandingkan operasi biasa dan sebaiknya digunakan secara terbatas.

Cara Cassandra Menangani Operasi Tulis dan Baca

Cara Cassandra menyimpan data pada setiap node menjelaskan alasan di balik performa penulisan yang luar biasa. Saat operasi tulis masuk, node terlebih dahulu menambahkan data tersebut ke dalam commit log di disk; langkah ini menjamin ketahanan data (durability) meskipun server mengalami kegagalan. Selanjutnya, data ditulis ke dalam struktur di dalam memori yang disebut memtable. Kedua langkah ini berlangsung cepat karena hanya melibatkan penambahan sekuensial dan operasi memori, bukan akses disk secara acak. Ketika memtable sudah cukup besar, isinya akan dipindahkan ke disk dalam bentuk file yang tidak dapat diubah (immutable), yang disebut sebagai SSTable.

Karena SSTable tidak pernah dimodifikasi secara langsung, operasi pembaruan (update) maupun penghapusan (delete) tidak menimpa data yang sudah ada. Penghapusan dicatat sebagai penanda yang disebut tombstone, dan saat data dibaca, versi terbaru dari suatu nilai akan digunakan. Seiring berjalannya waktu, proses latar belakang yang disebut compaction akan menggabungkan berbagai SSTable, membuang nilai-nilai usang serta tombstone yang sudah kedaluwarsa, guna menjaga efisiensi penyimpanan dan performa pembacaan. Operasi baca akan memeriksa memori serta satu atau lebih SSTable, dengan memanfaatkan struktur seperti bloom filter untuk mengeliminasi file yang dipastikan tidak memuat data yang dicari.

Cassandra juga dilengkapi dengan beberapa mekanisme untuk menjaga konsistensi antar-replika meskipun terjadi kegagalan. Hinted handoff berfungsi menyimpan sementara operasi tulis yang ditujukan bagi node yang sedang tidak aktif, lalu mengirimkannya kembali saat node tersebut pulih. Read repair dapat memperbaiki ketidakkonsistenan yang ditemukan selama proses pembacaan, sementara proses yang disebut anti-entropy repair—baik yang dijalankan secara manual maupun terjadwal—melakukan perbandingan dan penyelarasan data antar-replika secara lebih menyeluruh. Menjalankan proses perbaikan (repair) secara rutin merupakan tanggung jawab operasional yang penting; mengabaikannya adalah salah satu penyebab umum munculnya masalah pada sistem Cassandra seiring berjalannya waktu.

Apa yang Baru di Cassandra 5.0 dan 6.0

Cassandra telah mengalami perkembangan pesat dalam beberapa tahun terakhir. Rilis 4.0 pada tahun 2021 menjadi tonggak penting yang berfokus pada stabilitas dan kualitas, setelah melalui upaya pengujian yang ekstensif. Cassandra 5.0, yang dirilis pada September 2024, menghadirkan sejumlah kemampuan signifikan. Storage-Attached Indexes menyediakan cara yang jauh lebih mumpuni dan dapat diskalakan untuk melakukan kueri data berdasarkan kolom selain partition key, yang sekaligus mengatasi salah satu keterbatasan lama pada indeks sekunder sebelumnya. Tipe data vektor baru beserta kemampuan pencarian vektor—yang dibangun di atas indeks tersebut—memungkinkan pencarian kemiripan (similarity search), yang sangat berguna untuk aplikasi kecerdasan buatan seperti pencarian semantik dan sistem rekomendasi. Unified Compaction Strategy menawarkan pendekatan adaptif yang dapat menggantikan beberapa opsi pemadatan (compaction) lama. Selain itu, dukungan untuk versi Java modern melengkapi rilis ini, yang dirancang untuk meningkatkan performa sekaligus memberikan kemudahan bagi developer. Seri 5.0 terus menerima pembaruan pemeliharaan sejak diluncurkan.

Menatap ke depan, Cassandra 6.0 telah berada dalam tahap alfa sepanjang tahun 2026 dan menghadirkan perubahan yang lebih mendasar. Fitur utamanya adalah Accord, sebuah protokol konsensus baru yang dirancang untuk mendukung transaksi ACID lintas partisi dengan isolasi strict serializable—sebuah solusi untuk mengatasi keterbatasan lain yang telah lama ada pada database ini. Perubahan lainnya mencakup Transactional Cluster Metadata, yang membuat koordinasi keanggotaan klaster dan skema menjadi lebih andal, serta fitur perbaikan otomatis yang berjalan langsung di dalam Cassandra, sehingga tidak lagi bergantung pada perangkat eksternal. Karena Cassandra 6.0 masih dalam tahap alfa pada saat penulisan ini, fitur dan perilakunya mungkin akan berubah sebelum mencapai rilis stabil; oleh karena itu, penerapan di lingkungan produksi saat ini umumnya masih mengandalkan seri 5.0. Bagi siapa pun yang berencana melakukan peningkatan (upgrade), disarankan untuk memeriksa dokumentasi resmi Apache Cassandra guna mengetahui status rilis terkini.

Contoh Penggunaan Umum

Cassandra sangat cocok untuk aplikasi yang terus-menerus menulis data dalam volume besar dan harus selalu tersedia setiap saat. Data time-series merupakan salah satu contoh yang paling jelas—termasuk pembacaan sensor dari perangkat Internet of Things (IoT), metrik aplikasi, dan log peristiwa—karena pemartisian berdasarkan perangkat dan waktu selaras dengan model data Cassandra. Sistem pesan (messaging) dan feed aktivitas, di mana pengguna membaca konten terbaru secara berurutan, juga sangat sesuai untuk ditangani oleh Cassandra.

Contoh penggunaan umum lainnya mencakup katalog produk dan profil pelanggan yang harus dapat diakses dengan cepat oleh pengguna di seluruh dunia; sistem personalisasi dan rekomendasi yang menyimpan kumpulan data perilaku berskala besar; alur kerja deteksi penipuan yang memerlukan pencarian cepat terhadap riwayat data yang sangat luas; serta layanan apa pun yang harus tetap aktif di berbagai wilayah, bahkan saat terjadi kegagalan infrastruktur. Dalam skenario-skenario tersebut, kombinasi antara skalabilitas linear, replikasi lintas pusat data (multi-data-center), dan performa dengan latensi rendah yang konsisten sulit untuk ditandingi oleh basis data tradisional.

Perbandingan Cassandra dengan Database Lainnya

Dibandingkan dengan database relasional seperti PostgreSQL atau MySQL, Cassandra mengorbankan fitur join, kueri ad hoc yang fleksibel, serta transaksi tradisional yang melibatkan banyak tabel, demi mendapatkan skalabilitas horizontal dan ketersediaan tinggi (high availability). Database relasional tetap menjadi pilihan yang lebih baik jika data sangat saling terhubung, pola kueri tidak dapat diprediksi, atau jika jaminan transaksi yang kuat di berbagai tabel menjadi aspek krusial bagi aplikasi tersebut.

Di antara sistem NoSQL lainnya, perbandingannya lebih bernuansa. MongoDB menawarkan model dokumen yang fleksibel dan bahasa kueri yang lebih kaya, yang cocok untuk aplikasi dengan struktur data yang sering berubah. Amazon DynamoDB, yang memiliki akar yang sama dengan Cassandra—yakni berasal dari sistem Dynamo—merupakan layanan terkelola penuh (fully managed service) yang membebaskan pengguna dari beban operasional, namun membuat pengguna terikat pada satu penyedia layanan awan (cloud provider) tertentu. ScyllaDB adalah database yang kompatibel dengan Cassandra, ditulis menggunakan bahasa C++, dan dirancang untuk mencapai performa yang lebih tinggi per node. Apache HBase, seperti halnya Cassandra, mengadopsi konsep dari Bigtable, namun bergantung pada arsitektur berbasis master. Pilihan yang tepat bergantung pada beban kerja, keahlian tim, serta preferensi operasional.

Keterbatasan dan Tantangan

Pandangan yang objektif mengenai Cassandra harus mencakup berbagai kompromi yang ada di dalamnya. Proses pembelajaran untuk menguasai sistem ini cukup nyata, terutama bagi developer yang terbiasa dengan pola pikir relasional, karena pendekatan pemodelan data yang berorientasi pada kueri merupakan hal yang asing, dan kesalahan dalam penerapannya bisa memakan biaya besar untuk diperbaiki. Pemilihan partition key yang kurang tepat dapat menciptakan hot spot—kondisi di mana satu node menerima beban yang tidak proporsional—atau menghasilkan partisi yang terlalu besar, yang pada akhirnya akan menurunkan kinerja sistem.

Aspek operasional juga memerlukan perhatian khusus. Proses perbaikan data harus dijalankan secara berkala, mekanisme pemadatan data (compaction) perlu dipahami dan dipantau, serta penggunaan operasi penghapusan secara intensif dapat menciptakan sejumlah besar tombstone yang memperlambat proses pembacaan data. Cassandra kurang cocok untuk kebutuhan analisis ad hoc atau beban kerja yang sangat bergantung pada operasi penggabungan (join) yang kompleks dan transaksi lintas partisi, meskipun fitur seperti Storage-Attached Indexes dan protokol Accord yang akan datang mulai memperkecil kesenjangan tersebut. Untuk aplikasi berskala kecil dengan volume data yang terbatas, penggunaan Cassandra sering kali dianggap sebagai infrastruktur yang berlebihan.

Menjalankan Cassandra: Opsi yang Dikelola Sendiri maupun Dikelola Pihak Lain

Tim dapat menjalankan Cassandra di server mereka sendiri atau di cloud. Pendekatan ini memberikan kendali penuh, namun menuntut keahlian dalam perencanaan kapasitas, pemantauan, peningkatan sistem (upgrade), dan keamanan. Banyak organisasi lebih memilih layanan terkelola (managed services) yang menangani tugas-tugas tersebut. Beberapa opsinya meliputi DataStax Astra DB, Amazon Keyspaces (yang menawarkan antarmuka yang kompatibel dengan Cassandra), layanan Cassandra terkelola dari Azure, serta solusi dari penyedia khusus seperti Instaclustr. Layanan terkelola memang mengurangi beban operasional, tetapi juga dapat menimbulkan biaya tambahan, perbedaan fitur, dan tingkat ketergantungan tertentu terhadap vendor; oleh karena itu, penting untuk membandingkan opsi-opsi tersebut dengan kebutuhan proyek yang spesifik.

Memulai Penggunaan Apache Cassandra

Cara praktis untuk memulai adalah dengan menjalankan satu node secara lokal menggunakan distribusi resmi atau container image, menghubungkannya melalui shell baris perintah "cqlsh", lalu membuat keyspace dan tabel sederhana. Dengan mencoba menjalankan beberapa kueri dan mengamati kueri mana yang diizinkan serta mana yang ditolak, kita akan segera memahami pentingnya partition key. Selanjutnya, cobalah menerapkan pendekatan query-first dengan memilih skenario nyata—seperti melacak pembacaan sensor atau pesan pengguna—lalu tentukan kueri apa saja yang dibutuhkan aplikasi tersebut dan rancang tabel untuk masing-masing kueri.

Seiring dengan bertambahnya pemahaman, menjalankan klaster kecil dengan beberapa node di dalam kontainer akan memperlihatkan bagaimana replikasi, tingkat konsistensi, dan kegagalan node bekerja dalam praktik yang sesungguhnya. Mengingat database ini telah mengalami perubahan signifikan di berbagai versi, sebaiknya gunakan materi pembelajaran yang disusun untuk Cassandra 4.x atau 5.x, bukan tutorial versi lama. Selain itu, pastikan untuk membaca dokumentasi resmi sebagai panduan mengenai perbaikan (repair), pemadatan data (compaction), dan konfigurasi untuk lingkungan produksi.


Jadi, Apache Cassandra adalah database NoSQL terdistribusi tanpa model master ( masterless) yang menggabungkan skalabilitas linear, replikasi lintas pusat data, serta konsistensi yang dapat disesuaikan untuk menghadirkan ketersediaan tinggi dalam skala yang sangat masif. Dengan desain yang mengadopsi konsep dari Dynamo milik Amazon dan Bigtable milik Google, sistem ini sangat cocok bagi aplikasi yang memiliki beban penulisan tinggi, menuntut ketersediaan berkelanjutan meskipun terjadi kegagalan, dan dapat dimodelkan berdasarkan pola kueri yang telah diketahui.