Hôm nay tiếp tục một bài benchmark mọi người nhé, chẳng là giờ làm tối ưu hệ thống nhiều nên hay phải đi cân đo đong đếm, thôi thì mất công sức, tiền bạc, thời gian làm thì chia sẻ luôn cho anh em sau gặp có thể hữu ích.

Các bác đều biết là thứ quyết định giá trị của ứng dụng, đó là Database. Vậy thì, Postgres, MySQL, hay Mongo, con nào ổn? Câu hỏi quá khó để trả lời chính xác. Các bác xem benchmark trên mạng thì vô vàn, nhưng toàn dùng toy dataset hoặc test trên máy xịn. Thực tế là nhiều khi app chạy trên cấu hình không cao siêu như vậy như lần này mình benchmark trên con máy 3 vCPU, 6GB RAM mà nọ mới đọc được bài Cách nhận VPS miễn phí cấu hình 6G RAM 3vCPU thế là mình quyết định làm một cái stress test luôn đỡ phí 😀

Bài toán ở đây là ném 40GB data khoảng 400 triệu dòng (các bác nhắn hỏi mình cũng trả lời nhiều rồi data là mình đi mua nhé) vào một con máy cùi 3 vCPU, 6GB RAM, NVMe SSD. Sau đó, mình dùng các loại query đọc, ghi, tổng hợp vào và đo đạc xem con nào ngỏm trước, con nào hấp hối, và con nào vẫn chạy ổn.

Các bài test chính:

• Tốc độ nạp dữ liệu (Ingest): Thời gian để nạp 40GB dữ liệu.
• Đọc theo key (Point Read): Độ trễ (P99) khi truy vấn một dòng duy nhất qua index.
• Truy vấn tổng hợp (Aggregation): Thời gian hoàn thành một câu query GROUP BY phức tạp.
• Tải đồng thời (Concurrent Workload): Số request mỗi giây (RPS) giả lập 100 người dùng (80% đọc, 20% ghi).

Các DB quen thuộc (OLTP)

Với 6GB RAM, các bác trừ hao cho OS, dịch vụ linh tinh… thì RAM thực tế cho DB cache như shared_buffers của Postgres hay InnoDB buffer pool của MySQL là siêu nhỏ. Chúng nó gần như vô dụng với data 40GB.

PostgreSQL

Đây là kịch bản tệ cho Postgres. Cache buffer quá bé, gần như 100% các query kể cả đọc đơn giản đều phải dồn xuống NVMe SSD. 3 vCPU chạy rảnh rang vì toàn bộ hệ thống đang bị nghẹn ở I/O.

• Kết quả benchmark:
  • Tốc độ Ingest: Khoảng 11 giờ.
  • Point Read (P99 Latency): ~120ms.
  • Aggregation Query: ~18 phút. Đúng là đi pha ấm trà rồi quay lại có khi nó vẫn chưa chạy xong.
  • Concurrent Workload: Đạt khoảng 950 RPS trước khi latency tăng vọt.

Mình thấy nó đáng tin cậy, nó vẫn sống, nhưng hiệu năng tụt giảm thê thảm. Dùng ở mức này khác gì hành hạ user.

MySQL

Tương tự. Cái InnoDB buffer pool với vài GB RAM không thể kiêm nổi 40GB data. Read cache miss liên tục. Concurrent write càng lộ rõ yếu điểm. RAM ít dẫn đến lock contention và I/O wait xảy ra dày đặc hơn.

• Kết quả benchmark:
  • Tốc độ Ingest: Khoảng 12.5 giờ.
  • Point Read (P99 Latency): ~150ms.
  • Aggregation Query: ~22 phút.
  • Concurrent Workload: Gần như tê liệt, chỉ đạt ~800 RPS.

MongoDB

Mấy query đơn giản kiểu insert, tìm theo key ban đầu nhanh vèo vèo. Nhưng đó là câu chuyện của lúc mới bắt đầu. Khi 40GB data nằm trên disk và RAM thì chỉ có 6GB, mấy cái query aggregation phức tạp bắt đầu không ổn.

• Kết quả benchmark:
  • Tốc độ Ingest: Rất nhanh, khoảng 7 giờ.
  • Point Read (P99 Latency): ~60ms cho các tác vụ tìm theo key đơn giản.
  • Aggregation Query: ~12 phút, nhanh hơn DB quan hệ nhưng vẫn rất chậm và làm CPU quá tải.
  • Concurrent Workload: Đạt ~1800 RPS với các tác vụ đơn giản.

Mình thấy nó tuyệt vời cho schema linh hoạt, workload đơn giản. Nhưng đừng bao giờ bắt nó gánh data lớn và query phức tạp cùng lúc nếu không đủ RAM.

Các loại chuyên biệt

Mình cũng thử 2 con này, dù biết là hơi ép chúng nó.

Redis

Redis thì nhanh, query tốn dưới 1ms. Nhưng vấn đề là Redis là in-memory. Nó đòi 40GB data phải nằm trong 6GB RAM. Điều này là bất khả thi. Còn nếu bật chế độ dùng disk thì… nó không còn là Redis mà chúng ta biết nữa. Đưa vào so sánh này là chưa đúng.

Cassandra

Con này cũng tương tự. Cassandra sinh ra để chạy cluster. Các bác ném cho nó 1 con node 3 vCPU thì khác gì bắt cá mập bơi trong chậu cá cảnh. Nó chạy được, write ổn định, nhưng read thì thất thường. Test này cũng không công bằng cho nó. Muốn dùng Cassandra thì hãy chuẩn bị ít nhất 3 node.

Những loại về analytics

ClickHouse

Mấy cái query aggregation mà làm Postgres mất vài phút, thì ClickHouse nó chỉ trong… vài giây. Nhờ cơ chế compression dữ liệu theo columnar, 40GB data thô được nó xử lý cực kỳ gọn.

• Kết quả benchmark:
  • Tốc độ Ingest: Nạp theo batch cực nhanh, chỉ mất ~2.5 giờ.
  • Point Read (P99 Latency): Đây là điểm yếu, mất tới ~400ms để lấy 1 dòng đầy đủ.
  • Aggregation Query: Chỉ 14 giây. Một sự khác biệt không thể tin nổi.
  • Concurrent Workload: Không phải thế mạnh, chỉ khoảng 400 RPS.

Tốc độ query phân tích của nó đơn giản là ở một đẳng cấp khác so với phần còn lại trong bài test này. Nếu workload của các bác là analytics làm báo cáo, dashboard, xử lý log thì ClickHouse là lựa chọn số một.

DuckDB

Mình không kỳ vọng nhiều, vì nó là embedded engine. Nhưng nó xử lý 40GB data cũng rất ổn.

• Kết quả đo đạc:
  • Tốc độ Ingest: Khoảng 3 giờ.
  • Aggregation Query: Chỉ 25 giây. Cực kỳ ấn tượng.
  • Điểm yếu: Concurrency gần như bằng không, vì nó không thiết kế cho việc đó.

Mình thấy nó là một thứ vũ khí lợi hại cho các tác vụ phân tích data local, chạy script một lần, hoặc khi bác không muốn setup một server DB cồng kềnh.

Bảng tổng kết số liệu

Vậy cuối cùng các bác thấy sao?

Mình thấy Postgres vẫn ổn trong cân bằng và tin cậy cho các tác vụ OLTP. Nó là lựa chọn an toàn nhất. Nhưng DB chiến thắng thực sự trong bài test của mình là ClickHouse.

Ý kiến của mình là đừng bao giờ chọn DB theo đa số mà hãy nhìn thẳng vào workload và tài nguyên (CPU/RAM/Cost) của mình. Hay chính xác là mục tiêu bài toán của mình là gì.

Thứ mình đúc kết lại qua bài test

1. Cần DB ổn định cho app web (OLTP) thì cứ Postgres mà dùng.
2. Cần làm analytics, dashboard, xử lý log, data kho (OLAP) thì ClickHouse.
3. Cần cache thì Redis miễn là các bác đủ RAM để chứa hết data.
4. Dùng MongoDB thì ổn, nhưng hãy chắc chắn bác có rất nhiều RAM khi data phình to, và đừng bắt nó làm aggregation quá sức.
5. Muốn phân tích data nhanh trên máy cá nhân thì thử ngay DuckDB.