Коли вбудований пошук Бітрікс перестає працювати
При 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 днів |
Зв'яжіться з нами для консультації. Отримайте точну оцінку проекту та рекомендації щодо архітектури — без зобов'язань.