Các bài kiểm tra chuẩn cơ sở dữ liệu vector tiết lộ khoảng cách lớn về thời gian xây dựng và khả năng đồng thời

Percona đã công bố một bài kiểm tra chuẩn (benchmark) khắt khe so sánh hiệu suất tìm kiếm vector trên sáu công cụ cơ sở dữ liệu, làm nổi bật sự chênh lệch đáng kể về tốc độ lập chỉ mục, mức sử dụng bộ nhớ và khả năng xử lý đồng thời. Nghiên cứu đánh giá MariaDB, AliSQL, PostgreSQL kèm pgvector, Valkey và Percona Search cho MongoDB bằng tập hợp 990.000 embedding từ OpenAI. Kết quả cho thấy trong khi một số công cụ vượt trội về tốc độ xây dựng chỉ mục nhanh chóng, những công cụ khác lại cung cấp hiệu quả lưu trữ vượt trội hoặc thông lượng cao khi xử lý đồng thời, cung cấp dữ liệu quan trọng cho các kỹ sư thiết kế hệ thống tạo sinh tăng cường truy xuất (RAG).

Chuyện gì đã xảy ra

Bài kiểm tra chuẩn nạp 990.000 vector có 1.536 chiều vào mỗi công cụ, xây dựng chỉ mục HNSW và đo lường năm chỉ số chính: thời gian tạo chỉ mục có thể truy vấn, dung lượng lưu trữ và bộ nhớ, tỷ lệ recall so với thông lượng, hiệu suất dưới tải đồng thời của nhiều khách hàng, và hành vi khi dữ liệu biến động. Tất cả các bài kiểm tra đều chạy trên phần cứng giống hệt nhau, một máy chủ Intel Xeon Gold 6230 với 80 CPU logic và 187,5 GB RAM, đảm bảo so sánh công bằng. Bộ điều phối áp dụng các giới hạn tài nguyên nhất quán, chẳng hạn như buffer pool InnoDB 42,3 GB và phân bổ bộ nhớ cụ thể cho cache đồ thị, để ngăn ngừa thiên kiến cấu hình.

Kết quả tiết lộ những biến đổi bất ngờ trong các thao tác cơ bản. Thời gian xây dựng chỉ mục có thể truy vấn dao động từ chỉ 1,9 phút đối với Percona Search đến 6,7 giờ đối với AliSQL. Hiệu quả lưu trữ cũng khác nhau rất lớn, với MariaDB tạo ra chỉ mục nhỏ nhất ở mức 3,9 GiB, trong khi Percona Search yêu cầu 15,1 GiB. Đáng chú ý, công cụ có chỉ mục nhỏ nhất lại mất nhiều thời gian nhất để xây dựng nó, minh họa cho sự đánh đổi phổ biến giữa nén và tốc độ xây dựng. Những phát hiện này gợi ý rằng việc lựa chọn cơ sở dữ liệu vector đòi hỏi phải cân bằng giữa nhu cầu vận hành tức thì, chẳng hạn như tần suất lập lại chỉ mục, với chi phí lưu trữ dài hạn.

Kiểm thử đồng thời phơi bày thêm những điểm khác biệt. Dưới tải 32 khách hàng đồng thời, PostgreSQL kèm pgvector mở rộng thông lượng gấp 21,7 lần so với hiệu suất một khách hàng. Ngược lại, ba công cụ dựa trên InnoDB—MariaDB 11.8, MariaDB 12.3 và AliSQL—gần như không thể hiện sự mở rộng nào, duy trì thông lượng khoảng 1x. Tuy nhiên, nhóm benchmark đã rút lại các con số hiệu suất đồng thời cụ thể cho ba công cụ này sau khi phát hiện ra một hạn chế trong khung thử nghiệm. MariaDB Connector/C giữ khóa trình thông dịch Python trong khi chờ socket, nghĩa là một số khách hàng đang chờ khóa chứ không phải chờ cơ sở dữ liệu, làm sai lệch các chỉ số "đang phục vụ".

Cách thức hoạt động

Bài kiểm tra chuẩn sử dụng tập dữ liệu dbpedia-openai-1000k-angular, bao gồm 990.000 vector float32. Mỗi công cụ xây dựng chỉ mục HNSW với M=16, một tham số tiêu chuẩn kiểm soát kết nối của cấu trúc đồ thị. Hiệu suất truy vấn được đo bằng các giá trị ef_search khác nhau, xác định số lượng ứng viên được khám phá trong quá trình tìm kiếm. Recall được tính toán bằng định nghĩa ngưỡng khoảng cách từ ann-benchmarks, đảm bảo khả năng so sánh với tài liệu hiện có. Đối với các truy vấn có bộ lọc, ground truth được tính lại bằng phương pháp brute force chỉ trên các dòng thỏa mãn vị từ, ngăn các công cụ bị phạt vì loại trừ đúng các mục không khớp.

Các công cụ khác nhau áp dụng các chiến lược riêng biệt cho tìm kiếm có bộ lọc. PostgreSQL kèm pgvector sử dụng phương pháp post-filter, thu thập các ứng viên từ đồ thị rồi loại bỏ những ứng viên không đạt vị từ. Nếu quá nhiều ứng viên bị loại, nó sẽ dừng sớm, có thể trả về ít kết quả hơn yêu cầu. Percona Search sử dụng chiến lược pre-filter, có thể duy trì thông lượng cao hơn khi bộ lọc chặt chẽ hơn nhưng có thể hy sinh recall. MariaDB và AliSQL cũng post-filter nhưng tiếp tục tìm kiếm, giúp bảo toàn recall nhưng có thể làm tăng đáng kể độ trễ khi độ chọn lọc của bộ lọc giảm. Những lựa chọn kiến trúc này ảnh hưởng trực tiếp đến mức độ mỗi công cụ xử lý tốt các truy vấn phức tạp, thực tế liên quan đến bộ lọc metadata.

Chi tiết chính

• Thời gian xây dựng chỉ mục: Percona Search nhanh nhất ở mức 1,9 phút, trong khi AliSQL chậm nhất ở mức 6,7 giờ.
• Hiệu quả lưu trữ: MariaDB 11.8 và 12.3 tạo ra các chỉ mục nhỏ nhất ở mức 3,9 GiB, so với 15,1 GiB của Percona Search.
• Thông lượng một khách hàng: Ở recall 0,99, MariaDB 12.3 dẫn đầu với 277 QPS, theo sau là Valkey với 264 QPS và PostgreSQL với 210 QPS.
• Mở rộng đồng thời: Thông lượng của PostgreSQL tăng 21,7x với 32 khách hàng, trong khi các công cụ dựa trên InnoDB cho thấy sự mở rộng tối thiểu do xếp hàng phía máy chủ.
• Tìm kiếm có bộ lọc: Phương pháp post-filter mặc định của PostgreSQL khiến recall giảm xuống 0,1034 ở độ chọn lọc 1% vì nó dừng sớm sau khi loại bỏ các ứng viên không khớp.
• Biến động dữ liệu: MHNSW và VIDX cập nhật đồ thị mỗi lần chèn, khiến thời gian nạp tương đương với thời gian xây dựng chỉ mục, khác với pgvector tách biệt việc sao chép và xây dựng.

Tại sao điều này quan trọng

Đối với các kỹ sư phần mềm xây dựng ứng dụng AI, các bài kiểm tra chuẩn này nhấn mạnh rằng không có công cụ đơn lẻ nào thống trị tất cả các danh mục. Nếu ứng dụng của bạn yêu cầu lập lại chỉ mục thường xuyên hoặc cập nhật mô hình, sự khác biệt giữa thời gian xây dựng 40 phút của PostgreSQL và cửa sổ 6,7 giờ của AliSQL là rất đáng kể về mặt vận hành. Ngược lại, nếu chi phí lưu trữ là ràng buộc chính, chỉ mục gọn nhẹ 3,9 GiB của MariaDB mang lại khoản tiết kiệm đáng kể so với các lựa chọn khác, bất chấp quy trình xây dựng chậm hơn. Hiểu rõ những đánh đổi này giúp các đội ngũ chọn hạ tầng phù hợp với mẫu khối lượng công việc cụ thể của họ, dù họ ưu tiên tốc độ ghi, thông lượng đọc hay mật độ lưu trữ.

Kết quả đồng thời đặc biệt liên quan đến các dịch vụ có lưu lượng truy cập cao. Khả năng mở rộng thông lượng tuyến tính theo số lượng khách hàng của PostgreSQL và Valkey gợi ý rằng chúng phù hợp hơn với môi trường có nhiều người dùng đồng thời. Hiệu suất phẳng của các công cụ dựa trên InnoDB dưới tải đồng thời chỉ ra tiềm ẩn nút thắt cổ chai trong các triển khai vector hiện tại hoặc thư viện kết nối của chúng. Các kỹ sư phải tính đến những đặc điểm mở rộng này khi thiết kế kiến trúc hệ thống, có thể cần thêm các chiến lược cân bằng tải hoặc gom nối (connection pooling) cho các công cụ không mở rộng tốt một cách tự nhiên.

Bạn có thể làm gì

• Đánh giá tần suất lập lại chỉ mục; nếu bạn cập nhật embedding thường xuyên, hãy ưu tiên các công cụ có thời gian xây dựng nhanh hơn như PostgreSQL hoặc Valkey.
• Kiểm thử hiệu suất tìm kiếm có bộ lọc với phân bố metadata cụ thể của bạn, vì cấu hình mặc định có thể dẫn đến recall kém hoặc độ trễ cao.
• Cân nhắc chi phí lưu trữ so với thời gian xây dựng; nếu không gian đĩa đắt đỏ, các chỉ mục nhỏ hơn của MariaDB có thể biện minh cho cửa sổ xây dựng dài hơn.
• Benchmark đồng thời cho tải người dùng dự kiến, lưu ý rằng một số công cụ có thể yêu cầu nhiều instance hơn để xử lý hiệu quả các truy vấn song song.
• Xem xét các thư viện kết nối cho khách hàng ngôn ngữ cụ thể, vì những hạn chế của khung thử nghiệm trong nghiên cứu này gợi ý rằng nút thắt cổ chai ở cấp driver có thể che giấu hiệu suất cơ sở dữ liệu.
• Giám sát mức sử dụng bộ nhớ trong quá trình xây dựng chỉ mục, vì RSS đỉnh dao động từ 14,3 GB đến 48,8 GB, ảnh hưởng đến yêu cầu cung cấp hạ tầng.