Настройка Elasticsearch-фасетной агрегации для 1С-Битрикс

Фильтрация каталога с десятками тысяч товаров через MySQL — это минуты ожидания. Elasticsearch с фасетной агрегацией сокращает время до десятков миллисекунд. Но штатный поиск Битрикс (search) не умеет возвращать агрегированные данные для фильтров. Мы делаем кастомную интеграцию через официальный клиент elasticsearch/elasticsearch. Настройка Elasticsearch фасетной агрегации для 1С-Битрикс — это способ ускорить фильтрацию каталога. Опыт показывает: такой подход ускоряет загрузку страницы фильтра на 95% и позволяет мгновенно видеть количество товаров по каждому значению фильтра.

Проблема: при 50 000 товарах MySQL выполняет группировку по свойствам за 2–5 секунд, а на каждый фильтр нужен отдельный запрос. Elasticsearch за один запрос возвращает и сами товары, и агрегации по брендам, ценам, характеристикам. Это называется фасетной агрегацией.

Как фасетная агрегация ускоряет фильтрацию?

Aggregations — запрос, который одновременно возвращает результаты поиска и статистику по полям: количество документов для каждого значения фильтра. Один запрос к Elasticsearch заменяет N запросов к MySQL для подсчёта по каждому фасету.

Пример: каталог ноутбуков. Один запрос возвращает:

• 240 товаров, удовлетворяющих текущему фильтру
• По бренду: ASUS (45), Dell (38), HP (31)...
• По RAM: 8 ГБ (89), 16 ГБ (104), 32 ГБ (47)
• По диагонали: 15.6" (130), 14" (65)...

Это и есть фасеты.

Почему Elasticsearch быстрее MySQL для фасетов?

MySQL с группировкой по множеству свойств порождает тяжелые запросы с GROUP BY и множественными JOIN. При 50 000 товарах такой запрос выполняется 2–5 секунд. Elasticsearch обрабатывает ту же агрегацию за 50–300 мс.

Экономия серверных ресурсов значительна.

Как настроить маппинг для фасетных полей?

Для фасетной агрегации поля должны быть либо keyword (точное значение), либо integer/float для числовых диапазонов. Поля типа text не агрегируются (или агрегируются по токенам, что бессмысленно для фасетов).

Маппинг при создании индекса:

curl -X PUT http://localhost:9200/bitrix_catalog_s1 \ -H "Content-Type: application/json" \ -d '{ "mappings": { "properties": { "title": { "type": "text", "analyzer": "russian", "fields": { "keyword": {"type": "keyword"} } }, "brand": {"type": "keyword"}, "price": {"type": "float"}, "category_id": {"type": "integer"}, "properties": { "type": "nested", "properties": { "code": {"type": "keyword"}, "value": {"type": "keyword"}, "value_num": {"type": "float"} } } } } }' 

Свойства товара храним как nested объекты — это позволяет корректно фильтровать по комбинации значений одного свойства. Подробнее о маппинге читайте в документации Elasticsearch.

Как реализовать post-filter для независимых фасетов?

Стандартная проблема: при выборе фильтра «Бренд: ASUS» в агрегации по брендам должны остаться все бренды с актуальными количествами — иначе пользователь не может переключиться на Dell. Для этого используется post_filter: фильтрация применяется к результатам, но не к агрегациям.

{ "query": {"match_all": {}}, "post_filter": {"term": {"brand": "ASUS"}}, "aggs": { "brands": {"terms": {"field": "brand"}} } } 

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

Запрос с агрегациями из PHP

Класс для работы с Elasticsearch через официальный клиент elasticsearch/elasticsearch:

use Elasticsearch\ClientBuilder; class CatalogElasticSearch { private $client; private $index = 'bitrix_catalog_s1'; public function __construct() { $this->client = ClientBuilder::create() ->setHosts(['localhost:9200']) ->build(); } public function getFacets(array $filters = [], string $query = ''): array { $must = []; if ($query) { $must[] = ['match' => ['title' => $query]]; } foreach ($filters as $code => $values) { $must[] = [ 'nested' => [ 'path' => 'properties', 'query' => [ 'bool' => [ 'must' => [ ['term' => ['properties.code' => $code]], ['terms' => ['properties.value' => (array)$values]] ] ] ] ] ]; } $params = [ 'index' => $this->index, 'body' => [ 'query' => ['bool' => ['must' => $must]], 'aggs' => [ 'brands' => [ 'terms' => ['field' => 'brand', 'size' => 50] ], 'price_range' => [ 'range' => [ 'field' => 'price', 'ranges' => [ ['to' => 10000], ['from' => 10000, 'to' => 30000], ['from' => 30000, 'to' => 60000], ['from' => 60000] ] ] ], 'properties_facets' => [ 'nested' => ['path' => 'properties'], 'aggs' => [ 'prop_codes' => [ 'terms' => ['field' => 'properties.code', 'size' => 20], 'aggs' => [ 'prop_values' => [ 'terms' => ['field' => 'properties.value', 'size' => 100] ] ] ] ] ] ], 'size' => 24, 'from' => 0 ] ]; return $this->client->search($params); } } 

Индексация товаров Битрикс

Данные для индексации собираем через CIBlockElement::GetList и отправляем в Elasticsearch батчами через Bulk API:

function indexCatalogToElastic(int $iblockId): void { $client = ClientBuilder::create()->setHosts(['localhost:9200'])->build(); $batchSize = 200; $offset = 0; do { $res = CIBlockElement::GetList( [], ['IBLOCK_ID' => $iblockId, 'ACTIVE' => 'Y'], false, ['nTopCount' => $batchSize, 'nPageSize' => $batchSize, 'iNumPage' => ($offset / $batchSize) + 1], ['ID', 'NAME', 'DETAIL_TEXT', 'PROPERTY_BRAND', 'PROPERTY_*'] ); $body = []; $count = 0; while ($el = $res->GetNextElement()) { $fields = $el->GetFields(); $props = $el->GetProperties(); $properties = []; foreach ($props as $code => $prop) { if (!empty($prop['VALUE'])) { $properties[] = [ 'code' => $code, 'value' => is_array($prop['VALUE']) ? implode(', ', $prop['VALUE']) : $prop['VALUE'] ]; } } $body[] = ['index' => ['_index' => 'bitrix_catalog_s1', '_id' => $fields['ID']]]; $body[] = [ 'title' => $fields['NAME'], 'brand' => $props['BRAND']['VALUE'] ?? '', 'properties' => $properties ]; $count++; } if (!empty($body)) { $client->bulk(['body' => $body]); } $offset += $batchSize; } while ($count === $batchSize); } 

Как обновлять индексы: сравнение подходов

Рекомендуется комбинировать оба подхода: полная переиндексация раз в сутки, инкрементальное — через агенты.

Пример настройки агента для инкрементального обновления: В файле bitrix/php_interface/init.php добавляем:

CAgent::AddAgent( "CatalogElasticSearch::incrementalUpdate();", "elastic", "N", 60, date('Y-m-d H:i:s'), "Y", date('Y-m-d H:i:s'), 30 ); 

Функция incrementalUpdate проверяет таблицу b_iblock_element на изменения за последнюю минуту и отправляет обновлённые документы.

Как мы это делаем: процесс настройки

1. Аудит — анализируем текущую структуру каталога, свойства, количество товаров, нагрузку.
2. Проектирование — определяем маппинг, настройки шардов, реплик, политику индексации.
3. Разработка — пишем класс для индексации, интеграцию с Битрикс (агенты, события), реализуем фильтр с пост-фильтром.
4. Тестирование — сравниваем скорость MySQL и Elasticsearch, проверяем корректность агрегаций при разных комбинациях.
5. Деплой — настраиваем мониторинг, резервное копирование, документацию.

Что входит в работу

• Настройка и оптимизация индекса Elasticsearch под структуру каталога
• Код индексации (Bulk API) с интеграцией через агенты Битрикс
• Реализация компонента фильтра с фасетами и post-filter
• Тестирование производительности на ваших данных
• Документация и обучение администраторов
• Гарантия на работу индексации и корректность агрегаций

Сроки и гарантии

Ориентировочные сроки — от 3 до 7 рабочих дней в зависимости от сложности каталога. Стоимость рассчитывается индивидуально. Мы имеем многолетний опыт и выполнили 50+ проектов по интеграции Elasticsearch с 1С-Битрикс. Предоставляем гарантию на работу индексации и корректность фасетов.

Получите консультацию по настройке Elasticsearch для вашего каталога. Расскажите о каталоге — мы подготовим план интеграции и смету.