VPS tốt nhất để lưu trữ cơ sở dữ liệu: chọn cấu hình theo tải

Hai cơ sở dữ liệu có thể chiếm cùng dung lượng đĩa nhưng cần VPS khác nhau. Một bên đọc lặp lại ít hàng; bên kia ghi liên tục, tạo chỉ mục lớn hoặc cần phục hồi nhanh sau lỗi. Việc chọn bắt đầu từ những khác biệt này, trước khi so nhà cung cấp.

Mua VPS tự quản cũng là nhận trách nhiệm vận hành cơ sở dữ liệu. PostgreSQL, MySQL và MariaDB cần ngân sách bộ nhớ khác nhau; năng lực phục hồi phải được thiết kế cùng máy chủ chính. Cấu hình ban đầu phải chừa chỗ cho sao lưu, bảo trì và vượt qua thử nghiệm tải đại diện.

Đo tải cơ sở dữ liệu trước khi chọn gói

Trước khi chọn CPU, RAM và đĩa, đo dữ liệu/chỉ mục hoạt động, truy vấn đồng thời lúc cao điểm, tăng trưởng và yêu cầu phục hồi. Bổ sung tài nguyên theo giới hạn đo được. Tính cả chỗ bảo trì và đỉnh ứng dụng nếu chung máy; ngân sách phải chịu được cao điểm lẫn thường ngày.

Tập làm việc là dữ liệu và chỉ mục được truy cập đủ thường xuyên để có lợi khi nằm trong RAM. Dung lượng lưu còn gồm dữ liệu lạnh. Kết nối mở không phải truy vấn hoạt động: máy khách nhàn rỗi và sắp xếp đồng thời cần CPU/RAM khác nhau. Ghi cả hai, dạng truy vấn và tỷ lệ đọc/ghi.

Lập yêu cầu mua từ một giai đoạn bận đại diện:

• Đo đỉnh bộ nhớ ứng dụng nếu dùng chung VPS.
• Ghi kích thước dữ liệu/chỉ mục, tập làm việc ước tính, thao tác đồng thời và tăng trưởng trong kỳ dự kiến.
• Đo lượng nhật ký và xác định lần tạo chỉ mục, ghi lại bảng hay bảo trì lớn nhất dự kiến.
• Đặt mục tiêu độ trễ p95, cửa sổ mất dữ liệu chấp nhận được và thời gian khôi phục.
• Chọn nơi chạy ứng dụng và thử đường kết nối tới cơ sở dữ liệu.

Tài liệu giám sát PostgreSQL khuyên kết hợp thống kê cơ sở dữ liệu với công cụ hệ điều hành. Đo CPU, áp lực RAM và đĩa cùng thời gian truy vấn, commit. Cần điều tra độ trễ tăng khi sao lưu dù kiểm tra máy nhàn rỗi có vẻ tốt.

vCPU riêng cho quyền truy cập liên tục tới CPU được cấp, không phải cả máy vật lý hay bảo đảm IOPS. Đánh giá CPU, RAM và hành vi đĩa riêng. Nếu yêu cầu đo vượt các VPS có sẵn, xem phần cứng riêng thay vì suy từ tên gói lớn hơn.

Ghép tải SQL với cấu hình khởi đầu

Dùng PostgreSQL 16, MySQL 8.4 với InnoDB hoặc MariaDB 11.4 với InnoDB làm môi trường ví dụ thay thế theo tương thích ứng dụng. Chúng không hoán đổi trực tiếp, cũng không được nêu là bản mới nhất. Ghi phiên bản bản vá trước khi thử; ví dụ không chỉ định phiên bản ảnh của nhà cung cấp.

Đặt ứng dụng nhỏ và cơ sở dữ liệu chung máy

Với giả định 3 GB dữ liệu, tập nóng 1 GB và năm truy vấn đơn giản có chỉ mục đang hoạt động, thử 2 vCPU, 4 GB RAM và 60 GB SSD/NVMe danh nghĩa. Kết nối cục bộ nhưng cả hai phải vừa ngân sách RAM đỉnh chung.

Giả định đọc/ghi 90/10, tăng 1 GB mỗi tháng và không báo cáo dài khi sao lưu. CPU chung có thể hợp staging chịu được dao động. Chọn riêng nếu tranh chấp kéo dài làm phản hồi không đạt; bảng sản xuất sau chỉ dùng vCPU riêng.

Ngân sách RAM đề xuất, mọi số đều tính bằng GB:

Đặt vùng InnoDB MySQL/MariaDB trong ngân sách này. Áp phần trăm cho máy cơ sở dữ liệu riêng lên cả máy sẽ lấy RAM của ứng dụng. Với PostgreSQL, tính bộ đệm chung và bộ nhớ thao tác riêng trong phần cấp và dự phòng của cơ sở dữ liệu. Đo đỉnh tổng trước khi chấp nhận mỗi phương án.

Ví dụ đĩa: hệ điều hành/nhật ký 5 GB, dữ liệu/chỉ mục 3 GB, nhật ký máy 4 GB, tạm 3 GB và tăng trưởng 6 GB, tổng 21 GB. Phần danh nghĩa còn lại dành cho chi phí hệ thống tệp và việc tạm, không biện minh giữ bản sao trên máy chính.

Kết nối qua socket cục bộ hoặc localhost. Thử commit bền vững khi ứng dụng và sao lưu hoạt động, kể cả đồng bộ (fsync) yêu cầu hệ điều hành ghi ra lưu trữ bền vững. Nếu chủ sở hữu chấp nhận RPO 24 giờ là cửa sổ mất dữ liệu và RTO bốn giờ là đích phục hồi, đề xuất sao lưu bằng công cụ của hệ quản trị mỗi đêm ngoài nút và chứng minh thời gian bằng diễn tập. Nếu RAM, độ trễ hay phục hồi vượt ngân sách, chẩn đoán truy vấn/chỉ mục rồi tách, tăng cỡ hoặc sửa thiết kế.

Tách cơ sở dữ liệu SQL giao dịch

Với ứng dụng ở nơi khác, ví dụ 12 GB SQL và tập nóng 6 GB có thể bắt đầu thử trên 2 vCPU riêng, RAM cỡ 16 GB và đĩa cục bộ cỡ 50 GB. Giả định 20 truy vấn có chỉ mục hoạt động, ghi ngắn và ít tính toán kéo dài; thao tác nặng có thể làm ngân sách sai.

Giả định đọc/ghi 90/10 và tăng 1 GB mỗi tháng trong ba tháng. Đây là tải tham chiếu bảng nhà cung cấp. Đơn vị khác nhau: so RAM thực dùng và byte hệ thống tệp khả dụng trước khi cấp.

Với PostgreSQL VPS, hướng dẫn bộ đệm chung PostgreSQL 16 bắt đầu từ 25% RAM hệ thống trên máy cơ sở dữ liệu riêng có ít nhất 1 GB. PostgreSQL cũng dùng bộ đệm hệ điều hành. Đề xuất 16 GB: chung 4 GB, hệ điều hành/tác nhân 2 GB, dự phòng truy vấn/kết nối/bảo trì 2 GB và đệm tệp/dư địa 8 GB.

Dự phòng không phải giá trị work_mem. Tài liệu bộ nhớ thao tác truy vấn PostgreSQL giải thích mỗi sắp xếp và băm riêng có thể cấp RAM khi nhiều phiên chạy. Băm còn dùng hash_mem_multiplier. Đặt giới hạn theo số việc đồng thời cho phép; giá trị lớn mỗi thao tác vẫn vượt máy dù bộ đệm chung đủ.

Với MySQL VPS, hướng dẫn vùng đệm MySQL 8.4 Oracle thường khuyên 50–75% RAM có tính hệ điều hành và các phần khác. Thử InnoDB 8 GB, để phần còn lại cho thành phần khác và đỉnh tải.

MariaDB cần phép tính khác. Hướng dẫn cấp RAM bắt đầu ở 60–70% RAM còn sau hệ điều hành/dịch vụ cho hệ chủ yếu InnoDB. Còn 13 GB thì được 7,8–9,1 GB; khởi đầu 8 GB phù hợp. MyISAM hoặc Aria cần bộ đệm riêng. Đây là các phương án thay thế, không cộng lại.

Đĩa: 12 GB dữ liệu/chỉ mục + 3 GB tăng + 5 GB hệ điều hành + 4 GB nhật ký + 8 GB tạm/bảo trì = 32 GB. Đĩa cỡ 50 GB còn khoảng 18 GB danh nghĩa trước chi phí. Yêu cầu ít nhất 15 GB trống đo được; nhiều nhật ký hoặc ghi lại lớn hơn làm ví dụ không còn đúng.

Đặt ứng dụng gần cơ sở dữ liệu, có đường riêng đã thử nếu hỗ trợ, xác thực, kiểm soát truy cập và mã hóa. Đo truy vấn/commit bền vững khi checkpoint, flush và sao lưu. Cấp lưu trữ sao lưu độc lập; phần phục hồi dưới mô tả thêm. Tăng cỡ sau chẩn đoán nếu tài nguyên bão hòa, chỗ trống thiếu hoặc phục hồi không đạt.

Dự trù tập làm việc lớn hoặc ghi liên tục

Với giả định 100 GB dữ liệu và tập nóng 16 GB, thử 4 vCPU riêng, 32 GB RAM và NVMe cỡ 300 GB, ứng dụng tách riêng. Ví dụ cho 30 truy vấn hỗn hợp hoạt động và đọc/ghi 60/40; đo thực thi và áp lực đĩa trước khi tăng.

Giả định tăng 10 GB hàng tháng trong ba tháng. PostgreSQL: bộ đệm chung 8 GB, hệ điều hành/truy vấn/bảo trì 4 GB và đệm tệp/dư địa 20 GB. Với MySQL/MariaDB, InnoDB khoảng 16 GB là phương án khác sau các dự phòng. Không chép thiết lập PostgreSQL sang chúng.

Đĩa gồm việc đang diễn ra: dữ liệu/chỉ mục 100 GB + tăng 30 GB + nhật ký giữ/chờ 30 GB + thao tác tạm/bảo trì lớn nhất 60 GB + hệ điều hành 10 GB = 230 GB. Còn khoảng 70 GB danh nghĩa. Ghi lại bảng lớn hơn cần tính lại dù tăng hàng ngày nhỏ.

Tài liệu vacuum thường kỳ PostgreSQL phân biệt VACUUM tái sử dụng chỗ hàng chết với VACUUM FULL ghi bản bảng mới và tạm cần thêm đĩa. Đĩa chỉ lớn hơn dữ liệu chút ít có thể cản bảo trì thu hồi chỗ.

Đo CPU, áp lực bộ đệm và I/O vật lý riêng với độ trễ ghi. Gồm ghi tạm và giai đoạn checkpoint/flush. NVMe và CPU riêng mô tả cấu hình, không bảo đảm IOPS. Thử truyền sao lưu/nhân bản bền vững với kết nối riêng gần và lưu trữ phục hồi độc lập. Nhật ký nhanh hơn đổi nhu cầu lưu giữ và mạng. Tăng lõi, RAM hoặc đĩa theo giới hạn đo, không vì gói kế tiếp tăng cả ba.

Bổ sung năng lực phục hồi cho sản xuất

Chấp nhận mất 15 phút và mục tiêu phục hồi một giờ cần hơn ngân sách máy chính. Giữ giả định SQL tách biệt, thêm sao lưu bằng công cụ của hệ quản trị, nhật ký, lưu trữ độc lập và diễn tập bấm giờ. Đây là mục tiêu kế hoạch; chỉ diễn tập chứng minh đạt.

Tài liệu lưu trữ liên tục PostgreSQL mô tả bản sao lưu cơ sở và WAL không gián đoạn để khôi phục theo thời điểm. Tài liệu phục hồi MySQL Oracle dùng bản đầy đủ rồi nhật ký nhị phân. Quy trình PITR MariaDB khôi phục đầy đủ/tăng dần trước khi phát lại nhật ký. Phải bật ghi nhật ký nhị phân cho các luồng MySQL/MariaDB này.

Ví dụ dung lượng: mỗi bản đầy đủ/nền không nén 12 GB. Giữ ba bản nền hàng tuần và nhật ký liên tục từ đầu bản cũ nhất. Tính tối đa 21 ngày, 2 GB/ngày và biên 20%:

(3 × 12 + 21 × 2) × 1.2 = 93.6 GB

Lập ít nhất 100 GB sao lưu độc lập, không giả định nén. Gắn xóa nhật ký với hết hạn và thay thế bản sao thành công. Kiểm tra chuỗi hoàn chỉnh cho mọi điểm phục hồi đã hứa.

Dùng bản sao trên đích độc lập, thông tin đăng nhập và quyền xóa riêng máy chính. Snapshot nhà cung cấp không tự chứng minh chuỗi gốc này. Diễn tập phải tạo đích sạch, truyền/khôi phục, phát lại nhật ký, kiểm tra nhất quán cơ sở dữ liệu/ứng dụng và chuyển tuyến. Tính cả thời gian cấp máy và truyền.

Mục tiêu gián đoạn ngắn hơn có thể cần bản sao độc lập chịu toàn tải. Tính CPU, RAM và đĩa riêng; xác định nâng vai trò, cô lập máy chính cũ và định tuyến khách. Diễn tập thứ tự. Nhân bản không thay sao lưu; một VPS không là tính sẵn sàng cao. Sửa thiết kế nếu phục hồi quá giờ, trễ lưu trữ vượt RPO, dự phòng không chịu tải hoặc kho sao lưu gần đầy.

Khi nào chọn VPS được quản lý

Nếu không ai phản hồi cảnh báo hay khôi phục lúc sự cố, mua phạm vi vận hành xác định. VPS được quản lý có thể chuyển một số bảo trì, nhưng hợp đồng phải nêu tác vụ cơ sở dữ liệu. Bảng điều khiển không chứng minh phạm vi; VPS quản lý khác cơ sở dữ liệu quản lý.

Khác biệt giữa trách nhiệm VPS quản lý và tự quản hữu ích theo từng việc. Đây là danh sách mua sắm, không hứa dịch vụ nào cũng giống. Hạ tầng vật lý vẫn của nhà cung cấp; phần mềm khách và vận hành cơ sở dữ liệu cần chủ trách nhiệm rõ.

Câu hỏi hợp đồng hữu ích: ‘Nếu hết đĩa khi sao lưu, ai chẩn đoán, khôi phục dịch vụ và kiểm tra bản sau thành công?’ Nó phân biệt tiếp cận hỗ trợ với trách nhiệm kết quả. Hỏi thêm về nâng cấp lỗi và xóa nhầm.

Cơ sở dữ liệu quản lý có thỏa thuận riêng về vòng đời, sao lưu và chuyển lỗi. Có thể hợp hơn nếu muốn chuyển phục hồi/nâng cấp. Đừng suy tối ưu ứng dụng từ tên; thiết kế truy vấn và hành vi ứng dụng vẫn cần người chịu trách nhiệm trừ thỏa thuận khác.

Giao mỗi việc một lần với tuyến chuyển cấp và kiểm tra nghiệm thu. So giá với thời gian và khả năng sẵn sàng của bạn. Tự quản không có giá giờ phổ quát; máy rẻ không xử lý sự cố vô chủ.

Chọn VPS cho tải ngoài SQL

Ví dụ tách tải trong RAM, tài liệu và chỉ mục tìm kiếm. Đặt ứng dụng gần và thử kết nối, truyền tới sao lưu và bản sao khi dùng.

Hướng dẫn quản trị Redis cảnh báo lưu RDB hoặc ghi lại AOF dưới tải ghi nặng có thể dùng gấp đôi RAM thường tùy trang thay đổi. Vì thế 2 GB không được chiếm hết RAM. Tài liệu độ bền phân biệt snapshot RDB định kỳ và nhật ký AOF. Chọn theo mất mát chấp nhận rồi đo đỉnh RAM/đĩa khi chạy.

Tài liệu cache WiredTiger MongoDB mô tả cache nội bộ và hệ thống tệp. Mặc định là giá trị lớn hơn giữa 50% × (RAM − 1 GB) và 0,256 GB. Hướng dẫn replica set khuyên ba thành viên mang dữ liệu. Trọng tài biểu quyết nhưng không giữ dữ liệu. Thêm sao lưu độc lập và bật xác thực MongoDB trước khi nối ứng dụng.

Tài liệu thiết lập JVM Elastic khuyên heap tự động. Nếu thủ công, bằng nhau tối thiểu/tối đa và không quá 50% RAM có sẵn. Hướng dẫn chịu lỗi cụm nhỏ mô tả hai nút dữ liệu có thể làm master và nút phân xử chỉ biểu quyết. Đặt bản sao và tuyến khách tới nút dữ liệu; phân xử thêm phiếu, không thêm bản dữ liệu. Nếu hợp nhất/lưu giữ hết dự phòng, sửa ngân sách đĩa trước khi thêm tài liệu.

So sánh gói tự quản cho cấu hình cần dùng

Với SQL giao dịch tách riêng, lọc ít nhất 2 vCPU riêng, RAM cỡ 16 GB và 50 GB cục bộ. Đạt ngưỡng chỉ thành ứng viên thử. Gói CPU/đĩa, đơn vị và cam kết thanh toán khác nhau không cho phép coi phần cứng tương đương hay xếp hạng hiệu năng.

Tham chiếu là Linux tự quản tại Đức hoặc Trung Âu gần đó, ít dữ liệu và nhiều RAM hơn. Gần không đồng nghĩa cùng độ trễ. Đường riêng nếu hỗ trợ; báo giá giữ IPv4 công cộng chuẩn. Giả định truyền dưới mọi hạn mức.

Tài liệu chọn DigitalOcean nêu Memory-Optimized cho SQL/NoSQL và cache. Tôi đề xuất dòng trọn gói này cho ít đĩa, nhiều RAM. VPS tối ưu RAM không chỉ dành SQL. Nếu đo cho thấy dung lượng hoặc nhu cầu đĩa liên tục là giới hạn, đánh giá Storage-Optimized riêng.

Cả năm đạt ngưỡng với dư CPU/đĩa khác nhau. Có thể hỗ trợ tăng trưởng nhưng không chứng minh nhanh hơn nếu chưa thử. Danh mục Hetzner không bảo đảm hàng đặt được. Akamai ghi SSD cho G7 Dedicated. Vultr Optimized Memory khác High Frequency Compute dùng chung.

Phần cấp riêng của chúng tôi hợp cấu hình tự quản ở giá nêu. So tài nguyên, tiền tệ, cam kết tính phí và IPv4 trước khi đánh giá tổng giá trị.

Chi phí sở hữu: tính toán + địa chỉ + kho/yêu cầu/truyền sao lưu độc lập + năng lực thử phục hồi + dự phòng tùy chọn. Phí chưa biết không phải không có. Lấy giá phục hồi hiện tại và xác nhận gói, vị trí, đường nâng cấp trước cam kết. Không suy hóa đơn năm bằng nhân tương đương tháng làm tròn.

Chọn được máy SQL tương thích, ứng dụng một lần nhấp giúp rút ngắn cài đặt. PostgreSQL, MySQL và MariaDB là lựa chọn riêng; chọn một không cài cả ba. Vá, tối ưu và phục hồi vẫn do bạn quản lý.

Câu hỏi thường gặp