Оптимізація переіндексації Elasticsearch для 1С-Бітрікс
На одному з проєктів з каталогом 800 000 SKU повна переіндексація Elasticsearch з 1С-Бітрікс займала 14 годин. За цей час накопичувалася черга змін, пошук віддавав застарілі дані, а імпорт з 1С конкурував з індексацією за ресурси сервера. Більше того, в процесі індексації при кожному refresh пошук блокувався на частки секунди, що для інтернет-магазину з піковим навантаженням до 10 000 запитів на хвилину призводило до затримок до 3 секунд. Наше завдання — скоротити повну переіндексацію до 1–2 годин без жодної секунди простою пошуку. Досвід роботи з каталогами до 2 млн товарів дозволяє гарантувати такий результат. Подібна ситуація знайома багатьом: чим більший каталог, тим повільніші стандартні механізми. Але рішення лежить на поверхні — правильне налаштування Elasticsearch та оптимізація коду індексатора.
Чому переіндексація гальмує?
Типові причини повільної індексації — послідовна відправка кожного документа окремим PUT-запитом, примусовий refresh після кожного пакета та дефолтний refresh_interval в 1 секунду. Кожен refresh створює новий сегмент Lucene, який потім доводиться об'єднувати. На каталозі в 800k SKU це генерує сотні тисяч дрібних сегментів, і Elasticsearch витрачає ресурси на їх злиття.
Стратегія zero-downtime переіндексації
Ключовий прийом — індексувати в новий індекс, а не поверх робочого. Поточний індекс bitrix_catalog_v1 обслуговує пошук через аліас bitrix_catalog. Паралельно ми будуємо bitrix_catalog_v2. Після завершення переіндексації атомарно перемикаємо аліас — пошук переходить на новий індекс без переривання.
Які налаштування Elasticsearch прискорюють індексацію?
Перед масовою індексацією тимчасово змінюємо параметри:
PUT /bitrix_catalog_v2/_settings { "index": { "refresh_interval": "-1", "number_of_replicas": 0, "translog.durability": "async", "translog.sync_interval": "30s" } } Відключення refresh (-1) прискорює індексацію в 3–5 разів, оскільки документи не потрапляють до пошуку до явного виклику. Відключення реплік (number_of_replicas: 0) знижує навантаження на кластер. Асинхронний транслог скидається на диск кожні 30 секунд, а не при кожній операції. Після індексації відновлюємо стандартні налаштування та виконуємо forcemerge для об'єднання сегментів в один.
Як оптимізувати PHP-індексатор?
Використовуємо Bulk API з пакетами по 500 документів (5–15 МБ). Це в 10–20 разів швидше, ніж поодинокі запити. Elasticsearch Bulk API — стандартна практика для масового завантаження.
$batchSize = 500; $bulk = []; foreach ($products as $product) { $bulk[] = ['index' => ['_index' => 'bitrix_catalog_v2', '_id' => $product['ID']]]; $bulk[] = buildDocument($product); if (count($bulk) >= $batchSize * 2) { $client->bulk(['body' => $bulk]); $bulk = []; } } if (!empty($bulk)) { $client->bulk(['body' => $bulk]); } Паралельна індексація через кілька процесів — ділимо каталог за діапазонами ID. Три процеси на тринодовому кластері дають лінійне прискорення. Обмеження — швидкість читання з MySQL.
Що дає паралельна індексація?
Використання bulk API та паралельної індексації прискорює індексацію в 10–20 разів порівняно з послідовними поодинокими запитами. На нашому проєкті повна переіндексація скоротилася з 14 годин до 1 години 20 хвилин.
Перемикання аліасу
Після індексації атомарно перемикаємо аліас:
POST /_aliases { "actions": [ { "remove": { "index": "bitrix_catalog_v1", "alias": "bitrix_catalog" } }, { "add": { "index": "bitrix_catalog_v2", "alias": "bitrix_catalog" } } ] } Операція займає мілісекунди, пошук не переривається.
Приклад повного сценарію переіндексації
- Створити новий індекс з оптимізованими налаштуваннями.
- Налаштувати аліас на поточний індекс.
- Запустити паралельні процеси індексації з bulk API.
- Після завершення перемкнути аліас на новий індекс.
- Відновити налаштування (refresh_interval, репліки) та виконати forcemerge.
Порівняння до та після оптимізації
| Параметр | До оптимізації | Після оптимізації |
|---|---|---|
| Повна переіндексація (800k SKU) | 14 годин | 1 год 20 хв |
| Інкрементальне оновлення | 15–20 док/с | 200–300 док/с |
| Простій пошуку | Так | Ні |
Що входить в послугу
- Аудит поточної конфігурації Elasticsearch та PHP-індексатора
- Налаштування індексів та mapping під типові запити
- Оптимізація bulk API та паралельної обробки
- Реалізація zero-downtime з аліасами
- Документація з експлуатації
- Консультація та навчання вашої команди
Вартість послуги розраховується індивідуально після аудиту. Ми дамо точну оцінку протягом 2 робочих днів.
Як ми гарантуємо результат?
Наш досвід — понад 10 років розробки на Бітрікс, понад 50 впроваджень пошуку для каталогів з товарами від 10k до 2M SKU. Для кожного проєкту проводимо навантажувальне тестування та даємо гарантію на швидкість індексації. Elasticsearch — де-факто стандарт для високонавантажених каталогів. Зв'яжіться з нами для оцінки вашого проєкту — ми підготуємо план оптимізації. Замовте послугу оптимізації та отримайте прискорення індексації в 7+ разів.
Скільки часу займає оптимізація?
Зазвичай від 3 до 10 робочих днів залежно від складності каталогу та поточних налаштувань. Точні терміни визначаємо після аудиту. Економія ресурсів сервера та зниження витрат на інфраструктуру окупають вкладення протягом кількох місяців.