Ми знаємо, як важливо правильно спроектувати інфоблоки. Уявіть: після запуску фільтр за характеристиками товарів видає timeout, а імпорт із 1С створює дублі в кожному елементі. Причина — неправильно спроектовані інфоблоки. Помилки на цьому етапі обходяться дорого: переробка структури після запуску може вимагати міграції тисяч елементів, зупинки каталогу на кілька днів і додаткових витрат на розробку. З нами ви отримаєте структуру, яка витримає кілька років без змін. Наші спеціалісти з 10+ років досвіду в Бітрікс допоможуть обрати правильні типи властивостей, налаштувати HL-блоки та фасетний індекс для максимальної продуктивності. 10+ років досвіду в Бітрікс, сертифіковані спеціалісти, партнер 1С-Бітрікс. Правильне проектування структури інфоблоків 1С-Бітрікс — це інвестиція в стабільність і продуктивність вашого каталогу.
Типова помилка при проектуванні: використання одного інфоблоку для всіх сутностей — товари, статті, банери, довідники. Це призводить до роздутої таблиці b_iblock_element_property, падіння швидкості фільтрації та складнощів із кешуванням. Рішення: рознести домени даних за різними типами інфоблоків.
Як правильно вибрати тип властивості?
Кожна властивість інфоблоку має тип, і це рішення не можна змінити без міграції даних. Нижче таблиця з основними типами та рекомендаціями:
| Тип властивості | Призначення | Коли використовувати |
|---|---|---|
| Рядок | Текстові значення без повторень | Для унікальних полів (артикул, назва) |
| Число | Числові значення для фільтра за діапазоном | Ціна, вага, потужність |
| Список | Фіксований набір значень | Статуси, категорії розмірів |
| Довідник (HL-блок) | Динамічні довідники | Бренди, країни, метро (множинні) |
| Файл | Зображення та документи | Додаткові фото (якщо >2) |
| Прив'язка до елементів | Зв'язок елементів | Пов'язані товари, комплекти |
Згідно з документацією 1С-Бітрікс, правильний вибір типу властивості — основа продуктивності каталогу. Рядки без індексу та дублі в b_iblock_element_property — часта причина гальм. Фасетний індекс вирішує проблему, але тільки для властивостей числового типу, списків та довідників.
Структура типів інфоблоків
Тип інфоблоку — це групування, що не має технічного значення, але критичне для керованості. Правило: один тип інфоблоку = один домен даних. «Каталог», «Статті», «Банери», «Довідники» — правильне групування. «Сайт» як єдиний тип для всього — антипатерн.
Для інтернет-магазину типова структура типів:
-
catalog— інфоблоки каталогу товарів та торгових пропозицій -
content— новини, статті, FAQ -
references— довідники (використовувані як джерело для властивостей типу «Список», якщо не HL-блоки) -
landing— лендінгові блоки, банери
Як глибина розділів впливає на продуктивність?
Розділи (b_iblock_section) зберігаються в нативному дереві Бітрікс. Практичне обмеження: глибина вкладеності більше 5–6 рівнів створює проблеми з хлібними крихтами, ЧПУ та навігацією. Якщо бізнес вимагає глибшої ієрархії (наприклад, запчастини для обладнання: виробник → модель → серія → вузол → деталь) — розглядається заміна ієрархії властивостями з фільтрацією замість навігації за розділами.
Множинні властивості та продуктивність
Множинна властивість зберігає кілька значень у b_iblock_element_property — по одному рядку на кожне значення. 10 000 елементів × властивість із 5 значеннями = 50 000 рядків у таблиці тільки для цієї властивості. При множинних властивостях-довідниках фасетний індекс обробляє їх коректно, але навантаження при перестворенні індексу вище.
Правило: якщо властивість рідко буває заповнена (заповнена у 10% елементів) — порожні записи не зберігаються, що знижує обсяг таблиці. Якщо властивість заповнена у всіх елементів і рідко змінюється — розглянути перенесення в окрему HL-таблицю через DataManager.
Чому важливо розбивати дані на різні типи інфоблоків?
Правильне розділення за типами дозволяє уникнути уповільнення запитів при змішуванні різнорідних даних. Наприклад, товари та банери мають різні набори властивостей і частоту оновлення. Якщо їх об'єднати, при вибірці банерів доводиться сканувати й товарні записи, що збільшує навантаження. Агенції, які нехтують цим правилом, часто стикаються з ростом часу виконання компонента 'catalog'.
Кейс: проектування інфоблоків для агрегатора нерухомості
Платформа оголошень про продаж та оренду нерухомості. Початкове рішення: один інфоблок «Об'єкти» з 40 властивостями, включаючи рядкові адреса, район, метро.
Проблеми під навантаженням:
- Фільтр за метро працював як текстовий пошук (LIKE), а не за індексом
- Дублі значень: «м. Арбатська», «Арбатська», «арбатська» — три різні записи
- Пошук за радіусом від метро неможливий без геокоординат
Реструктуризована схема:
-
catalogтип: інфоблок «Об'єкти» + інфоблок «Житлові комплекси» - HL-блок hl_metro з полями: UF_NAME, UF_LINE, UF_LAT, UF_LON — 342 записи замість текстових значень
- HL-блок hl_district — райони з прив'язкою до міста
- Властивості «Площа», «Поверх», «Поверховість» — тип «Число» для фільтра за діапазоном
- Властивість «Метро» — довідник (HL), множинне (кілька станцій)
Фасетний індекс після реструктуризації: створюється за 3 хвилини на 85 000 об'єктів, фільтр за метро та типом — 0.15 секунди. Наш клієнт отримав прискорення фільтрації більш ніж у 50 разів. Це дозволило зекономити бюджет на серверних ресурсах і скоротити час очікування користувачів. Це рішення в 50 разів краще за типову реалізацію з рядковими властивостями. Проектування структури для такого агрегатора коштувало 1500 доларів, а щомісячна економія на серверних ресурсах склала 300 доларів. Детальніше про фасетний індекс — на Wikipedia.
Що входить в роботу
Етапи проектування
- Аналіз предметної області — список сутностей і зв'язків (1–2 дні).
- Проектування схеми властивостей — вибір типів, HL-блоки, фасетний індекс (1–3 дні).
- Проектування ієрархії розділів — оптимальна глибина, заміна властивостями при необхідності (0.5–1 день).
- Документування — схема в табличному форматі для кожного інфоблоку (0.5–1 день).
- Узгодження — затвердження схеми із замовником (0.5 дня).
- Опціонально: реалізація — розгортання структури, перенесення даних (від 2 днів).
| Етап | Тривалість | Результат |
|---|---|---|
| Аналіз предметної області | 1-2 дні | Список сутностей і зв'язків |
| Проектування схеми | 1-3 дні | Документ структури інфоблоків |
| Узгодження | 0.5 дня | Затверджена схема |
| Реалізація (опціонально) | від 2 днів | Працююча структура з перенесенням даних |
Після завершення ви отримаєте: документ структури інфоблоків, рекомендації з налаштування, консультацію з перенесення даних, підтримку протягом місяця. Вартість проектування від 500 доларів.
Замовте проектування під ключ – ми виконаємо роботу за 7-10 днів. Пишіть нам, щоб оцінити ваш проект безкоштовно. У вартість входить: аналіз, проектування, документування та консультація. Спроектована структура знижує витрати на підтримку та розробку нових функцій.