OLTP vs OLAP: Kenapa Query Analitik Lambat di Database Aplikasi

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.

Apa itu OLTP dan OLAP?

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.

Apa bedanya OLTP dan OLAP?

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.

Kenapa query analitik lambat di database aplikasi?

Ada empat sebab yang paling sering muncul, dan biasanya kejadian barengan.

1. Indeks ga kepakai waktu memindai banyak baris

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.

2. Data disimpan per baris

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.

3. Normalisasi bikin JOIN menumpuk

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.

4. Query analitik rebutan sumber daya sama transaksi

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.

Gimana cara mindahin beban analitik dari database produksi?

Ada tiga tingkatan, urut dari yang paling murah. Ambil yang paling cocok sama ukuran data dan tim kamu.

1. Bikin read replica. Salinan database yang cuma bisa dibaca. Query laporan diarahkan ke sini, transaksi tetap ke database utama. Paling cepat dipasang, dan sering udah cukup buat data di bawah puluhan juta baris.
2. Bikin tabel ringkasan. Hitung total harian sekali sehari, simpan di tabel terpisah. Dashboard baca dari tabel ringkasan, bukan dari tabel transaksi mentah. Di PostgreSQL bisa pakai materialized view yang di-refresh terjadwal.
3. Pindah ke data warehouse. Data disalin rutin dari database aplikasi ke sistem yang dirancang buat analitik. Alur penyalinannya namanya ETL. Struktur tabelnya biasanya dimensional, dan pilihan modelnya dibahas di star schema vs snowflake schema.

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.

Contoh kasus: laporan bulanan toko_berkah

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.

Apa kesalahan umum waktu misahin OLTP dan OLAP?

• Nambah indeks terus tiap kali laporan lambat. Tiap indeks baru bikin INSERT dan UPDATE makin berat. Ujungnya aplikasi ikut lambat.
• Nge-query database produksi langsung dari tool BI. Satu orang klik refresh dashboard, 12 query berat jalan bareng.
• Nyalin seluruh tabel tiap jam. Kalau tabelnya 1,8 juta baris, salin ulang penuh itu boros. Pakai penyalinan bertahap berdasarkan kolom waktu update.
• Lupa nyimpan riwayat perubahan. Database aplikasi nge-update alamat pelanggan di tempat. Data warehouse butuh riwayatnya biar laporan tahun lalu tetap akurat.
• Bikin tabel ringkasan tapi ga ada yang ngecek. Kalau proses refresh gagal diam-diam, dashboard tetap nampilin angka lama tanpa peringatan. Pasang pemantauan tanggal terakhir refresh.

FAQ

Apakah PostgreSQL bisa dipakai buat 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.

Apa bedanya data warehouse sama database biasa?

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.

Kapan aku perlu pindah dari database aplikasi ke data warehouse?

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.

Apakah OLAP selalu butuh ETL?

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.

Kenapa query yang sama bisa cepat di laptop tapi lambat di server?

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.

Langkah berikutnya

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.