Проєктування структури highload-блоків 1С-Бітрікс

Проєктування структури highload-блоків 1С-Бітрікс

Уявіть: каталог на 50 000 товарів з 200 характеристиками — кожен новий параметр додає мільйони рядків у b_iblock_element_property. Система втрачає продуктивність, індекси роздуваються, фасетний індекс перестворюється годинами. Як розвантажити базу даних без втрати швидкодії? Ми бачимо рішення в грамотному проєктуванні highload-блоків. Це не просто «створити таблицю» — це інженерна задача, від якої залежить швидкість роботи всього каталогу.

HL-блок — генератор користувацьких таблиць у MySQL/PostgreSQL поверх D7 ORM. Технічно це запис у b_highload_block, набір полів у b_user_field і автоматично створювана таблиця hl_{XML_ID}. Нічого магічного — просто спосіб створити таблицю з типізованими полями через інтерфейс Бітрікс без написання SQL. Але саме від того, як ця структура спроєктована, залежить, чи буде HL-блок працювати як високопродуктивний довідник чи перетвориться на вузьке місце.

Коли HL-блок, а коли інфоблок чи власна таблиця?

HL-блок замінює інфоблок там, де не потрібні розділи, SEO-поля (META_TITLE, META_KEYWORDS), preview/detail-зображення та вбудовані механізми публікації. Це довідники: бренди, країни, теги, одиниці вимірювання, характеристики для фасета.

HL-блок програє власній D7-таблиці (DataManager) коли:

• Потрібні складені індекси (HL підтримує тільки індекси за окремими полями через UF_*)
• Потрібні зовнішні ключі та каскадні операції
• Схема таблиці змінюється часто і потребує міграцій

У цих випадках правильніше створити клас, що успадковує \Bitrix\Main\ORM\Data\DataManager, і керувати таблицею через нього.

Як вибрати між HL-блоком і власною таблицею?

Висновок: використовуйте HL-блок, якщо не потрібні складені індекси та зв'язки. Інакше — DataManager. HL-блок створюється в 10 разів швидше (хвилини проти годин), але DataManager дозволяє прискорити запити до 5 разів за рахунок кастомних індексів. Застосування HL-блоків замість властивостей інфоблоку дозволяє прискорити вибірку даних у 3-5 разів.

Типи полів HL-блоку та їх особливості

HL-блоки використовують систему користувацьких полів (UF_*). Доступні типи:

• string / string_formatted — VARCHAR. Для імен, назв.
• integer — INT. Для числових ідентифікаторів, сортування.
• double — DECIMAL/FLOAT. Для цін, коефіцієнтів.
• boolean — TINYINT(1). Прапорці активності.
• file — зберігає ID файлу з b_file. Для зображень у довідниках.
• enumeration — прив'язка до b_user_field_enum. Для фіксованих статусів всередині HL-запису.
• datetime / date — DATETIME / DATE.
• iblock_element / iblock_section — прив'язка до елемента або розділу інфоблоку. Використовується з обережністю: створює неявний зв'язок між HL та інфоблоком.

Проблема поля типу iblock_element в HL-блоці: при видаленні елемента інфоблоку HL-запис не оновлюється автоматично — потрібен обробник події OnAfterIBlockElementDelete.

Як правильно індексувати HL-таблиці?

За замовчуванням HL-блок створює таблицю тільки з PRIMARY KEY за полем ID. Всі інші поля — без індексів. Якщо HL-блок використовується як довідник для фасетного індексу каталогу, додаткові індекси зазвичай не потрібні — фасет працює з b_iblock_{ID}_index, а не з HL-таблицею напряму.

Але якщо HL-блок використовується для зберігання операційних даних (історія дій, лог замовлень, записи бонусної програми) — індекси за полями вибірки критичні. Додаються вручну через SQL-міграцію:

ALTER TABLE hl_loyalty_history ADD INDEX idx_user_id (UF_USER_ID); ALTER TABLE hl_loyalty_history ADD INDEX idx_date (UF_DATE); 

Бітрікс не надає UI для керування індексами HL-таблиць — тільки прямий SQL або скрипт міграції. Детальне профілювання запитів допомагає визначити оптимальну індексну стратегію.

Кейс із нашої практики: HL-блок для B2B-каталогу

Наш клієнт — дистриб'ютор електроніки. У каталозі 2 200 унікальних характеристик товарів (технічні параметри). Спочатку — властивості інфоблоку типу «Рядок», b_iblock_element_property містила 8 млн рядків.

Рішення: перевести довідкові характеристики на HL-блоки за доменами:

• hl_tech_connectivity — інтерфейси підключення (USB-C, HDMI, тощо)
• hl_tech_resolution — роздільна здатність екранів та матриць
• hl_tech_standard — стандарти (Wi-Fi 6, Bluetooth 5.2, тощо)

Кожен HL-блок: поля UF_NAME (VARCHAR 255), UF_XML_ID (VARCHAR 50, унікальний), UF_ACTIVE (boolean), UF_SORT (integer). Індекси за UF_XML_ID — додані вручну для швидкого пошуку при імпорті з 1С.

Результат: b_iblock_element_property скоротилася з 8 млн до 1.2 млн рядків (залишилися тільки числові властивості). Розмір таблиці зменшено на 85% порівняно з оригінальною схемою. Фасетний індекс перестворюється за 8 хвилин замість 45.

Керування даними HL-блоку через D7

Робота з HL-блоком у коді — через \Bitrix\Highloadblock\HighloadBlockTable і динамічно створюваний клас:

$hlblock = \Bitrix\Highloadblock\HighloadBlockTable::getById($id)->fetch(); $entity = \Bitrix\Highloadblock\HighloadBlockTable::compileEntity($hlblock); $dataClass = $entity->getDataClass(); $rows = $dataClass::getList(['filter' => ['UF_ACTIVE' => true]]); 

Це стандартний патерн — його важливо закріпити в code style проєкту, щоб звернення до HL-блоків не розповзалися по шаблонах у вигляді SQL-запитів.

Рекомендований підхід до проєктування HL-блоків

1. Проаналізуйте поточну схему даних та визначте кандидати на винесення в HL.
2. Створіть ER-діаграму для нових HL-блоків.
3. Визначте індекси для полів фільтрації.
4. Реалізуйте міграцію даних через D7 ORM.
5. Проведіть тестування продуктивності.

Що входить у роботу з проєктування HL-блоків

Орієнтовний термін повного циклу для 10-15 HL-блоків — від 2 до 5 робочих днів. Вартість розраховується індивідуально залежно від складності предметної області та необхідності міграції. Щоб отримати консультацію та оцінку вашого проєкту — просто напишіть нам. Ми — сертифікований партнер 1С-Бітрікс з 10+ роками досвіду та 50+ реалізованими проєктами з оптимізації продуктивності. Гарантуємо прозорість на кожному етапі.

Корисні ресурси:

• Документація 1С-Бітрікс по HL-блоках
• Bitrix D7 ORM