Nỗi đau quản trị: Khi hạ tầng phình to vì quá nhiều Database
Hãy tưởng tượng dự án của bạn đang chạy ngon lành trên PostgreSQL để xử lý các giao dịch tài chính phức tạp. Đột nhiên, team cần thêm một module lưu trữ log hoặc metadata linh hoạt, và thế là MongoDB được kéo vào. Kết quả? Bạn phải vận hành, giám sát và backup hai hệ quản trị cơ sở dữ liệu (DBMS) khác nhau chỉ để phục vụ một vài nhu cầu nhỏ.
Vận hành song song hai ông lớn này ngốn ít nhất 2-4GB RAM cho các instance tối thiểu. Với anh em DevOps, đây là cơn ác mộng khi phải nhân đôi quy trình bảo mật, phân quyền và chiến lược sao lưu. Chưa kể, việc MongoDB chuyển sang giấy phép SSPL khiến bài toán chi phí và tính tự do lâu dài trở nên đau đầu hơn bao giờ hết.
Tại sao chúng ta khó dứt bỏ MongoDB?
Tại sao không dùng jsonb của Postgres ngay từ đầu? Câu trả lời nằm ở MongoDB Driver. Logic code đã gắn chặt với cú pháp NoSQL, việc chuyển đổi sang SQL thuần túy giống như một ca “phẫu thuật tim” cho ứng dụng: cực kỳ tốn thời gian và đầy rủi ro.
Gỡ bỏ MongoDB đồng nghĩa với việc refactor hàng nghìn dòng code. Trong khi đó, PostgreSQL dù xử lý JSON rất tốt nhưng lại không thể giao tiếp bằng ngôn ngữ (wire protocol) mà các ứng dụng MongoDB hiểu được. Chúng ta cần một “thông dịch viên” có thể dịch lệnh từ Mongo sang SQL trong tích tắc.
3 hướng đi phổ biến cho anh em
Để thoát khỏi cảnh này, đa phần chúng ta thường chọn 3 con đường:
- Chấp nhận thực tại: Tiếp tục chạy song song cả hai. Cách này an toàn nhưng cực kỳ ngốn RAM và CPU của server.
- Rewrite toàn bộ: Đập đi xây lại logic dùng
jsonbcủa Postgres. Đây là cách làm sạch nhất nhưng tốn hàng tuần, thậm chí hàng tháng nhân công. - Triển khai FerretDB: Giải pháp trung dung nhưng vô cùng hiệu quả. Bạn giữ nguyên code cũ, vẫn dùng MongoDB Driver nhưng dữ liệu thực tế lại nằm trong PostgreSQL.
FerretDB: Khi PostgreSQL “giả danh” MongoDB
FerretDB (tên cũ là MangoDB) là dự án mã nguồn mở (Apache 2.0) hoạt động như một lớp Proxy. Nó không lưu trữ dữ liệu mà chỉ làm nhiệm vụ chuyển đổi các truy vấn MongoDB sang PostgreSQL SQL.
FerretDB thực chất là cầu nối giúp bạn tận dụng sự linh hoạt của document-oriented database trên nền tảng cực kỳ ổn định của Postgres. Bạn nhận được sự tin cậy tuyệt đối của ACID mà không mất đi cái sướng của việc thao tác JSON linh hoạt.
Cài đặt FerretDB siêu tốc với Docker Compose
Để thử nghiệm, mình sẽ dựng một cụm gồm PostgreSQL 16 và FerretDB đứng chặn phía trước. Chỉ mất khoảng 2 phút để hệ thống sẵn sàng.
version: '3.8'
services:
# Database backend chính
postgres:
image: postgres:16
container_name: postgres
environment:
POSTGRES_USER: ferretuser
POSTGRES_PASSWORD: secretpassword
POSTGRES_DB: ferretdb
ports:
- "5432:5432"
# FerretDB Proxy
ferretdb:
image: ghcr.io/ferretdb/ferretdb:latest
container_name: ferretdb
restart: always
environment:
FERRETDB_POSTGRESQL_URL: "postgres://ferretuser:secretpassword@postgres:5432/ferretdb"
ports:
- "27017:27017" # Cổng chuẩn của MongoDB
depends_on:
- postgres
Chuẩn bị xong file docker-compose.yml, bạn chỉ cần gõ lệnh để kích hoạt:
docker-compose up -d
Xác thực kết nối bằng mongosh
Thử nghiệm thực tế bằng tool mongosh huyền thoại. Bạn sẽ thấy mọi thứ hoạt động y hệt như đang kết nối vào một instance MongoDB thực thụ:
mongosh "mongodb://127.0.0.1:27017/"
Thử thêm một bản ghi vào collection:
db.itfromzero.insertOne({
name: "FerretDB Tutorial",
type: "Database Proxy",
save_cost: "50% RAM"
});
db.itfromzero.find().pretty();
Bí mật nằm ở đây: Khi bạn kiểm tra database PostgreSQL bằng pgAdmin, bạn sẽ thấy FerretDB đã tự tạo bảng và đổ dữ liệu vào cột jsonb. Mọi thứ diễn ra hoàn toàn tự động và minh bạch.
Những “hố vôi” cần lưu ý khi lên Production
Dù rất tiện lợi, FerretDB không phải là viên đạn bạc cho mọi trường hợp. Anh em cần soi kỹ 3 điểm sau trước khi migrate:
- Độ tương thích: Hiện tại FerretDB hỗ trợ tốt Wire Protocol 5.0+, nhưng các toán tử Aggregation quá phức tạp có thể chưa chạy được 100%. Hãy check roadmap của họ thường xuyên.
- Hiệu năng: Qua một lớp proxy chắc chắn sẽ có độ trễ (latency) nhẹ. Với các app CRUD thông thường thì không thành vấn đề, nhưng với app High-Traffic thì cần benchmark kỹ.
- Quản lý Index: FerretDB tự map index nhưng đôi khi không tối ưu bằng việc bạn tay thủ công trên Postgres. Đừng quên monitoring chậm (Slow Query) bên phía Postgres nhé.
Tóm lại, nếu bạn muốn tối giản hạ tầng, gom hết dữ liệu về một mối cho dễ quản lý mà không muốn đụng vào code cũ, FerretDB là lựa chọn cực kỳ sáng suốt. Nó giải phóng bạn khỏi việc vận hành những cụm DB cồng kềnh không cần thiết.

