Оценка емкости Lakebase Search: уроки реального приложения и 4 миллионов фрагментов

Slide Hub — это внутреннее приложение Databricks. Инженеры по работе с клиентами используют его для поиска и повторного использования слайдов примерно из 700 внутренних презентаций: выступлений на мероприятиях, презентаций продуктов и архитектурных презентаций. Панель поиска находит отдельные слайды по смыслу и ключевым словам, а сервер Model Context Protocol (MCP) предоставляет ИИ-агентам те же возможности поиска. Приложение хранит свои слайды, голоса, телеметрию поиска и историю изменений в Lakebase Postgres. Мы используем Slide Hub в качестве базового примера для тестирования производительности Lakebase Postgres. Это реальное приложение с реальным вариантом использования и реальными пользователями, поэтому его показатели демонстрируют, как база данных ведет себя при реальной рабочей нагрузке.

Эта статья предназначена для разработчиков и архитекторов, которые создают приложения на базе Databricks и хотят встроить поиск в собственную базу данных приложений Lakebase Postgres. В ней предполагается, что вы знаете SQL и основы PostgreSQL. Если вы планируете создать поисковую строку или инструмент для агента на базе Lakebase Postgres, приведенные ниже цифры помогут вам выбрать размер вычислительных ресурсов перед запуском в производство.

В этой статье показано, как Slide Hub выполняет поиск внутри Lakebase Postgres, какие ограничения возникают при высокой нагрузке, во сколько это обходится и как ведет себя Lakebase Search при объеме от 1 млн до 4 млн строк общедоступного корпуса данных.

Одна база данных для приложения и его поиска

Lakebase Search стал общедоступным в сентябре. Это набор расширений Postgres, поэтому он работает рядом с таблицами приложения. Приложение не копирует данные в отдельную поисковую систему. Разработчику не нужно поддерживать второй путь транзакций.

Две команды CREATE EXTENSION активируют эти компоненты. lakebase_vector хранит эмбеддинги — числовые векторы, представляющие смысл текста, — и поддерживает индекс lakebase_ann для поиска методом приближенных ближайших соседей (ANN). lakebase_text поддерживает индекс lakebase_bm25 для алгоритма BM25, стандартного метода ранжирования текста по содержащимся в запросе словам. lakebase_tokenizer является необязательным. Индекс ANN использует разбиение на разделы IVF, которое группирует похожие векторы, благодаря чему запрос считывает лишь несколько групп, а также квантование RaBitQ, сжимающее каждый вектор примерно до 1 бита на измерение. BM25 оценивает текст с помощью оператора <@>.

23 тысячи строк слайдов в Slide Hub располагаются в том же бессерверном экземпляре Lakebase Postgres, что и голоса, телеметрия, история изменений, превью и оба индекса. Приложение считывает данные и индексы в рамках одного соединения и одной модели разрешений.

Поисковый запрос

Slide Hub выполняет гибридный поиск. Он объединяет векторный поиск, который находит слайды с похожим на запрос смыслом, и поиск по ключевым словам BM25, который находит слайды, содержащие слова запроса. Каждый метод возвращает короткий список лучших совпадений — кандидатов. Один оператор SQL реализует всю политику ранжирования. Он ранжирует каждый список кандидатов, объединяет два рейтинга, применяет фильтры приложения и соединяет голоса. Логика поиска и приложения разделяют одно соединение, один набор предоставленных прав (grants) и одну операцию фиксации (commit).

Slide Hub берет по 200 кандидатов от каждого метода. Он объединяет два списка с помощью метода Reciprocal Rank Fusion (RRF) при k=60: слайд получает оценку 1/(60 + его ранг) в каждом списке, и обе оценки складываются. Порог сходства 0.70 отклоняет векторные совпадения, которые находятся слишком далеко от запроса, чтобы быть полезными для данной модели эмбеддингов. Уровни заголовков добавляют вес, когда запрос совпадает с заголовком слайда. Заметки получают вес 0.5. Фильтры области видимости ограничивают результат активами, на просмотр которых у пользователя есть разрешение.

Что ограничивает приложение при нагрузке

Запрос на поиск использует два независимых вычислительных ресурса, и любой из них может стать узким местом.

Вычислительные ресурсы Lakebase Postgres управляют базой данных. Lakebase Postgres измеряет их в единицах вычислений (Compute Units, CU). Одна единица CU выделяет базе данных около 2 ГБ оперативной памяти, а также соответствующую долю ЦП и локального SSD. Вычислительные мощности автоматически масштабируются между минимальным и максимальным размером от 0.5 CU до 64 CU, причем максимум может превышать минимум не более чем на 16 CU. Ресурсы фиксированного размера достигают 112 CU, а ресурсы размером до 32 CU могут масштабироваться до нуля. Postgres хранит таблицы и индексы на страницах по 8 КБ. Lakebase Postgres хранит недавно прочитанные страницы в локальном файловом кеше (Local File Cache, LFC) на вычислительном узле. Кеш увеличивается вместе с размером CU и может занимать до 75% памяти вычислительного модуля. Страница, отсутствующая в кеше, загружается из хранилища, что занимает больше времени.

Вычислительные ресурсы Databricks Apps запускают веб-сервер Slide Hub. Его размер фиксирован для каждого приложения. Приложение уровня MEDIUM имеет до 2 виртуальных ЦП и 6 ГБ памяти, а приложение уровня LARGE — до 4 виртуальных ЦП и 12 ГБ. Slide Hub запускает один экземпляр приложения. Каждый рабочий процесс Python в нем содержит пул из 8 соединений с базой данных, поэтому 2 воркера открывают максимум 16 соединений, а 4 воркера — максимум 32.

Для каждого запроса приложение генерирует эмбеддинг текста запроса, отправляет один SQL-оператор в Lakebase Postgres и возвращает результат. Чтобы найти предел, тест изменяет параметры поочередно. Он фиксирует Lakebase Postgres на одном размере CU и меняет приложение, либо сохраняет приложение неизменным и меняет размер CU. Генератор нагрузки имитирует пользователей, отправляющих поисковые запросы, и поэтапно увеличивает количество пользователей. В списке указаны запросы в секунду и медианная задержка (p50) при 500 пользователях для каждого размера Lakebase Postgres и приложения.

• 1 CU, приложение MEDIUM с 2 воркерами: 196 запр/с, p50 1.8 с
• от 0.5 до 1 CU, приложение LARGE с 4 воркерами: 193 запр/с, p50 1.6 с
• 2 CU, приложение MEDIUM с 2 воркерами: 201 запр/с, p50 1.8 с
• 4 CU, приложение MEDIUM с 2 воркерами: 219 запр/с, p50 1.6 с
• 8 CU, приложение MEDIUM с 2 воркерами: 336 запр/с, p50 1.0 с
• 16 CU, приложение MEDIUM с 2 воркерами: 349 запр/с, p50 1.0 с
• 16 CU, приложение LARGE с 4 воркерами: не менее 662 запр/с, p50 343 мс

До 4 CU узким местом является Lakebase. Приложение LARGE с удвоенным количеством воркеров и соединений ничего не добавляет при 1 CU. При 1 CU поисковый запрос выполнялся в среднем за 146 мс и считывал 14.9 млн страниц из хранилища при размере файлового кеша 1.5 ГБ. При 8 CU время выполнения составляло в среднем 34 мс при кеше 12 ГБ, а пропускная способность выросла примерно на 50%.

Начиная с 8 CU, узким местом становится приложение. 16 CU с тем же приложением MEDIUM добавляют всего 4%, а его соединения с базой данных большую часть времени простаивают. Приложение LARGE с 4 воркерами при 16 CU достигает как минимум 662 запр/с, и здесь ограничителем выступал уже сам генератор нагрузки. Сначала рассчитайте размер запроса. Затем масштабируйте Lakebase Postgres до тех пор, пока узким местом не станут воркеры приложения, после чего масштабируйте приложение.

Вывод: найдите предел перед масштабированием. Ниже 8 CU добавляйте вычислительные единицы Lakebase Postgres. Начиная с 8 CU, выделите приложению больше воркеров.

Пул соединений по-прежнему необходим. При 50 пользователях приложение достигало 45 запр/с и 2.4 с p95 без пула, и 85 запр/с и 0.7 с p95 с ним. Кеш эмбеддингов не показал измеримой разницы при нагрузке.

Пулы кандидатов и холодные старты

Лимит кандидатов определяет количество страниц, к которым обращается запрос. При холодном кеше этот показатель определяет задержку. Slide Hub поставлялся с 1000 кандидатов на метод. В документации рекомендуется использовать 40. В эксперименте с лимитом кандидатов изменялся только параметр candidate_limit, при этом измерялись 20 публичных запросов в трех состояниях. «Холодный» (Cold) — это первый запрос после масштабирования вычислительных ресурсов до нуля с пустым кешем. «Первое касание» (First-touch) — это первый запуск запроса на работающих вычислительных ресурсах. «Повторный» (Repeat) — это тот же запрос, запущенный повторно, когда его страницы находятся в кеше. «Прочитанные страницы» (Pages touched) подсчитывает страницы, которые запрос считывает из любого источника. «Перекрытие топ-10» (Top-10 overlap) — это доля результатов из первой десятки, совпадающих с результатом при 1000 кандидатов.

• 40 кандидатов: «холодный» запуск — 127 мс, первое обращение — 13 мс, повторный — 5,0 мс. Задействовано страниц: 5 655. Пересечение в топ-10: 74,5%.
• 100 кандидатов: «холодный» запуск — 240 мс, первое обращение — 16 мс, повторный — 7,9 мс. Задействовано страниц: 7 355. Пересечение в топ-10: 89%.
• 200 кандидатов: «холодный» запуск — 387 мс, первое обращение — 24 мс, повторный — 11,7 мс. Задействовано страниц: 10 401. Пересечение в топ-10: 90,5%.
• 1 000 кандидатов: «холодный» запуск — 740 мс, первое обращение — 109 мс, повторный — 35,3 мс. Задействовано страниц: 28 972. Пересечение в топ-10: 100% (эталон).

При 200 кандидатах 90,5% топ-10 остается прежним, а заявленное количество совпадений составляет 81% от значения при 1 000 кандидатах. Пользователи редко просматривают больше 200 результатов, поэтому Slide Hub теперь по умолчанию использует 200. Измерения от начала до конца для задачи в том же облачном регионе, что и приложение, показали, что «холодный» поиск при 200 кандидатах занял 2,9 с, а повторный — 40 мс. Время «холодного» запуска состоит из двух частей. Соединение ожидает около 1 с, пока эндпоинт просыпается. Затем каждый запрос считывает свои страницы из хранилища до тех пор, пока кэш не прогреется. Первый запрос по новому соединению также тратит около 75 мс на планирование.

Вывод: держите пул кандидатов небольшим. 200 кандидатов сохраняют 90,5% из топ-10 результатов, считывают примерно треть страниц по сравнению с 1 000 кандидатов и вдвое сокращают задержку при «холодном» запуске.

Масштаб: от 1 млн до 4 млн строк MIRACL English

В тестах масштабирования используется MIRACL English, корпус фрагментов текста, созданный на основе Википедии. Полный корпус содержит 32 893 221 фрагмент. Мы встроили его с помощью gte-large-en-v1.5, открытой модели с размерностью 1024, размер которой совпадает с эмбеддингами Slide Hub. Мы развернули модель самостоятельно на одном графическом процессоре A10G со скоростью 379 фрагментов в секунду. Обработка всего корпуса заняла 2,95 часа работы GPU по сравнению с $48.87 за ту же работу на эндпоинте обслуживания моделей. Векторы GPU совпали с векторами эндпоинта (среднее косинусное расстояние 1,0000, минимум 0,9978).

Мы создали три подмножества: 1 млн, 2 млн и 4 млн фрагментов. Индекс lakebase_ann рос вместе с корпусом: 5,8 ГБ при 1 млн, 11,5 ГБ при 2 млн, 23,0 ГБ при 4 млн. Двоичная команда COPY загрузила все 4 млн строк за 19 минут при 8 вычислительных единицах (CU).

Lakebase Postgres удерживает около 1,6 ГБ файлового кэша на одну CU. Масштабирование порождает один вопрос: что происходит, когда индекс оказывается больше кэша? Каждая тестовая ячейка представляет собой определенный размер корпуса при определенном размере CU, поэтому кэш составляет известную долю индекса. Эту долю мы называем коэффициентом кэширования: размер кэша, деленный на размер векторного индекса. Коэффициент 1.0 означает, что индекс ровно помещается. Коэффициент попаданий — это доля прочитанных запросом страниц, которые не берутся из хранилища.

Мы запустили три набора запросов для каждой ячейки. Равномерный набор отправляет новый заголовок каждый раз и никогда не повторяется — это худший случай для кэша. Набор с неравномерным распределением выбирает заголовки из пула в 20 000 элементов по закону Ципфа, что является стандартной моделью для поискового трафика. Набор для «холодного» запуска выполняет первые запросы сразу после пробуждения, когда кэш пуст. Перед измерениями для равномерного и неравномерного наборов выполняется прогрев до тех пор, пока коэффициент попаданий не перестает изменяться. Результаты после прогрева мы называем «теплыми».

Коэффициент попаданий зависит от коэффициента кэширования

Коэффициент попаданий определяется коэффициентом кэширования. Размер корпуса на него не влияет: точки для 2 млн и 4 млн ложатся на одну кривую. При коэффициенте 0,07 для неравномерного набора в кэше оказалось 45% страниц. При 0,57 этот показатель составил 86%. При 1,14, когда индекс как раз помещается, — 97%. Равномерный набор располагается на несколько пунктов ниже, поскольку ничего не переиспользует.

Отсюда следует правило определения размеров. Измерьте размер своего индекса, выберите размер CU для желаемого коэффициента кэширования и определите коэффициент попаданий по кривой. Этот коэффициент применим для разных размеров корпуса, поэтому тест на 2 млн предсказывает поведение на 4 млн.

Вывод: рассчитывайте размер кэша исходя из векторного индекса, а не из количества строк. Кэш размером примерно с индекс обслуживает от 95% до 98% страниц без обращений к хранилищу.

Задержка зависит от коэффициента попаданий

«Теплый» векторный показатель p50 снизился со 187 мс при коэффициенте 0,07 до 4 мс при коэффициенте 2,3. Гибридный поиск держался на уровне около 800 мс, пока коэффициент не приближался к 1, после чего падал до 33 мс. Поисковая половина гибридного запроса по ключевым словам считывает больше всего страниц, поэтому она получает наибольшую выгоду от заполненного кэша.

Вывод: векторный поиск занимает от 160 до 230 мс, пока в кэше находится менее трети индекса, и от 11 до 23 мс, когда весь индекс помещается целиком.

Промах — это одна страница Postgres размером 8 КБ, которой нет в локальном файловом кэше. В векторном индексе одна страница содержит один или два эмбеддинга. Чтение одной страницы из хранилища обходится в фиксированное количество времени. Для каждого измеренного запроса время выполнения увеличивается примерно на 252 микросекунды на каждую пропущенную страницу для векторного поиска и на 316 микросекунд для гибридного. Запрос, пропускающий 2 000 страниц, тратит около полсекунды. Заполненный кэш убирает почти все промахи. Именно поэтому коэффициент кэширования определяет задержку: он задает, сколько страниц каждый запрос считывает из хранилища.

Вывод: каждая страница из хранилища добавляет около 0,3 мс. Умножьте количество промахов хранилища на запрос на 0,3 мс, чтобы оценить экономию от кэша.

При наличии кэша задержка почти не растет с увеличением корпуса

Сохраняйте коэффициент кэширования на уровне около 1.0 и изменяйте размер корпуса. Задержка «теплого» векторного поиска оставалась в диапазоне от 11 до 23 мс при росте от 1 млн до 4 млн. Задержка «теплого» гибридного поиска оставалась на уровне около 276 мс. «Холодные» запросы, которые считывают данные из хранилища, росли вместе с корпусом: «холодный» векторный запрос вырос с 44 мс при 1 млн до 133 мс при 4 млн, а «холодный» гибридный запрос достиг 911 мс при 4 млн.

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

Вывод: увеличивайте вычислительные мощности вместе с корпусом, и задержка для «теплых» запросов останется неизменной. Медленнее становятся только те запросы, которые не попадают в кэш по мере роста корпуса.

Пропускная способность масштабируется с вычислительными мощностями

Тест пропускной способности отправлял гибридные запросы напрямую в Lakebase Postgres, минуя приложение, поэтому он измеряет саму базу данных. Он одновременно открывал 1, 4, 16 или 64 соединения с Lakebase Postgres. Каждое соединение отправляло запрос, жгло ответ, а затем отправляло следующий. На графике показано общее количество запросов в секунду по всем соединениям. Когда линия выравнивается в горизонтальную плоскость, увеличение числа соединений больше не приводит к завершению дополнительных запросов. В этот момент Lakebase Postgres достигает своего предела, и каждый запрос начинает ждать дольше. Собственная загрузка ЦПУ генератора нагрузки оставалась близкой к нулю, поэтому все показатели определялись Lakebase Postgres.

На корпусе в 4 млн строк неравномерный набор достиг примерно 4 запросов в секунду при 2 CU, 15 при 8 CU и 65 при 16 CU. При 64 соединениях медианное время ожидания одного запроса составляло 14,5 с при 2 CU, 5,2 с при 8 CU и 343 мс при 16 CU. Равномерный набор при 16 CU достиг пика в 30 запросов в секунду, так как он никогда не переиспользует страницы. Пропускная способность масштабируется одновременно с размером вычислительных ресурсов и коэффициентом кэширования.

Воспринимайте эти показатели как стоимость промахов кэша под нагрузкой. Большинство запросов в реальном приложении повторяются или группируются, поэтому установившуюся емкость определяет коэффициент попаданий для «теплых» данных, а не равномерный набор.

Вывод: большее количество CU удваивает прирост пропускной способности за счет большего объема ЦПУ и увеличенного кэша. Переход с 8 CU на 16 CU увеличил пропускную способность для неравномерного набора с 15 до 65 запросов в секунду.

Полнота (recall) по сравнению с точным поиском

Индекс lakebase_ann является приближенным. Recall@10 — это доля истинных 10 ближайших фрагментов (из точного поиска по всем векторам), которую также возвращает индекс. Индекс делит векторы на разделы (IVF), а lakebase_ann.probes задает, сколько разделов считывает запрос. Полнота Recall@10 практически не изменилась с ростом размера корпуса при числе проб по умолчанию: 0,74 для 1 млн, 0,75 для 2 млн и 0,75 для 4 млн. Увеличение числа проб жертвует задержкой ради полноты.

При использовании индекса по умолчанию на 4 млн элементов стандартные 109 проб обеспечивали Recall@10 на уровне 0,74 за 3 мс, а 2000 проб — 0,95 за 49 мс. Индекс, созданный с параметром build_mode = 'quality', повышал полноту при любом числе проб: 0,80 при числе проб по умолчанию за 3 мс и 0,97 при 2000 проб примерно за то же время, что и сборка по умолчанию. Его создание заняло 52 минуты при 16 CU. Увеличение lakebase_ann.epsilon до 4 (максимальное значение, поддерживаемое в наших тестах) добавило менее 0,3 пункта.[9] Полнота зависит от данных и модели встраивания, поэтому измеряйте ее на собственных данных и выбирайте количество проб, необходимое вашему приложению. Lakebase Search поддерживает единый индекс размером более 1 миллиарда векторов.[1]

Вывод: Создавайте векторный индекс с параметром build_mode = 'quality'. При числе проб по умолчанию это увеличило Recall@10 с 0,74 до 0,80 примерно за 3 мс, а при 500 пробах показатель достиг 0,91 за 13 мс (для сборки по умолчанию требуется 1000 проб и 20 мс). Платой за это является время построения: 52 минуты для 4 млн фрагментов при 16 CU. Увеличивайте количество проб только в том случае, если вашему приложению требуется большая полнота.

Стоимость

Стоимость Lakebase зависит от использования. Приостановленные вычислительные ресурсы не оплачиваются, а хранилище тарифицируется отдельно. Затраты на Lakebase составили около 1% от 30-дневного счета Slide Hub. Slide Hub — это внутреннее приложение, и замедленный первый поиск после 5 минут простоя приемлем для его пользователей, поэтому его производственная база данных масштабируется до нуля, когда никто не выполняет поиск.

Оценка масштабирования обошлась недорого. Автономное создание эмбеддингов для всего корпуса заняло 2,95 часа работы GPU, а стоимость эндпоинта обслуживания моделей составила 48,87 долл. Один региональный тест нагрузки выполнялся в течение 14 минут и стоил 0,13 долл. по прейскуранту: 0,11 долл. за приложение и 0,02 долл. за Lakebase Postgres, который автоматически масштабировался в диапазоне от 0,5 до 1 CU и использовал 0,21 CU-часа. При нагрузке до 1000 пользователей тест обработал 109 602 запроса без ошибок. Ядра работали в диапазоне от 0,5 до 16 CU и приостанавливались между запусками. Согласно таблицам биллинга нашего воркспейса, один CU-час равен 0,213 DBU: около 0,085 долл. по прейскуранту Premium и 0,11 долл. по прейскуранту Enterprise в регионе AWS US East.

Вывод: Lakebase Postgres тарифицирует вычислительные ресурсы только во время их работы. 14-минутный тест нагрузки использовал вычислительные ресурсы Lakebase Postgres на сумму 0,02 долл., и эта стоимость составила около 1% от 30-дневного счета Slide Hub. Для продакшена установите минимум в 0,5 CU вместо масштабирования до нуля. По прейскуранту это стоит около 31–40 долл. в месяц, и поиск больше не ждет около 1 с пробуждения вычислений или запуска с пустым кэшем.[11] Позвольте веткам разработки и тестирования масштабироваться до нуля.

Примечание о данных

MIRACL English находится в открытом доступе. Корпус распространяется под лицензией Apache-2.0, а его фрагменты взяты из Википедии под лицензией CC BY-SA. Модель встраивания gte-large-en-v1.5 использует лицензию Apache-2.0. В этой статье приводятся только агрегированные метрики. Те же тесты работают с любой 1024-мерной моделью: замените шаг встраивания, сохранив таблицу, индексы и поиск.

Заключение

Представьте Lakebase Postgres в виде читателя за столом перед большой книжной полкой.

• Книжная полка — это хранилище, а стол — это кэш. Страницы на столе читаются быстро. Страницы на полке требуют времени на поиск — около 0,3 мс каждая.
• Сделайте стол размером с используемые вами книги. Когда кэш примерно равен по размеру векторному индексу, почти каждая страница находится на столе, а векторный поиск занимает миллисекунды.
• Большее количество CU дает больший стол и больше рук. Это делает каждый поиск быстрее и позволяет Lakebase Postgres обрабатывать больше поисковых запросов одновременно.
• Запрашивайте меньше книг. Запрос, который берет 200 кандидатов вместо 1000, содержит около трети страниц и сохраняет 9 из 10 лучших результатов.
• Хорошо упорядочите полки, а затем выберите, сколько из них просматривать. Индекс, созданный в режиме качества (quality), возвращает 8 из истинных 10 ближайших фрагментов при числе проб по умолчанию за 3 мс и 97 из 100 при 2000 проб примерно за 50 мс.
• У приложения есть собственный стол. Как только Lakebase Postgres начинает работать быстро, узким местом становятся воркеры приложения. В таком случае выделите приложению больше воркеров. Большее количество CU Lakebase Postgres в этот момент уже не поможет.
• Вам не нужна вся библиотека на столе. Lakebase Postgres считывает остальное из хранилища. Это медленнее, но работает, а коэффициент попаданий в кэш показывает, как часто это происходит.
• Вы платите за стол только тогда, когда кто-то читает. Когда никто не выполняет поиск, Lakebase Postgres может приостановиться, и оплачиваться будет только хранилище; в Slide Hub это составило около 1% от 30-дневного счета. В продакшене держите открытым небольшой стол: 0,5 CU стоит около 31–40 долл. в месяц и позволяет избежать холодного старта.

В Databricks есть три вида поиска, и каждый из них решает определенную задачу. Выберите тот, который находится ближе к вашим данным.

• Lakebase Search работает внутри базы данных Postgres приложения. Используйте его, когда поиск должен находиться рядом с собственными таблицами приложения и мгновенно видеть каждую запись.
• AI Search (ранее Vector Search) — это управляемая поисковая служба по таблицам озера данных (Lakehouse) в Unity Catalog. Она поддерживает синхронизацию своего индекса с таблицей Delta или Iceberg и может самостоятельно создавать эмбеддинги. Используйте ее для RAG, агентов и рекомендаций на основе данных Lakehouse.
• Индексы полнотекстового поиска (бета-версия) ускоряют SQL-запросы к управляемым таблицам Delta и Iceberg. Функции поиска search и isearch используют индекс для пропуска файлов, которые не могут содержать совпадения, поэтому поиск по логам и ключевым словам считывает меньше данных. Они фильтруют строки, но не ранжируют результаты для поисковой строки.

Slide Hub запускает все это в одной базе данных Lakebase Postgres: данные приложения, векторный индекс и индекс ключевых слов. Начните с документации по Lakebase Search, а затем запустите аналогичный тест на собственных данных.