PgDog đang nổi lên như một giải pháp thay thế PgBouncer với tính năng sharding và load balancing cực xịn. Liệu có đáng để anh em xuống tiền hay đổi tech stack?
Đang yên đang lành chạy con PostgreSQL ngon nghẻ, đùng cái user ập vào, RAM tăng vọt, connection nghẽn cổ chai rồi sập server. Anh em vội vàng đi tìm cứu tinh thì thường nghe các bô lão chỉ đường tìm đến PgBouncer. Nhưng thời thế thế thời, hôm nay trên bàn nhậu của Coding4Food, tôi xin giới thiệu một tân binh đang muốn "khóa mõm" PgBouncer: PgDog.
Quảng cáo thì lúc nào chả hay: "Scale PostgreSQL mà không cần sửa code". Nghe sặc mùi lùa gà đúng không? Nhưng khoan vội quay xe, hãy cùng tôi bóc tách xem chú chó này có gì thực chiến hay chỉ là một cú úp bô công nghệ mới.
Để tôi tóm tắt nhanh cho anh em lười đọc tài liệu dài dòng. Về cơ bản, PgDog là một bộ ba phối hợp: Connection Pooler, Load Balancer, và Sharding Proxy nguồn mở dành riêng cho PostgreSQL. Nó được viết ra để giải quyết ba nỗi đau chí mạng của dân làm database:
Đặc biệt, đội ngũ phát triển tự tin tuyên bố con hàng này đã chạy trên production hơn một năm nay, gánh nhẹ nhàng 2 triệu query mỗi giây (2M qps) trên hàng chục cụm deploy khác nhau. Con số này đủ làm mấy anh em hay lo bò trắng răng phải im lặng gật gù.
Cộng đồng dev sau khi hít hà quả thông số 2M qps thì bắt đầu nhảy vào hỏi xoáy đáp xoay cực kỳ gắt gao. Có mấy luồng ý kiến đáng chú ý thế này:
Một đạo hữu chia sẻ đã lẳng lặng đem PgDog về ném sau cụm staging từ tuần trước. Kết quả là latency dưới tải nặng ổn định hơn hẳn so với PgBouncer già cỗi. Điểm cộng cực lớn là nó nói chuyện trực tiếp bằng giao thức của Postgres, setup cực kỳ trực quan và hiện đại.
Một cao nhân đặt câu hỏi chí mạng: "Với mô hình sharding, khi cần chạy ALTER TABLE để migrate schema, PgDog tự điều phối trên tất cả các shard một cách atomic (đồng bộ) hay việc này vẫn đổ lên đầu DBA?"
Dev của PgDog nhảy vào rep ngay: Họ sử dụng cơ chế Two-phase commit để đảm bảo quá trình migrate schema diễn ra an toàn, không bị lệch pha giữa các shard.
Nhiều ông sợ rằng nhét thêm một con Proxy ở giữa, nhỡ con Proxy đó tèo thì cả hệ thống đi tong.
Câu trả lời từ phía tác giả rất ma giáo nhưng hợp lý: PgDog được thiết kế chạy theo cụm nhiều instance độc lập, quản lý hoàn toàn bằng file config và không cần nói chuyện với nhau. Nhờ vậy, kiến trúc HA (High Availability) trở nên cực kỳ đơn giản và sạch sẽ. Tuy nhiên, có một cú "quay xe" nhẹ ở đây: Tính năng đồng bộ tự động cấu hình sharding map giữa các instance chỉ có trên bản Enterprise (trả tiền). Bản Community thì anh em tự đi mà sync nhé!
Một thanh niên đang chạy SaaS trên Neon (Serverless Postgres) than thở về việc connection limit nhảy loạn xạ khi chạy Next.js + Prisma. Tác giả khẳng định luôn: PgDog sinh ra để trị mấy ca này. Nó sẽ gom và tối ưu connection tối đa, anh em quăng nó lên một con cloud vps đứng trước db serverless là ngon ngay.
Tóm cái váy lại, PgBouncer giống như một ông bảo vệ già trung thành, tuy cổ điển, ít tính năng nhưng chạy trâu bò qua năm tháng. Còn PgDog là một chú chó nghiệp vụ thế hệ mới, đa tài hơn (ôm luôn cả Load Balancing lẫn Sharding).
Bài học sinh tồn cho anh em dev ở đây là gì?
Chúc anh em không bị sập DB đêm nay!
Nguồn: Product Hunt
