Có cần Redis không? Khi PostgreSQL cung cấp hàng đợi, khóa và cả chức năng pub/sub (2021)

 (spin.atomicobject.com)
2 điểm bởi GN⁺ 2024-11-04 | 1 bình luận | Chia sẻ qua WhatsApp

  • Trường hợp sử dụng 1: Xếp hàng công việc

    • Redis thường được dùng để điều phối các tác vụ nền trong dịch vụ web.
    • Từ PostgreSQL phiên bản 9.5, có thể triển khai xếp hàng công việc bằng tùy chọn SKIP LOCKED.
    • Tùy chọn này cho phép chọn công việc mà không phải chờ khóa, giúp đảm bảo nhiều worker không xử lý cùng một công việc cùng lúc.

  • Trường hợp sử dụng 2: Khóa ứng dụng

    • Redis thường được dùng cho khóa phân tán.
    • Có thể triển khai cùng chức năng đó bằng advisory lock của PostgreSQL.
    • Advisory lock cho phép tận dụng bộ máy khóa nội bộ của PostgreSQL cho các mục đích do ứng dụng định nghĩa.

  • Trường hợp sử dụng 3: Pub/Sub

    • Redis được dùng để đẩy sự kiện tới các client đang hoạt động.
    • Từ PostgreSQL phiên bản 9, có thể cung cấp chức năng Pub/Sub bằng các câu lệnh LISTEN và NOTIFY.
    • Client PostgreSQL có thể đăng ký một kênh thông điệp cụ thể, và khi client khác gửi thông điệp vào kênh đó, mọi bên đăng ký đều sẽ nhận được thông báo.

  • Khai thác PostgreSQL một cách trọn vẹn

    • Redis được dùng cho các mục đích khác với PostgreSQL và rất mạnh ở việc cache dữ liệu có TTL cũng như lưu trữ dữ liệu tạm thời.
    • PostgreSQL cung cấp nhiều hơn một cơ sở dữ liệu SQL, và có khả năng thay thế bằng PostgreSQL cho một số tác vụ vốn đang dùng Redis.
    • Đây có thể là một lựa chọn đáng cân nhắc để giảm độ phức tạp khi vận hành nhiều dịch vụ dữ liệu và cắt giảm chi phí vận hành.

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-11-04
Ý kiến Hacker News

  • Redis cung cấp tốc độ phản hồi rất nhanh khi chạy trên cùng máy với ứng dụng. Điều này cho phép làm những việc khác với Postgres

    • Kho lưu trữ khóa-giá trị trong bộ nhớ phù hợp với các tác vụ cần đặc tính hiệu năng của RAM
    • Rõ ràng là không thể có được hiệu năng của RAM thông qua kết nối mạng

  • PostgreSQL cung cấp nhiều hơn một cơ sở dữ liệu SQL đơn thuần

    • Nếu chỉ dùng cơ sở dữ liệu phía sau ORM, bạn có thể bỏ lỡ nhiều tính năng
    • Thay vì thêm một dịch vụ như Redis, có thể tốt hơn là tận dụng cơ sở dữ liệu đã được thiết lập sẵn

  • PGQueuer là một lựa chọn thay thế tối giản dùng PostgreSQL để cung cấp hàng đợi công việc, khóa và thông báo thời gian thực

    • Giảm nhu cầu phải dùng Redis

  • Postgres là một cơ sở dữ liệu mạnh mẽ

    • Redis có rào cản sử dụng thấp, hiệu năng cao và giúp giảm tải cho cơ sở dữ liệu chính
    • Có thể cache phản hồi API bằng Postgres, nhưng dùng Redis đơn giản hơn
    • Việc dùng một hệ thống riêng là một nhược điểm, nhưng với Redis thì nhược điểm đó không lớn

  • Phần lớn dự án chỉ cần một hàng đợi công việc đơn giản, và điều quan trọng là đơn giản hóa stack phức tạp

    • Có nhiều lựa chọn thay thế khác nhau với các lợi ích thương mại khác nhau

  • Postgres có một số hạn chế

    • Có thể giải quyết các chức năng như KV store, hàng đợi, pub/sub, khóa, v.v., nhưng không hề đơn giản

  • Nên bắt đầu với PostgreSQL và chuyển sang Redis khi cần

    • Điều quan trọng là giảm thiểu số lượng thành phần phải vận hành

  • Nhược điểm lớn của pub/sub trong Postgres là kích thước thông điệp bị giới hạn ở 8000 byte

    • Có thể lưu dữ liệu trong cơ sở dữ liệu rồi gửi ID, nhưng cách này đòi hỏi thêm công việc

  • Caching, một trong những ứng dụng quan trọng nhất của Redis, phức tạp hơn trong Postgres

    • Cập nhật trong Postgres tốn kém hơn chèn, và đảm bảo độ bền không quan trọng đối với caching

  • Khi dùng các chức năng này trong Postgres, việc cập nhật và sao chép cũng trở nên khó hơn

    • Vẫn làm được, nhưng tôi thích tập trung vào những tính năng được dùng rộng rãi hơn của Postgres