Sejarah Singkat: Dari Buku Kas ke Big Data
Pada era 1970-an dan 80-an, database dirancang untuk meniru buku kas fisik. Jika seorang nasabah datang ke bank, kasir perlu mencari satu baris data spesifik (nama, alamat, saldo) dan memperbaruinya. Inilah cikal bakal Relational Database (RDBMS) dengan format Row-based.
Sistem seperti Oracle atau MySQL merajai dunia karena sangat efisien untuk OLTP (Online Transactional Processing)—yaitu menangani ribuan transaksi kecil secara cepat. Namun, memasuki era 2000-an, kebutuhan berubah. Kita mulai bertanya “berapa total tren penjualan di 50 juta transaksi?”. Di sinilah format Row-based mulai kewalahan, dan lahirlah teknologi Columnar (seperti Snowflake, BigQuery, atau ClickHouse).
Row-based Storage: Paket Lengkap yang Berat
Bayangkan database Row-based seperti sebuah toko kelontong yang hanya menjual paket sembako raksasa. Jika Anda hanya butuh sebutir telur, Anda dipaksa membeli satu kotak besar yang berisi beras, minyak, susu, dan daging sekaligus.
- Cara Kerja: Data ditulis ke disk secara horizontal. Dalam tabel dengan 100 kolom, semua nilai untuk “User A” disimpan berdampingan secara fisik dalam satu blok data.
- Kelebihan: Sangat cepat untuk menulis data (Write). Menambah pelanggan baru hanya butuh satu “ketukan” di akhir file.
- Musuh Dashboard: Saat dashboard ingin menghitung “Total Keuntungan”, komputer harus memindai seluruh kolom (Nama, Alamat, No. Telp, dll) hanya untuk menemukan angka “Keuntungan”. Ini menciptakan beban I/O masif karena membaca 90% data yang tidak dibutuhkan.
Columnar Storage: Rak Spesialis yang Cerdas
Penyimpanan kolom membalikkan logika tersebut. Alih-alih membungkus data per orang, ia mengelompokkan data berdasarkan kategori. Semua data “Harga” ada di satu tempat, semua “Tanggal” di tempat lain.
Mengapa Ini Membuat Dashboard Lebih Cepat?
Secara teknis, ada beberapa hal yang terjadi di balik layar mesin Columnar:
- Pembacaan Selektif (Projection): Jika grafik Anda hanya butuh “Tanggal” dan “Pendapatan”, database hanya melakukan seek pada blok fisik kolom tersebut dan mengabaikan ratusan kolom lainnya.
- Kompresi Tingkat Tinggi: Karena satu kolom berisi tipe data yang sama, database menggunakan algoritma cerdas:
- Run-Length Encoding (RLE): Menulis “Indonesia x 1000” daripada menulis kata yang sama seribu kali.
- Dictionary Encoding: Mengganti kata panjang dengan kode angka pendek (misal: “Smartphone” jadi 1).
- Data Skipping (Predicate Pushdown): Mesin ini menyimpan metadata (nilai Min/Max) di setiap blok. Jika Anda mencari “Tahun 2024”, mesin akan langsung melompati (skip) atau disebut data pruning jutaan baris yang metadatanya menunjukkan rentang tahun 2020-2022 tanpa membacanya sama sekali.
- Vectorized Execution (SIMD): Berbeda dengan sistem Row-based yang memproses data satu per satu, mesin kolom menggunakan teknologi SIMD (Single Instruction, Multiple Data). CPU bisa mengambil 1.000 data sekaligus dan menghitungnya dalam satu detak jam.
| Fitur | Row-based (OLTP) | Column-oriented (OLAP) |
| Analogi | Paket Sembako | Rak Spesialis |
| Kecepatan Baca | Lambat untuk agregasi besar | Super cepat untuk analitik |
| Kecepatan Tulis | Sangat cepat (Update/Insert) | Lebih lambat (Batch load) |
| Efisiensi Disk | Boros (Data tidak terkompresi) | Sangat hemat (Kompresi tinggi) |
| Cocok Untuk | Aplikasi Web, Transaksi ATM | Dashboard, BI, Data Science |
Kesimpulan: Solusi Dashboard Lemot
Jika dashboard Anda lambat, kemungkinan besar Anda sedang mencoba melakukan perhitungan analitik berat di atas mesin transaksional Row-based.
Beralih ke database Columnar bukan sekadar “perbaikan kecil”, melainkan perpindahan dari truk pengangkut barang yang berat ke kereta peluru yang super cepat. Dengan memanfaatkan efisiensi I/O dan kekuatan pemrosesan paralel, data sebesar apapun bukan lagi beban, melainkan aset yang bisa dipanggil seketika.
