Designing Highload-Block Structure in 1C-Bitrix

Designing Highload-Block Structure in 1C-Bitrix

Imagine: a catalog with 50,000 products and 200 characteristics — each new parameter adds millions of rows to b_iblock_element_property. The database starts to slow down, indexes bloat, the facet index takes hours to rebuild. How do you offload the system without losing performance? We see the solution in competent highload-block design. It's not just "create a table" — it's an engineering task that determines the speed of the entire catalog.

An HL-block is a generator of custom tables in MySQL/PostgreSQL on top of D7 ORM. Technically, it's a record in b_highload_block, a set of fields in b_user_field, and an automatically created table hl_{XML_ID}. Nothing magical — just a way to create a table with typed fields through the Bitrix interface without writing SQL. But exactly how this structure is designed determines whether the HL-block will work as a fast reference or become a bottleneck.

When HL-block, and when infoblock or custom table?

An HL-block replaces an infoblock where sections, SEO fields (META_TITLE, META_KEYWORDS), preview/detail images, and built-in publication mechanisms are not needed. These are reference books: brands, countries, tags, units of measurement, characteristics for facets.

An HL-block loses to a custom D7 table (DataManager) when:

• Composite indexes are needed (HL supports only indexes on individual fields via UF_*)
• Foreign keys and cascade operations are needed
• The table schema changes frequently and requires migrations

In these cases, it is better to create a class inheriting \Bitrix\Main\ORM\Data\DataManager and manage the table through it.

How to choose between HL-block and custom table?

Conclusion: use HL-block if composite indexes and relationships are not required. Otherwise — DataManager.

HL-block field types and their features

HL-blocks use the user field system (UF_*). Available types:

• string / string_formatted — VARCHAR. For names, titles.
• integer — INT. For numeric identifiers, sorting.
• double — DECIMAL/FLOAT. For prices, coefficients.
• boolean — TINYINT(1). Activity flags.
• file — stores file ID from b_file. For images in reference books.
• enumeration — binds to b_user_field_enum. For fixed statuses within an HL record.
• datetime / date — DATETIME / DATE.
• iblock_element / iblock_section — binds to an infoblock element or section. Use with caution: creates an implicit link between HL and infoblock.

The problem with the iblock_element field type in an HL-block: when an infoblock element is deleted, the HL record is not automatically updated — you need an event handler for OnAfterIBlockElementDelete.

How to properly index HL tables?

By default, an HL-block creates a table only with a PRIMARY KEY on the ID field. All other fields are without indexes. If the HL-block is used as a reference for the catalog facet index, additional indexes are usually not needed — the facet works with b_iblock_{ID}_index, not directly with the HL table.

But if the HL-block is used to store operational data (action history, order log, bonus program records) — indexes on filter fields are critical. They are added manually via SQL migration:

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

Bitrix does not provide a UI for managing HL-table indexes — only direct SQL or a migration script.

Case from our practice: HL-block for a B2B catalog

An electronics distributor. The catalog has 2,200 unique product characteristics (technical parameters). Initially — infoblock properties of type "String", b_iblock_element_property contained 8 million rows.

Solution: move reference characteristics to HL-blocks by domain:

• hl_tech_connectivity — connection interfaces (USB-C, HDMI, etc.)
• hl_tech_resolution — screen and matrix resolutions
• hl_tech_standard — standards (Wi-Fi 6, Bluetooth 5.2, etc.)

Each HL-block: fields UF_NAME (VARCHAR 255), UF_XML_ID (VARCHAR 50, unique), UF_ACTIVE (boolean), UF_SORT (integer). Indexes on UF_XML_ID — added manually for fast search during 1C import.

Result: b_iblock_element_property shrank from 8 million to 1.2 million rows (only numeric properties remained). The facet index rebuilds in 8 minutes instead of 45.

Managing HL-block data via D7

Working with an HL-block in code — through \Bitrix\Highloadblock\HighloadBlockTable and a dynamically created class:

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

This is a standard pattern — it is important to establish it in the project code style so that HL-block accesses do not spread across templates in the form of SQL queries.

What is included in the HL-block design work

Estimated time for a full cycle of 10-15 HL-blocks — from 2 to 5 working days. The cost is calculated individually depending on the complexity of the subject area and the need for migration. To get a consultation and evaluation of your project — just write to us. We are a certified 1C-Bitrix partner with 10+ years of experience and 50+ completed performance optimization projects. We guarantee transparency at every stage.

Useful resources:

• More about HL-blocks: 1C-Bitrix documentation
• ORM standards: Bitrix D7 ORM