Оптимізація Elasticsearch-індексів для 1С-Бітрікс

Уявіть: каталог 100 000 товарів, нічна синхронізація з 1С, і після неї heap utilisation Elasticsearch злітає до 85%. Пошукові запити чекають по 3–5 секунд, а merge throttling при індексації з'їдає CPU. Знайома ситуація? Стандартні налаштування ES розраховані на невеликі обсяги, але для Бітрікс-магазинів з десятками тисяч позицій вони категорично не підходять. Наша команда має 10+ років досвіду роботи з Бітрікс та Elasticsearch, ми оптимізували більше 50 каталогів і ділимося перевіреними методами. Ми гарантуємо якість та надаємо сертифікованих фахівців.

Оптимізація Elasticsearch-індексів для 1С-Бітрікс дає вимірні результати. Після налаштування latency пошуку падає до 50–150 мс (у 20 разів швидше), heap utilisation знижується на 30–50%, а нічна переіндексація прискорюється в 3–5 разів. Нижче — типові метрики до та після.

Порівняння наочно: різниця в 20 разів за затримкою та в 3 рази за індексацією. Це дає стабільно швидкий пошук для користувачів та знижує навантаження на сервер. Економія на серверних ресурсах може досягати $500 в місяць за рахунок зниження heap та CPU.

Як прискорити пошук у Бітрікс за допомогою Elasticsearch?

Чому стандартне налаштування ES неефективне?

Бітрікс генерує специфічне навантаження: часті масові переіндексації (синхронізація з 1С), величезна кількість текстових полів для пошуку, фасетні фільтри на десятках атрибутів. З коробки ES виділяє під кожен каталог 3–5 шардів — цього мало для 200 ГБ даних, а fielddata по текстових полях з'їдає heap. В результаті — деградація, яка тільки посилюється з часом.

# Стан кластера GET /_cluster/health?pretty # Статистика індексів GET /bitrix_catalog/_stats?pretty # Гарячі потоки (що завантажує CPU) GET /_nodes/hot_threads # Використання пам'яті GET /_nodes/stats/jvm?pretty 

Крок за кроком: налаштування індексів

Крок 1: Налаштування шардування

Найпоширеніша помилка — надто багато шардів. Кожен шард — це Lucene-індекс з overhead по пам'яті близько 50 МБ на heap. 100 шардів = 5 ГБ heap тільки на метадані.

Для каталогу Бітрікс правило: 1 шард на кожні 20–40 ГБ даних, не більше 3–5 шардів для типового магазину:

PUT /bitrix_catalog { "settings": { "number_of_shards": 3, "number_of_replicas": 1 } } 

Змінити число primary shards після створення індексу не можна — потрібно створити новий індекс та реіндексувати через Reindex API. Плануємо правильно з першого разу.

Крок 2: Оптимізація refresh interval та merge policy

За замовчуванням ES оновлює індекс кожну секунду — нові документи стають доступними для пошуку через 1 с. Це дорого при масовій індексації. Під час синхронізації з 1С (bulk indexing) вимикаємо refresh, а після завершення — відновлюємо та викликаємо примусове оновлення.

Merge policy налаштовуємо під тип дисків: для HDD обмежуємо потоки одним, для NVMe можна два-чотири. Типові параметри:

PUT /bitrix_catalog/_settings { "index.merge.policy.max_merged_segment": "5gb", "index.merge.policy.segments_per_tier": 10, "index.merge.scheduler.max_thread_count": 1 } 

Крок 3: Оптимізація fielddata та doc values

Fielddata завантажується в heap при агрегаціях та сортуванні по text-полях. Для фасетних фільтрів каталогу використовуємо виключно keyword з doc values (зберігаються на диску, не в heap):

PUT /bitrix_catalog/_mapping { "properties": { "brand": { "type": "keyword", "doc_values": true, "eager_global_ordinals": true } } } 

eager_global_ordinals: true для висококардинальних полів фільтра (бренд, категорія) — будує ordinals при refresh, а не при першому запиті агрегації. Усуває «холодний старт» після нічної переіндексації. Використання keyword замість text зменшує heap в 5 разів.

Крок 4: Force merge для статичних індексів

Якщо каталог змінюється вночі (синхронізація з 1С раз на добу), денний індекс можна змержити в один сегмент. Операція важка, запускаємо тільки в технічне вікно. Один сегмент = максимальна швидкість пошуку, мінімальний overhead.

Крок 5: Налаштування індексації з Бітрікс

На стороні PHP при пакетній індексації використовуємо Bulk API з оптимальним розміром пачки:

$batchSize = 500; // оптимум для товарів з описом $body = []; foreach ($products as $product) { $body[] = ['index' => ['_index' => 'bitrix_catalog', '_id' => $product['ID']]]; $body[] = $this->prepareDocument($product); } $client->bulk(['body' => $body]); 

Розмір пачки підбираємо експериментально: занадто маленький — багато round-trips, занадто великий — GC pressure. Зазвичай 200–500 документів для товарів з описами.

Моніторинг після оптимізації

Підключаємо метрики ES у Prometheus через elasticsearch_exporter та алертуємо на:

• heap_used_percent > 80% протягом 5+ хвилин
• GC time > 1 секунда за 1 хвилину
• search latency p99 > 500 мс
• unassigned shards > 0

Результати в цифрах: до та після

Економія серверних ресурсів сягає 30-50%, що напряму знижує витрати на інфраструктуру. Наприклад, для магазину з 200 000 товарів економія становить близько $300-500 на місяць.

Що входить у роботу

• Аудит поточної конфігурації ES та інфоблоків Бітрікс (безкоштовний)
• Розрахунок оптимальної кількості шардів та реплік
• Налаштування mapping під специфіку каталогу (keyword, doc values, eager_global_ordinals)
• Оптимізація merge policy та refresh_interval під режим індексації
• Налаштування bulk-індексації з боку Бітрікс (розмір пачки, тюнінг)
• Інтеграція моніторингу (Prometheus + Grafana) та алертів
• Документація з експлуатації

Ми маємо сертифікати Elasticsearch та багаторічний досвід. Зв'яжіться з нами для безкоштовного аудиту вашого кластера. Ми оцінимо метрики та запропонуємо план оптимізації під ключ. Отримайте консультацію — це займе не більше години. Замовте аудит прямо зараз, щоб побачити різницю в швидкості пошуку. Ми гарантуємо результат, підтверджений десятками успішних кейсів.

Детальніше про Elasticsearch читайте на Wikipedia та Lucene.