OLTP vs OLAP
Basis data transaksional vs analitis.
OLTP vs OLAP adalah pelajaran SQL Academy gratis di CoddyKit. Ini adalah pelajaran 1 dari 4. Kamu bisa membaca pelajaran lengkapnya di bawah secara gratis — lalu praktikkan langsung di browser dengan editor kode bawaan dan tutor AI 24/7. Ini adalah bagian dari jalur belajar SQL Academy, dan progresmu tersinkronisasi di web dan aplikasi CoddyKit. Kursus SQL Academy mencakup 4 pelajaran total.
Apa Itu OLTP dan OLAP
Basis data tidak dibuat untuk memenuhi semua kebutuhan. Dua beban kerja yang pada dasarnya berbeda telah membentuk cara kita merancang dan mengoperasikan basis data: OLTP (Pemrosesan Transaksi Daring) dan OLAP (Pemrosesan Analitis Daring).
Memahami perbedaannya sangat penting bagi setiap profesional data. Pilihan yang tepat antara OLTP dan OLAP menentukan kecepatan kueri, biaya penyimpanan, dan arsitektur keseluruhan sistem data Anda.
OLTP: Dibuat untuk Transaksi
Sistem OLTP menangani operasi singkat dan cepat dalam jumlah besar — penyisipan, pembaruan, dan penghapusan yang mencerminkan peristiwa bisnis waktu nyata. Contohnya adalah membuat pesanan, memproses pembayaran, atau memperbarui catatan pelanggan.
Sifat utama OLTP adalah latensi rendah per operasi, tingkat akses bersamaan yang tinggi, dan konsistensi kuat. Setiap transaksi harus memenuhi ACID untuk melindungi integritas data.
-- OLTP example: inserting a new order
INSERT INTO orders (customer_id, product_id, quantity, order_date)
VALUES (1042, 88, 3, CURRENT_DATE);
-- Immediately update inventory
UPDATE inventory
SET stock = stock - 3
WHERE product_id = 88;OLAP: Dibuat untuk Analisis
Sistem OLAP dioptimalkan untuk kueri kompleks yang memindai data historis dalam jumlah besar guna mengungkapkan tren, pola, dan ringkasan. Analis bisnis dan ilmuwan data menggunakan OLAP untuk menjawab pertanyaan seperti: 'Berapa total penjualan kita per wilayah pada kuartal lalu?'
Kueri OLAP sering mengagregasikan jutaan baris dan melibatkan beberapa penggabungan di antara tabel fakta dan dimensi. Kecepatan penulisan individual bukanlah prioritas; kemampuan baca dan fleksibilitas kueri adalah hal yang penting.
-- OLAP example: total sales by region for Q1 2024
SELECT
d.region,
SUM(f.sales_amount) AS total_sales,
COUNT(f.order_id) AS order_count
FROM fact_sales f
JOIN dim_date dd ON f.date_key = dd.date_key
JOIN dim_store d ON f.store_key = d.store_key
WHERE dd.year = 2024
AND dd.quarter = 1
GROUP BY d.region
ORDER BY total_sales DESC;Membandingkan Keduanya Berdampingan
Cara termudah untuk mengingat perbedaannya adalah dengan memikirkan siapa yang menggunakan setiap sistem dan bagaimana mereka menggunakannya:
- OLTP: digunakan oleh bagian belakang aplikasi; ribuan pengguna bersamaan; setiap kueri menyentuh beberapa baris.
- OLAP: digunakan oleh analis dan alat pelaporan; kueri bersamaan lebih sedikit, tetapi setiap kueri memindai jutaan baris.
Pola akses yang berbeda ini menghasilkan rancangan skema, strategi pengindeksan, dan bahkan pilihan perangkat keras yang sangat berbeda.
-- OLTP: lookup a single customer's latest order (row-level access)
SELECT o.order_id, o.order_date, o.total_amount
FROM orders o
WHERE o.customer_id = 1042
ORDER BY o.order_date DESC
LIMIT 1;
-- OLAP: monthly revenue trend over the past year (aggregate scan)
SELECT
DATE_TRUNC('month', order_date) AS month,
SUM(total_amount) AS revenue
FROM orders
WHERE order_date >= CURRENT_DATE - INTERVAL '12 months'
GROUP BY 1
ORDER BY 1;Desain Skema: Ternormalisasi vs Denormalisasi
Basis data OLTP mengutamakan skema ternormalisasi (3NF atau lebih tinggi) untuk menghilangkan redundansi dan membuat penulisan data efisien. Setiap entitas berada dalam tabelnya sendiri, sehingga data yang disentuh setiap transaksi lebih sedikit.
Basis data OLAP mengutamakan skema terdenormalisasi — terutama skema bintang dan kepingan salju — yang datanya telah digabungkan sebelumnya dan bersifat redundan. Ini menghilangkan penggabungan yang mahal saat kueri dijalankan dan memungkinkan mesin penyimpanan kolumnar memindai data lebih cepat.
-- Normalized OLTP design (3NF)
CREATE TABLE customers (
customer_id SERIAL PRIMARY KEY,
name VARCHAR(100),
email VARCHAR(150) UNIQUE
);
CREATE TABLE orders (
order_id SERIAL PRIMARY KEY,
customer_id INT REFERENCES customers(customer_id),
order_date DATE,
total NUMERIC(10,2)
);
-- Denormalized OLAP fact table (star schema)
CREATE TABLE fact_sales (
sale_id BIGINT PRIMARY KEY,
customer_key INT,
date_key INT,
product_key INT,
region VARCHAR(50),
category VARCHAR(50),
amount NUMERIC(12,2)
);Strategi Pengindeksan Berbeda
Sistem OLTP sangat mengandalkan indeks pohon-B pada kunci utama dan kunci asing untuk memungkinkan pencarian satu baris dengan cepat serta penggabungan yang efisien dalam satu transaksi.
Sistem OLAP memperoleh manfaat dari indeks peta bit, penyimpanan kolumnar, dan pemartisian. Pemindaian seluruh kolom (misalnya, semua nilai penjualan) jauh lebih efisien jika data disimpan per kolom, bukan per baris.
-- OLTP: B-tree index for fast order lookup by customer
CREATE INDEX idx_orders_customer
ON orders (customer_id);
-- OLTP: compound index for range queries
CREATE INDEX idx_orders_date_customer
ON orders (order_date, customer_id);
-- OLAP: partition fact table by year to prune scan
CREATE TABLE fact_sales_2024
PARTITION OF fact_sales
FOR VALUES FROM ('2024-01-01') TO ('2025-01-01');Konkruensi dan Penguncian
Sistem OLTP harus menangani ribuan penulisan bersamaan tanpa konflik. Basis data menggunakan penguncian tingkat baris dan MVCC (Kontrol Konkruensi Multi-Versi) agar pembaca tidak pernah menghalangi penulis dan sebaliknya.
Kueri OLAP sebagian besar hanya membaca. Penguncian jarang menjadi masalah, tetapi pemindaian yang berjalan lama dapat menghabiskan CPU dan operasi masukan/keluaran secara signifikan. Sebagian besar gudang data menjalankan OLAP pada sistem terpisah yang diisi melalui ETL secara berkelompok atau CDC (Pengambilan Data Perubahan) dari sumber OLTP.
-- OLTP: explicit transaction with row-level lock
BEGIN;
SELECT balance
FROM accounts
WHERE account_id = 7
FOR UPDATE;
UPDATE accounts
SET balance = balance - 200
WHERE account_id = 7;
COMMIT;ETL: Menjembatani OLTP dan OLAP
Karena OLTP dan OLAP memiliki desain yang tidak kompatibel, organisasi menjalankan ETL (Ekstrak, Transformasi, Muat) untuk menyalin dan membentuk ulang data dari basis data transaksional ke gudang analitis berdasarkan jadwal (setiap malam, setiap jam, atau hampir waktu nyata).
Proses ETL mengubah baris OLTP yang ternormalisasi menjadi catatan fakta dan dimensi yang terdenormalisasi, sambil menerapkan logika bisnis (misalnya, konversi mata uang dan segmentasi pelanggan).
-- Simplified ETL INSERT from OLTP orders into OLAP fact table
INSERT INTO fact_sales (
customer_key,
date_key,
product_key,
amount
)
SELECT
dc.customer_key,
dd.date_key,
dp.product_key,
o.total_amount
FROM orders o
JOIN dim_customer dc ON dc.source_customer_id = o.customer_id
JOIN dim_date dd ON dd.calendar_date = o.order_date
JOIN dim_product dp ON dp.source_product_id = o.product_id
WHERE o.order_date = CURRENT_DATE - INTERVAL '1 day'
AND o.order_id NOT IN (SELECT source_order_id FROM fact_sales);Pola Kueri OLAP yang Umum
Kueri OLAP hampir selalu melibatkan agregasi (SUM, COUNT, AVG), pengelompokan berdasarkan beberapa dimensi, dan penyaringan menurut rentang tanggal atau kategori. Semua ini merupakan dasar dasbor dan laporan bisnis.
Fungsi jendela sangat berguna dalam beban kerja OLAP — fungsi tersebut memungkinkan Anda membandingkan angka setiap periode dengan periode sebelumnya tanpa penggabungan tabel dengan dirinya sendiri.
-- Year-over-year revenue comparison using a window function
SELECT
dd.year,
dd.quarter,
SUM(f.amount) AS revenue,
LAG(SUM(f.amount)) OVER (PARTITION BY dd.quarter
ORDER BY dd.year) AS prev_year_revenue,
ROUND(
100.0 * (SUM(f.amount) -
LAG(SUM(f.amount)) OVER (PARTITION BY dd.quarter
ORDER BY dd.year))
/ NULLIF(LAG(SUM(f.amount)) OVER (PARTITION BY dd.quarter
ORDER BY dd.year), 0)
, 2) AS yoy_pct_change
FROM fact_sales f
JOIN dim_date dd ON f.date_key = dd.date_key
GROUP BY dd.year, dd.quarter
ORDER BY dd.quarter, dd.year;Mengaburkan Batas
Sistem modern seperti TiDB, SingleStore, dan ekstensi kolumnar PostgreSQL menerapkan HTAP (Pemrosesan Transaksional/Analitis Hibrida). Sistem ini bertujuan menangani kedua beban kerja dalam satu mesin, sehingga menghindari kerumitan operasional dalam memelihara sistem OLTP dan OLAP yang terpisah.
HTAP mencapainya dengan menyimpan data dalam dua format secara bersamaan: penyimpanan baris untuk penulisan transaksional dan penyimpanan kolom untuk pembacaan analitis, yang disinkronkan secara otomatis.
-- PostgreSQL with cstore_fdw (columnar extension) example
-- Analytical table stored in columnar format
CREATE FOREIGN TABLE fact_sales_columnar (
date_key INT,
product_key INT,
region VARCHAR(50),
amount NUMERIC(12,2)
)
SERVER cstore_server
OPTIONS (filename '/data/fact_sales_columnar');
-- Regular OLTP table remains row-based
-- Both can be queried in the same SQL statement
SELECT f.region, SUM(f.amount)
FROM fact_sales_columnar f
GROUP BY f.region;Memilih Sistem yang Tepat
Keputusan antara OLTP dan OLAP (atau HTAP) bergantung pada beban kerja utama Anda:
- Jika Anda membangun aplikasi yang mencatat peristiwa secara waktu nyata — gunakan basis data OLTP (PostgreSQL, MySQL, Server SQL).
- Jika Anda membangun lapisan pelaporan di atas data historis — gunakan gudang OLAP (BigQuery, Pergeseran Merah, Kepingan Salju, ClickHouse).
- Jika Anda memerlukan keduanya dan menginginkan kesederhanaan operasional — evaluasilah pilihan HTAP.
Banyak arsitektur produksi menggunakan keduanya: basis data OLTP sebagai sumber data utama dan gudang data terpisah untuk analisis, yang dihubungkan oleh alur ETL.
-- Quick diagnostic: check table access pattern
-- High seq_scan relative to idx_scan = analytical (OLAP-like) load
SELECT
relname AS table_name,
seq_scan,
idx_scan,
n_live_tup AS live_rows
FROM pg_stat_user_tables
ORDER BY seq_scan DESC
LIMIT 10;Uji Pemahaman
Ujilah pemahaman Anda tentang perbedaan utama antara sistem OLTP dan OLAP.
Rangkuman Pelajaran
OLTP dibandingkan OLAP — poin utama:
- OLTP menangani beban kerja transaksional waktu nyata: penulisan yang cepat dan bersamaan pada tingkat baris dengan jaminan ACID.
- OLAP menangani beban kerja analitis: agregasi kompleks atas kumpulan data historis berukuran besar, menggunakan skema terdenormalisasi.
- Desain skema mengikuti beban kerja — ternormalisasi (3NF) untuk OLTP, bintang/kepingan salju untuk OLAP.
- Alur ETL menjembatani kedua sistem dengan memuat data OLTP yang telah ditransformasi ke dalam gudang analitis.
- Sistem HTAP berupaya melayani kedua beban kerja dari satu mesin menggunakan penyimpanan baris/kolom ganda.
Memilih arsitektur yang tepat sejak awal mencegah migrasi yang menyulitkan di kemudian hari dan memastikan kueri berjalan secepat yang diharapkan pengguna Anda.
Pertanyaan yang Sering Diajukan
Apakah pelajaran “OLTP vs OLAP” gratis?
Ya — teks lengkap “OLTP vs OLAP” gratis dibaca di sini di web. Untuk praktiknya secara interaktif (editor kode bawaan dan tutor AI 24/7) dan buka sisa kursus SQL Academy, upgrade ke CoddyKit PRO. Kursus SQL Academy mencakup 4 pelajaran total.
Apa yang akan aku pelajari di “OLTP vs OLAP”?
Basis data transaksional vs analitis. Kamu berlatih SQL Academy dengan kode praktik yang langsung kamu jalankan di browser, dan tutor AI 24/7 menjawab pertanyaanmu saat kamu mengerjakan pelajaran ini.
Apakah aku perlu pengalaman untuk memulai SQL Academy?
Tidak diperlukan pengalaman sebelumnya. SQL Academy di CoddyKit dirancang untuk pemula hingga pelajar tingkat lanjut, jadi kamu bisa memulai di sini atau dari awal dan belajar sesuai kecepatan kamu sendiri. Ini adalah pelajaran 1 dari 4.
Berapa lama pelajaran “OLTP vs OLAP” memakan waktu?
Sebagian besar pelajaran CoddyKit memakan waktu sekitar 5–10 menit. Setiap pelajaran ringkas dan interaktif, jadi kamu membuat kemajuan stabil dan melanjutkan dari tempat kamu tinggalkan di web dan aplikasi.
Bisakah aku menulis dan menjalankan kode dalam pelajaran SQL Academy ini?
Ya. Setiap pelajaran SQL Academy menyertakan editor kode bawaan, jadi kamu menulis dan menjalankan kode nyata langsung di browser dan mendapatkan umpan balik AI instan — tidak diperlukan penyiapan lokal.