Инфоблоки 2.0 — обновлённая архитектура хранения данных элементов и разделов, пришедшая на смену классической структуре таблиц инфоблоков. Разберём, что реально меняется под капотом, когда стоит включать новую версию, а когда лучше остаться на классической.
В чём принципиальное отличие от классических инфоблоков
Классические инфоблоки хранят свойства элементов в универсальных таблицах значений свойств, общих для всех инфоблоков сайта, — это гибко, но создаёт большие таблицы со временем и требует дополнительных JOIN-ов при выборке. Инфоблоки 2.0 переходят на отдельные таблицы под каждый инфоблок со своими именованными колонками для каждого свойства — структура становится ближе к обычной реляционной таблице, что даёт более быстрые выборки и более простые SQL-запросы напрямую к данным без универсальной прослойки.
Прирост производительности на больших объёмах
Выигрыш от новой архитектуры заметнее всего на больших инфоблоках с активной фильтрацией по свойствам — выборка по колонке в обычной таблице с индексом работает быстрее, чем аналогичная выборка через универсальную таблицу значений свойств с дополнительным JOIN. На небольших инфоблоках разница в производительности между версиями практически не ощущается.
Нужна помощь с Битрикс?
Совместимость со старым кодом
Публичный API (CIBlockElement::GetList,
Add, Update) продолжает работать
одинаково для обоих типов инфоблоков — переход на 2.0 не требует
переписывания прикладного кода, использующего штатный API. Риск
несовместимости возникает там, где код напрямую обращается
к структуре таблиц базы данных в обход API — такой код требует
ревизии перед переходом, поскольку структура таблиц физически
меняется.
Как включить инфоблоки 2.0
Переход на новую архитектуру выполняется через раздел настроек конкретного инфоблока в административной панели, с конвертацией существующих данных в новую структуру таблиц, — операция необратима без восстановления из резервной копии, поэтому обязательна предварительная резервная копия базы данных перед конвертацией, особенно для инфоблоков с большим объёмом накопленных данных.
Когда стоит переходить
- Крупные инфоблоки каталога с активной фильтрацией по множеству свойств, где производительность выборки уже ощутимо влияет на скорость сайта.
- Новые проекты, стартующие с нуля, — логично сразу выбирать актуальную архитектуру без необходимости последующей миграции.
Когда переход не оправдан
- Небольшие справочные инфоблоки без заметной нагрузки, где выигрыш в производительности не будет ощутим на практике.
- Проекты с большим объёмом кода, напрямую обращающегося к структуре таблиц инфоблоков в обход API, — риск поломки такого кода перевешивает выгоду от перехода без предварительной ревизии этого кода.
Тестирование перед переводом боевого инфоблока
Конвертацию стоит сначала опробовать на копии сайта или тестовом окружении, а не сразу на боевом инфоблоке с реальными данными посетителей, — особенно если в проекте есть кастомный код, взаимодействующий со структурой данных нестандартным образом, который может повести себя иначе после смены архитектуры хранения.
Частые ошибки
- Конвертация выполнена без предварительной резервной копии. Операция необратима без восстановления из бэкапа при сбое.
- Не проверен код, обращающийся к таблицам базы напрямую. Такой код ломается при смене структуры таблиц под капотом.
- Переход выполнен для инфоблока без реальной проблемы производительности. Выигрыш не ощущается, а риск операции остаётся.
Итог
Инфоблоки 2.0 дают заметный прирост производительности выборки для крупных инфоблоков с активной фильтрацией по свойствам, сохраняя совместимость публичного API со старым кодом. Переход оправдан не для каждого инфоблока — небольшие справочники и проекты с кодом, завязанным напрямую на структуру таблиц базы, требуют более осторожного подхода или вовсе не нуждаются в миграции.