Máy chủ PostgreSQL: RAM, storage và cách nghiệm thu

Máy chủ PostgreSQL cần được chọn theo workload truy vấn và dữ liệu hoạt động, không chỉ dung lượng database. Một database nhỏ với truy vấn nặng có thể chậm hơn database lớn được tổ chức và truy cập tốt.

Thu thập số liệu đầu vào

• Dữ liệu hiện tại, index và tốc độ tăng trưởng.
• Truy vấn quan trọng: đọc, ghi, báo cáo hoặc batch.
• Số kết nối và giao dịch hoạt động ở giờ cao điểm.
• Latency mục tiêu, timeout, lock và lỗi.
• Chu kỳ backup, RPO/RTO và môi trường khôi phục.

Tách latency database khỏi thời gian request ứng dụng. Một API chậm có thể do chờ connection, mạng hoặc xử lý sau truy vấn. Log và metric cần cho phép xác định bước đang tốn thời gian.

CPU và RAM

CPU hỗ trợ xử lý truy vấn, transaction và tác vụ nền; thêm nhân không đảm bảo một truy vấn tuần tự nhanh hơn. RAM cần cho cache, process và thao tác truy vấn. Không dùng một tỷ lệ cấu hình cố định cho mọi hệ: hãy đo bộ nhớ cùng tải và kiểm tra OOM/swap.

Tăng số connection hoặc memory dành cho thao tác có thể tăng tổng sử dụng bộ nhớ. Connection limit cần được thiết kế với ứng dụng và pool; nâng giới hạn chỉ để hết lỗi kết nối có thể đẩy server vào thiếu RAM.

Storage: đo độ trễ dưới tải

IOPS danh định cần kèm block size, queue depth và read/write mix. Không lấy một phép benchmark tuần tự để kết luận tốc độ giao dịch. Khi database ghi đồng bộ, storage và cấu hình độ bền dữ liệu ảnh hưởng trực tiếp; tránh đánh đổi durability để có số benchmark đẹp.

Kiểm thử truy vấn và tải đồng thời

1. Dựng môi trường thử với dữ liệu đại diện.
2. Xác định truy vấn/giao dịch quan trọng và tiêu chí latency.
3. Kiểm tra query plan, index và lock trước khi tăng máy.
4. Chạy tải đồng thời; đo CPU/RAM, I/O và connection chờ.
5. Thử report hoặc batch cùng tải nghiệp vụ.
6. Thử backup và restore với dung lượng gần production.

Giữ dữ liệu kiểm thử và cấu hình được phép dùng; không chạy stress test tùy tiện trên database production. Nghiệm thu cần tính đúng của giao dịch, không chỉ số truy vấn mỗi giây.

Backup và khả năng phục hồi

PostgreSQL có các phương án backup như SQL dump, backup cấp filesystem và continuous archiving. Lựa chọn cần phù hợp mục tiêu phục hồi và điều kiện nhất quán. Replication không tự thay backup nếu lỗi dữ liệu đã lan sang replica.

Thử khôi phục vào máy khác với đủ quyền, phiên bản và cấu hình. Ghi thời gian tải bản sao, phục hồi database và xác minh ứng dụng; RTO của hệ thống không dừng ở lúc database khởi động.

Khi nào tách database khỏi app?

Tách có thể hữu ích khi tài nguyên cạnh tranh, cần quản trị riêng hoặc triển khai cơ chế dự phòng. Nó cũng thêm phụ thuộc mạng và vận hành. Quyết định dựa trên workload; không mặc định database riêng phải có IP public.

Xem chọn cấu hình máy chủ và bảng giá server. Gửi loại truy vấn, dung lượng, concurrency và RPO/RTO để có phương án có thể nghiệm thu.