Коли пошук у 1С-Бітрікс починає гальмувати?
Вбудований пошук 1С-Бітрікс використовує таблиці b_search_content, b_search_content_stem, b_search_stem. На каталозі з 30 000 товарів повна переіндексація займає 4–12 годин, агент CSearchIndex::IndexAgent крутиться безперервно, а якість пошуку залишається низькою: стемінг не справляється з морфологією, релевантність не враховує продажі. Наш досвід показує, що грамотне налаштування скорочує час індексації на 50–80% і підвищує точність видачі на 30–40%. Ми працюємо з Бітрікс більше 10 років і гарантуємо результат. Проблема посилюється, якщо на сайті одночасно активні кілька модулів — кожен зайвий модуль додає 15–20% обсягу індексних таблиць. Типова картина: адміністратор вмикає пошук по форумах, блогах і документах, хоча користувачам потрібен лише каталог товарів. У результаті індекс роздувається, запити сповільнюються, а агент не встигає обробляти зміни.
Діагностика поточної індексації
Першим ділом дивимося стан індексних таблиць:
SELECT table_name, ROUND(data_length / 1024 / 1024, 2) AS data_mb, ROUND(index_length / 1024 / 1024, 2) AS index_mb, table_rows FROM information_schema.TABLES WHERE table_schema = DATABASE() AND table_name LIKE 'b_search%' ORDER BY data_length DESC; Таблиця b_search_content_stem на великому порталі може займати 2–5 ГБ. OPTIMIZE TABLE для неї блокує запити на години — робимо тільки в технічне вікно.
Як налаштувати параметри індексації?
В адміністративному інтерфейсі (Налаштування → Пошук → Налаштування) міняємо ключові параметри:
- Мінімальна довжина слова — збільшуємо з 2 до 3–4. Двобуквенні слова засмічують індекс і не несуть пошукового сенсу.
- Стоп-слова — додаємо прийменники, сполучники, артиклі. Для україномовного сайту базовий список включає 50–80 слів.
- Модулі, що індексуються — вимикаємо модулі, пошук за якими не потрібен користувачам (форуми, блоги, документообіг).
- Кількість елементів за один прохід агента — оптимально 50–100.
// У налаштуваннях модуля пошуку або через агент CSearch::ReIndex($moduleId, $start, $finish, $step = 50); Інкрементальна vs повна індексація
Повна переіндексація (ReIndexAll) — тільки при первинному налаштуванні або після серйозних змін структури каталогу. У робочому режимі має працювати інкрементальна індексація через агент. Проблема: агент CSearchIndex::IndexAgent спрацьовує на будь-яку зміну DATE_CHANGE. При синхронізації з 1С дата змінюється навіть якщо контент не змінився — агент фактично переіндексує весь каталог щоразу. Рішення: порівнюємо хеш значущих полів до та після оновлення. Оновлюємо DATE_CHANGE тільки при реальній зміні:
$oldHash = md5($oldElement['NAME'] . $oldElement['DETAIL_TEXT'] . implode(',', $oldProperties)); $newHash = md5($newElement['NAME'] . $newElement['DETAIL_TEXT'] . implode(',', $newProperties)); if ($oldHash !== $newHash) { // Оновлюємо зі зміною DATE_CHANGE } else { // Оновлюємо залишки/ціни без тригера переіндексації $DB->Query("UPDATE b_iblock_element SET TIMESTAMP_X = TIMESTAMP_X WHERE ID = {$id}"); } MySQL FULLTEXT vs Elasticsearch: що обрати?
| Параметр | MySQL FULLTEXT (вбудований) | Elasticsearch (через модуль) |
|---|---|---|
| Швидкість на 30 000 товарів | 0.5–2 сек | 0.1–0.3 сек |
| Морфологія мови | Базова (стемінг) | Повноцінна (морфологія) |
| Фасетний пошук | Не підтримується | Підтримується |
| Складність налаштування | Низька | Середня |
| Витрати ресурсів сервера | Низькі | Вимагає окремого сервера |
Якщо каталог до 30 000 позицій і потрібен простий пошук — достатньо оптимізації FULLTEXT. Для 50 000+ і складних фільтрів краще Elasticsearch.
Чистка застарілих записів індексу
На живих сайтах у b_search_content накопичуються записи видалених елементів. Чистимо пакетами по 1000 записів через агент або cron — одним DELETE на 100 000 в прод не працюємо:
-- Знайти записи видалених елементів інфоблоку SELECT sc.ID, sc.PARAM1, sc.PARAM2 FROM b_search_content sc LEFT JOIN b_iblock_element ie ON ie.ID = CAST(sc.PARAM1 AS UNSIGNED) WHERE sc.MODULE_ID = 'iblock' AND ie.ID IS NULL LIMIT 10000; Що входить в оптимізацію пошуку?
- Діагностика поточних індексів і налаштувань модуля пошуку
- Налаштування стоп-слів, мінімальної довжини слова, виключення зайвих модулів
- Оптимізація агента інкрементальної індексації (хешування полів)
- Налаштування MySQL FULLTEXT (my.cnf: innodb_ft_min_token_size, стоп-таблиця)
- Чистка сміття в індексах
- Моніторинг нульових запитів (b_search_log)
- Документація з рекомендаціями та регламентом підтримки
Моніторинг якості пошуку
Після оптимізації налаштовуємо логування запитів з нульовою видачею. Запити з нульовою видачею — сигнал до розширення контенту або переходу на Elasticsearch.
Кейс: скорочення часу індексації в 4 рази
Клієнт — інтернет-магазин автозапчастин (40 000 товарів). Повна індексація тривала 8 годин, агент тримав навантаження CPU 70–90%. Після налаштування інкрементальної індексації з хешуванням та оптимізації FULLTEXT час повного обходу скоротився до 2 годин, навантаження CPU — до 15–20%. Якість пошуку покращилася: кількість нульових запитів знизилася на 35%. Економія бюджету на хмарні ресурси склала близько 400 000 грн на рік.
Типові помилки при налаштуванні пошуку
- Встановлення мінімальної довжини слова = 1: індекс забивається сміттям, пошук сповільнюється.
- Повна переіндексація щоночі: зайве навантаження, достатньо інкрементальної.
- Ігнорування стоп-слів: пошук знаходить статті з прийменниками замість потрібних товарів.
- Відсутність моніторингу: нульові запити залишаються непоміченими, контент не доповнюється.
Результат
Оптимізація параметрів і стратегії індексування скорочує час повного обходу на 50–80%, знижує навантаження агента до фонового рівня та покращує релевантність видачі. Зв'яжіться з нами, щоб отримати консультацію та план робіт. Замовте аудит пошуку — оцінимо ваш проект за 1 день.