Materialized views untuk dashboard: prekomputasi dan refresh dengan aman

Mengapa dashboard bertrafik tinggi menjadi lambat

Dashboard biasanya terasa cepat saat pengujian karena hanya ada sedikit pengguna dan data yang kecil. Di produksi, setiap penyegaran bisa memicu kueri berat yang sama berulang-ulang. Jika kueri itu memindai jutaan baris, melakukan join beberapa tabel, lalu mengelompokkan berdasarkan waktu atau kategori, database harus bekerja keras untuk setiap orang yang membuka halaman.

Penyebab umum adalah:

• Join besar (misalnya, orders + customers + products) yang menggandakan jumlah data yang harus dipindahkan database.
• Group-by pada event mentah ("count per day", "sum per region") yang memerlukan penyortiran dan agregasi.
• Banyak filter dan segmen (rentang tanggal, negara, perangkat, paket) yang mengubah bentuk kueri dan mencegah reuse yang mudah.

Caching membantu, tetapi seringkali gagal saat dashboard punya banyak kombinasi filter. Satu pengguna meminta "7 hari terakhir, UE, berbayar" sementara yang lain meminta "30 hari terakhir, AS, trial". Anda berakhir dengan terlalu banyak cache key, tingkat hit cache rendah, dan performa tidak dapat diprediksi. Lebih parah lagi, cache bisa menyembunyikan kueri lambat sampai terjadi cache miss pada puncak lalu lintas.

Di sinilah materialized views untuk dashboard berguna. Secara sederhana, materialized view adalah tabel yang menyimpan hasil yang telah diprekomputasi. Alih-alih menghitung ulang total yang sama dari data mentah setiap kali, Anda menghitungnya sekali (berdasarkan jadwal atau pemicu) dan menyajikan dashboard dari snapshot yang tersimpan itu.

Index biasa cocok ketika Anda masih perlu membaca baris mentah dengan cepat (misalnya mencari satu pelanggan atau memfilter berdasarkan satu kolom). Materialized view tepat ketika bagian yang mahal adalah agregasi berulang: penjumlahan, penghitungan, dan metrik tergrup yang banyak pengguna tanyakan sepanjang hari.

Jika Anda membangun dashboard di PostgreSQL (termasuk proyek yang dibuat di AppMaster), perbedaan ini penting: index mempercepat lookup, tetapi prekomputasi yang membuat halaman dengan agregasi berat tetap stabil saat beban tinggi.

Tentukan apa yang harus cepat

Sebelum Anda membangun materialized views untuk dashboard, tentukan bagian mana dari dashboard yang harus merespons seketika. Tidak setiap angka perlu real-time. Jika Anda menganggap semuanya harus real-time, Anda akan membayar dengan waktu muat yang lambat, timeouts, dan tekanan refresh yang konstan.

Mulailah dengan memetakan layar dashboard ke kueri nyata yang dipicu. Setiap tile, grafik, dan tabel biasanya memiliki setidaknya satu kueri di baliknya, dan filter sering menggandakannya menjadi banyak varian. Dashboard "sederhana" dengan 8 tile dan 6 filter bisa diam-diam berubah menjadi puluhan bentuk kueri.

Cara praktis adalah menuliskan tiap tile dan menjawab tiga pertanyaan:

• Filter apa yang bisa mengubahnya (rentang tanggal, wilayah, tim, status)?
• Tabel apa yang disentuh, dan di mana join terjadi?
• Apa arti "cukup cepat" untuk tile ini (sub-detik, 2 detik, 5 detik)?

Lalu pisahkan kebutuhan real-time sejati dari metrik yang "boleh sedikit tertinggal". Pengguna sering membutuhkan alert dan hitungan operasional cepat (misalnya, "insiden terbuka sekarang"), tetapi mereka bisa mentolerir keterlambatan untuk ringkasan yang lebih berat (seperti konversi mingguan menurut segmen). Aturan yang baik adalah memilih target kesegaran per tile, seperti instan, 1 menit, 5 menit, atau 15 menit.

Selanjutnya, identifikasi apa yang mahal. Cari join lebar antar tabel besar, pemindaian besar pada log event mentah, dan agregasi berat seperti distinct count dan perhitungan persentil. Itu adalah bagian yang paling mungkin mendapat manfaat dari prekomputasi.

Contoh: dashboard support mungkin perlu "tiket menunggu" secara instan, tetapi "waktu respon pertama rata-rata per channel" bisa tertinggal 5–15 menit tanpa mengganggu pengguna. Jika Anda membangun dashboard di alat seperti AppMaster, latihan ini tetap berlaku: UI terasa cepat hanya jika endpoint data yang dipanggilnya cepat, dan itu dimulai dengan memutuskan apa yang harus diprioritaskan.

Apa yang harus diprekomputasi untuk dashboard

Untuk dashboard, prekomputasi apa saja yang sering diminta, berubah dengan cara yang dapat diprediksi, dan menyakitkan jika dihitung dari event mentah setiap kali. Jika dilakukan dengan baik, materialized views mengubah "memindai jutaan baris" menjadi "membaca beberapa ratus baris".

Mulailah dari tile yang paling sering diperhatikan orang: total, tren, dan breakdown. Jika grafik mengelompokkan data berdasarkan waktu, pre-aggregate sesuai bucket waktu yang digunakan UI (jam, hari, minggu) dan hanya dimensi yang paling sering difilter pengguna.

Kandidat yang baik untuk prekomputasi biasanya:

• Agregat ber-bucket waktu (count, sum, average) plus beberapa dimensi kunci yang sering difilter, seperti region, tim, paket, atau status.
• Baris yang telah dipre-join untuk menghilangkan pekerjaan join berulang, seperti event yang digabung ke accounts, products, dan owners.
• Top-N dan ringkasan "matematika berat", seperti 20 pelanggan teratas berdasarkan pengeluaran, p95 latency, atau bucket persentil.
• Lookup referensi yang berubah perlahan, seperti "nama paket saat ini" atau "tim yang ditugaskan", sehingga dashboard tidak sering mengakses tabel referensi.
• Tabel "dashboard" kecil dan khusus yang mengecualikan payload event mentah dan hanya menyimpan apa yang UI butuhkan.

Aturan sederhana: jangan masukkan event mentah ke dalam view kecuali dashboard benar-benar membutuhkan detail event. Jika Anda perlu drill-down, prekomputasi ringkasan untuk tampilan utama dan muat event detail hanya ketika pengguna membuka panel drill.

Contoh: dashboard ops menampilkan "tiket dibuat hari ini", "median waktu respon pertama", dan diagram batang per queue support. Prekomputasi jumlah tiket harian dan per jam per queue, plus bucket persentil waktu respon. Simpan riwayat pesan tiket lengkap di luar materialized view.

Jika Anda membangun dashboard di alat no-code seperti AppMaster, pendekatan ini juga membuat endpoint backend lebih sederhana: API Anda dapat membaca satu dataset yang sudah disiapkan daripada membangun ulang join dan kalkulasi yang sama setiap permintaan.

Memilih granularitas dan dimensi yang tepat

Materialized view berguna ketika dapat menjawab sebagian besar pertanyaan dengan satu kueri cepat. Cara termudah mencapai itu adalah mulai dengan set dimensi terkecil yang benar-benar digunakan orang setiap hari, bukan setiap filter yang bisa ditampilkan UI.

Mulailah dengan mencantumkan 5–10 pertanyaan teratas yang harus dijawab dashboard, lalu lingkari field yang diperlukan untuk mengelompokkan jawaban tersebut. Misalnya, dashboard ops sering membutuhkan waktu, status, dan tim. Jarang membutuhkan waktu + status + tim + pengguna individu + model perangkat sekaligus.

Jika Anda membuat view terpisah untuk setiap filter, Anda akan meningkatkan jumlah view atau akhirnya merefresh tabel besar untuk manfaat kecil. Pola yang lebih baik adalah satu atau dua view yang dipilih dengan bijak yang mencakup jalur umum, dan biarkan filter long-tail sebagai kueri on-demand (atau halaman drill-down terpisah).

Gunakan rollup daripada satu view "sempurna"

Waktu biasanya penggerak ukuran dan biaya refresh. Rollup memungkinkan Anda tetap cepat tanpa menyimpan setiap grain di mana-mana:

• Simpan rollup level-hari untuk rentang tanggal panjang (90 hari, 12 bulan).
• Tambahkan rollup level-jam hanya jika pengguna sering memperbesar ke "hari ini" atau "24 jam terakhir".
• Simpan event mentah (atau tabel fact tipis) untuk drill-down yang detil.

Ini memberi Anda performa yang dapat diprediksi untuk dashboard bertrafik tinggi tanpa mencoba membuat satu view melayani setiap rentang waktu.

Rencanakan untuk kedatangan terlambat dan backfill

Data nyata sering datang terlambat: retry, perangkat offline, konfirmasi pembayaran, impor. Rancang view sehingga dapat dikoreksi dengan aman. Salah satu pendekatan sederhana adalah selalu merefresh jendela trailing kecil (misalnya 2–3 hari terakhir) walaupun dashboard default ke "hari ini".

Jika Anda membangun di AppMaster di atas PostgreSQL, perlakukan dimensi ini seperti bagian dari kontrak data: jaga stabilitasnya, beri nama dengan jelas, dan tahan godaan menambah "satu dimensi lagi" kecuali terikat ke pertanyaan nyata.

Strategi refresh yang bekerja di produksi

Dashboard bisa terasa instan atau menyakitkan bergantung pada satu keputusan: bagaimana Anda me-refresh data di baliknya. Untuk materialized views pada dashboard, tujuannya sederhana: buat kueri dapat diprediksi sambil menjaga angka cukup segar untuk bisnis.

Full refresh vs incremental refresh

Full refresh membangun ulang semuanya. Mudah dipahami dan kecil kemungkinan menyimpang, tetapi bisa lambat dan berkompetisi dengan trafik puncak.

Incremental refresh hanya memperbarui apa yang berubah, biasanya jendela waktu terbaru. Lebih cepat dan lebih murah, tetapi memerlukan aturan jelas tentang data terlambat, update, dan delete.

Gunakan full refresh ketika dataset kecil, logikanya kompleks, atau ketepatan lebih penting daripada kesegaran (misalnya, penutupan keuangan). Gunakan incremental ketika sebagian besar pertanyaan dashboard fokus pada aktivitas terbaru dan tabel sumber bersifat append-heavy (event, orders, tickets).

Kinerja dan penjadwalan

Pilih cadence refresh yang sesuai dengan seberapa usang yang aman. Banyak tim mulai dengan 5 menit, lalu memperketat ke 1 menit hanya untuk tile yang benar-benar membutuhkan. Per jam seringkali cukup untuk chart tren dan perbandingan "minggu lalu".

Cara praktis menentukan cadence adalah mengaitkannya ke keputusan nyata: jika seseorang akan memanggil on-call engineer berdasarkan sebuah angka, tile itu butuh refresh lebih cepat daripada kartu KPI mingguan.

Berikut pola refresh yang tahan beban:

• Refresh setelah data tiba, bukan hanya berdasarkan jam (misalnya, jalankan saat batch ETL terakhir selesai).
• Offset jadwal untuk menghindari puncak menit (top of the minute) saat banyak sistem spike.
• Pertahankan view "hot" kecil untuk 1–7 hari terakhir dan view "history" terpisah untuk period lama.
• Gabungkan hot + history di kueri dashboard, sehingga sebagian besar pekerjaan refresh tetap kecil.
• Untuk aplikasi berbasis Postgres (umum saat membangun dashboard di AppMaster), jalankan rebuild yang lebih berat di jam-jam rendah lalu lintas dan pertahankan refresh sering yang ringan.

Contoh konkret: dashboard ops menampilkan "orders dalam 1 jam terakhir" dan "orders per hari untuk 90 hari." Refresh view 1 jam terakhir setiap menit, tetapi refresh rollup harian 90 hari setiap jam atau semalaman. Pengguna mendapat chart cepat dan stabil, dan database terhindar dari re-aggregasi konstan data lama.

Cara menangani data usang dengan aman

Dashboard tidak perlu benar-benar segar untuk berguna, tetapi harus dapat dipercaya. Pendekatan paling aman adalah menganggap kesegaran sebagai bagian dari produk: tentukan apa arti "cukup segar" per tile, dan buat itu terlihat.

Mulailah dengan mendefinisikan jendela staleness maksimal untuk tiap metrik. Total finance mungkin mentolerir 15 menit, sementara penghitung insiden mungkin butuh 1 menit. Jendela itu menjadi aturan sederhana: jika data lebih tua dari batas, tile berubah perilaku daripada diam-diam menampilkan angka lama.

Polanya yang praktis untuk materialized views adalah "last-known-good" serving. Jika sebuah refresh gagal, terus tampilkan snapshot sukses sebelumnya daripada merusak halaman atau mengembalikan hasil parsial. Pasangkan dengan monitoring agar kegagalan cepat terdeteksi, tetapi pengguna tetap mendapat dashboard yang stabil.

Buat kesegaran terlihat. Tambahkan timestamp "updated at" (atau "data as of") per tile, bukan hanya di atas halaman. Orang membuat keputusan lebih baik ketika mereka dapat menilai umur setiap angka.

Saat tile terlalu usang, sediakan jalur fallback untuk metrik yang benar-benar kritikal. Misalnya:

• Gunakan kueri langsung yang lebih sederhana pada rentang waktu yang lebih kecil (1 jam terakhir, bukan 90 hari)
• Kembalikan nilai perkiraan (sampled atau cached) dengan label yang jelas
• Sembunyikan breakdown sementara dan tampilkan hanya angka headline
• Tampilkan last-known-good plus status peringatan

Contoh: dashboard ops di AppMaster bisa menampilkan "Diperbarui 2 menit lalu" di samping tiket terbuka dan kegagalan pembayaran. Jika view terprekalkulasi berumur 20 menit, ia dapat beralih ke kueri real-time kecil hanya untuk dua tile itu, sementara chart kurang kritis tetap memakai snapshot lama.

Kunci adalah konsistensi: data usang boleh asal terkendali, terlihat, dan gagal dengan aman.

Hindari masalah refresh saat puncak lalu lintas

Puncak lalu lintas adalah saat refresh bisa paling merusak. Satu refresh berat bisa bersaing dengan pembacaan dashboard untuk CPU, disk, dan lock, dan pengguna merasakannya sebagai chart lambat atau timeouts.

Pertama, isolasi pekerjaan bila memungkinkan. Jika setup Anda memiliki read replica, jalankan bagian berat di sana dan hanya salin hasil akhir ke primary, atau dedikasikan node database terpisah untuk job refresh. Bahkan tanpa replica, Anda bisa membatasi resource worker refresh sehingga kueri pengguna tetap punya ruang.

Kedua, hindari pola yang memblokir pembacaan. Di PostgreSQL, REFRESH MATERIALIZED VIEW biasa mengambil lock yang dapat menjeda kueri. Pilih pendekatan non-blocking seperti REFRESH MATERIALIZED VIEW CONCURRENTLY (ketika didukung dan diindeks dengan benar), atau pola swap: bangun tabel atau hasil view baru di latar belakang, lalu ganti dalam transaksi cepat.

Overlaps adalah pembunuh senyap. Jika refresh butuh 6 menit tetapi Anda menjadwalkannya setiap 5 menit, backlog tumbuh dan puncak lalu lintas mendapat beban terberat. Pasang penjaga agar hanya satu refresh berjalan pada satu waktu, dan lewati atau tunda run berikutnya jika yang sebelumnya masih berjalan.

Beberapa perlindungan praktis yang saling melengkapi:

• Jalankan job refresh dari sumber daya terpisah (replica, worker berdedikasi, atau pool yang dibatasi)
• Gunakan refresh non-blocking (concurrent refresh atau swap-in results)
• Tambahkan lock "single-flight" untuk mencegah overlapping refresh
• Batasi jumlah permintaan refresh yang dipicu pengguna (per pengguna dan global)
• Catat durasi refresh dan beri alert saat meningkat

Jika dashboard memiliki tombol "Update", perlakukan seperti request, bukan perintah. Biarkan tombol mengantri percobaan refresh, lalu respon dengan data saat ini plus waktu "last updated" yang jelas. Di AppMaster, pengendalian semacam ini sering paling mudah diterapkan sebagai Business Process kecil yang memeriksa refresh terakhir dan memutuskan apakah menjalankan atau melewati.

Kesalahan umum dan jebakan

Kesalahan terbesar dengan materialized views untuk dashboard adalah menganggapnya ajaib. Mereka bisa membuat dashboard terasa instan, tetapi hanya jika view cukup kecil, direfresh pada tempo yang tepat, dan dibandingkan dengan tabel sumber secara berkala.

Mode kegagalan umum adalah merefresh terlalu agresif. Jika Anda merefresh setiap menit hanya karena bisa, Anda mungkin membuat database sibuk melakukan rebuild sepanjang hari. Pengguna masih merasakan halaman lambat saat spike refresh itu terjadi, dan tagihan compute Anda naik.

Jebakan lain adalah membuat view untuk setiap ide chart. Tim sering membuat lima versi metrik yang sama (per minggu, per hari, per region, per sales rep) dan hanya satu yang dipakai. View tambahan menambah beban refresh, storage, dan lebih banyak tempat terjadinya ketidaksesuaian angka.

Waspadai dimensi ber-kardinalitas tinggi. Menambahkan field seperti user_id, session_id, atau tag bebas dapat meledakkan jumlah baris. View menjadi lebih besar dari kueri sumber yang ingin dipercepat, dan waktu refresh tumbuh bersamanya.

Event terlambat dan backfill juga dapat membuat dashboard terasa tidak dapat dipercaya. Jika data kemarin masih bisa berubah hari ini (refund, log tertunda, koreksi manual), pengguna akan melihat total melompat tanpa penjelasan kecuali Anda merencanakannya.

Tanda bahwa setup Anda menuju masalah:

• Job refresh saling tumpang tindih atau tampak tidak pernah selesai
• Jumlah baris view tumbuh lebih cepat daripada tabel dasar
• Filter kecil (seperti satu tim) masih memindai bagian besar view
• Chart tidak cocok bergantung pada layar mana yang dibuka
• Tiket dukungan mengatakan "dashboard salah tadi"

Beberapa pengaman sederhana mencegah sebagian besar ini:

• Jaga satu kueri sumber-kebenaran dan bandingkan total secara reguler
• Batasi dimensi ke yang benar-benar difilter orang
• Rencanakan aturan backfill (misalnya, selalu proses ulang 7 hari terakhir)
• Tambahkan timestamp "last updated" yang terlihat di dashboard
• Uji beban refresh saat puncak, bukan hanya di malam hari

Jika Anda membangun dashboard internal di PostgreSQL (misalnya di dalam aplikasi AppMaster), perlakukan setiap materialized view seperti fitur produksi: butuh pemilik, tujuan, dan tes yang membuktikan angka cocok dengan kenyataan.

Daftar periksa cepat sebelum rilis

Sebelum dashboard dirilis ke audiens luas, tuliskan apa arti "cukup baik". Untuk tiap tile, tetapkan target kesegaran yang jelas (misalnya: "orders per jam boleh tertinggal 2 menit, refunds boleh 15 menit"). Jika Anda tidak bisa menjelaskannya dalam satu kalimat, Anda akan berdebat nanti saat insiden.

Gunakan pengecekan akhir ini sebagai pemeriksaan keselamatan praktis untuk materialized views. Ini lebih tentang menghindari kejutan setelah peluncuran daripada desain sempurna.

• Definisikan kesegaran per tile dan per audiens. Ringkasan CEO boleh sedikit usang, tetapi panel on-call ops biasanya tidak. Letakkan SLA di samping kueri, bukan hanya di dokumen.
• Lacak ukuran dan pertumbuhan view. Catat jumlah baris saat ini, ukuran penyimpanan, dan pertumbuhan harian sehingga Anda menyadari saat dimensi baru atau riwayat panjang menggandakan biaya.
• Ukur waktu refresh dan cegah overlap. Refresh harus selesai jauh sebelum run terjadwal berikutnya, bahkan pada "hari buruk" (lebih banyak trafik, I/O lebih lambat). Jika refresh overlap, lock dan antrean bisa membesar.
• Putuskan bagaimana menunjukkan staleness. Tetapkan usia maksimal, tampilkan timestamp "updated at" di tiap tile, dan pilih fallback (sajikan snapshot terakhir yang baik, sembunyikan tile, atau tampilkan status peringatan).
• Jalankan pemeriksaan rekonsiliasi. Secara berkala, bandingkan beberapa total kunci di view dengan tabel dasar (hari ini, kemarin, 7 hari terakhir). Beri alert pada drift, bukan hanya kegagalan.

Satu tes sederhana: simulasikan refresh tertunda dengan menghentikannya selama 10 menit. Jika dashboard menjadi menyesatkan atau orang tidak bisa melihat bahwa datanya usang, sesuaikan UI dan aturan sebelum rilis. Jika Anda membangun dashboard di AppMaster, tambahkan label "updated at" sebagai field kelas satu sehingga ia ikut bersama data, bukan sekadar pemikiran tambahan.

Contoh realistis: menjaga dashboard ops tetap cepat

Bayangkan tim ecommerce menonton dashboard ops selama flash sale. Ratusan orang di dalam perusahaan membuka halaman yang sama: orders per jam, rasio sukses pembayaran, refund, dan "apa yang laku sekarang". Jika setiap tile menjalankan kueri berat pada tabel orders dan payments mentah, database terus-menerus digempur, dan dashboard melambat saat paling dibutuhkan.

Sebagai gantinya, Anda bisa menggunakan materialized views untuk dashboard untuk memprekomputasi sejumlah kecil angka yang sering dibaca.

Berikut set prekomputasi praktis untuk tampilan ops ini:

• Jumlah order per jam untuk 7 hari terakhir (di-grup per jam)
• Pendapatan harian dan refund harian untuk 90 hari terakhir
• Hasil pembayaran (sukses, gagal, pending) per bucket 5 menit untuk 24 jam terakhir
• Produk teratas berdasarkan unit terjual untuk "hari ini" dan "7 hari terakhir"

Campuran itu menjaga tile tetap cepat, sambil memungkinkan drill-down ke order mentah hanya ketika seseorang membuka layar detail.

Rencana refresh sesuai cara orang menggunakan dashboard. Data terbaru diperiksa terus, sementara history lama bisa "cukup baik" jika diperbarui lebih jarang.

Jadwal refresh sederhana bisa seperti ini:

• 24 jam terakhir: refresh setiap 1–2 menit
• 7 hari terakhir: refresh setiap 10–15 menit
• Riwayat lama: refresh per jam atau semalaman
• Top products: refresh setiap 2–5 menit selama jam kerja

Data usang ditangani dengan aturan jelas, bukan tebak-tebak. Setiap tile kunci menampilkan timestamp "data updated". Jika timestamp lebih lama dari 10 menit untuk tile kritikal (orders per jam, sukses pembayaran), dashboard beralih ke state peringatan dan memicu alert ke channel on-call.

Saat spike lalu lintas, pengalaman tetap cepat karena dashboard sebagian besar membaca tabel kecil yang sudah disiapkan daripada memindai seluruh riwayat orders dan payments. Jika Anda membangun UI dashboard di alat seperti AppMaster (dengan PostgreSQL di belakang), ini juga menjaga respons API dapat diprediksi sehingga halaman tetap terasa responsif ketika semua orang me-refresh sekaligus.

Langkah selanjutnya: implementasi, ukur, dan iterasi

Mulailah dari yang paling menyakitkan, bukan yang terlihat elegan. Ambil kueri dashboard paling lambat Anda (dari log, APM, atau statistik database) dan kelompokkan menurut pola: join yang sama, filter yang sama, jendela waktu yang sama, agregasi yang sama. Ini mengubah daftar panjang keluhan menjadi daftar pendek bentuk kueri yang bisa dioptimalkan.

Lalu pilih satu atau dua perubahan yang akan berdampak minggu ini. Untuk kebanyakan tim, itu berarti membuat materialized views yang menutupi 1–2 pola kueri teratas, bukan setiap chart yang mungkin ditambahkan nanti.

Langkah praktis pertama:

• Tuliskan 5 kueri paling lambat dan apa yang masing-masing coba jawab
• Gabungkan yang tumpang tindih menjadi 1–2 candidate view
• Tentukan target kesegaran (misalnya, "boleh sampai 5 menit")
• Tambahkan index yang benar-benar dipakai filter dashboard Anda
• Roll out di balik feature flag sederhana atau toggle "new query path"

Setelah dirilis, anggap refresh sebagai bagian dari produk, bukan detail latar belakang. Tambahkan monitoring yang menjawab tiga pertanyaan: apakah refresh berjalan, berapa lama, dan seberapa tua data sekarang? Juga catat kegagalan refresh dengan jelas. Kegagalan senyap adalah bagaimana "cukup segar" perlahan berubah jadi "salah."

Pertahankan satu kebiasaan kecil: setiap kali menambah widget baru, putuskan apakah ia bisa menggunakan view yang ada, perlu view baru, atau harus real-time. Jika perlu view baru, mulai dengan versi terkecil yang memenuhi pertanyaan dashboard.

Jika Anda ingin mengirim aplikasi dashboard dengan cepat, AppMaster dapat membantu: Anda bisa membangun web app dan menghubungkannya ke PostgreSQL, lalu mengubah layar, filter, dan logika saat kebutuhan berubah tanpa menulis ulang semuanya. Itu membuat iterasi murah, yang penting karena potongan pertama prekomputasi dan strategi refresh Anda jarang yang terakhir.