OpenData Vector: Công cụ tìm kiếm Vector mã nguồn mở trên Object Storage

OpenData Vector là một giải pháp tìm kiếm vector mới nổi, được cấp phép MIT và xây dựng trên nền tảng SlateDB. Đây là một công cụ tìm kiếm không trạng thái (stateless), bền bỉ và có tính sẵn sàng cao, có thể chạy ở bất kỳ đâu có quyền truy cập vào Object Storage (lưu trữ đối tượng). OpenData Vector được thiết kế để đủ đơn giản để người dùng tự vận hành, nhưng lại đủ hiệu quả để phục vụ tới 100 triệu vector với chi phí khoảng 350 USD/tháng.

Giải pháp này ra đời nhằm lấp đầy khoảng trống giữa việc tự chạy pgvector và việc phải trả phí cho các nhà cung cấp dịch vụ tìm kiếm database, nơi chi phí thường cao gấp nhiều lần so với chi phí phần cứng thực tế.

Kiến trúc không trạng thái (Stateless)

Trong cộng đồng cơ sở dữ liệu hiện nay, có sự đồng thuận ngày càng tăng rằng Object Storage là một giải pháp tuyệt vời. Các cam kết về độ bền SLA lên tới 99.999999999%, hiệu quả về chi phí (lưu trữ rẻ hơn 1/4, mạng lưới cross-AZ miễn phí) và tính nhất quán mạnh mẽ là những cơn ác mộng của hệ thống phân tán đã được Object Storage giải quyết triệt để.

Do đó, trong thập kỷ qua, các hệ thống trực tuyến đã ngày càng phụ thuộc nhiều hơn vào Object Storage. Chúng ta đã chứng kiến sự tiến hóa qua ba thế hệ:

• Thế hệ 1 (Tiered Storage): Lưu trữ phân tầng, nơi dữ liệu lạnh được lưu trên S3.
• Thế hệ 2 (Disaggregated): Tách biệt hoàn toàn, ủy thác độ bền và sao chép cho Object Storage, nhưng các nút (node) vẫn được gán shard cục bộ và cần phối hợp để cân bằng lại tải.
• Thế hệ 3 (Stateless): Không trạng thái, ủy thác cả quản lý metadata cho Object Storage, cho phép bất kỳ nút nào cũng có thể phục vụ bất kỳ dữ liệu nào.

OpenData Vector thuộc về thế hệ thứ 3. Các hệ thống không trạng thái này đơn giản hơn đáng kể, do đó rẻ hơn, đáng tin cậy hơn và dễ vận hành hơn các thế hệ tiền nhiệm.

Tối ưu hóa cho Object Storage

Để có khả năng cạnh tranh về hiệu suất và chi phí với kiến trúc không trạng thái, chỉ mục của Vector cần được tối ưu hóa cho độ trễ cao và các yêu cầu GET tốn kém của Object Storage. Điều này có nghĩa là phải lấy dữ liệu chỉ mục theo lô (batch).

Vector thực hiện điều này bằng cách duy trì một chỉ mục tệp ngược (Inverted File Index - IVF) dựa trên SPFresh. Chỉ mục này nhóm các vector thành các cụm (clusters) sử dụng thuật toán k-means. Mỗi cụm được đại diện bởi một vector "trung tâm" (centroid), nắm giữ các tham chiếu đến các vector trong cụm của nó thông qua một "posting list" trong SlateDB. Quá trình tìm kiếm diễn ra bằng cách tìm các centroid gần nhất với truy vấn, sau đó chấm điểm (scoring) toàn diện các vector từ danh sách đăng ký của chúng.

Lựa chọn này khác với các chỉ mục dựa trên đồ thị như HNSW hay Vamana. IVF được chọn vì hai lý do chính: Thứ nhất, các chỉ mục đồ thị yêu cầu việc duyệt qua từng nút, yêu cầu các yêu cầu GET tuần tự đến Object Storage (trong đó độ trễ byte đầu tiên có thể lên tới 100ms). IVF có thể tải dữ liệu theo lô mỗi vòng lặp. Thứ hai, việc duy trì các chỉ mục dựa trên đồ thị rất tốn kém khi có các lượt ghi mới đến.

Độ trễ và thông lượng truy vấn

Đơn giản hóa việc triển khai

Như tất cả các hệ thống OpenData, kiến trúc không trạng thái của Vector giúp việc chạy một hệ thống sản xuất trên một single Kubernetes pod trở nên khả thi.

Tuy nhiên, để xử lý nhiều yêu cầu khác nhau, Vector có thể chạy với nhiều cấu hình khác nhau và cung cấp mức độ sẵn sàng cao hơn mà không làm giảm tính đơn giản của việc triển khai:

• Topology 1 (Embedded): Vector chạy cùng trong quá trình ứng dụng của bạn.
• Topology 2 (Single-Node): Một quá trình Vector độc lập kết nối với S3.
• Topology 3 (Writer + Readers): Tách biệt quá trình ghi và đọc để mở rộng quy mô.
• Topology 4 (Buffered Ingest): Sử dụng cơ chế nhập liệu có vùng đệm (buffer) để tối ưu hóa việc ghi.

Các chế độ khác nhau này mang lại cho bạn toàn quyền kiểm soát đường cong chi phí/độ phức tạp tùy theo yêu cầu. Chạy một nút đơn trong sản xuất sẽ không bao giờ làm mất dữ liệu, và việc chuyển đổi dự phòng (failover) có thể diễn ra trong vài giây.

Hiệu năng và Đánh đổi

Vector thực hiện hai sự đánh đổi có ý nghĩa để đạt được thiết kế không trạng thái của mình:

1. Độ trễ truy vấn Warm vs Cold: Cấu trúc chỉ mục IVF cần đánh giá nhiều vector hơn một chỉ mục đồ thị được tối ưu hóa như HNSW. Trong thực tế, điều này có nghĩa là các truy vấn "ấm" (warm) chạy trong khoảng 10ms so với mili-giây dưới mức. Tuy nhiên, các truy vấn "lạnh" (cold) có thể chạy dưới một giây, trong khi chỉ mục HNSW có thể cần hàng chục giây để tải một đồ thị lạnh.
2. Độ trễ ghi: Vector gộp nhiều lượt ghi lại với nhau để phân bổ chi phí PUT của object store và công việc lập chỉ mục trên nhiều lần ghi. Điều này có nghĩa là có thể mất tới một giây để Vector xác nhận một lượt ghi là bền vững.

Thông lượng nhập liệu

Theo các bài kiểm tra chuẩn (benchmark), Vector duy trì thông lượng giữa ~1K và ~12K vector ghi/giây, tùy thuộc vào kích thước dữ liệu và chiều vector. Độ trễ truy vấn ấm (P90) nằm trong mức mili-giây thấp cho các tập dữ liệu nhỏ và mức十几 mili-giây cho các tập dữ liệu lớn hơn.

Tương lai của OpenData Vector

Đội ngũ phát triển có một số kế hoạch nâng cấp để cải thiện khả năng truy xuất và tăng hiệu suất, bao gồm hỗ trợ các kiểu dữ liệu vector nhỏ hơn (ví dụ: byte, float 16-bit) và lượng tử hóa (quantization). Ngoài ra, họ đang thêm hỗ trợ tìm kiếm văn bản đầy đủ (full-text search) để người dùng có thể sử dụng Vector như một cơ sở dữ liệu tìm kiếm chung hỗ trợ cả tìm kiếm ngữ nghĩa và văn bản.

OpenData Vector hiện đã có sẵn với giấy phép MIT. Bạn có thể đọc tài liệu RFC về lưu trữ, tìm hiểu thêm về thiết kế, hoặc thử nghiệm nhanh qua trang chủ của dự án.