Допустим, у вашего товара в основной базе уже есть ID 550e8400-e29b-41d4-a716-446655440000. Он попадает в события, логи и ответы API. Но при загрузке того же товара в Manticore приложению приходится выдавать ему ещё один, числовой ID.

До Manticore Search 28.5.0 ID документа был беззнаковым 64-битным числом. UUID можно было сохранить в отдельном строковом атрибуте, однако идентификатором документа он от этого не становился. Для UPDATE, REPLACE и DELETE всё равно требовался числовой id.

В результате приходилось хранить соответствие между UUID из основной БД и числовым ID в таблице Manticore. Теперь без него можно обойтись: RT-таблица Manticore умеет использовать UUID как ID документа.

Фасеты в интернет-магазине кажутся простыми до первого выбранного фильтра.

В каталоге это часть навигации. Выбранный цвет не должен исчезать из списка. Соседние цвета лучше оставить доступными: пользователь может переключиться на них или расширить выбор. А варианты без товаров полезнее сразу показать как недоступные. Внутри одного фасета обычно работает OR: красный или синий. Между разными фасетами - AND: бренд, цвет и размер одновременно.

Неприятная часть начинается после первого выбора. Представьте каталог товаров: пользователь выбрал бренд, цвет и размер. Основная выдача должна остаться узкой и показать только товары, которые подходят под все три условия. Но панель фильтров живёт по другим правилам. В ней нужно сохранить выбранный цвет и одновременно показать цвета, на которые можно переключиться при том же бренде и размере.

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

В Manticore Search 25.12.0 появился facet_filter_mode, который переносит это поведение в API фасетов. Теперь в запросе можно описать, как ведёт себя панель фильтров магазина, а приложению не нужно вручную собирать почти одинаковые запросы для каждого фасета.

Несколько дней назад Meilisearch опубликовал сравнение с Manticore Search . Мы тоже любим сравнения: в 2023 году опубликовали своё с воспроизводимыми бенчмарками. Сразу оговоримся: мы спорим не со всей статьёй. Часть выводов Meilisearch справедлива, а кое-где сравнение говорит в пользу Manticore Search.

Однако часть сведений о Manticore Search уже устарела. Спорить в теории мы не стали: запустили актуальные версии обоих движков (Manticore Search 28.4.4 и Meilisearch 1.41/1.48) и повторили описанные сценарии. Ниже мы приводим команды и ответы обоих движков, чтобы проверку можно было повторить самостоятельно.

В проде подход «включил и готово» почти никогда не работает. Для автономного узла техническая последовательность короткая: включить auth, перезапустить Manticore, создать администратора и обновить клиентов. В топологии с распределёнными таблицами или репликационными кластерами нужна дополнительная подготовка, потому что узлам тоже приходится аутентифицироваться друг у друга.

Относитесь к внедрению как к небольшому релизу. Сначала инвентаризируйте клиентов и узлы, подготовьте данные аутентификации и отрепетируйте процедуру для своей топологии. Затем переключайтесь. Репетиция выявит сбои до технологического окна.

Этот чек‑лист написан для пользователей, которые планируют включить аутентификацию и хотят сделать это максимально безопасно для текущей системы. Помните, что аутентификация отключена, пока вы не настроите auth; после переключения клиенты, которые по‑прежнему не передают учётные данные будут получать отказ.

Выберите процедуру по топологии:

Поиск нередко считают просто инфраструктурой. Но в продакшене он фактически работает как API приложения: принимает пользовательский трафик, отдаёт бизнес‑данные, обслуживает дашборды и нередко стоит рядом с записями, которые не должны быть доступны каждому клиенту в сети.

В Manticore Search теперь (с релиза 27.1.5 ) есть встроенная аутентификация и авторизация — для SQL по протоколу MySQL, для HTTP/HTTPS‑эндпоинтов и для операций, связанных с репликацией.

Аутентификация отвечает на вопрос «кто делает запрос?». Авторизация — «что этому пользователю разрешено делать?».

Пользователи, которые уже используют Manticore могут подключить новую функциональность, сохранив привычные способы работы с Manticore. Существующие SQL и HTTP‑клиенты сохраняют свои обычные паттерны подключения. В приложениях требуются минимальные изменения.

Поиск — уже не просто поле на веб‑сайте. Во многих случаях Manticore Search работает как внутренняя служба обработки данных: приложения направляют к нему запросы, процессы загрузки данных обновляют таблицы в нём, панели мониторинга получают из него данные, а операторы изменяют схемы таблиц. Когда всё это опирается лишь на сетевое доверие, контроль доступа быстро становится уязвимым.

Именно поэтому в Manticore Search теперь встроены аутентификация и авторизация. Функциональность добавлена в версиях 27.x и описана в посте о релизе 27.1.5 : она позволяет Manticore проверять, кто подключается и что этому пользователю разрешено делать.

Новая функциональность работает через SQL, HTTP/HTTPS-клиентов, распределённых и удалённых агентов и поддерживает репликацию.

Мы выпустили Manticore Search 28.4.4 . В этом релизе ресоринг KNN стал быстрее, диалоговый поиск — гибче, установка и обновление — проще, фасеты получили дополнительные параметры, появились настройки релевантности по умолчанию на уровне таблицы, а также исправления в аутентификации, репликации, совместимости SQL, распределённых запросах и внутренних механизмах columnar/KNN.

В этом посте собраны изменения, вышедшие с 27.2.0 по 28.4.4.

Векторные базы данных в serverless-модели обычно обещают простую вещь: не требуется развёртывание и настройка, а провайдер берёт на себя управление хранилищем, масштабирование и обеспечение доступности. turbopuffer - один из лучших примеров этого класса: быстрый движок векторного поиска, использующий object storage в качестве хранилища, которым пользуются Cursor, Notion, Linear и другие.

Такой подход действительно снижает операционную нагрузку на команду, но он не бесплатен. Поэтому возникает закономерный вопрос: какая часть этих преимуществ нужна небольшому, четко определенному сценарию, и во что обойдется та же нагрузка на двух недорогих VPS с Manticore Search - по цене и по производительности?

В этой статье мы подтверждаем это цифрами: сравниваем две системы в одинаковых условиях на одном и том же наборе данных.

На старте поисковая система часто устроена просто: одна таблица на одном сервере. Это работает, пока не случится одно из двух. Либо отдельный запрос перестаёт задействовать весь CPU, за который вы заплатили, либо одного сервера перестаёт хватать — по объёму, по пропускной способности или просто потому, что сервер может выйти из строя, и данные на нём будут потеряны.

Автоматический шардинг, встроенный в Manticore Search и доступный начиная с релиза 27.1.5 , решает обе проблемы, разбивая таблицу на несколько физических фрагментов меньшего размера (шардов), по которым можно выполнять поиск параллельно и которые можно размещать на разных узлах:

Раньше построение KNN-индекса было самым медленным этапом при сохранении и слиянии чанков в таблицах с векторными атрибутами. Начиная с v27.1.5 , Manticore может задействовать несколько ядер CPU при сохранении чанков, слияниях через OPTIMIZE, авто-оптимизации и ALTER TABLE ... REBUILD KNN. На 16-ядерном Ryzen 9 5950X построение KNN-индекса для 1 миллиона 1536-мерных векторов сократилось с 8 минут до 39 секунд.

Если вы запускаете Manticore Search на Linux, в качестве основного инструмента управления стоит выбрать systemd.

На текущий момент это общепринятая практика, хотя ранее существовали определённые ограничения. Да, Manticore Search мог работать под systemd, но интеграция обладала рядом функциональных ограничений. Архитектура демона основана на традиционных подходах Unix; systemd появился позже и хотел от службы совсем другого. Так что настройка работала, но не соответствовала современным требованиям к управлению службами.

Теперь Manticore Search поддерживает нативные уведомления systemd — это и есть главное изменение.

Почему это важно? Потому что устраняется ряд операционных проблем:

Когда мы выпустили Auto Embeddings — функцию автоматического преобразования текстов в векторные представления — без развёртывания отдельного сервиса для работы с ML-моделью, — главный запрос пользователей касался скорости работы. Ранее для генерации эмбеддингов использовался только стек SentenceTransformers поверх Candle (Rust-рантайм Hugging Face для ML-инференса), и ресурсы CPU использовались далеко не полностью: в большинстве сценариев нагрузки показатель QPS держался на уровне нескольких десятков документов в секунду независимо от способа подачи данных, а параллельные запросы обрабатывались последовательно в рамках одной сессии модели.

Поэтому мы в течение нескольких недель оптимизировали механизм запуска ONNX-моделей в Manticore. Новый бэкенд ONNX Runtime доступен начиная с Manticore Search 27.1.5 . ONNX (Open Neural Network Exchange) — переносимый формат моделей, в котором уже публикуется большинство популярных open-source моделей для эмбеддингов: MiniLM, BGE, E5 и другие. В результате получилось решение, которое в среднем в 14 раз быстрее прежней реализации SentenceTransformers/Candle на том же оборудовании (обычный недорогой сервер с 16 ядрами / 32 потоками), с той же моделью и теми же весами, если усреднить по всей матрице замеров threads × batch, — и это преимущество сохраняется как при одном клиентском потоке, так и при тридцати двух. Предыдущая реализация во всём диапазоне нагрузок показывала 5–11 документов/с; новая реализация работает в диапазоне 70–230 документов/с.

Manticore Search 27.1.5 выпущен. Этот релиз приносит встроенные аутентификацию и авторизацию, шардированные таблицы, conversational search, более быструю сборку HNSW, улучшенные фасетирование и агрегации, а также длинный список исправлений в KNN, репликации, совместимости протоколов и других областях.

Этот пост - сводка всего, что вышло с 25.0.1 по 27.1.5.

Кратко: Три изменения в HNSW-поиске ускоряют KNN-поиск до 29% при больших k и дают более 20% прироста при параллельной нагрузке. Без изменений API, без перестроения индексов и без новых настроек — просто более быстрый поиск.

Во многих поисковых сценариях пользователь начинает не с пустой строки запроса, а с существующего результата.

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

Этот сценарий традиционно называют More Like This (MLT): функцией поиска документов, похожих на выбранный. В статье под MLT понимается поиск от уже известного документа, а не от заново введённого запроса.

Классический подход MLT (поиск похожих документов) основывался на сравнении текстовых совпадений. Современные реализации всё чаще используют эмбеддинги: числовые представления документов. Поисковый индекс хранит эмбеддинги в виде векторов, а поисковая система может находить документы с близкими векторными представлениями.

Современные поисковые системы уже не просто сопоставляют ключевые слова. Когда вы ищете «уютный детектив, действие которого происходит в Париже», а получаете результаты вроде «атмосферный детективный роман во Франции», это векторный поиск в действии: документы и запросы превращаются в списки чисел — эмбеддинги, — а поисковый движок находит документы, чьи векторы ближе всего к вектору запроса.

Manticore Search поддерживает это из коробки. Внутри используется структура данных HNSW: граф, который соединяет близкие векторы и позволяет быстро находить ближайших соседей без сканирования каждого документа. Благодаря этому векторный поиск по миллионам документов выполняется за миллисекунды.

С версии 23.0.0 Manticore может делать так, чтобы запрос xt850 находил xt 850, используя bigram_delimiter вместе с режимами bigram_index , учитывающими цифры.

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

bigram_index можно использовать для разных задач, но в этой статье мы говорим именно о производительности поиска фраз: в приведённом ниже бенчмарке на 1 млн документов bigram_index='all' повысил QPS примерно в 2.9x и сократил среднее время ответа фразовых запросов примерно в 3.2x.

Если ваша основная проблема — сопоставление xt850 с xt 850, а не ускорение поиска фраз, см. Как заставить xt850 совпадать с xt 850 .

Поиск по фразам бывает дорогим. Даже если запрос короткий, движку всё равно нужно проверять порядок слов и стоят ли они рядом, и это особенно заметно, когда:

Сделать поиск по каталогу легко. Гораздо сложнее — сделать каталог, который полезен не только на первом запросе.

Это демо как раз об этом. Здесь мы используем небольшой каталог настольных игр, но сам сценарий знаком многим: пользователь вводит что-то полузабытое, ошибается в написании, сужает выдачу по ограничениям, листает дальше, открывает карточку, а потом хочет увидеть «что-то похожее», не начиная всё заново. Если в вашем продукте есть такой сценарий, основная работа — не в полировке интерфейса. Важнее добиться правильного поведения поиска и не переусложнить весь стек.

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

Сначала можно попробовать уже развёрнутую версию:

https://catalog.manticoresearch.com

Один из наших пользователей недавно пришёл к нам со знакомой проблемой: поиск внезапно стал заметно медленнее, хотя внешне ничего явно не ломалось.

Сервис работал, ошибок в логах не было, загрузка CPU выглядела нормально, но пользователи уже начали жаловаться, что поиск тормозит.

Так обычно и проявляются проблемы с поиском в продакшене. Не как драматичный сбой, а как медленное, ползучее ухудшение. Чуть больше трафика здесь, чуть больше индексации там, и прежде чем вы это заметите, производительность уже просела.

К тому моменту, когда пользователи это замечают, настоящая проблема нередко копится уже несколько часов. Без хорошей видимости остаётся только гадать: система перегружена? Одна таблица съедает ресурсы? Или незаметно что-то идёт не так?

Вот почему мониторинг важен. С ним расплывчатое «поиск стал медленным» превращается в проблему, которую можно диагностировать и исправить.