TL;DR
OLTP adalah cara kerja database yang dirancang buat nyimpan dan mengubah transaksi satu per satu secepat mungkin, misalnya database aplikasi kasir. OLAP adalah cara kerja database yang dirancang buat membaca jutaan baris sekaligus lalu menghitung ringkasannya, misalnya data warehouse buat laporan. Query analitik lambat di database aplikasi karena OLTP nyimpan data per baris dan indeksnya disetel buat ngambil sedikit baris, bukan buat memindai seluruh tabel.
OLTP dan OLAP adalah dua cara kerja database yang beda tujuan. OLTP nyimpan transaksi satu per satu dengan cepat, OLAP baca jutaan baris sekaligus buat dihitung ringkasannya.
Query laporan yang jalan 40 detik di database aplikasi biasanya bukan salah SQL kamu. Database itu memang disetel buat ngelayani ribuan transaksi kecil, bukan buat menjumlah setahun data dalam sekali jalan.
Di bawah ini aku jelasin bedanya, kenapa lambatnya bisa separah itu, dan tiga cara mindahin beban analitik tanpa harus langsung beli data warehouse.
OLTP (Online Transaction Processing) adalah cara kerja database yang fokus ke operasi kecil dan sering: insert, update, delete satu baris. OLAP (Online Analytical Processing) adalah cara kerja database yang fokus ke pembacaan besar: hitung total, rata-rata, dan tren dari jutaan baris sekaligus. Aplikasi kasir pakai OLTP. Dashboard penjualan bulanan pakai OLAP.
Beda tujuan ini bikin rancangan penyimpanannya juga beda. OLTP nyimpan data per baris, jadi ambil satu pesanan cukup baca satu blok. OLAP banyak yang nyimpan per kolom, jadi kalau kamu cuma butuh kolom total dan tanggal, kolom lain ga ikut dibaca.
Istilah lama yang sering nemplok di OLAP adalah cube. Sekarang kebanyakan orang cukup nyebutnya data warehouse atau lakehouse.
Bedanya ada di beban kerja, bentuk data, dan cara ngukur suksesnya. OLTP dinilai dari berapa transaksi per detik yang bisa dilayani dan seberapa cepat satu baris ketemu. OLAP dinilai dari berapa lama query agregat selesai dan berapa banyak baris yang bisa dipindai. Satu ngejar waktu tanggap milidetik, satunya ngejar daya olah.
| Aspek | OLTP | OLAP |
|---|---|---|
| Tujuan | Menjalankan operasi harian | Menganalisis data historis |
| Operasi dominan | INSERT, UPDATE, DELETE | SELECT dengan agregasi |
| Jumlah baris per query | 1 sampai puluhan | Ribuan sampai miliaran |
| Bentuk penyimpanan | Per baris | Sering per kolom |
| Model data | Ternormalisasi, banyak tabel | Dimensional, tabel lebar |
| Data historis | Sering dihapus atau diarsip | Disimpan bertahun-tahun |
| Pengguna | Aplikasi dan pelanggan | Analis dan manajemen |
| Contoh sistem | PostgreSQL, MySQL, SQL Server | BigQuery, Snowflake, ClickHouse |
Perlu dicatat satu hal: PostgreSQL dan MySQL bisa dipakai buat analitik juga. Yang beda itu cara kamu nyusun tabelnya, bukan cuma merek databasenya.
Ada empat sebab yang paling sering muncul, dan biasanya kejadian barengan.
Indeks itu enak buat nyari 10 baris dari 5 juta. Begitu query kamu butuh 3 juta baris, database malah milih baca seluruh tabel, karena lompat-lompat lewat indeks justru lebih mahal. Penjelasan cara PostgreSQL milih rencana eksekusi ada di dokumentasi EXPLAIN PostgreSQL.
Tabel transaksi punya 30 kolom. Query kamu cuma butuh 3. Di penyimpanan per baris, database tetap ngangkat semua kolom itu dari disk. Ada 27 kolom yang kebaca sia-sia.
Database aplikasi sengaja dipecah jadi banyak tabel biar ga ada data ganda. Bagus buat konsistensi. Tapi laporan penjualan per kota bisa butuh 5 JOIN, dan tiap JOIN nambah kerjaan.
Ini yang paling bahaya. Query laporan kamu makan memori dan disk yang sama dengan proses checkout pelanggan. Laporan lambat masih bisa ditunggu. Checkout lambat bikin orang batal beli.
Ada tiga tingkatan, urut dari yang paling murah. Ambil yang paling cocok sama ukuran data dan tim kamu.
Aturan praktis yang aku pakai: selama satu query laporan masih di bawah 5 detik dan ga ganggu aplikasi, tahan dulu di replica. Lewat dari itu, mulai bikin tabel ringkasan.
Dataset latihan toko_berkah punya 1,8 juta baris transaksi dari 3 tahun operasional, tersebar di 6 kota. Aku jalanin query omzet per kota per bulan langsung ke tabel mentah, lalu ke tabel ringkasan harian.
Di tabel mentah, query-nya mindai 1,8 juta baris dan selesai di 11,4 detik. Setelah dibikin tabel ringkasan harian, jumlah barisnya turun jadi 6.570 (6 kota kali 1.095 hari), dan query yang sama selesai di 0,08 detik.
Bedanya 142 kali lipat, dan ga ada satu pun indeks baru yang ditambahin. Yang berubah cuma berapa banyak baris yang harus dibaca.
Tabel ringkasannya dibikin sekali, lalu di-refresh tiap malam:
CREATE MATERIALIZED VIEW ringkasan_penjualan_harian AS
SELECT
tanggal::date AS tanggal,
kota,
SUM(total) AS omzet_harian,
COUNT(*) AS jumlah_transaksi,
COUNT(DISTINCT id_pelanggan) AS pelanggan_unik
FROM transaksi
GROUP BY 1, 2;
CREATE UNIQUE INDEX idx_ringkasan_harian
ON ringkasan_penjualan_harian (tanggal, kota);
-- dijalankan tiap malam lewat penjadwal
REFRESH MATERIALIZED VIEW CONCURRENTLY ringkasan_penjualan_harian;Satu catatan penting: begitu kamu pakai tabel ringkasan, angka yang tampil di dashboard umurnya sesuai jadwal refresh. Kalau bosmu butuh angka jam ini juga, sebutin batas itu dari awal.
Fungsi kayak SUM dan COUNT di query barusan disebut aggregate function. Ini yang paling banyak dipakai di beban kerja OLAP.
Bisa, dan banyak tim kecil di Indonesia jalan pakai itu. PostgreSQL punya materialized view, partisi tabel, dan ekstensi kolumnar kayak Citus buat beban analitik. Batasnya baru kerasa pas data masuk ratusan juta baris atau banyak orang query bareng. Selama data kamu masih puluhan juta baris, PostgreSQL yang disetel bener biasanya cukup tanpa perlu pindah sistem.
Database biasa nyimpan keadaan terkini buat dipakai aplikasi. Data warehouse nyimpan riwayat dari banyak sumber, disusun buat dianalisis. Isinya sering gabungan data dari aplikasi kasir, sistem HR, dan iklan digital. Datanya juga sengaja dibikin ga ternormalisasi biar query-nya sedikit JOIN. Tujuannya beda, jadi cara nyusun tabelnya juga beda.
Ada tiga tanda yang jelas. Pertama, query laporan udah nyentuh menitan walau udah dioptimalkan. Kedua, kamu butuh gabungin data dari lebih dari satu sistem. Ketiga, tim analis mulai ganggu kinerja aplikasi. Kalau cuma satu tanda yang muncul, coba read replica atau tabel ringkasan dulu. Pindah warehouse itu mahal di waktu dan perawatan.
Hampir selalu, karena data mentah dari aplikasi jarang siap dianalisis. ETL yang nyalin, bersihin, dan nyusun ulang datanya. Sebagian tim sekarang pakai urutan ELT: salin dulu apa adanya, baru diolah di dalam warehouse. Bedanya cuma di urutan tahap olahnya. Yang ga bisa dilewat itu tahap pembersihan dan penjadwalan salinannya.
Biasanya karena volume datanya beda. Di laptop kamu pakai contoh 10 ribu baris, di server ada 5 juta. Rencana eksekusi yang dipilih database bisa berubah total kalau ukuran datanya beda jauh. Jalanin EXPLAIN ANALYZE di kedua tempat dan bandingin hasilnya. Sering ketahuan bahwa di server database milih memindai tabel penuh.
Dua hal yang perlu kamu bawa dari sini. Query laporan lambat di database aplikasi itu wajar, karena rancangannya emang buat transaksi kecil. Dan solusi paling murah biasanya bukan indeks baru, tapi tabel ringkasan.
Coba jalanin EXPLAIN ANALYZE di satu query laporan yang paling sering kamu pakai minggu ini. Lihat berapa baris yang beneran dipindai. Angka itu yang nentuin langkah berikutnya.
Mau lanjut ke cara nyusun tabel di sisi analitik? Baca Star Schema vs Snowflake Schema.
Mau praktek langsung? Mulai latihan SQL gratis
Latihan interaktif, langsung di browser.
Kolom waktu isinya angka gede kayak 1704067200 dan bikin bingung? Itu Unix timestamp. Ini cara ngubahnya jadi tanggal beneran di SQL, plus balik lagi.
Data transaksi tersimpan UTC, tapi laporan harus jam WIB. Kalau salah konversi, angka penjualan tengah malam bisa kecatat di tanggal yang salah. Ini cara handle timezone di SQL dengan benar.
Nambah 30 hari ke tanggal invoice, ngurangin sebulan buat cari periode lalu, ngitung selisih hari antar order. Semua itu aritmetika tanggal, dan SQL punya operator INTERVAL buat ngerjainnya.