Neki đạt 118 triệu truy vấn mỗi giây: Cột mốc mới cho cơ sở dữ liệu phân tán

PlanetScale vừa công bố kết quả thử nghiệm đáng chú ý với Neki — hệ thống cơ sở dữ liệu phân tán vừa được phát hành ở dạng xem trước trên nền tảng. Nhóm kỹ sư đặt mục tiêu ban đầu chỉ là 1 triệu truy vấn mỗi giây, nhưng họ nhanh chóng vượt qua giới hạn đó và quyết định đẩy hệ thống lên tới con số cuối cùng là 118,5 triệu truy vấn mỗi giây.

Kết quả này đạt được trên 512 shard với tổng dung lượng dữ liệu lên tới 1,22 PiB, mở ra những góc nhìn mới về khả năng mở rộng của các hệ cơ sở dữ liệu phân tán hiện đại.

Bài kiểm tra đơn giản nhưng quy mô khổng lồ

Điểm đáng chú ý là bài benchmark được thiết kế khá đơn giản. Mỗi truy vấn chỉ là một phép point select trên một shard duy nhất, lấy đúng một dòng dữ liệu theo khóa chính. Không có thao tác ghi, không có phép join, cũng không có truy vấn xuyên shard.

Khối lượng công việc mà mỗi shard nhận được hoàn toàn độc lập — không có truy vấn đơn lẻ nào trải rộng trên nhiều shard.

Mục tiêu đặt ra là duy trì 200.000 truy vấn mỗi giây trên từng shard, sau đó mở rộng cụm để tăng tổng thông lượng. Nhóm bắt đầu với 5 shard, rồi 50, và cuối cùng là 512.

Biểu đồ tổng quan hiệu năng của hệ thống Neki

Khả năng mở rộng tuyến tính

Bảng kết quả cho thấy mối quan hệ gần như tuyến tính hoàn hảo giữa số lượng shard và thông lượng:

Số shard	Số router	QPS đạt được	QPS mỗi shard
5	12	999.624	199.925
50	489	89.923.900	198.478
512	480	118.538.803	231.521

Gấp mười lần số shard, gấp mười lần thông lượng — và lặp lại thêm một lần nữa. Từ 5 lên 50 shard, tốc độ mỗi shard chỉ chênh lệch trong khoảng 0,8%. Đến 512 shard, các shard vẫn còn dư địa, nên nhóm để trình tạo tải tận dụng hết và mỗi shard ổn định ở mức 231.000 QPS thay vì 200.000 như kế hoạch ban đầu.

Con số 118,5 triệu QPS

Hiệu năng thực tế được duy trì trong 16 phút trên 512 shard. Con số ghi nhận cao nhất là 118.747.267 QPS.

Cấu hình cụ thể của lần chạy này bao gồm:

• 512 shard, mỗi shard có một Postgres primary chạy trên instance r8g.16xlarge
• 480 Neki router, mỗi router trên một instance 8xlarge riêng biệt
• Độ trễ p99 là 6,06ms tại router và 13,95ms tại phía client
• 67 lỗi mỗi giây, tương đương khoảng một truy vấn lỗi trong mỗi 1,8 triệu truy vấn
• 15,8 triệu read IOPS trên toàn bộ hệ thống
• Băng thông mạng vượt 2 Tb mỗi giây

Biểu đồ QPS trong quá trình thử nghiệm

Những điều cần lưu ý về lần chạy này

Nhóm nghiên cứu khá thẳng thắn về giới hạn của phép thử. Các shard chỉ chạy ở chế độ primary-only, không có replica. Khối lượng công việc thuần đọc với độ phức tạp truy vấn ở mức thấp, và hệ thống không trải qua tình huống failover nào trong suốt khoảng thời gian đo.

Điều này có nghĩa đây chưa phải là một bài kiểm tra toàn diện về độ bền vững của hệ thống trong điều kiện thực tế — nơi luôn tồn tại song song cả đọc lẫn ghi, các truy vấn phức tạp và những sự cố ngoài dự kiến.

Ý nghĩa với người dùng Việt Nam

Với các doanh nghiệp Việt Nam đang vận hành hệ thống chịu tải lớn như fintech, thương mại điện tử hay các nền tảng có lượng người dùng cao điểm đột biến, kết quả này cho thấy hướng tiếp cận sharding có thể mở rộng gần như tuyến tính mà không phải đánh đổi quá nhiều độ trễ.

Tuy nhiên, cần lưu ý rằng chi phí hạ tầng cho một cụm 512 instance lớn là rất đáng kể. Với phần lớn dự án tại thị trường Việt Nam, mô hình này phù hợp khi áp dụng ở quy mô nhỏ hơn — vài shard là đủ để xử lý hàng triệu truy vấn mỗi giây, mức mà nhiều hệ thống nội địa hiện vẫn còn xa mới chạm tới.

Nhóm PlanetScale cho biết sẽ công bố chi tiết về quá trình kỹ thuật và những thách thức trên đường đạt 100 triệu QPS trong một bài viết tiếp theo.