Cứ dùng Postgres ở mọi nơi

 (amazingcto.com)
50 điểm bởi xguru 2022-12-13 | 13 bình luận | Chia sẻ qua WhatsApp
  • Postgres có thể thay thế rất nhiều công nghệ backend (lên tới hàng triệu người dùng)
    → Kafka, RabbitMQ, Mongo, Redis,..
  • Với cache, thay vì Redis thì dùng bảng UNLOGGED và TEXT ở dạng JSON
    • Đặt thời gian hết hạn cho dữ liệu bằng stored procedure
  • Hàng đợi thông điệp (Kafka): SKIP LOCKED
  • Kho dữ liệu dùng Postgres + TimescaleDB
  • Thay vì Mongo, lưu trữ JSONB rồi tìm kiếm và lập chỉ mục
  • Dùng pg_cron như một daemon CRON cho các tác vụ như gửi email
  • Dùng cho truy vấn không gian địa lý
  • Thay vì Elastic, dùng cho tìm kiếm full-text
  • Tạo JSON ngay trong DB để chuyển thẳng tới API mà không cần code phía server
  • Cũng hỗ trợ GraphQL thông qua adapter GraphQL

Bài viết liên quan

13 bình luận

 
bbulbum 2022-12-15

Ừm... có vẻ ý chính là nếu không cần nhiều tính năng hơn mà từng ứng dụng hỗ trợ, thì với các khái niệm cơ bản, Postgres là đủ.
Vì mỗi ứng dụng đều có thể dùng được nhiều tính năng hơn so với luồng đang được thay thế ở phía trên.
 
colossus 2022-12-14

Tôi nghĩ đây không hẳn là một ý kiến quá vô lý nếu thiết kế interface đủ tốt và dùng đúng cách. Tuy vậy, tôi vẫn thấy cứ giao phần cache/message queue cho Redis thì cũng ổn.
 
gninggoon 2022-12-14

Gần đây tôi cũng có suy nghĩ tương tự như bài viết ở trên. Tất nhiên, với các dịch vụ quy mô lớn thì tốt nhất là phân tán tối đa để phân tán rủi ro, nhưng khi thỉnh thoảng làm các dự án outsource nhỏ, nếu không dùng NoSQL riêng mà tận dụng kiểu jsonb của Postgres thì tính ứng dụng cao hơn hẳn. Nó mang lại trải nghiệm sử dụng như đang kết hợp cả RDB + NoSQL, và trong các dự án nhỏ thì hiệu năng cũng hoàn toàn đủ dùng.
 
a9t84j1k5j2j1 2022-12-13

Cứ làm mọi thứ bằng một thứ thì mọi điểm rủi ro cũng dồn về một chỗ..!
 
ehlegeth 2022-12-13

Một số việc này thực ra đúng là từng được làm bằng RDB hồi chưa có sản phẩm thay thế, nhưng những thứ như Redis, Kafka hay Cron dường như không thể thay thế được các lợi thế cốt lõi của chúng. Có vẻ đây chỉ là một ý tưởng để xem cho vui rồi bỏ qua thôi.
 
ifmkl 2022-12-13

Có vẻ sẽ rất hợp với những ai thích dùng một thứ để làm mọi việc.
 
s0400615 2022-12-13

Trước đây tôi dùng Postgres vì Geospatial.
So với các DB khác, nó nhanh hơn khoảng 10~100 lần.. mảng geo thì thực sự áp đảo.

Nhưng như mọi người đều biết, khi dữ liệu tăng nhiều mà vacuum chạy sai thì sẽ nếm trải địa ngục..
 
kbumsik 2022-12-13

Ồ, có khá nhiều mẹo nhỉ

Tuy vậy, riêng tổ hợp UNLOGGED và stored procedure đầu tiên thì có lẽ dùng Redis sẽ gọn gàng hơn nhiều ấy haha
 
youknowone 2022-12-13

Cũng là chuyện vài năm trước, nhưng tôi từng làm theo kiểu khi dùng JSONB mà tải bắt đầu tăng mạnh thì chọn giải pháp phù hợp với mẫu kv rồi tách sang Redis, và đó là một trải nghiệm khá dễ chịu.
 
sangheon 2022-12-13

Ý kiến khá thú vị.
 
xguru 2022-12-13

Tiêu đề có phần giật gân, nhưng đây cũng là một chủ đề đáng để suy nghĩ nên tôi giữ nguyên khi chuyển lại.
Vì khi làm MVP giai đoạn đầu, việc đưa vào quá nhiều thành phần cũng đúng là một vấn đề.
 
jujumilk3 2022-12-13

Có vẻ là một ý tưởng hay.
 
devo209 2022-12-20

Cảm ơn.