Một cuộc thảo luận gần đây trong cộng đồng nhà phát triển đã làm nổi bật những hạn chế đáng kể của materialized views trong PostgreSQL, gây ra tranh luận về nhu cầu bảo trì view tăng dần thực sự tự động trong cơ sở dữ liệu. Cuộc trò chuyện tập trung vào khoảng cách giữa những gì các nhà phát triển mong đợi từ materialized views và những gì các triển khai hiện tại thực sự cung cấp.
Vấn đề làm mới thủ công của PostgreSQL
Vấn đề cốt lõi với materialized views của PostgreSQL là chúng yêu cầu làm mới thủ công bằng cách sử dụng lệnh REFRESH MATERIALIZED VIEW. Không giống như phiên bản lý tưởng được mô tả trong nhiều hướng dẫn, những view này không tự động giữ đồng bộ với dữ liệu cơ bản của chúng. Điều này khiến chúng giống như một cơ chế caching tinh vi hơn là giải pháp kỳ diệu luôn cập nhật mà nhiều nhà phát triển mong đợi.
Tình huống trở nên có vấn đề hơn khi xử lý các tập dữ liệu lớn. Làm mới một materialized view trong PostgreSQL yêu cầu xây dựng lại toàn bộ view, điều này có thể tốn nhiều tài nguyên và có khả năng gây gián đoạn cho các hệ thống production. Cách tiếp cận tất cả hoặc không có gì này có nghĩa là bạn không thể cập nhật có chọn lọc các phần của view, dẫn đến các nút thắt hiệu suất tiềm ẩn.
Các Extension PostgreSQL cho Incremental Views
- pg_ivm: Extension của bên thứ ba bổ sung tính năng incremental view maintenance cho PostgreSQL
- Không khả dụng trên Amazon RDS
- Cung cấp cập nhật tự động nhưng yêu cầu cài đặt và cấu hình thủ công
Các giải pháp bên thứ ba lấp đầy khoảng trống
Một số công ty đã xuất hiện để giải quyết hạn chế này, cung cấp khả năng bảo trì view tăng dần thực sự. Materialize, ReadySet, Feldera, RisingWave và DeltaStream là những startup cung cấp giải pháp có thể tự động giữ materialized views đồng bộ với dữ liệu nguồn của chúng. Các nền tảng này sử dụng các kỹ thuật như differential dataflow và incremental view maintenance để đạt được những gì mà các cơ sở dữ liệu truyền thống gặp khó khăn.
Materialized views trong ScyllaDB được biết đến (đã từng?) là một triển khai có nhiều lỗi. Đặc biệt, chúng thường phụ thuộc vào việc cluster khỏe mạnh tại thời điểm truyền bá các thay đổi.
Các Công ty Cung cấp Bảo trì Tăng dần cho View
- Materialize: Cơ sở dữ liệu streaming chuyên biệt với cập nhật view tự động
- ReadySet: Lớp cache SQL với bảo trì tăng dần
- Feldera: Nền tảng dựa trên DBSP với độ phức tạp cập nhật O(1)
- RisingWave: Cơ sở dữ liệu streaming cho phân tích thời gian thực
- DeltaStream: Xử lý luồng với materialized views
- Confluent: Nền tảng streaming dựa trên Kafka với khả năng view
Các nhà cung cấp cơ sở dữ liệu đang bắt kịp
Trong khi PostgreSQL tụt lại phía sau, các hệ thống cơ sở dữ liệu khác cung cấp các triển khai materialized view tốt hơn. Microsoft SQL Server cung cấp indexed views cập nhật đồng bộ với các bảng cơ bản, mặc dù điều này đi kèm với các tác động hiệu suất trong các hoạt động ghi. Oracle cung cấp cả tùy chọn rebuild đầy đủ và tăng dần, với các phiên bản gần đây bổ sung khả năng refresh đồng thời.
Các nhà cung cấp cloud cũng đang tiến bộ trong lĩnh vực này. Materialized views của BigQuery cho phép điều chỉnh các tham số độ tươi và có thể tự động viết lại các truy vấn để sử dụng các aggregate được tính toán trước. Tuy nhiên, những tính năng tiên tiến này thường đi kèm với các cân nhắc về vendor lock-in.
So sánh Cơ sở dữ liệu cho Materialized Views
| Cơ sở dữ liệu | Tự động cập nhật | Làm mới tăng dần | Sẵn sàng sản xuất |
|---|---|---|---|
| PostgreSQL | Không | Chỉ qua Extension | Có |
| MySQL | Không | Không | Có |
| SQL Server | Có (Indexed Views) | Có | Có |
| Oracle | Tùy chọn | Có | Có |
| BigQuery | Có | Có | Có |
| ScyllaDB | Có (có lỗi) | Có | Hạn chế |
Sự đánh đổi giữa hiệu suất và độ phức tạp
Cuộc thảo luận tiết lộ một căng thẳng cơ bản trong thiết kế cơ sở dữ liệu. Các truy vấn đếm đơn giản hoạt động hoàn hảo với indexing thích hợp thường được over-engineer thành các giải pháp caching phức tạp. Nhiều nhà phát triển chỉ ra rằng đối với các trường hợp sử dụng điển hình liên quan đến hàng nghìn thay vì hàng triệu bản ghi, một truy vấn COUNT(*) được index tốt hoạt động đầy đủ mà không có độ phức tạp của materialized views.
Giá trị thực sự của materialized views xuất hiện với các truy vấn phân tích phức tạp hơn liên quan đến nhiều join, aggregation và transformation. Những kịch bản này hưởng lợi đáng kể từ các kết quả được tính toán trước, đặc biệt trong các ứng dụng data warehousing và báo cáo.
Sự phát triển đang diễn ra trong không gian này cho thấy rằng bảo trì view tăng dần tự động có thể sẽ trở thành một tính năng tiêu chuẩn trong các hệ thống cơ sở dữ liệu tương lai. Cho đến lúc đó, các nhà phát triển phải cân nhắc cẩn thận sự đánh đổi giữa hiệu suất truy vấn, độ tươi của dữ liệu và độ phức tạp của hệ thống khi chọn cách tiếp cận quản lý dữ liệu dẫn xuất.
Tham khảo: Materialized views are obviously useful