Bagaimanakah materialized view berfungsi dalam PostgreSQL?

Question

Accepted Answer

Sebuah **materialized view** menyimpan *hasil* sesuatu query secara fizikal (dikira terlebih dahulu), berbeza dengan view biasa (yang menjalankan semula query-nya setiap kali). Ini menjadikan bacaan pantas untuk query yang mahal, dengan kos bahawa data hanya sesegar **refresh** terakhir — satu mekanisme caching di dalam pangkalan data.

## View biasa vs materialized view

```sql
-- regular VIEW — runs the query EVERY time (always fresh, but recomputed)
CREATE VIEW sales_summary AS SELECT region, SUM(amount) FROM orders GROUP BY region;

-- MATERIALIZED VIEW — stores the RESULTS physically (fast reads, but can be stale)
CREATE MATERIALIZED VIEW sales_summary_mat AS
SELECT region, SUM(amount) AS total FROM orders GROUP BY region;

SELECT * FROM sales_summary_mat;     -- reads STORED results — fast (no recompute)
```

Sebuah materialized view mengira dan menyimpan hasil terlebih dahulu, jadi membuat query terhadapnya adalah pantas (seperti membaca jadual) — sesuai untuk pengagregatan mahal yang kerap diquery.

## Refresh (mengemas kini data yang disimpan)

```sql
-- the data is stale until you refresh it
REFRESH MATERIALIZED VIEW sales_summary_mat;          -- recompute (locks reads during refresh)

-- CONCURRENTLY — refresh WITHOUT blocking reads (requires a unique index)
CREATE UNIQUE INDEX idx_sales_region ON sales_summary_mat(region);
REFRESH MATERIALIZED VIEW CONCURRENTLY sales_summary_mat;   -- reads continue during refresh
```

Anda mesti **refresh** untuk mengemas kini data. `REFRESH ... CONCURRENTLY` (memerlukan unique index) mengemas kini tanpa menyekat bacaan serentak — penting untuk production.

## Bila hendak menggunakan materialized view

```text
✓ EXPENSIVE queries (complex aggregations, joins) queried FREQUENTLY
✓ Data that doesn't need real-time freshness (dashboards, reports, analytics)
✓ Reducing load from repeatedly running the same heavy query
→ Refresh on a schedule (cron / pg_cron) or after data changes.

✗ Data needing real-time accuracy → use a regular view or query directly
```

## Pertukaran (trade-off)

```text
Fast reads (precomputed) ⟷ Stale data (until refreshed) + storage cost.
You trade freshness and storage for read speed — a caching decision.
You can also index a materialized view (it's a physical table of results).
```

## Mengapa ia penting

Materialized view ialah ciri PostgreSQL yang berharga untuk **pengoptimuman prestasi** — ia menyediakan mekanisme caching dalam pangkalan data untuk query yang mahal, jadi memahaminya berguna untuk mengoptimumkan aplikasi dengan query yang mahal dan kerap dijalankan.

Nilai terasnya ialah mengira dan menyimpan terlebih dahulu hasil query yang mahal (pengagregatan kompleks, join berat) supaya membacanya adalah pantas (seperti membuat query pada jadual) dan bukannya menjalankan semula query mahal itu setiap kali — yang merupakan pengoptimuman ketara untuk dashboard, laporan, dan analitik di mana query berat yang sama dijalankan berulang kali.

Memahami **trade-off** utama adalah penting: materialized view memberikan bacaan pantas tetapi datanya **basi (stale)** sehingga di-refresh (dan ia memerlukan kos storan), jadi ia merupakan keputusan caching yang sesuai untuk data yang tidak memerlukan kesegaran masa nyata.

Mengetahui cara **refresh** mereka — terutamanya `REFRESH ... CONCURRENTLY` (yang mengemas kini tanpa menyekat bacaan, penting untuk ketersediaan production, memerlukan unique index) — dan strategi refresh (mengikut jadual melalui cron/pg_cron, atau selepas data berubah) adalah pengetahuan praktikal untuk menggunakannya dengan berkesan.

Memahami **bila hendak menggunakan** materialized view (query yang mahal dan kerap dijalankan yang boleh menerima sedikit kebasian — dashboard, analitik) berbanding bila tidak (data yang memerlukan ketepatan masa nyata) mencerminkan pertimbangan yang baik.

Memandangkan query berulang yang mahal merupakan kebimbangan prestasi sebenar, dan memandangkan materialized view menyediakan penyelesaian caching dalam pangkalan data yang berkesan (hasil yang dikira terlebih dahulu, boleh diindeks) dengan trade-off kesegaran/kelajuan yang jelas, memahaminya — cara ia berfungsi, refresh (terutamanya secara concurrent), trade-off, dan penggunaan yang sesuai — ialah pengetahuan PostgreSQL yang berharga dan relevan secara praktikal untuk mengoptimumkan prestasi query analitik dan pelaporan, satu keperluan biasa di mana materialized view menawarkan penyelesaian terbina dalam yang kemas.