Фільтрація каталогу з десятками тисяч товарів через 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 мс.
| Параметр | MySQL (CIBlockElement::GetList з групуванням) |
Elasticsearch (aggregations) |
|---|---|---|
| Час запиту для 50 000 товарів | 2–5 секунд | 50–300 мс |
| Кількість запитів на сторінку | 1 основний + N на кожен фасет | 1 |
| Масштабування на 1 млн товарів | деградація до 30+ секунд | 500 мс – 2 с |
| Підтримка комбінованих фільтрів | складні HAVING | post_filter і nested |
Економія серверних ресурсів значна.
Як налаштувати маппінг для фасетних полів?
Для фасетної агрегації поля мають бути або 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 на зміни за останню хвилину та відправляє оновлені документи.
Як ми це робимо: процес налаштування
- Аудит — аналізуємо поточну структуру каталогу, властивості, кількість товарів, навантаження.
- Проектування — визначаємо маппінг, налаштування шардів, реплік, політику індексації.
- Розробка — пишемо клас для індексації, інтеграцію з Бітрікс (агенти, події), реалізуємо фільтр з пост-фільтром.
- Тестування — порівнюємо швидкість MySQL та Elasticsearch, перевіряємо коректність агрегацій при різних комбінаціях.
- Деплой — налаштовуємо моніторинг, резервне копіювання, документацію.
Що входить у роботу
- Налаштування та оптимізація індексу Elasticsearch під структуру каталогу
- Код індексації (Bulk API) з інтеграцією через агенти Бітрікс
- Реалізація компонента фільтра з фасетами та post-filter
- Тестування продуктивності на ваших даних
- Документація та навчання адміністраторів
- Гарантія на роботу індексації та коректність агрегацій
Терміни та гарантії
Орієнтовні терміни — від 3 до 7 робочих днів залежно від складності каталогу. Вартість розраховується індивідуально. Ми маємо багаторічний досвід та виконали 50+ проектів з інтеграції Elasticsearch з 1С-Бітрікс. Надаємо гарантію на роботу індексації та коректність фасетів.
Отримайте консультацію з налаштування Elasticsearch для вашого каталогу. Розкажіть про каталог — ми підготуємо план інтеграції та кошторис.