Materialized view hoạt động như thế nào trong PostgreSQL?

Question

Accepted Answer

Một **materialized view** lưu trữ *kết quả* của một truy vấn một cách vật lý (đã tính toán trước), khác với một view thông thường (vốn chạy lại truy vấn của nó mỗi lần). Điều này giúp việc đọc các truy vấn tốn kém trở nên nhanh, đổi lại dữ liệu chỉ mới đến mức của lần **refresh** gần nhất — một cơ chế caching ngay trong database.

## View thông thường so với materialized view

```sql
-- VIEW thông thường — chạy truy vấn MỖI lần (luôn mới, nhưng phải tính lại)
CREATE VIEW sales_summary AS SELECT region, SUM(amount) FROM orders GROUP BY region;

-- MATERIALIZED VIEW — lưu KẾT QUẢ một cách vật lý (đọc nhanh, nhưng có thể cũ)
CREATE MATERIALIZED VIEW sales_summary_mat AS
SELECT region, SUM(amount) AS total FROM orders GROUP BY region;

SELECT * FROM sales_summary_mat;     -- đọc kết quả ĐÃ LƯU — nhanh (không tính lại)
```

Một materialized view tính toán trước và lưu kết quả, nên truy vấn nó rất nhanh (như đọc một bảng) — lý tưởng cho các phép tổng hợp tốn kém được truy vấn thường xuyên.

## Refresh (cập nhật dữ liệu đã lưu)

```sql
-- dữ liệu sẽ cũ cho đến khi bạn refresh nó
REFRESH MATERIALIZED VIEW sales_summary_mat;          -- tính lại (khóa việc đọc trong lúc refresh)

-- CONCURRENTLY — refresh mà KHÔNG chặn việc đọc (cần một unique index)
CREATE UNIQUE INDEX idx_sales_region ON sales_summary_mat(region);
REFRESH MATERIALIZED VIEW CONCURRENTLY sales_summary_mat;   -- việc đọc tiếp tục trong lúc refresh
```

Bạn phải **refresh** để cập nhật dữ liệu. `REFRESH ... CONCURRENTLY` (cần một unique index) cập nhật mà không chặn các thao tác đọc đồng thời — quan trọng cho môi trường production.

## Khi nào nên dùng materialized view

```text
✓ Các truy vấn TỐN KÉM (tổng hợp phức tạp, join) được truy vấn THƯỜNG XUYÊN
✓ Dữ liệu không cần độ mới thời gian thực (dashboard, báo cáo, analytics)
✓ Giảm tải từ việc lặp đi lặp lại cùng một truy vấn nặng
→ Refresh theo lịch (cron / pg_cron) hoặc sau khi dữ liệu thay đổi.

✗ Dữ liệu cần độ chính xác thời gian thực → dùng view thông thường hoặc truy vấn trực tiếp
```

## Sự đánh đổi

```text
Đọc nhanh (đã tính trước) ⟷ Dữ liệu cũ (cho đến khi refresh) + chi phí lưu trữ.
Bạn đánh đổi độ mới và dung lượng lưu trữ để lấy tốc độ đọc — một quyết định caching.
Bạn cũng có thể đánh index một materialized view (nó là một bảng vật lý chứa kết quả).
```

## Tại sao điều này quan trọng

Materialized view là một tính năng giá trị của PostgreSQL cho **tối ưu hiệu năng** — chúng cung cấp một cơ chế caching ngay trong database cho các truy vấn tốn kém, nên hiểu chúng là hữu ích để tối ưu các ứng dụng có các truy vấn tốn kém, chạy thường xuyên.

Giá trị cốt lõi là tính toán trước và lưu kết quả của các truy vấn tốn kém (tổng hợp phức tạp, join nặng) để việc đọc chúng nhanh (như truy vấn một bảng) thay vì chạy lại truy vấn tốn kém mỗi lần — đây là một tối ưu đáng kể cho dashboard, báo cáo, và analytics nơi cùng một truy vấn nặng chạy đi chạy lại.

Hiểu **sự đánh đổi** then chốt là quan trọng: materialized view cho việc đọc nhanh nhưng dữ liệu sẽ **cũ** cho đến khi refresh (và chúng tốn dung lượng lưu trữ), nên chúng là một quyết định caching phù hợp cho dữ liệu không cần độ mới thời gian thực.

Biết cách **refresh** chúng — đặc biệt là `REFRESH ... CONCURRENTLY` (vốn cập nhật mà không chặn việc đọc, quan trọng cho khả năng sẵn sàng trong production, cần một unique index) — và các chiến lược refresh (theo lịch qua cron/pg_cron, hoặc sau khi dữ liệu thay đổi) là kiến thức thực tiễn để dùng chúng hiệu quả.

Hiểu **khi nào nên dùng** materialized view (các truy vấn tốn kém, chạy thường xuyên, chấp nhận được độ cũ nhẹ — dashboard, analytics) so với khi nào không nên (dữ liệu cần độ chính xác thời gian thực) phản ánh khả năng phán đoán tốt.

Vì các truy vấn lặp đi lặp lại tốn kém là một mối lo hiệu năng thực tế, và vì materialized view cung cấp một giải pháp caching hiệu quả ngay trong database (kết quả đã tính trước, có thể đánh index) với sự đánh đổi rõ ràng giữa độ mới/tốc độ, hiểu chúng — cách chúng hoạt động, việc refresh (đặc biệt là concurrently), sự đánh đổi, và việc sử dụng phù hợp — là kiến thức giá trị, thực tiễn của PostgreSQL để tối ưu hiệu năng của các truy vấn phân tích và báo cáo, một nhu cầu phổ biến nơi materialized view cung cấp một giải pháp gọn gàng, tích hợp sẵn.