Tanggal Berita: 7 Desember 2025
Gunnar Morling membedah paradoks dalam rekayasa data: untuk mendapatkan performa query (pull) yang instan, Anda harus terus-menerus mendorong (push) perubahan data di latar belakang. Ini adalah pengantar menuju Incremental View Maintenance (IVM).
🚧 Problem Statement: Keterbatasan "Pull Query"
Secara historis, sistem database dibangun di atas konsep pull queries. Pengguna mengirim pertanyaan (SQL), dan mesin database harus bekerja keras memindai tabel, menggabungkan data (join), dan menghitung agregasi pada saat itu juga.
🐢 Lambat & Mahal Pendekatan ini memiliki batas kinerja yang nyata. Saat dataset membesar atau logika join menjadi terlalu kompleks, waktu tunggu untuk mendapatkan jawaban menjadi tidak masuk akal. Selain itu, bentuk data di database operasional (OLTP) seringkali tidak optimal untuk menjawab pertanyaan analitik, dan lokasi data mungkin terlalu jauh dari pengguna untuk latensi rendah.
🛠️ Solusi: Materialized Views & Data Duplication
Solusi untuk masalah di atas adalah Materialized Views dalam arti luas. Idenya adalah melakukan pra-komputasi (precompute) hasil query dan menyimpannya dalam format yang siap baca.
👯 Jangan Takut Duplikasi Penulis menyarankan untuk merangkul duplikasi data. Selama ada satu "Sumber Kebenaran" (Source of Truth) yang kanonik, Anda bebas membuat banyak salinan data (view) yang masing-masing dioptimalkan untuk kebutuhan query tertentu.
🌊 Push Queries (Incremental) Alih-alih menghitung ulang seluruh view dari nol setiap kali ada perubahan (yang sangat boros), gunakan pendekatan Push Queries. Saat ada data baru masuk, sistem hanya menghitung delta atau selisihnya saja. Contoh: Jika ada pesanan baru, jangan hitung ulang total pendapatan dari nol; cukup tambahkan nilai pesanan baru tersebut ke total yang sudah ada.
⚡ Findings: Stream untuk Mesin, Tabel untuk Manusia
Inti dari filosofi ini adalah pembagian peran yang jelas antara mesin dan manusia.
🤖 Push untuk Mesin Mesin (sistem) bekerja terbaik dengan aliran data (streams) dan perubahan inkremental yang terus-menerus didorong (push) untuk memperbarui status terkini.
👤 Pull untuk Manusia Manusia tidak ingin dibanjiri notifikasi setiap milidetik saat angka berubah. Manusia ingin melihat hasil akhir (snapshot) pada saat mereka membutuhkannya. Dengan menggabungkan keduanya—push query untuk memelihara view, dan pull query untuk membaca view tersebut—kita mendapatkan kecepatan pemrosesan real-time dan kemudahan akses data.
⚙️ How to Use: Implementasi IVM
Untuk menerapkan arsitektur ini, Anda memerlukan komponen yang mendukung Incremental View Maintenance (IVM).
🏗️ Stack Teknologi Anda bisa menggunakan pemroses aliran seperti Flink SQL yang mengambil data perubahan (Change Data Capture) dari database, memprosesnya, dan menulis hasilnya ke Elasticsearch atau tabel Iceberg. Alternatif lain adalah menggunakan database dengan ekstensi IVM seperti Postgres (pg_ivm), atau mesin IVM khusus seperti Feldera, Materialize, atau RisingWave.
🗝️ Key Takeaways
🔄 Instant Pull butuh Constant Push Jika Anda menginginkan query baca (pull) yang instan, Anda memerlukan proses tulis (push) yang konstan di belakang layar.
📉 Efisiensi Delta Memproses perubahan kecil (delta) jauh lebih hemat sumber daya daripada menghitung ulang dataset besar secara berkala (batch processing).
💾 Duplikasi Terkelola Duplikasi data bukanlah dosa dalam data engineering, melainkan strategi optimasi, asalkan konsistensi terjaga (walaupun eventual consistency).
💬 Interaksi Pembaca
Apakah arsitektur data Anda saat ini masih melakukan query berat (join 5 tabel) secara langsung ke database utama, atau Anda sudah mulai memisahkan jalur tulis dan baca menggunakan Materialized Views?
Sumber:
https://www.morling.dev/blog/you-gotta-push-if-you-wanna-pull/
#DataEngineering #SoftwareArchitecture #StreamingData #MaterializedViews #DatabaseDesign #ApacheFlink #CDC #RealTimeAnalytics #SQL
