Kenalan dengan Column-Family Database: Kenapa Cassandra Menolak Query Kita?
Kalau selama ini kenalnya database cuma MySQL atau PostgreSQL, wajar kalau pertama kali ketemu Cassandra rasanya aneh. Tabelnya ada, perintahnya mirip SQL, tapi tiba-tiba query sederhana seperti “cari pesanan berdasarkan nama produk” malah ditolak. Di tugas mata kuliah Basis Data kali ini, kelompok kami membahas column-family database lewat video di atas. Artikel ini rangkuman singkatnya.
Kenapa NoSQL muncul?
RDBMS itu bagus, tapi punya batas ketika datanya sudah masuk kategori big data. Biasanya masalahnya dirangkum dengan 3V:
- Volume: data berukuran terabyte sampai petabyte.
- Velocity: data masuk cepat dan terus-menerus, seperti klik, sensor, dan log.
- Variety: data terstruktur, semi-terstruktur, sampai tidak terstruktur.
Menambah kemampuan satu server (scale-up) mahal dan ada batas fisiknya. JOIN dan transaksi ACID juga jadi berat kalau data tersebar di banyak server. Dari sinilah muncul NoSQL, singkatan dari Not Only SQL. Bukan pengganti RDBMS, tapi pelengkap.
NoSQL punya empat tipe: key-value (Redis), document (MongoDB), graph (Neo4j), dan column family (Cassandra, HBase). Yang terakhir inilah fokus kami.
Apa itu column family?
Column family database menyimpan data per baris berdasarkan row key, dan kolom-kolomnya dikelompokkan dalam column family. Bedanya dengan tabel relasional: setiap baris boleh punya kolom yang berbeda. Istilahnya sparse. Kalau di relasional atribut kosong diisi NULL, di column family baris itu cukup tidak menyimpan kolomnya sama sekali.
Sejarahnya menarik. Tahun 2006 Google menerbitkan paper Bigtable, lalu Amazon merancang Dynamo, sistem terdistribusi tanpa master. Facebook kemudian membuat Apache Cassandra yang menggabungkan model data Bigtable dengan arsitektur Dynamo.
Beberapa padanan istilah supaya tidak bingung:
- Database jadi keyspace
- Table jadi table / column family
- Primary key jadi partition key + clustering key
Mulai dari query, bukan dari entitas
Ini perbedaan pola pikir yang paling penting. Di relasional, kita biasanya mulai dari entitas lalu normalisasi. Di column family, kita mulai dari pertanyaan apa yang akan sering ditanyakan ke database. Satu tabel dirancang untuk satu pola akses, dan data yang sama boleh disimpan di beberapa tabel (denormalisasi) supaya tidak perlu JOIN.
Di studi kasus kami, toko online fiktif bernama SuroMart, ada dua kebutuhan: melihat pesanan dari sisi pembeli dan dari sisi toko. Jadi kami buat dua tabel. Ini tabel untuk sisi toko:
CREATE TABLE pesanan_by_toko (
id_toko text,
bulan text,
tgl_pesan timestamp,
id_pesanan text,
id_pembeli text,
nama_produk text,
jumlah int,
total_harga decimal,
status text,
PRIMARY KEY ((id_toko, bulan), tgl_pesan, id_pesanan)
) WITH CLUSTERING ORDER BY (tgl_pesan DESC);Partition key-nya (id_toko, bulan), artinya semua pesanan satu toko dalam satu bulan disimpan di partisi yang sama. Clustering key tgl_pesan DESC membuat pesanan terbaru selalu muncul paling atas.
Get Timotius Patrick’s stories in your inbox
Join Medium for free to get updates from this writer.
Karena satu pesanan disimpan di dua tabel, kami pakai BATCH supaya keduanya tetap sinkron:
BEGIN BATCH
INSERT INTO pesanan_by_pembeli (...) VALUES (...);
INSERT INTO pesanan_by_toko (...) VALUES (...);
APPLY BATCH;Bagaimana data dibagi ke banyak server?
Cassandra memakai arsitektur peer-to-peer berbentuk cincin. Tidak ada master, semua node setara dan saling bertukar status lewat gossip protocol. Kalau satu node mati, node lain tetap melayani. Ini beda dengan HBase yang memakai pola master-slave.
Partition key dimasukkan ke fungsi hash (Murmur3) dan menghasilkan token. Node yang memegang rentang token itu menjadi pemilik datanya. Berkat consistent hashing, menambah atau menghapus node hanya memindahkan sebagian kecil data.
Untuk keamanan, data direplikasi. Dengan replication factor 3, setiap data ada di tiga node. Cassandra juga membolehkan kita memilih consistency level: ONE paling cepat, ALL paling kuat, dan QUORUM di tengah. Rumus yang perlu diingat: konsistensi kuat tercapai kalau R + W > RF. Contohnya QUORUM baca + QUORUM tulis, 2 + 2 > 3, terpenuhi.
Kenapa write di Cassandra cepat sekali? Data cukup dicatat ke commit log, masuk ke memtable di memori, lalu klien langsung dapat respons. Belakangan memtable di-flush ke SSTable dan digabung lewat compaction. Tidak ada baca sebelum tulis, tidak ada locking.
Lalu kenapa query kita ditolak?
Sekarang bagian yang paling bikin penasaran. Kami coba query ini:
SELECT * FROM pesanan_by_toko WHERE nama_produk = 'Syal Rajut';Cassandra menolaknya. Alasannya, nama_produk bukan bagian dari key, jadi Cassandra tidak tahu partisi mana yang harus dibaca dan terpaksa memeriksa semua data di semua node. Query ini bisa dipaksa dengan ALLOW FILTERING, tapi itu jalan pintas yang akan sangat berat saat datanya besar.
Solusi yang benar justru kembali ke prinsip awal: buat tabel baru sesuai query-nya.
SELECT * FROM pesanan_by_produk
WHERE nama_produk = 'Syal Rajut' AND bulan = '2026-10';Tabel pesanan_by_produk memakai (nama_produk, bulan) sebagai partition key, sehingga query berjalan cepat tanpa ALLOW FILTERING.
Kapan sebaiknya dipakai?
Column family cocok kalau beban tulis tinggi (log, IoT, time-series, riwayat transaksi), butuh high availability, pola query sudah jelas dari awal, dan data tersebar di banyak data center. Netflix dan Instagram adalah contoh pemakainya.
Sebaliknya, hindari kalau butuh transaksi ACID yang kompleks, banyak JOIN, datanya kecil dan relasional, atau sering butuh agregasi bebas di seluruh data.
Penutup
Pelajaran terbesar dari tugas ini buat saya: di column-family database, desain tabel itu mengikuti query, bukan sebaliknya. Query yang sesuai desain berjalan efisien, sedangkan query di luar desain butuh tabel baru, bukan ALLOW FILTERING.
Penjelasan lengkap tiap bagian, termasuk demo setup Cassandra lewat Docker di Google Cloud Shell, ada di video di bawah artikel. Semoga membantu!
https://www.youtube.com/watch?v=eV10HWdDpUs
Timotius Christopher Patrick Sihombing, Basis Data, Fakultas Teknologi Maju dan Multidisiplin, Universitas Airlangga
