Một bài benchmark gần đây so sánh PostgreSQL và Redis cho việc caching đã gây ra nhiều thảo luận trong cộng đồng developer, với kết quả cho thấy PostgreSQL đạt được khoảng hai phần ba hiệu suất của Redis trong khi đặt ra câu hỏi về chính phương pháp kiểm tra.
Nghiên cứu ban đầu đã kiểm tra cả hai cơ sở dữ liệu bằng cách sử dụng các cluster Kubernetes với giới hạn tài nguyên cụ thể, phát hiện Redis luôn vượt trội hơn PostgreSQL trên các workload khác nhau. Tuy nhiên, bài benchmark đã nhận được những chỉ trích gay gắt từ cộng đồng kỹ thuật về phương pháp tiếp cận và kết luận của nó.
Kết quả So sánh Hiệu suất
| Loại Benchmark | Redis (req/giây) | PostgreSQL (req/giây) | Ưu thế của Redis |
|---|---|---|---|
| Thao tác GET | 2,327 | 1,686 | Nhanh hơn 38% |
| Thao tác SET | 2,586 | 1,453 | Nhanh hơn 78% |
| Khối lượng công việc hỗn hợp | 2,377 | 1,497 | Nhanh hơn 59% |
Cấu hình Kiểm thử:
- Phần cứng: Giới hạn 20 lõi CPU , phân bổ bộ nhớ cao
- Phiên bản cơ sở dữ liệu: PostgreSQL 15 , Redis 7
- Bộ dữ liệu: 10 triệu mục
- Thời gian kiểm thử: 1 phút cho mỗi benchmark
- Tỷ lệ cache hit: 80% cho thao tác GET , tỷ lệ cập nhật 10% cho thao tác SET
Phương pháp kiểm tra có lỗ hổng làm suy yếu kết quả
Tính hợp lệ của bài benchmark đã bị cộng đồng developer xem xét kỹ lưỡng và chỉ ra những vấn đề cơ bản với thiết lập kiểm tra. Các nhà phê bình nhấn mạnh rằng PostgreSQL bị giới hạn bởi CPU ở mức sử dụng 100% trên các core được phân bổ, trong khi Redis bị nghẽn cổ chai bởi HTTP server chứ không phải bởi chính cơ sở dữ liệu. Điều này có nghĩa là việc so sánh không đo lường được tiềm năng hiệu suất thực sự của cả hai hệ thống trong điều kiện công bằng.
Phương pháp kiểm tra cũng không sử dụng các kỹ thuật tối ưu hóa hiệu suất có sẵn cho cả hai hệ thống. Đối với Redis, các tính năng như pipelining và auto-pipelining client có thể mang lại cải thiện hiệu suất lên đến 10 lần. PostgreSQL cũng tương tự hỗ trợ query pipelining thông qua các thư viện client phổ biến, điều này không được khám phá trong bài benchmark.
Mức Độ Sử Dụng Tài Nguyên Trong Quá Trình Kiểm Thử
Hiệu Suất Redis:
- Sử dụng CPU: ~1,200-1,280 mCPU (thấp hơn nhiều so với giới hạn 2,000 mCPU)
- Sử dụng bộ nhớ: 3,800-4,300 MB
- Điểm nghẽn: HTTP server, không phải bản thân Redis
Hiệu Suất PostgreSQL:
- Sử dụng CPU: 100% trên 2 lõi được phân bổ (giới hạn 2,000 mCPU)
- Sử dụng bộ nhớ: 5,000-6,000 MB
- Điểm nghẽn: Mức sử dụng CPU của cơ sở dữ liệu
Phát Hiện Quan Trọng: PostgreSQL bị giới hạn bởi CPU trong khi Redis bị giới hạn bởi HTTP server, khiến việc so sánh hiệu suất có thể gây hiểu lầm.
Câu hỏi về hiệu suất thực tế
Ngoài những lo ngại về phương pháp, cuộc tranh luận trong cộng đồng còn tiết lộ những câu hỏi sâu sắc hơn về nhu cầu hiệu suất thực tế. Bài benchmark cho thấy PostgreSQL xử lý khoảng 1,500 request mỗi giây, tương đương với hơn nửa tỷ request mỗi ngày. Đối với hầu hết các ứng dụng, mức hiệu suất này vượt xa các yêu cầu thực tế.
Nhiều developer cho rằng việc lựa chọn giữa Redis và PostgreSQL cho caching không nên dựa hoàn toàn vào các con số hiệu suất thô. Quyết định thường phụ thuộc vào độ phức tạp vận hành, hạ tầng hiện có, và liệu sự khác biệt về hiệu suất có thực sự quan trọng đối với trường hợp sử dụng cụ thể hay không.
Đánh đổi vận hành và phụ thuộc
Cuộc thảo luận đã làm nổi bật những cân nhắc vận hành quan trọng mà các benchmark hiệu suất thuần túy bỏ qua. Redis cung cấp các tính năng tích hợp như tự động hết hạn key (TTL) rất cần thiết cho việc caching hiệu quả. Việc triển khai chức năng tương tự trong PostgreSQL đòi hỏi các thành phần bổ sung như cron job và logic hết hạn tùy chỉnh.
Khả năng đặt TTL trên cache key là một tính năng quan trọng của cache, không phải thứ có thể được gắn thêm sau này.
Tuy nhiên, những người ủng hộ phương pháp PostgreSQL cho rằng việc tránh các phụ thuộc bổ sung có thể có giá trị, đặc biệt đối với các dự án nhỏ hơn. Họ chỉ ra rằng hầu hết các ứng dụng đã yêu cầu một cơ sở dữ liệu, vì vậy việc sử dụng PostgreSQL cho caching loại bỏ nhu cầu quản lý một dịch vụ khác. Các cân nhắc về chi phí cũng ủng hộ phương pháp này, vì các instance PostgreSQL thường được sử dụng dưới mức và có thể xử lý workload caching bổ sung mà không cần chi phí thêm.
Các giải pháp thay thế và hướng phát triển tương lai
Cuộc tranh luận cũng đã thu hút sự chú ý đến các giải pháp hybrid như Redka, cung cấp khả năng tương thích API Redis được hỗ trợ bởi SQLite hoặc PostgreSQL. Phương pháp này cố gắng kết hợp giao diện Redis quen thuộc với sự đơn giản vận hành của các cơ sở dữ liệu SQL.
Một số developer đã đề xuất rằng PostgreSQL có thể hưởng lợi từ các tính năng caching native, chẳng hạn như khả năng đánh dấu các cột timestamp làm cột hết hạn sẽ được xử lý tự động bởi quá trình vacuum của cơ sở dữ liệu. Những tính năng như vậy sẽ làm cho PostgreSQL cạnh tranh hơn cho các trường hợp sử dụng caching mà không cần các công cụ bên ngoài.
Cuối cùng, tranh cãi về benchmark phản ánh một căng thẳng rộng lớn hơn trong kiến trúc phần mềm giữa tối ưu hóa hiệu suất và sự đơn giản vận hành. Trong khi Redis rõ ràng cung cấp hiệu suất thô vượt trội cho các workload caching, quyết định thực tế liên quan đến việc cân nhắc lợi thế đó với các yếu tố như độ phức tạp hạ tầng, chi phí và yêu cầu hiệu suất thực tế. Đối với nhiều ứng dụng, hiệu suất đủ tốt của PostgreSQL có thể có giá trị hơn hiệu suất đỉnh cao của Redis, đặc biệt khi xem xét tổng chi phí sở hữu và chi phí vận hành.
Tham khảo: Redis is fast - I'll cache in Postgres