Пошук Sphinx для 1С-Бітрікс: налаштування, морфологія, дельта-індексація

Чому стандартний пошук у Бітрікс не справляється з великим каталогом?

Каталог на 200 000 товарів — стандартний пошук Бітрікс видає сторінку за 5 секунд, фільтрація за властивостями — ще довше. Стандартний модуль пошуку використовує таблиці b_search_*, які не оптимізовані для складної фільтрації за багатьма властивостями та повнотекстового пошуку з морфологією. Sphinx вирішує обидві проблеми: інкрементальна індексація, морфологія, фасетний пошук. Ми налаштовуємо його під ключ за 3–10 днів. Рушій читає дані безпосередньо з MySQL, що спрощує інтеграцію: не потрібно писати експортер — джерело даних описується SQL-запитами в конфігу Sphinx.

Наприклад, у проекті інтернет-магазину автозапчастин з каталогом 350 тис. позицій після впровадження Sphinx час пошуку скоротився з 8 секунд до 50 мс, а фільтрація за 12 властивостями стала миттєвою. Ми впровадили Sphinx в 30+ проектах на Бітрікс з каталогами від 10 тис. до 500 тис. позицій. Гарантуємо стабільну роботу та підтримку після запуску. Зв'яжіться з нами — опрацюємо архітектуру пошуку під ваш проект.

Як налаштувати джерело даних для Sphinx?

Sphinx читає дані через source — SQL-запит, що виконується при переіндексації. Приклад конфігу для каталогу товарів:

source bitrix_catalog
{
    type            = mysql
    sql_host        = localhost
    sql_user        = bitrix
    sql_pass        = password
    sql_db          = bitrix_db
    sql_port        = 3306

    sql_query = \
        SELECT \
            e.ID, \
            e.IBLOCK_ID, \
            e.NAME, \
            e.DETAIL_TEXT, \
            e.CODE, \
            UNIX_TIMESTAMP(e.TIMESTAMP_X) AS updated_at \
        FROM b_iblock_element e \
        WHERE e.IBLOCK_ID IN (5, 6) \
          AND e.ACTIVE = 'Y' \
          AND e.WF_STATUS_ID = 1

    sql_attr_uint  = IBLOCK_ID
    sql_attr_uint  = updated_at
    sql_field_string = NAME
}

sql_attr_uint оголошує числові атрибути для фільтрації, sql_field_string — рядкове поле для пошуку та виведення. Sphinx підтримує до сотень атрибутів без втрати продуктивності.

Підключення властивостей товарів для фасетної фільтрації

Для фасетної фільтрації додаємо властивості через sql_attr_multi:

sql_attr_multi = uint PROPERTY_COLOR FROM query; \
    SELECT e.ID, p.VALUE_NUM \
    FROM b_iblock_element e \
    JOIN b_iblock_element_prop_s5 p ON p.IBLOCK_ELEMENT_ID = e.ID \
    WHERE e.IBLOCK_ID = 5

Таблиця b_iblock_element_prop_s5 відповідає інфоблоку ID 5. Це особливість Бітрікс: кожному інфоблоку — своя таблиця властивостей. У складних проектах ми об'єднуємо кілька таблиць через UNION. Також можна індексувати множинні властивості через sql_attr_multi з роздільниками, що дозволяє реалізувати фільтр за декількома значеннями одночасно.

Як налаштувати російську морфологію?

Sphinx підтримує російську мову через вбудований стеммер. Конфігурація індексу:

index bitrix_catalog
{
    source          = bitrix_catalog
    path            = /var/lib/manticore/bitrix_catalog
    morphology      = stem_ru, stem_en
    min_word_len    = 2
    charset_table   = 0..9, A..Z->a..z, a..z, U+410..U+42F->U+430..U+44F, U+430..U+44F
    min_prefix_len  = 3
}

min_prefix_len = 3 включає prefix-пошук: «ноут» → «ноутбук». Збільшує індекс, але ми завжди оптимізуємо під ваш обсяг даних. Для великих каталогів (понад 300 тис.) рекомендуємо відмовитися від prefix і використовувати інфіксний пошук. Налаштування charset_table забезпечує коректну обробку кирилиці та реєстронезалежність.

PHP-клієнт та запити з Бітрікс

Sphinx використовує протокол MySQL, тому звертаємося через PDO:

$sphinx = new PDO('mysql:host=127.0.0.1;port=9306', '', '');

$stmt = $sphinx->prepare(
    "SELECT id, weight() as w, NAME
     FROM bitrix_catalog
     WHERE MATCH(:query) AND IBLOCK_ID = :iblock
     ORDER BY w DESC
     LIMIT :offset, :limit
     OPTION max_matches=1000"
);
$stmt->execute([
    ':query'  => $searchQuery,
    ':iblock' => CATALOG_IBLOCK_ID,
    ':offset' => ($page - 1) * $pageSize,
    ':limit'  => $pageSize,
]);

$ids = array_column($stmt->fetchAll(), 'id');

Отримавши $ids, завантажуємо повні дані через CIBlockElement::GetList(). Це стандартний патерн, який ми використовуємо у всіх проектах. Для прискорення можна кешувати ID результату на 5–10 хвилин. При великій кількості запитів рекомендуємо пул з'єднань PDO.

Як налаштувати дельта-індексацію для актуальних даних?

Повна переіндексація (indexer --all) — для нічних крон-завдань. Delta-індекс — індексує лише змінені записи з останньої індексації. Потрібне поле updated_at та окреме джерело:

source bitrix_catalog_delta : bitrix_catalog
{
    sql_query = \
        SELECT e.ID, ... \
        FROM b_iblock_element e \
        WHERE UNIX_TIMESTAMP(e.TIMESTAMP_X) > (SELECT max_doc_date FROM sph_counter WHERE id=1)
}

Об'єднання: indexer --merge bitrix_catalog bitrix_catalog_delta. Delta-індексація виконується кожні 5–10 хвилин через крон. Ми також налаштовуємо sph_counter для коректного відстеження часу останньої індексації. При збоях крон-завдань автоматично запускається повна переіндексація.

Чому Sphinx, а не Elasticsearch?

Sphinx у 2-3 рази швидше індексує дані з MySQL на серверах з 2 CPU та 4 GB RAM. Порівняння для типового каталогу Бітрікс:

Обирайте Sphinx, якщо сервер < 4 GB RAM і дані тільки з MySQL. Elasticsearch підійде для кластерів та агрегацій у реальному часі. У 80% наших проектів для Бітрікс використовуємо саме Sphinx. Детальніше про Sphinx читайте у Wikipedia.

Які типові помилки виникають при налаштуванні Sphinx?

Найчастіша — неправильна charset_table: якщо кирилиця не вказана, пошук за російськими словами повертає пустий результат. Друга за частотою — відсутність sql_attr_multi для властивостей: фасетна фільтрація перестає працювати. Третя — занадто великий min_prefix_len: при каталозі >500 тис. позицій індекс зростає в 2-3 рази, і час індексації збільшується. Ми в кожному проекті проводимо аудит конфігурації та навантажувальне тестування, щоб виключити ці проблеми.

Що входить в інтеграцію

• Аналіз структури каталогу та вимог до пошуку
• Розгортання Sphinx (Manticore) на сервері
• Конфігурація джерел даних (інфоблоки, властивості, hl-блоки)
• Налаштування індексів з морфологією та prefix-пошуком
• Розробка PHP-шлюзу для запитів з Бітрікс
• Інтеграція з компонентом каталогу (фасетний пошук, фільтр)
• Реалізація дельта-індексації (актуальність даних)
• Тестування на тестовому навантаженні
• Документація та навчання адміністратора
• Гарантія 12 місяців на всі роботи

Терміни та вартість

Вартість розраховується індивідуально після аналізу вашого проекту. Оцінимо обсяг даних, складність фасетів та вимоги до швидкості. Замовте інтеграцію — отримайте консультацію з архітектури пошуку. Сертифіковані спеціалісти з досвідом 7+ років гарантують стабільну роботу та підтримку після запуску.

80% сайтів на Бітрікс гальмують через одну таблицю

b_iblock_element_property — EAV-структура. Кожен рядок зберігає одне значення однієї властивості одного елемента. Каталог у 50 000 товарів з 30 властивостями дає 1,5 млн рядків. Коли розумний фільтр робить JOIN цієї таблиці з b_iblock_element за п'ятьма властивостями, MySQL іде в full table scan на 3–5 секунд.

Наш досвід показує: без втручання в цю таблицю прискорення неможливе. Ми беремося за проекти, де швидкість завантаження впала до 8–10 секунд, і повертаємо TTFB < 200 мс за 1–2 тижні. Оптимізація швидкості сайту починається з аудиту slow-запитів і закінчується комплексною перебудовою інфраструктури під ключ. У нашому портфоліо — понад 200 успішних проєктів. Ми — команда сертифікованих фахівців з 10‑річним досвідом роботи в Бітрікс.

Серверна оптимізація

Nginx. Не просто «увімкнули gzip». Конкретно:

• gzip_comp_level 4-5 — вище безглуздо, CPU з'їдає більше, ніж економить трафік;
• brotli on з brotli_static on — для попередньо стиснутих файлів (Brotli стискає на 20–30% краще за gzip);
• HTTP/2 з http2_max_concurrent_streams 128;
• fastcgi_cache для PHP-відповідей — кешування на рівні Nginx, минаючи PHP-FPM;
• worker_processes auto, worker_connections під кількість одночасних з'єднань.

PHP-FPM. Вибір між pm = dynamic і pm = static — не академічний:

• Static: фіксована кількість воркерів, без overhead на форк — для виділених серверів з передбачуваним навантаженням.
• Dynamic: економить RAM при низькому трафіку. pm.max_children рахуємо як (доступна RAM − RAM для MySQL/Redis) / середня витрата на процес.
• OPcache: opcache.memory_consumption=256, opcache.max_accelerated_files=20000, opcache.validate_timestamps=0 на продакшені (перезавантаження PHP-FPM при деплої).

MySQL/MariaDB. Головне вузьке місце майже завжди:

• slow_query_log з порогом 0.5 сек — кожен запит розбираємо через EXPLAIN.
• innodb_buffer_pool_size = 70–80% доступної RAM на виділеному сервері.
• Складені індекси для фасетного пошуку: (IBLOCK_ID, IBLOCK_PROPERTY_ID, VALUE) на b_iblock_element_property.
• OPTIMIZE TABLE b_iblock_element_property після масових операцій.

Як налаштувати кешування на три рівні?

Керований кеш компонентів. TTL налаштовуємо для кожного компонента окремо. Каталог — 3600 сек, новинна стрічка — 300 сек, банери — 86400. Однаковий TTL всюди — гарантія або застарілих даних, або марного кешу.

Композитний кеш. Технологія bitrix:composite — Nginx віддає готовий HTML із файлу, PHP не запускається. Динамічні зони (кошик, авторизація) підвантажуються AJAX-запитом через CBitrixComponent::setFrameMode(true). TTFB < 50 мс. Але не всі компоненти сумісні: $APPLICATION->ShowPanel() і прямий вивід через echo ламають композит. Перевіряємо кожну сторінку через панель «Продуктивність → Композитний сайт».

Порівняння: композитний кеш швидший за керований у 10–20 разів за часом першого байта. Офіційна документація Бітрікс з композитного кешу — Bitrix Composite.

Memcached / Redis. Переносимо кеш із файлової системи:

• Сесії → Redis (session.save_handler = redis) — швидше за файли в 10–50×, плюс робота в кластері.
• Кеш компонентів → Memcached через .settings.php: 'cache' => ['type' => 'memcache'].
• Кеш ORM-запитів — однакові GetList() не навантажують MySQL на кожному хіті.

Чому стандартних налаштувань MySQL недостатньо?

Індекси. Складені для фасетного пошуку. Покриваючі — для частих вибірок MySQL відповідає з індексу, не звертаючись до даних. Часткові індекси (MariaDB) для фільтрації за ACTIVE = 'Y'. Аудит невикористовуваних індексів — кожен сповільнює INSERT/UPDATE.

Партиціонування. Для таблиць з мільйонами рядків: b_stat_session, b_search_content_stem, Highload-блоки з історією. Партиція за датою — запит «замовлення за місяць» не сканує дані за три роки.

Реальний кейс: каталог 200 000 товарів, 50 властивостей. Фільтр за 10 властивостями займав 12 секунд. Після створення складених індексів за (IBLOCK_ID, IBLOCK_PROPERTY_ID, VALUE) та партиціонування b_iblock_element_property за IBLOCK_ID час виконання впав до 0,3 секунди. Навантаження на MySQL знизилося в 40 разів. Це дозволило скоротити витрати на сервер до 40% без втрати продуктивності.

Очищення. У будь-якій базі за рік-два накопичується: застарілий пошуковий індекс, прострочені записи в b_cache_tag, історія b_iblock_element_prop_s*, логи в b_event_log на гігабайти. Налаштовуємо регулярне очищення через агенти.

Партиціонування також вирішує проблему з паралельними запитами при обміні з 1С через CommerceML. Докладніше: MySQL Partitioning Documentation.

Після аудиту вашого проекту ми визначимо вузькі місця за 2 години та запропонуємо конкретний план прискорення. Замовте безкоштовний аудит швидкості — заповніть форму на сайті.

Фронтенд

Зображення — 60–80% ваги сторінки:

• WebP через CFile::ResizeImageGet() з BX_RESIZE_IMAGE_PROPORTIONAL + конвертація;
• srcset + sizes — не завантажуємо 3000px картинку в блок 400px;
• loading="lazy" для всього нижче першого екрану;
• AVIF — ще 20–30% економії порівняно з WebP.

CSS/JS:

• Вбудований модуль Бітрікс: об'єднання та мініфікація через «Налаштування → Оптимізація CSS/JS»;
• PurgeCSS / UnCSS — на типовому Бітрікс-проекті 60–70% CSS не використовуються;
• defer / async для некритичного JS;
• Critical CSS інлайном у <head> для миттєвого FCP.

Шрифти:

• <link rel="preload" as="font" crossorigin> для основного шрифту;
• font-display: swap — текст видно одразу;
• Subsetting через pyftsubset — вирізаємо кирилицю + латиницю, файл зменшується в 3–5 разів.

CDN

Cloudflare, BunnyCDN, AWS CloudFront або локальні (Selectel CDN, VK Cloud CDN).

• Статика (CSS, JS, зображення, шрифти) — через CDN.
• Правила кешування: Cache-Control: public, max-age=31536000, immutable для файлів з хешем.
• Оптимізація зображень на льоту (imgproxy, Cloudflare Polish) без навантаження на origin.

Навіщо потрібне навантажувальне тестування?

Не синтетичні бенчмарки, а реальні сценарії:

• k6 / wrk — імітація маршрутів: каталог → фільтрація → картка → кошик → оформлення.
• Метрики: RPS, час відповіді (p50, p95, p99), відсоток помилок.
• Xdebug (callgrind) або Blackfire — профілювання PHP, пошук вузьких місць.

Результат тестування — об'єктивна картина, де реально гальмує. Після оптимізації проганяємо повторно — фіксуємо покращення.

Результати

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

1. Аудит поточної продуктивності — аналіз slow-запитів, профілювання PHP, перевірка кешування, CDN, серверних налаштувань.
2. Налаштування серверної частини — Nginx, PHP-FPM, MySQL, Redis/Memcached, OPcache.
3. Оптимізація кешування — керований кеш, композитний сайт, налаштування TTL, теговане кешування.
4. Робота з БД — створення індексів, партиціонування, очищення, реорганізація EAV-таблиць.
5. Фронтенд — зображення (WebP/AVIF), CSS/JS (мініфікація, deferred), шрифти (preload, subsetting).
6. CDN — підключення, налаштування правил кешування.
7. Навантажувальне тестування — сценарії реальних користувачів, звіт за метриками.
8. Документація — опис усіх змін, рекомендації щодо подальшого обслуговування.
9. Гарантія — підтримка протягом 1 місяця після здачі.

Моніторинг

Без моніторингу через півроку все деградує. Новий модуль, неочищені логи, зміна в шаблоні — і швидкість повернулася до початкової.

• web-vitals API — Real User Monitoring від реальних відвідувачів.
• Synthetic monitoring — Pingdom, UptimeRobot, регулярні перевірки з різних локацій.
• Алерти — TTFB > 500 мс або LCP > 3 сек → сповіщення.

Терміни та вартість

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