Поиск по смыслу в базах данных: как ускорить построение карты векторов в 12 раз и что проверить на своём сервере

Представьте: вы загружаете в базу данных тысячу описаний товаров, каждое — длинный список чисел, который описывает смысл текста. Раньше, чтобы потом быстро искать похожие товары, системе нужно было построить специальную карту-граф. И на это уходило больше восьми минут. Сервер в это время был занят, другие задачи ждали. Администратор компании «ТехноСервис» как раз столкнулся с такой ситуацией: процесс зависал на несколько минут, а потом растягивался на 8+ минут.

После обновления системы до версии 27.1.5 та же самая загрузка (миллион описаний, каждое из 1536 чисел) на 16-ядерном процессоре заняла всего 39 секунд. Время ожидания сократилось в десятки раз. Нагрузка на сервер теперь распределяется равномерно по всем ядрам, а не висит на одном.

Что именно изменилось

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

• Сохранение нового куска данных. Когда вы добавляете записи, они сначала собираются в оперативной памяти, а потом записываются на диск вместе с картой-графом. Теперь эта запись идёт быстрее.
• Слияние кусков. Со временем в базе накапливается много маленьких кусков. Команда OPTIMIZE объединяет их в один большой. Раньше это тоже делалось на одном ядре, теперь — на нескольких.
• Перестройка карты. Если вы меняете структуру таблицы, карту-граф нужно пересобрать. Раньше это приводило к простою, теперь — быстрее.

Кому это выгодно

Всем, кто использует поиск по смыслу (векторный поиск) в своей базе данных. Например:

• Интернет-магазины, которые ищут похожие товары по описанию.
• Сервисы рекомендаций, которые подбирают контент.
• Системы поиска изображений или аудио.
• Любые приложения, где нужно быстро найти «похожее» среди тысяч или миллионов записей.

Что проверить на своём сервере

Прежде чем обновляться, стоит убедиться, что ваша система готова. Вот простой чек-лист:

1. Узнайте, сколько ядер у вашего процессора. Чем больше ядер, тем заметнее ускорение. Если у вас 4 ядра, выигрыш будет меньше, чем на 16.
2. Проверьте текущую версию Manticore. Выполните запрос SELECT version();. Если версия ниже 27.1.5, планируйте обновление.
3. Проверьте настройку optimize_cutoff. Выполните SHOW VARIABLES LIKE 'optimize_cutoff';. Если значение не равно 1, система будет оставлять несколько кусков, и выгода от ускорения будет частично потеряна. Рекомендуется установить SET GLOBAL optimize_cutoff = 1;.
4. Проведите тест. Загрузите небольшой набор данных (например, 100 тысяч описаний) и замерьте время построения карты до и после обновления. Разница должна быть заметной.
5. Следите за нагрузкой на процессор. Во время построения карты используйте команды top или htop. Если загрузка всех ядер не превышает 70%, переход безопасен.
6. Проверьте количество кусков после оптимизации. После выполнения OPTIMIZE должно остаться не больше одного куска. Это ускорит и сам поиск.

Какие риски нужно учесть

• Нагрузка на процессор. Параллельное построение использует несколько ядер. Если на том же сервере работают другие важные сервисы, они могут конкурировать за ресурсы. В часы пик лучше отключать автоматическую оптимизацию или настраивать её на ночное время.
• Память. Параллельный режим требует примерно в 1.5–2 раза больше оперативной памяти, чем однопоточный. Для больших наборов данных (более миллиона записей) на 16-ядерных системах рекомендуется не менее 32 ГБ RAM.
• Совместимость скриптов. Если ваши автоматические задачи ожидают определённого количества кусков, после обновления их количество может измениться. Проверьте все скрипты, которые работают с базой.
• Версия клиентских библиотек. Убедитесь, что драйверы (например, для Python) поддерживают новую версию сервера.

Что делать прямо сейчас

Если вы используете Manticore Search для поиска по смыслу, вот план на эту неделю:

1. Узнайте количество ядер на сервере.
2. Проверьте текущую версию.
3. Запланируйте обновление до версии 27.1.5.
4. После обновления установите optimize_cutoff = 1.
5. Проведите тест с небольшим объёмом данных.
6. Если всё прошло успешно, включите новую настройку в стандартные скрипты обслуживания.

Как это работает внутри (для тех, кому интересно)

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

Часто задаваемые вопросы

Нужно ли отключать автоматическую оптимизацию после обновления? Нет, она продолжает работать. Но рекомендуется явно задать optimize_cutoff = 1, чтобы гарантировать минимальное количество кусков.

Можно ли включить параллелизм только для слияния, оставив обычные вставки однопоточными? Да, через переменную knn_parallel_optimize можно ограничить параллелизм только этапом слияния.

Какой объём памяти требуется? Примерно в 1.5–2 раза больше, чем при однопоточном режиме. Для больших наборов данных на 16-ядерных системах рекомендуется минимум 32 ГБ RAM.

Где взять новую версию? Официальный сайт Manticore Search и страница релизов на GitHub.

Что почитать дальше

• AI-фотографии 2026: как работает генерация изображений, где применять и какие ограничения
• Agentic SAMM: аудит ИИ-агентов в разработке и что проверить на этой неделе
• Claude Science от Anthropic: что изменилось и как проверить, стоит ли внедрять в лабораторию
• Claude Tag в Slack: какой ИИ-агент можно пускать в общий канал и что проверить перед запуском
• Clipia MCP для Claude Code, Cursor и Codex: генерация фото и видео через AI-агента вместо отдельного сервиса