Когда встроенный поиск Битрикс перестаёт работать
При 100 тысячах товаров встроенный поиск на MySQL-индексе тормозит: запросы к b_search_content занимают 300–500 мс, а на миллионной базе — timeout. Клиенты жалуются на долгий поиск, сортировка по цене не работает, фасеты перегружают базу. Например, недавний проект с каталогом 250 000 товаров: стандартный поиск выдавал результаты через 2–3 секунды, сложные фильтры по свойствам (цена, бренд, размер) приводили к 30-секундным паузам. Elasticsearch решает это кардинально: время отклика 5–30 мс, агрегации на лету, опечатки и морфология из коробки. Наш опыт — 30+ интеграций ES с Битрикс, гарантируем результат под ключ. Мы используем лицензированные компоненты и сертифицированы 1С-Битрикс. Чтобы понять, подходит ли Elasticsearch вашему проекту, закажите бесплатный аудит — мы проанализируем нагрузку и структуру данных.
Проблемы, которые решает Elasticsearch
Elasticsearch заменяет стандартную поисковую машину Битрикс и решает три ключевые проблемы:
- Скорость полнотекстового поиска. MySQL FULLTEXT начинает тормозить при 50–100 тысячах документов. ES справляется с миллионами.
- Фасетный поиск (агрегации). Встроенные фильтры Битрикс — это отдельные запросы по каждому свойству. ES возвращает агрегации в одном запросе, что даёт выигрыш в 10–20 раз на сложных фильтрах.
- Поиск с опечатками и синонимы. Без установки сторонних модулей MySQL не поддерживает нечёткий поиск. ES из коробки имеет fuzziness и синонимы.
Если вы столкнулись с подобными проблемами, свяжитесь с нами для аудита — это поможет оценить узкие места.
Почему Elasticsearch быстрее MySQL FULLTEXT?
| Характеристика | MySQL FULLTEXT | Elasticsearch |
|---|---|---|
| Тип индекса | B-tree + inverted file | Inverted index + FST |
| Морфология | Нужны внешние словари (morphy) | Стеммер и анализаторы (russian) |
| Поиск с опечатками | Нет | Fuzziness (AUTO) |
| Агрегации (фасеты) | Нет | Да, в одном запросе |
| Скорость на 1 млн документов (один запрос) | 200–500 мс | 5–30 мс |
Elasticsearch быстрее MySQL FULLTEXT в 10–50 раз на больших данных.
Архитектура интеграции
Интеграция состоит из трёх частей:
- Индексатор — компонент, который читает данные из Битрикс (инфоблоки, пользователи, страницы) и записывает документы в индекс Elasticsearch.
- Поисковый шлюз — заменяет стандартные запросы к b_search_content запросами к Elasticsearch API. Шлюз реализован как PHP-прокси: получает запрос от стандартного компонента
bitrix:search.page, преобразует его в Elasticsearch query DSL и возвращает результаты в формате, ожидаемом Битрикс. - Обработчики событий — обновляют индекс при изменении или удалении сущностей.
Структура индекса для каталога товаров
Индекс создаётся через Elasticsearch Mapping API. Пример маппинга для товаров:
PUT /bitrix_catalog
{
"mappings": {
"properties": {
"id": { "type": "integer" },
"iblock_id": { "type": "integer" },
"name": { "type": "text", "analyzer": "russian" },
"description": { "type": "text", "analyzer": "russian" },
"sku": { "type": "keyword" },
"price": { "type": "float" },
"active": { "type": "boolean" },
"section_id": { "type": "integer" },
"properties": { "type": "object" },
"updated_at": { "type": "date" }
}
},
"settings": {
"analysis": {
"analyzer": {
"russian": {
"type": "custom",
"tokenizer": "standard",
"filter": ["lowercase", "russian_stop", "russian_stemmer"]
}
},
"filter": {
"russian_stemmer": { "type": "stemmer", "language": "russian" },
"russian_stop": { "type": "stop", "stopwords": "_russian_" }
}
}
}
}
Анализатор russian с стеммером — ключевое отличие от MySQL FULLTEXT, который без дополнительных словарей не понимает морфологию.
Пример конфигурации анализатора с синонимами
PUT /bitrix_catalog/_settings
{
"analysis": {
"filter": {
"russian_synonyms": {
"type": "synonym",
"synonyms": [
"брюки, штаны, джинсы => trousers",
"смартфон, телефон, мобила => mobile"
]
}
},
"analyzer": {
"russian_with_synonyms": {
"tokenizer": "standard",
"filter": ["lowercase", "russian_stop", "russian_stemmer", "russian_synonyms"]
}
}
}
}
Как настроить автоматическое обновление индекса?
Подписываемся на события инфоблока:
// local/php_interface/init.php
AddEventHandler('iblock', 'OnAfterIBlockElementUpdate', 'esUpdateProduct');
AddEventHandler('iblock', 'OnAfterIBlockElementDelete', 'esDeleteProduct');
function esUpdateProduct(array &$arFields): void
{
$client = getEsClient();
$productId = (int)$arFields['ID'];
// Переиндексировать один документ
$client->index([
'index' => 'bitrix_catalog',
'id' => $productId,
'body' => buildProductDocument($productId),
]);
}
function esDeleteProduct(int $productId): void
{
getEsClient()->delete(['index' => 'bitrix_catalog', 'id' => $productId]);
}
Событие OnAfterIBlockElementUpdate срабатывает и при изменении через API (импорт из 1С), что важно для актуальности индекса.
Индексация данных
Первичная индексация запускается через cron-скрипт. Данные читаются пакетами через CIBlockElement::GetList() с nTopCount = 100 и смещением, чтобы не перегрузить память:
\Bitrix\Main\Loader::includeModule('iblock');
$client = \Elasticsearch\ClientBuilder::create()
->setHosts(['localhost:9200'])
->build();
$offset = 0;
$batchSize = 100;
do {
$res = \CIBlockElement::GetList(
[],
['IBLOCK_ID' => CATALOG_IBLOCK_ID, 'ACTIVE' => 'Y'],
false,
['nTopCount' => $batchSize, 'nPageSize' => $batchSize, 'iNumPage' => floor($offset / $batchSize) + 1],
['ID', 'NAME', 'DETAIL_TEXT', 'IBLOCK_ID', 'IBLOCK_SECTION_ID']
);
$bulk = [];
while ($item = $res->GetNext()) {
$bulk[] = ['index' => ['_index' => 'bitrix_catalog', '_id' => $item['ID']]];
$bulk[] = [
'id' => (int)$item['ID'],
'iblock_id' => (int)$item['IBLOCK_ID'],
'name' => $item['NAME'],
'description'=> strip_tags($item['DETAIL_TEXT']),
'section_id' => (int)$item['IBLOCK_SECTION_ID'],
'active' => true,
'updated_at' => date('c'),
];
$offset++;
}
if (!empty($bulk)) {
$client->bulk(['body' => $bulk]);
}
} while ($res->SelectedRowsCount() === $batchSize);
Bulk API позволяет отправлять до 1000 документов за запрос. Не используйте индивидуальные index-запросы для первичной индексации — это в 10–50 раз медленнее.
Поисковый запрос
Замена стандартного компонента bitrix:search.page на кастомный, обращающийся к Elasticsearch:
$response = $client->search([
'index' => 'bitrix_catalog',
'body' => [
'query' => [
'multi_match' => [
'query' => $searchQuery,
'fields' => ['name^3', 'description', 'sku'],
'type' => 'best_fields',
'fuzziness' => 'AUTO',
],
],
'sort' => ['_score' => ['order' => 'desc']],
'from' => ($page - 1) * $pageSize,
'size' => $pageSize,
],
]);
Параметр fuzziness: AUTO обеспечивает поиск с опечатками: для слов до 5 символов допускается 1 замена, для более длинных — 2.
Что входит в нашу работу?
- Аудит текущего поиска и нагрузки.
- Настройка Elasticsearch-кластера (версия, конфигурация, мониторинг).
- Создание маппинга под структуру ваших данных.
- Разработка индексатора и поискового шлюза.
- Настройка событий для автоматического обновления.
- Тестирование производительности и точности.
- Документация и обучение вашей команды.
- Поддержка в течение гарантийного срока.
- Мониторинг и алерты при сбоях индексации.
Сроки внедрения
| Масштаб | Состав | Срок |
|---|---|---|
| Базовый | Установка ES, маппинг, индексатор, поисковый шлюз | 5–7 дней |
| Полный | Фасетный поиск через агрегации, подсказки (suggest), синонимы, автодополнение | 10–14 дней |
Свяжитесь с нами для консультации. Получите точную оценку проекта и рекомендации по архитектуре — без обязательств.