Databricks добавляет полнотекстовый и векторный поиск в Lakebase Postgres

Databricks 28 сентября 2026 г., представил Lakebase Search, встроенный поисковый движок для его базы данных Lakebase Postgres, поставляемый через два расширения: lakebaseвектор для поиска приближенных ближайших соседей и lakebasetext для полнотекстового поиска BM25. Оба расширения доступны в AWS и Azure.

Эти расширения позволяют разработчикам выполнять семантический, ключевой и гибридный поиск непосредственно внутри Postgres рядом с операционными данными. Databricks заявила, что традиционные OLTP‑системы не предназначены для поисковых требований AI‑агентов, которым необходимы низкая задержка, высокая точность извлечения и часто выполнение масштабных параллельных поисков, а решение этой задачи до настоящего времени означало подключение отдельного поискового движка к основной базе данных через ETL‑конвейер. Компания заявила, что построила Lakebase Search, опираясь на отзывы сотен бета‑клиентов.

Результаты тестов и развертывание Conexiom

Databricks заявила, что lakebase_вектор обеспечивает вдвое большую пропускную способность по сравнению со следующей лучшей системой в тесте VectorDBBench 100M, использующем набор данных LAION, и что он в четыре раза дешевле, чем облачный поставщик Postgres, использующий pgvector, без учёта дополнительных экономий от автмасштабирования. Компания сообщила о P99‑задержке 71 мс при 97 % полноте, что означает, что движок успешно находил истинных ближайших соседей в 97 % случаев, и отметила, что pgvector и DiskANN были протестированы только на одной крупной инстанции.

Databricks также сообщила о результате клиента Conexiom, который выполняет гибридный поиск BM25 более чем по 100 млн строк, используя вдвое меньший вычислительный ресурс по сравнению с предыдущей конфигурацией pgvector. По словам компании, инфраструктурные расходы Conexiom сократились в три раза, а пропускная способность выросла в пять раз относительно pgvector.

«Lakebase Search дает нам совершенно новый уровень масштабируемости по сравнению с pgvector и открывает BM25 в той же безсерверной базе данных», — сказал Джордан Вовес, архитектор AI/ML в Conexiom. «Мы используем Lakebase, чтобы подключать данные к нашим агентам в масштабе».

Ограничения pgvector, лежащие в основе дизайна

Databricks заявила, что pgvector является самым часто устанавливаемым расширением в Lakebase Postgres, и описала три повторяющиеся проблемы, наблюдаемые у клиентов, использующих его в масштабе.

Первой является стоимость, масштабируемая с объёмом данных, а не с использованием. pgvector хранит свой HNSW‑индекс в памяти базы данных, и поскольку поиск HNSW опирается на обход графа со случайным доступом, производительность падает в 10‑50 раз, как только индекс переходит на диск и запросы превращаются в цепочки случайных чтений. Вектор размерностью 768 в формате float32 занимает около 3,3 КБ памяти с учётом связей графа и накладных расходов Postgres, поэтому индекс более 100 млн строк требует примерно 330 ГБ ОЗУ для постоянного размещения, полностью выделяемый независимо от того, обращаются ли к нему запросы.

Вторая — обслуживание индекса. Когда построение переходит на диск, индекс pgvector занимал почти 50 часов на стандартном облачном инстансе, сообщила Databricks, и записи страдают от того же узкого места, поскольку вставка вектора требует обхода с случайным доступом и модификации нескольких слоёв графа. Поскольку у HNSW нет глобального ребалансирования, восстановление качества поиска означает запуск полного REINDEX, операции, блокирующей таблицу и останавливающей записи в продакшн.

Третья — невозможность параллелизации отдельного запроса. Запрос pgvector выполняется одним процессом backend Postgres, оставляя сканирование HNSW‑индекса без какой‑либо параллелизации. Увеличение полноты требует обхода большего количества узлов графа, что добавляет случайные чтения памяти и сравнения расстояний, увеличивая задержку и снижая количество запросов в секунду, поэтому масштабирование пропускной способности подразумевает добавление соединений с базой данных или реплик чтения.

Как построен Lakebase_vector

Lakebase Postgres разделяет хранение и вычисления: постоянные данные находятся в недорогом облачном объектном хранилище, тогда как ОЗУ и локальный NVMe служат краткоживущими кэшами, удерживающими активный рабочий набор. На этой основе Databricks объединила два метода.

Иерархическая кластеризация IVF группирует векторы в кластеры, хранящиеся как смежные блоки. Запрос оценивает центроиды кластеров в памяти, а затем читает только небольшое количество блоков, которые выглядят перспективными, как крупные последовательные чтения, вместо множества случайных переходов. Бинарная квантизация с использованием метода RaBitQ сжимает каждый вектор до примерно одного бита на измерение, что примерно в 32 раза меньше, чем float32, поэтому запросы сканируют компактные коды, формируют короткий список кандидатов и переупорядочивают только этот список по сравнению с векторами полной точности.

Поскольку дизайн без состояния, он масштабируется до нуля, а в простое пользователи платят только за хранение. Databricks сообщила измеренный P90 = 1,13 секунды для первого запроса после масштабирования до нуля на наборе данных из 100 млн векторов размерностью 768, и заявила, что 100 млн векторов могут обслуживаться одним Lakebase Compute Unit.

Построение индекса обучает центроиды кластеров один раз на небольшом случайном наборе; каждый вектор затем назначается ближайшему центроиду, квантуется и записывается в соответствующий блок как независимая операция, поэтому работа распределяется на столько ядер, сколько доступно. Databricks заявила, что её архитектура LTAP переносит построение индексов из основной базы данных на распределённые движки, такие как Spark, сокращая время построения до минут, и добавила, что в этом направлении планируются дальнейшие улучшения. Поскольку предикаты применяются во время самого сканирования блока, отфильтрованные запросы избегают избыточного извлечения кандидатов и сохраняют высокий уровень полноты, а один запрос параллелится по ядрам CPU.

Текстовый поиск BM25 и гибридные запросы

Databricks заявила, что стандартный поиск tsvector в Postgres не учитывает контекст релевантности по всему корпусу. lakebase_text оценивает термины, используя глобальную обратную частоту документов, придавая больший вес редким, целенаправленным терминам и меньший — распространённым «заполнительным» словам. Он также проверяет верхние границы оценки при обходе индекса, отбрасывая целые блоки постингов, которые не могут повлиять на результат топ‑K, что, по словам компании, делает его быстрее, чем tsvector с GIN‑индексами.

Комбинация двух расширений позволяет выполнять нативный гибридный поиск внутри Postgres: один запрос может применять обычные предикаты фильтрации SQL, соединять живые оперативные таблицы и объединять семантическую оценку векторов с релевантностью ключевых слов BM25. Databricks заявила, что система масштабируется от одной строки до одного миллиарда векторов и от одного запроса в секунду до тысяч без ручного перераспределения ресурсов, описывая дизайн как предназначенный для AI‑агентов, чьи рабочие процессы могут генерировать тысячи одновременных запросов извлечения за секунды.

Databricks позиционирует Lakebase Search для пользователей, желающих консолидировать оперативные и поисковые данные в единой базе, тогда как Databricks AI Search остаётся их управляемым движком для извлечения, готовым к использованию сразу же. Lakebase Search доступен в общем доступе на AWS и Azure; существующие пользователи Lakebase могут включить расширения, а новые пользователи могут зарегистрироваться в Lakebase.