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

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

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

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

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

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

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

https://catalog.manticoresearch.com

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

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

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

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

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

Самый неприятный тип инцидента — когда база данных не падает полностью, а просто начинает работать медленнее.

Пользователи замечают это сразу. Жалобы начинают поступать. Технически всё по-прежнему работает, но явно что‑то не так.

И обычно самое сложное здесь не заметить проблему, а понять, что на самом деле происходит.

Начиная с Manticore Search 24.4.0, компактизация RT-таблиц использует более эффективную модель выполнения. Вместо последовательного слияния пар чанков оптимизация теперь поддерживает два важных улучшения:

С тех пор как мы представили инструмент резервного копирования в Manticore Search 6, создавать резервные копии данных стало заметно проще. Но мы постоянно слышали один и тот же вопрос: "А как насчёт облачного хранилища?" Сегодня мы рады объявить, что manticore-backup теперь поддерживает S3-совместимое хранилище с потоковой загрузкой — без промежуточных файлов, без проблем с местом на локальном диске, только бэкапы напрямую в облако.

Представьте, что вы создаёте мощное поисковое приложение. Пользователи вводят ключевые слова, а ваш бэкенд должен выполнять запрос к базе данных Manticore Search, чтобы найти подходящие результаты. Распространённый (и соблазнительный!) подход — напрямую вставлять ввод пользователя в SQL‑запросы. Например, вы можете фильтровать по числовому полю, такому как категория или идентификатор записи. Если пользователь передаёт обычное значение, например 5, запрос будет SELECT FROM products WHERE id=5. А что, если он передаст 1 OR 1=1? Запрос станет SELECT FROM products WHERE id=1 OR 1=1 — условие всегда истинно, поэтому запрос вернёт все строки вместо одной. Это SQL‑инъекция.

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

Manticore Search поддерживает prepared statements через стандартный протокол MySQL, предоставляя мощный инструмент для создания безопасных поисковых приложений. Используя prepared statements, вы не только значительно снизите риск SQL‑инъекций, но и улучшите читаемость вашего кода.

prepared statements — это не просто функция; иногда они являются обязательными. Например, библиотека Rust sqlx работает с MySQL-эндпоинтом, используя исключительно prepared statements. Кроме того, некоторые OLE DB‑коннекторы, позволяющие MS SQL работать с сервером MySQL, тоже используют prepared statements внутри.

Вы слышали, что Manticore Search быстрый. Вы слышали, что он объединяет полнотекстовый, векторный и нечеткий поиск в одном движке. Но когда вы начинаете реально работать с ним, вы сидите перед документацией, угадываете синтаксис SQL и надеетесь, что CREATE TABLE не выдаст непонятную ошибку.

MCP-Manticore меняет правила игры.

Это сервер Model Context Protocol (MCP), который подключает Cursor, Claude Code, Codex CLI или любой другой MCP-совместимый AI-ассистент напрямую к вашему экземпляру Manticore. AI может:

Поиск редко сводится к одному универсальному сценарию. Пользователь, вводящий "cheap running shoes", хочет точных совпадений по ключевым словам, а пользователь, задающий "comfortable footwear for jogging", выражает то же намерение другими словами. Традиционный полнотекстовый поиск хорошо справляется с первым случаем. Векторный поиск решает второй. Гибридный поиск объединяет оба в одном запросе, так что вам не приходится выбирать.

В современных поисковых системах это часто описывается как комбинирование лексического (разреженного) поиска с семантическим (плотным) поиском. Разные термины, одна идея: точное совпадение плюс смысл.

Теперь Manticore Search поддерживает прямое указание настроек токенизации непосредственно в команде CREATE TABLE. Таким образом, исчезает необходимость создавать внешние файлы при настройке стоп-слов, исключений, словоформ и слов без позиции, делая создание таблиц проще и удобнее для развертывания.

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

Kafka — это популярный брокер сообщений, который используется в самых разных проектах: от обработки логов и управления очередями задач до персонализации контента и аналитики в реальном времени. Например, его можно использовать для индексирования изменений в Википедии или поиска товаров в интернет-магазинах. Manticore Search, в свою очередь, поддерживает интеграцию с Kafka, что позволяет автоматически импортировать данные и использовать их для полнотекстового поиска, аналитики, векторного поиска и многого другого.

При импорте данных в Manticore вы можете гибко их обрабатывать:

Эта статья написана Мариусом Матилионисом, старшим разработчиком и экспертом по Manticore Search в компании Ivinco. Ivinco специализируется на предоставлении передовых решений для поиска, оптимизации баз данных, управлении инцидентами и настройке систем мониторинга, помогая бизнесам достигать более быстрых, эффективных и масштабируемых операций.

Кратко: Узнайте, как Manticore Search даёт возможность искать изображения по текстовому описанию, совмещая обработку естественного языка и поиск по векторным представлениям. Мы рассмотрим разные пути — от классических методов до современных решений на базе векторного поиска. А если хотите увидеть всё в реальном времени, загляните в наше демо.

TL;DR: Узнайте, как создать приложение для обратного поиска изображений с использованием Manticore Search. В статье рассказывается об истории технологии, её устройстве и практических подходах к системам поиска изображений.

Введение

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

Попробуйте демо на image.manticoresearch.com или посмотрите реализацию на GitHub.

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

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

Что такое полнотекстовый поиск? Полнотекстовый поиск – это классический метод поиска информации, который сопоставляет введённые вами слова. Он ищет не только точные совпадения, но также поддерживает такие функции, как поиск по префиксам и инфиксам, морфологическую обработку (например, стемминг и лемматизацию), и даже нечеткие методы поиска, такие как кворумный или поиск по близости. Это означает, что полнотекстовый поиск может быть довольно гибким – он помогает вам находить нужную информацию, даже если вы не уверены в точной формулировке.

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

Краткое содержание

Мы рады представить две новые важные функции в Manticore Search: нечёткий поиск и автокорректировка запросов (или "автодополнение"). Эти функции улучшают возможности поиска, предлагая более удобный для пользователя опыт.

Привет, я Майк.

Недавно я начал работать в компании Manticore на должности Developer Advocate. Я не совсем далёк от ИТ, но сейчас активно осваиваю современные технологии. В этом блоге я буду делиться своим опытом и тем, что узнаю о Manticore. Я планирую вести дневник, где буду рассказывать, что такое Manticore и как с ним работать. Давайте вместе разбираться, как все устроено, выявлять проблемы и взаимодействовать с разработчиками.

Если вам интересно изучать Manticore вместе со мной, я буду держать вас в курсе в:

Вместо интро

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

Для затравки — посмотрите, что у нас получильнось на нашем репозитории → Демка
Можно проиндексировать и свой, для этого нужно немного подождать завершения процесса индексации → github.manticoresearch.com, а пока идет индексация — добро пожаловать под кат.

Elasticdump - это инструмент для управления и миграции данных в Elasticsearch. Elasticdump позволяет пользователям перемещать и сохранять индексы, экспортируя данные в файл JSON, а затем импортируя их в другое место. Эта функциональность особенно полезна для целей резервного копирования и восстановления, а также для миграции данных между различными средами (например, из разработки в продакшн).