3. Bukti & angka nyata
Latensi diukur dengan \timing (PostgreSQL) dan clickhouse-client --time (ClickHouse) pada dataset yang sama.
OLTP — row-store (PostgreSQL 16)
SELECT merchant_category, count(*), sum(amount)
FROM transactions GROUP BY 1 ORDER BY 3 DESC;
409,8 ms untuk 5.000.000 baris — harus membaca hampir seluruh tabel (sequential scan) karena agregasi tidak terindeks.
OLAP — column-store (ClickHouse 24.8)
SELECT merchant_category, count(), sum(amount)
FROM finance.transactions GROUP BY 1;
47 ms untuk 4.900.607 baris — hanya kolom yang dibutuhkan yang dibaca (column pruning) + kompresi kolumnar.
Pre-agregat siap BI
SELECT sum(total_amount)
FROM finance.daily_transaction_summary;
6 ms untuk 46.848 baris hasil dbt — inilah yang dibaca Metabase, sehingga dashboard tetap responsif walau data mentah jutaan baris.
Hasil pengujian kualitas data
dbt test: PASS=4 · WARN=0 · ERROR=0 dalam 3,30 detik (memori proses 160 MB).
Test yang berjalan: unique(transaction_id), not_null(transaction_id), not_null(amount), accepted_values(status= 'success').
Kenapa arsitektur ini dipilih
Setiap komponen punya alasan teknis yang bisa dipertanggungjawabkan:
| Keputusan | Alasan |
|---|---|
| Batch insert 20.000 | round-trip jaringan jauh lebih mahal daripada ukuran payload |
| CDC vs polling | polling membebani OLTP; CDC membaca WAL/binlog secara non-invasif |
| dbt + test | transformasi terversi di Git dan gagal cepat saat data kotor |
| MergeTree + partisi bulanan | query per rentang waktu hanya memindai partisi relevan |
| Pre-agregat harian | BI tidak lagi menyentuh jutaan baris mentah |
| Sink idempotent | aman dijalankan ulang tanpa data ganda |