Databricks Mang Tìm Kiếm Toàn Văn Bản và Vector vào Lakebase Postgres

Databricks vào ngày 28 tháng 9, 2026, đã giới thiệu Lakebase Search, một công cụ tìm kiếm tích hợp cho cơ sở dữ liệu Lakebase Postgres của mình, được cung cấp thông qua hai phần mở rộng: lakebasevector cho tìm kiếm lân cận gần nhất xấp xỉ và lakebasetext cho tìm kiếm toàn văn bản BM25. Cả hai phần mở rộng đều có sẵn chung trên AWS và Azure.

Các phần mở rộng cho phép các nhà phát triển thực hiện tìm kiếm ngữ nghĩa, từ khóa và hỗn hợp trực tiếp bên trong Postgres cùng với dữ liệu hoạt động. Databricks cho biết các hệ thống OLTP truyền thống không được xây dựng để đáp ứng nhu cầu tìm kiếm của các tác nhân AI, những người đòi hỏi truy xuất độ trễ thấp, độ chính xác cao và thường thực hiện các tìm kiếm song song quy mô lớn, và rằng việc giải quyết vấn đề này cho đến nay đồng nghĩa với việc gắn một công cụ tìm kiếm độc lập vào cơ sở dữ liệu chính thông qua một quy trình ETL. Công ty cho biết họ đã xây dựng Lakebase Search dựa trên phản hồi từ hàng trăm khách hàng beta.

Kết Quả Đánh Giá và Triển Khai Conexiom

Databricks cho biết lakebase_vector cung cấp gấp đôi thông lượng so với hệ thống kế tiếp tốt nhất trên bộ chuẩn VectorDBBench 100M, sử dụng bộ dữ liệu LAION, và rằng nó rẻ hơn bốn lần so với nhà cung cấp Postgres đám mây sử dụng pgvector, chưa kể các khoản tiết kiệm bổ sung từ việc tự động mở rộng. Công ty báo cáo độ trễ P99 là 71 mili giây với độ thu hồi 97%, nghĩa là công cụ đã truy xuất thành công các hàng xóm gần nhất thực sự 97% thời gian, và lưu ý rằng pgvector và DiskANN chỉ được thử nghiệm trên một phiên bản lớn duy nhất.

Databricks cũng báo cáo kết quả của một khách hàng từ Conexiom, công ty này chạy tìm kiếm hỗn hợp BM25 trên hơn 100 triệu dòng với mức tiêu thụ tính toán bằng một nửa so với cấu hình pgvector trước đây của họ. Chi phí hạ tầng của Conexiom giảm ba lần và thông lượng tăng năm lần so với pgvector, công ty cho biết.

“Lakebase Search mang lại cho chúng tôi một mức độ mở rộng hoàn toàn mới so với pgvector, và mở khóa BM25 trong cùng một cơ sở dữ liệu không máy chủ,” Jordan Voves, kiến trúc sư AI/ML tại Conexiom, nói. “Chúng tôi sử dụng Lakebase để kết nối dữ liệu với các tác nhân của mình ở quy mô lớn.”

Các Giới Hạn của Pgvector Đằng Sau Thiết Kế

Databricks cho biết pgvector là phần mở rộng được cài đặt nhiều nhất trong Lakebase Postgres, và họ mô tả ba vấn đề đau đầu lặp lại được khách hàng gặp phải khi vận hành nó ở quy mô lớn.

Điểm đầu tiên là chi phí tăng theo khối lượng dữ liệu hơn là theo mức sử dụng. pgvector giữ chỉ mục HNSW trong bộ nhớ cơ sở dữ liệu, và vì tìm kiếm HNSW dựa trên việc duyệt đồ thị truy cập ngẫu nhiên, hiệu năng giảm từ 10 đến 50 lần khi chỉ mục tràn sang đĩa và các truy vấn trở thành chuỗi đọc ngẫu nhiên. Một vector float32 768 chiều chiếm khoảng 3,3 kilobyte bộ nhớ khi đã tính cả liên kết đồ thị và chi phí phụ trợ của Postgres, vì vậy một chỉ mục trên 100 triệu dòng cần khoảng 330 gigabyte RAM để duy trì, được cung cấp đầy đủ dù các truy vấn có truy cập hay không.

Điểm thứ hai là bảo trì chỉ mục. Khi một lần xây dựng tràn sang đĩa, một chỉ mục pgvector mất gần 50 giờ để xây dựng trên một máy ảo đám mây tiêu chuẩn, Databricks cho biết, và các thao tác ghi cũng gặp cùng một nút thắt vì việc chèn một vector đòi hỏi duyệt truy cập ngẫu nhiên và sửa đổi nhiều lớp đồ thị. Vì HNSW không có cân bằng lại toàn cục, việc khôi phục chất lượng tìm kiếm đồng nghĩa với việc chạy một REINDEX toàn bộ, một thao tác khóa bảng và ngừng các ghi sản xuất.

Điểm thứ ba là một truy vấn đơn không thể được song song hoá. Một truy vấn pgvector được thực thi bởi một tiến trình backend của Postgres, khiến việc quét chỉ mục HNSW không có bất kỳ sự song song nào. Tăng độ thu hồi yêu cầu truy cập nhiều nút đồ thị hơn, điều này làm tăng các lần đọc bộ nhớ ngẫu nhiên và các phép so sánh khoảng cách, làm tăng độ trễ và giảm số truy vấn mỗi giây, vì vậy mở rộng thông lượng đồng nghĩa với việc thêm kết nối cơ sở dữ liệu hoặc các bản sao đọc.

Cách Lakebase_vector Được Xây Dựng

Lakebase Postgres tách riêng lưu trữ khỏi tính toán: dữ liệu cố định nằm trong lưu trữ đối tượng đám mây chi phí thấp, trong khi RAM và NVMe cục bộ hoạt động như bộ nhớ đệm ngắn hạn giữ tập dữ liệu đang hoạt động. Trên nền tảng này, Databricks kết hợp hai kỹ thuật.

Phân cụm IVF theo thứ bậc nhóm các vector thành các cụm được lưu trữ dưới dạng các khối liên tiếp. Một truy vấn tính điểm cho các trung tâm cụm trong bộ nhớ, sau đó chỉ đọc một vài khối có vẻ tiềm năng như các lần đọc tuần tự lớn thay vì thực hiện nhiều bước nhảy ngẫu nhiên. Phương pháp lượng tử nhị phân, sử dụng kỹ thuật RaBitQ, nén mỗi vector xuống khoảng một bit mỗi chiều, khoảng 32 lần nhỏ hơn so với float32, vì vậy các truy vấn quét các mã nén để tạo danh sách ngắn các ứng cử viên và chỉ sắp xếp lại danh sách ngắn này so với các vector độ chính xác đầy đủ.

Vì thiết kế không trạng thái, nó có thể mở rộng xuống mức zero, và khi không hoạt động người dùng chỉ trả phí lưu trữ. Databricks báo cáo P90 đo được là 1,13 giây cho truy vấn đầu tiên sau khi mở rộng xuống zero trên bộ dữ liệu 100 triệu vector, 768 chiều, và cho biết 100 triệu vector có thể được phục vụ trên một Lakebase Compute Unit.

Quá trình xây dựng chỉ mục huấn luyện các centroid cụm một lần duy nhất trên một mẫu ngẫu nhiên nhỏ; mỗi vector sau đó được gán cho centroid gần nhất, được lượng tử hoá và ghi vào khối thích hợp như một thao tác độc lập, vì vậy công việc được phân tán trên số lõi có sẵn. Databricks cho biết kiến trúc LTAP của họ chuyển tải việc xây dựng chỉ mục từ cơ sở dữ liệu chính sang các engine phân tán như Spark, rút ngắn thời gian xây dựng xuống còn vài phút, và cho biết sẽ có thêm tính năng trong tương lai. Vì các điều kiện được áp dụng trong quá trình quét khối, các truy vấn đã lọc tránh việc lấy quá nhiều ứng cử viên và duy trì độ thu hồi cao, và một truy vấn đơn có thể song song hoá trên các lõi CPU.

Tìm kiếm Văn bản BM25 và Truy vấn Lai

Databricks cho biết tìm kiếm tsvector tiêu chuẩn của Postgres thiếu ngữ cảnh liên quan trên toàn bộ tập dữ liệu. lakebase_text tính điểm cho các thuật ngữ bằng cách sử dụng tần suất ngược tài liệu toàn cầu, cho trọng số cao hơn cho các thuật ngữ hiếm, có ý định mạnh và ít trọng số hơn cho các từ thường dùng. Nó cũng kiểm tra giới hạn trên của điểm khi duyệt chỉ mục, loại bỏ toàn bộ các khối posting mà không thể ảnh hưởng đến kết quả top-K, điều mà công ty cho rằng làm cho nó nhanh hơn so với tsvector sử dụng các chỉ mục GIN.

Kết hợp hai tiện ích mở rộng này cho phép tìm kiếm lai bản địa trong Postgres: một truy vấn duy nhất có thể áp dụng các điều kiện lọc SQL thông thường, nối các bảng hoạt động trực tiếp, và kết hợp điểm vector ngữ nghĩa với độ liên quan từ khóa BM25. Databricks cho biết hệ thống có thể mở rộng từ một hàng tới một tỷ vector và từ một truy vấn mỗi giây lên hàng ngàn mà không cần tái cung cấp thủ công, mô tả thiết kế này dành cho các tác nhân AI mà quy trình làm việc có thể kích hoạt hàng ngàn yêu cầu truy xuất đồng thời trong vòng vài giây.

Databricks định vị Lakebase Search cho những người dùng muốn dữ liệu vận hành và tìm kiếm được hợp nhất trong một cơ sở dữ liệu duy nhất, trong khi Databricks AI Search vẫn là động cơ quản lý của họ cho việc truy xuất hoạt động ngay lập tức. Lakebase Search hiện đã có sẵn trên AWS và Azure; người dùng Lakebase hiện tại có thể bật các tiện ích mở rộng, và người dùng mới có thể đăng ký sử dụng Lakebase.