Налаштування фасетної агрегації 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 для вашого каталогу. Розкажіть про каталог — ми підготуємо план інтеграції та кошторис.