Прискорення Highload-блоків: аудит, індекси, кеш, партиціонування

Прискорення роботи Highload-блоків: підходи та інструменти

Уявіть: highload-блок з історією замовлень на 5 млн рядків — запит вибірки за датою фільтрації виконується 40 секунд. Після оптимізації — 8 мілісекунд. Таке можливе при правильному індексуванні, кешуванні та партиціонуванні. Highload-блоки (модуль highloadblock) — механізм Бітрікс для зберігання довільних даних в окремих таблицях. Популярні застосування: журнали подій, каталоги товарів з нестандартною структурою, профілі користувачів, накопичувальні дані (історія замовлень, аналітика, черги). Доки рядків менше 50–100 тисяч — все працює нормально. При 1–10 мільйонах рядків починаються проблеми: ORM Бітрікс генерує неоптимальні запити, індекси не покривають реальні вибірки, JOINи гальмують. Ми стикалися з проектами, де час вибірки сягав 40 секунд — після оптимізації падав до 8 мілісекунд. Економія часу на кожному запиті — до 99.9%.

Чому highload-блоки гальмують на великих даних?

Основні антипатерни при роботі з Highload:

• Відсутність потрібних індексів. Highload-блок створює таблицю з первинним ключем ID та автоінкрементом. Користувацькі поля типу UF_* не індексуються автоматично. Вибірка getList(['filter' => ['UF_PRODUCT_ID' => 123]]) при мільйоні рядків — це table scan.
• SELECT *-подібні запити. ORM Бітрікс за замовчуванням вибирає всі поля. Якщо у запису 30 UF-полів, включаючи TEXT та FILE, це дорогий запит навіть при малому result set.
• Необмежені вибірки без пагінації. DataManager::getList() без limit поверне всі записи в пам’ять PHP.
• Пов’язані таблиці через Reference. Якщо Highload пов’язаний з іншим Highload або інфоблоком через Reference-поля — ORM будує JOIN, який без правильних індексів вбиває продуктивність.
• Часті UPDATE по полях без індексу. Типово для статусних полів, лічильників.

Як діагностувати вузькі місця?

Вмикаємо лог повільних запитів MySQL:

[mysqld] slow_query_log = 1 slow_query_log_file = /var/log/mysql/slow.log long_query_time = 1 log_queries_not_using_indexes = 1 

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

Додаємо індекси через прямий SQL — в агенті при встановленні або в migration-скрипті:

$connection = \Bitrix\Main\Application::getConnection(); $tableName = 'b_hl_product_catalog'; // Приклад $connection->queryExecute( "CREATE INDEX IF NOT EXISTS idx_product_id ON {$tableName} (UF_PRODUCT_ID)" ); $connection->queryExecute( "CREATE INDEX IF NOT EXISTS idx_status_date ON {$tableName} (UF_STATUS, UF_DATE_CREATE)" ); 

Що робити, якщо ORM гальмує навіть з індексами?

Явний SELECT потрібних полів. Ніколи не запитуємо select: ['*'] або порожній масив select:

$result = ProductCatalogTable::getList([ 'select' => ['ID', 'UF_NAME', 'UF_PRICE', 'UF_ACTIVE'], 'filter' => ['UF_CATEGORY_ID' => $categoryId, 'UF_ACTIVE' => 1], 'order' => ['UF_SORT' => 'ASC'], 'limit' => 50, 'offset' => ($page - 1) * 50, ]); 

Прямі SQL-запити для агрегації. Для COUNT, SUM, GROUP BY з великими таблицями — прямий SQL в 5–7 разів швидший за ORM. Використовуйте Bitrix\Main\Application::getConnection()->query().

Партиціонування для хронологічних даних. Якщо Highload зберігає логи або події з датою — партиціонування за діапазоном дат різко прискорює вибірки за період:

ALTER TABLE b_hl_event_log PARTITION BY RANGE (YEAR(UF_DATE_CREATE) * 100 + MONTH(UF_DATE_CREATE)) ( PARTITION p_jan VALUES LESS THAN (202402), PARTITION p_feb VALUES LESS THAN (202403), PARTITION p_future VALUES LESS THAN MAXVALUE ); 

Кешування результатів. Highload-дані добре кешуються через Bitrix\Main\Data\Cache з тегуванням. Приклад реалізації:

class CachedProductCatalog { private const CACHE_TAG = 'hl_product_catalog'; private const CACHE_TTL = 3600; public function getByCategory(int $categoryId): array { $cache = \Bitrix\Main\Data\Cache::createInstance(); $cacheKey = 'hl_catalog_cat_' . $categoryId; if ($cache->initCache(self::CACHE_TTL, $cacheKey, '/hl/catalog/')) { return $cache->getVars(); } $cache->startDataCache(); // Fetch from DB $result = $this->fetchFromDb($categoryId); // Тегований кеш $tagCache = new \Bitrix\Main\Data\TaggedCache(); $tagCache->startTagCache('/hl/catalog/'); $tagCache->registerTag(self::CACHE_TAG . '_' . $categoryId); $tagCache->endTagCache(); $cache->endDataCache($result); return $result; } } 

Бенчмарки: що дає кожна оптимізація

Покроковий план оптимізації

1. Аудит Highload-блоків. Збір структури, обсягів даних, типових запитів. Включення slow query log.
2. Аналіз вузьких місць. Виявлення топ-5 гальмівних запитів за часом.
3. Додавання індексів. Створення одиночних та складених індексів під реальні фільтри.
4. Рефакторинг коду. Заміна select: ['*'] на явний список, впровадження лімітів та пагінації.
5. Кешування. Впровадження тегованого кешу для часто запитуваних даних.
6. Партиціонування. Для хронологічних таблиць — розбиття за датою.
7. Навантажувальне тестування. AB-порівняння продуктивності до та після.

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

• Аудит Highload-блоків: структура, обсяг даних, типові запити та slow query log.
• Аналіз вузьких місць: виявлення топ-5 гальмівних запитів.
• Додавання індексів: одиночних та складених під реальні патерни фільтрації.
• Рефакторинг коду: явний select, ліміти, пагінація, заміна ORM на прямий SQL там, де це дає суттєвий виграш.
• Впровадження тегованого кешу для важких вибірок.
• Партиціонування хронологічних таблиць (за потреби).
• Навантажувальне тестування з AB-порівнянням до/після.
• Документація та навчання вашого розробника.

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

Терміни робіт: аудит + індекси + кеш — 2–3 тижні. Повна оптимізація з партиціонуванням та рефакторингом — 4–8 тижнів. Вартість розраховується індивідуально в залежності від обсягу даних та складності. Наша команда з багаторічним досвідом у Бітрікс, яка реалізувала понад 50 проектів з оптимізації, гарантує прозорий підхід та вимірювані результати. Зв’яжіться з нами для попередньої оцінки — ми запропонуємо план робіт з контрольними точками. Замовте аудит продуктивності та отримайте консультацію інженера.

Докладніше про Highload-блоки в офіційній документації.