PostgreSQL hay MySQL: workload quyết định, không phải một bảng benchmark

Hãy chọn PostgreSQL hay MySQL theo những thao tác ứng dụng thực sự phải xử lý và khả năng vận hành của đội ngũ. PostgreSQL đáng thử trước khi bộ lọc JSON thay đổi thường xuyên; MySQL cũng là ứng viên phù hợp khi ứng dụng chủ yếu đọc theo khóa và nhóm đã vận hành hệ này thành thạo. Bản tổng hợp theo workload kết luận không hệ nào nhanh hơn trong mọi trường hợp và khuyên kiểm tra lại bằng tải sử dụng cụ thể.

Với dự án mới, câu hỏi hữu ích là truy vấn nào chiếm nhiều tài nguyên, giao dịch cần thấy dữ liệu nhất quán đến mức nào và đội ngũ sẽ duy trì hệ thống ra sao. Một kết quả đo chỉ có ý nghĩa khi hai phương án trả lời cùng yêu cầu nghiệp vụ trên dữ liệu và điều kiện chạy có thể đối chiếu.

Sáu workload dẫn đến sáu câu hỏi lựa chọn

Cây quyết định dưới đây xác định phương án cần kiểm tra kỹ hơn. Mỗi nhánh là một tình huống sử dụng, không phải cam kết rằng một hệ sẽ thắng về tốc độ.

• Đọc theo khóa chính: Nếu phần lớn yêu cầu lấy một tài khoản, sản phẩm hoặc đơn hàng bằng mã định danh, hãy thử cả hai hệ với kích thước dữ liệu và số phiên truy cập dự kiến. Khi cả hai đáp ứng mục tiêu độ trễ, kinh nghiệm vận hành và công cụ sẵn có thường là căn cứ lựa chọn thiết thực hơn một chênh lệch nhỏ trong phép đo.
• Nối nhiều bảng: Nếu màn hình nghiệp vụ lọc đơn hàng theo khách hàng, trạng thái và thời gian rồi tổng hợp kết quả, hãy đo chính truy vấn đó. Cấu trúc chỉ mục, độ chọn lọc của điều kiện và kế hoạch thực thi có thể làm thay đổi kết quả; phép thử đọc một bản ghi theo khóa không trả lời được câu hỏi này.
• Tìm kiếm JSON theo thuộc tính biến động: Khi bộ lọc phải tìm nhiều khóa hoặc đường dẫn khác nhau, đưa PostgreSQL vào vòng thử đầu tiên và tính cả chi phí duy trì chỉ mục. Nếu ứng dụng chỉ lọc vài thuộc tính ổn định, MySQL cũng có cách lập chỉ mục phù hợp; sự khác biệt nằm ở biểu thức truy vấn thực tế.
• Sửa một phần tài liệu JSON: Nếu thao tác ghi chủ đạo là thay một giá trị nhỏ trong tài liệu lớn, kiểm tra câu lệnh cập nhật dự kiến trên MySQL. Điều kiện để cập nhật tại chỗ khác với việc gán lại toàn bộ tài liệu, nên hai phép thử này không thể thay thế nhau.
• Ghi có tranh chấp: Khi nhiều giao dịch cùng sửa một nhóm bản ghi nhỏ, hãy quan sát thời gian chờ khóa, độ trễ ở tải cao và số giao dịch phải chạy lại. Kết quả chỉ có giá trị lựa chọn nếu hai cấu hình cùng đáp ứng yêu cầu nhất quán của nghiệp vụ.
• Giao dịch đi cùng báo cáo: Nếu báo cáo chạy trên dữ liệu đang phục vụ người dùng, đo hỗn hợp thao tác đọc, ghi và tổng hợp. Một phương án hoàn thành báo cáo nhanh nhưng khiến giao dịch thường ngày chậm vượt ngưỡng vẫn có thể không phù hợp.

JSON: cách lập chỉ mục và cập nhật tạo ra khác biệt

Tài liệu PostgreSQL về jsonb mô tả dạng lưu trữ nhị phân đã phân rã: xử lý nhanh hơn kiểu json vì không phải phân tích lại văn bản, hỗ trợ lập chỉ mục, nhưng có thể nhập chậm hơn. Chỉ mục GIN có thể phục vụ truy vấn tìm khóa hoặc cặp khóa–giá trị trong nhiều tài liệu. Lợi ích đối với dự án phụ thuộc vào toán tử trong điều kiện lọc, tỷ lệ bản ghi khớp và phần chi phí ghi thêm do chỉ mục.

Tài liệu MySQL 8.0 về JSON mô tả việc lập chỉ mục giá trị vô hướng trích qua cột sinh và chỉ mục đa giá trị cho mảng JSON ở các bản phát hành hỗ trợ tính năng này. Tài liệu cũng nêu điều kiện cập nhật một phần tại chỗ: câu lệnh dùng JSON_SET(), JSON_REPLACE() hoặc JSON_REMOVE() trên chính cột JSON, thay giá trị đã tồn tại và thông thường không làm giá trị mới lớn hơn phần được thay. Vì vậy, không nên suy từ khả năng cập nhật một phần rằng mọi thao tác sửa JSON đều tránh được việc ghi lại toàn bộ tài liệu.

Nếu cấu trúc bộ lọc đã ổn định, việc trích đúng thuộc tính cần tìm có thể là cách thiết kế gọn cho MySQL. Nếu sản phẩm cho phép người dùng thay đổi nhiều điều kiện tìm kiếm trên tài liệu, hãy kiểm tra các toán tử và chỉ mục jsonb của PostgreSQL bằng chính tập truy vấn đó. Cả hai trường hợp đều cần đo thêm dung lượng chỉ mục và tốc độ ghi sau khi lập chỉ mục.

Giao dịch phải được so trên cùng yêu cầu nhất quán

Tài liệu PostgreSQL về cô lập giao dịch ghi READ COMMITTED là mức mặc định: hai lệnh SELECT liên tiếp trong một giao dịch có thể thấy dữ liệu khác nhau nếu giao dịch khác hoàn tất giữa hai lần đọc. Điều này quan trọng với luồng đọc dữ liệu rồi quyết định cập nhật. Khi nghiệp vụ cần một ảnh chụp ổn định trong suốt giao dịch, cấu hình thử phải phản ánh yêu cầu đó.

Trong khi đó, tài liệu MySQL về InnoDB ghi mức mặc định là REPEATABLE READ; các lần đọc nhất quán trong cùng giao dịch dùng ảnh chụp được thiết lập từ lần đọc đầu. Tài liệu còn phân biệt khóa khi tìm theo chỉ mục duy nhất với khóa khi quét một khoảng giá trị. Vì vậy, so hai cấu hình mặc định đồng nghĩa với việc so cả hành vi giao dịch khác nhau: cần ghi rõ mức cô lập, kiểu đọc có khóa và quy tắc chạy lại giao dịch bị xung đột.

Một phép benchmark trả lời đúng câu hỏi của dự án

Hãy nạp cùng tập dữ liệu nghiệp vụ vào hai hệ: cùng số bản ghi, phân bố giá trị, độ lớn tài liệu JSON và tỷ lệ thuộc tính vắng mặt. Với ví dụ giả định là cửa hàng trực tuyến, bộ thao tác có thể gồm đọc sản phẩm theo mã, lọc thuộc tính, tạo đơn hàng, cập nhật tồn kho và tổng hợp doanh số. Câu SQL có thể khác để tận dụng cách lập chỉ mục của từng hệ, nhưng điều kiện lọc, kết quả trả về và quy tắc giao dịch phải tương đương.

Chạy từng nhóm thao tác riêng để thấy truy vấn nào tạo ra chênh lệch, rồi chạy hỗn hợp theo tỷ lệ sử dụng dự kiến. Ghi lại phiên bản hệ quản trị, phần cứng, bộ nhớ, số kết nối, cấu hình chỉ mục, mức cô lập và trạng thái bộ nhớ đệm. Cho cả hai hệ thời gian khởi động trước khi đo; thay đổi một yếu tố cấu hình thì chạy lại cả hai phương án theo cùng quy trình.

Thông lượng cho biết hệ xử lý được bao nhiêu việc, còn độ trễ ở nhóm yêu cầu chậm cho thấy trải nghiệm có thể xấu đi ra sao khi tải tăng. Theo dõi thêm mức dùng CPU, bộ nhớ, dung lượng đĩa, thời gian chờ khóa và giao dịch phải chạy lại. Lặp lại phép đo để phân biệt chênh lệch ổn định với dao động của một lượt chạy; một con số từ cấu hình hoặc truy vấn khác không đủ để quyết định nền tảng cho dự án.

Chi phí chuyển đổi và vận hành có thể đảo chiều lựa chọn

Nếu đội ngũ đã có mã ứng dụng hoặc dữ liệu trên một hệ, chuyển sang hệ còn lại đòi hỏi kiểm tra nhiều hơn tốc độ truy vấn. Danh sách cần rà soát gồm cú pháp SQL riêng, kiểu dữ liệu, cách xử lý JSON, quy tắc sắp xếp chuỗi, giá trị rỗng, thời gian, giao dịch và cách ứng dụng phản ứng khi gặp xung đột khóa. Hãy đối chiếu cả kết quả truy vấn sau chuyển đổi, vì một câu lệnh chạy thành công chưa chắc giữ nguyên ý nghĩa nghiệp vụ.

Sao lưu và khôi phục, giám sát truy vấn chậm, nâng cấp, sao chép dữ liệu và năng lực xử lý sự cố cũng là chi phí dài hạn. Nếu cả hai hệ đạt mục tiêu truy vấn và giao dịch với khoảng dự phòng phù hợp, lựa chọn dễ vận hành hơn có thể đem lại giá trị lớn hơn chênh lệch nhỏ về tốc độ. Nếu chỉ một hệ đáp ứng được thao tác cốt lõi trong phép thử tương đương, chính kết quả đó mới là lý do mạnh để chọn nó.

Đọc thêm:

• Claude sửa 10 lỗi căn chỉnh: kết quả tốt nhưng benchmark vẫn là giới hạn
• Claude Sonnet 5.5 rẻ nửa Opus: benchmark độc lập cho thấy đổi chỗ ở đâu
• DeepSeek V4.1 Flash thay thế bản Pro: rẻ hơn nhưng đừng đọc sai benchmark