Как хранить большое количество характеристики товара?

Вот что Битрикс ответил после недельной переписки:
- проблема не распространенная и вообще не типовой случай...

"Обычно такая задача решается разделением на инфоблоки (по разделам или по типам).
Каких-то штатных средств нет для ускорения продукта при таком количестве свойств."

"Прочитайте статью наших специалистов по производительности:
https://www.itsumma.ru/blog/problemy-proizvoditelnosti-saytov-na-1c-bitrix
Особенное внимание уделите пункту "Неправильная структурная организация инфоблоков".
Я думаю, что часть вопросов пропадёт.

Если у вас есть предложения по развитию продукта, пишите на наш сайт идей:  http://idea.1c-bitrix.ru/
Если доработка понравится другим пользователям и разработчикам, то она будет включена в план на реализацию."

В самой статье ничего нового, а по этой теме привожу отрывок -

"Неправильная структурная организация инфоблоков

Пожалуй, это наиболее распространенная проблема — встречается в 90% проектах (а Битрикс сказал, что не типичная проблема). Когда все товары «складывают» в один инфоблок. У такого инфоблока накапливается большое количество свойств всех товаров, это чревато большими выборками и медленным импортом. Рассмотрим на примере абстрактного спортивного магазина, у которого в ассортименте одежда, лыжи, велосипеды (и у каждого вида товаров свои свойства). Свойства товаров попадают в один инфоблок, велосипеды получают свойства лыж и одежды (и, соответственно, наоборот — данные виды товаров получают свойства велосипедов). Представьте, сколько «избыточных» свойств накапливается, если категорий товаров у магазина много.

При этом однажды мы столкнулись с противоположной проблемой: у проекта была правильная структура инфоблоков, но также было много агрегирующих выборок (новинки, акции, хиты). Получилось, что вместо одного запроса в «долгий» инфоблок для генерации выборки отправлялось по запросу в 50+ быстрых инфоблоков и затем ещё происходило их совмещение в коде. Из-за этого компонент в целом стал работать медленнее. Так что если проекту необходима такая функциональность, то надо разрабатывать запасной план — создавать отдельную таблицу в базе данных (делать «денормализацию» структуры инфоблоков), либо через внешнюю агрегацию, либо что-то ещё."

Подготовил ссылки на темы по данной проблеме, может кому то полезно будет:

1. Как хранить большое количество характеристики товара? - https://dev.1c-bitrix.ru/community/forums/forum6/topic69934/

2. Каталог тормозит от большого количества свойств - https://dev.1c-bitrix.ru/community/forums/forum6/topic97415/

3. Организация инфоблока с большим количеством элементов - https://dev.1c-bitrix.ru/support/forum/forum6/topic33363/

4. Значения свойств элементов инфоблоков - какой вариант самый оптимальный? - https://dev.1c-bitrix.ru/community/forums/forum6/topic32741/

5. Максимальное количество свойств инфоблоков ограничено? Не сохраняются настройки инфоблока. - https://dev.1c-bitrix.ru/community/forums/forum6/topic42755/

6. При создании свойства выдается ошибка - https://dev.1c-bitrix.ru/support/forum/forum6/topic58153/

7. Битрикс тормозит при большом количестве свойств - https://dev.1c-bitrix.ru/support/forum/forum6/topic102853/

8. Битроник: 2-е архитектуры торгового каталога на выбор! - https://dev.1c-bitrix.ru/community/webdev/user/3308/blog/5478/

Ну это конечно трэш, угар и содомия. Вместо того, что бы разбить каталог на раздельные инфоблоки Вы решили переписать двиг.
Вам понадобиться свои компоненты каталога, своя админка и свой обмен. Это жесть. И самое простое это обмен. При таком обьеме правок возможно Вам не следовало покупать битрикс. Если прям Вам так надо, что бы все было в одном инфоблоке, то просто вынесите свойства в свои таблицы. 60к товаров это небольшое количество, тут у Вас не будет проблем. Вы слишком усложняете элементарные вещи.

Тут свои геморрои. В зависимости от типа хранения возникает некоторые проблемы. Например, если данные хранятся как сериализованный массив, а потом возникает задача изменить какую-то характеристику - руками обычного менеджера это уже не сделать. Если хранить как кусок html-кода в виде таблицы или еще как-то подобно, то получается избыточное хранение html-тегов и жесткая привязка к существующему дизайну. Ну и характеристики зачастую для того и существуют, чтобы их фильтровать, если они числовые или списочные. Иначе просто можно было бы вставлять табличку характеристик в описание товара и не знать никаких проблем.

100-200 инфоблоков тоже перебор, я скорей говорил о 10, ну максимум 20. 100+ инфоблоков тоже ошибка.

Оптимизация выборки в catalog.section это мелочь, еще нужно страницу товар переделать, плюс фильтра, плюс сравнение. Плюс админка, редактирование товара на 8к свойств тоже надо переделывать, плюс редактирование в таблице. Производительность публички хорошо, но об админке то не надо забывать.
Плюс обмен с 1с. Плюс возможные экспорты во внешнии базы, маркет и мерчант например.

Делать свои компоненты это точно не хороший тон, тупо делать ради того что бы было "свое" бессмысленно. После здачи проекта код не обновляеться и менее надежен чем типовой обновляймый и проверенный тестерами команды битрикса. Максимум что вы можете получить так это только придельную оптимизацию для узко-специализированного решения. На типовых компонентах для разделов новости/статьи/каталог/контакты/справка/тд заметного прироста не будет. А код может сдохнуть после обновления ядра или хостинга.
Свой компонент и/или свой модуль нужен на не типовых задачах, типа генерации медиа файлов (jpg, pdf, mp3, тд), выборки не типовых сущностей, формы и виджеты, различные конструкторы/интерактивы и тд. А новости и каталог это самое типовое решение, практически все можно дописать в шаблоне.

Да, битрикс не расчитан на такие цифры в таких сценариях. Да, это можно исправить поправив ядро. Можете предложить свои правки разрабам. Но уверен, что они сами прекрасно все знают. Пока что имеем, то что имеем, и 8к свойств в одном инфоблоке это не решение. Когда то может доработают ядро и можно будет смело столько забивать, но не сейчас.

Модерацию перечня свойств контенщик полюбому делает как минимум для умного фильтра.
Для сценария с одним инфоблоком, я завожу белый список свойств, с интерфейсом в админке. В нем указываються перечень свойств для фильтрации и редактирования, только они и импортируються в инфоблок. все остальное у меня храниться в отдельной таблице и подгружаеться в шаблоне. За одно тут же расширенный функционал по валидации/нормализации/обьединения/подмены/парсинга/тд значений свойств. Если нужно редактируемое свойство, то оно вноситься контенщиком в белый список и следующей синхронизацией автоматом создаеться и заполняеться с сответсвующих баз(1с, яндекс маркет, прайсы, апи дестрибьютеров).

Ну не нужны 8к свойств в инфоблоке. Минимум 90% таких свойств, просто справка и дубликаты с путаницей написания, и их можно хранить более дешевыми методами.

Так выходит минимальное количество правок, максимальная производительность публички и админки, масштабируемость базы, целое ядро.

Дело не в нагрузке базы, таблицы для 100к товаров с 10к свойств это копейки. Разбивай по отдельным таблицам или нет, толком нечего не даст. Для MySQL это не те цифры.

Проблема чисто в админской оснаске и типовых компонентов вывода. Формы редактирования элемента или списка элементов. Редактирование настроек.

На таких цифрах должна быть ajax с отдельным редактирования каждого поля, а не как щяс в редактировании инфоблока вываливаться стандартная форма с 100к+ полей, ведь на каждое свойство десяток input. Это все равно что бы если свойств не было и мы редактировали бы абсолютно все товары каталога на одной единственной странице. Нужна оптимизация и переделка всех форм инфоблока. Плюс нужно оптимизировать выборки в компонентах, не выхватывать все 10к свойств на каждый товар, а только нужные. В АПИ скорее всего надо еще оптимизировать некоторые выборки, например в индексации поиском.

И тогда будет все летать на одном инфоблоке. База, а точнее её схема, к данной проблеме не имеет отношения. Можно и нужно схему/архитектуру улучшить, но это не связанная задача.

Привязка свойств к разделу есть и это нечего не дает и не теряет в скорости текущих таблиц. Лиш уменьшает выборки в определенных сценариях и некоторые формы.

---

Да, архитектура "кривая", но это в наше время, хоть проблема напрямую не в ней. Когда её задумывали и реализовали все летало и таких проблем не было. Новые реалии требуют новую архитектуру.

---

Отдельное замечание:
Добавление новых инфоблоков одного каталога не требует редактирования кода. А если требует то это бага от разраба. Не каких "мы подписываемся на вечную доработку" и не каких "пляски с бубном". Я даю гарантию два года на свои разработки/интеграции и мне не выгодно что бы постоянно дергали по таким пустякам.
Добавление разделов в выгрузку, ну это уж очень элементарно, хоть пару кнопок то клацнуть то можно же. Или вы как то не так настраиваете структуру разделов.

---

"Почему тогда 99% решений из маркетплейса", ну тут я боюсь обидеть других разработчиков, и схватить бан, Но почти все вопросы/проблемы такого типа один ответ: "Потому, что 99% решений в маркетплейса откровенный гов**код" и задуманны чисто зарабатывать с продажи, а не работы/поддержки. Продал и забыл.

Эти "решения" крайне плохо тестируються, установка может убить сайт, крайне узкоспециализированы, крайне конфликты между собой, крайне неудобны для дороботок, крайне криво обновляються, зарание крайне устарели, почти никакой документации, крайне ленивый суппорт. Любой тикет начинаеться с "Дайте админские доступы в битрикс, в хостинг, в билинг/банкинг или в связанные с решением сервисы", и без доступов вообще отказывают в поддержке. Может для кого-то это нормально, а я считаю это дно, от которого нужно со временем избавляться. Возможности зделать возврата нету. Штрафов или каких то санкций недобросовесным разрабам нету. Вот и сформировался такой бардак. Есть конечно же реально адекватные и афигенные модули(значительная часть сделана бескорыстными людьми бесплатно), но их по штучно и можно перечислить. Постепенно будет развиваться рынок, введут средства тестирования, более строгую политику. А пока так.

И снова же "решения" не связанны с проблемой данной ветки и они не должны их решать.

Плюс, по идее большенство "решений" должны спокойно работать с каталогом на множетсве инфоблоков. Просто корявые "мастер настройки" не продуман или демо данные такие. А так думаю готовые решения спокойно и быстро дорабатываються для конкретно данной функции.

Хайлоад почти не использую. Мне мягко говоря не нравиться интерфейс. Контенщику совсем плохо. Использую ORM и доработаную формы редактирования элемента через события. Описанный баг реально дикость. Что-то мне кажеться на конференции заявляли, что хайлоды задуманы на многомиллионные таблицы.
---
Привязка реализуеться через классы CIBlockSectionPropertyLink и \Bitrix\Iblock\SectionPropertyTable.
Задаеться в /bitrix/admin/cat_catalog_edit.php?lang=ru&IBLOCK_ID=#IBLOCK_ID# (подставить свой ID инфоблока) и в редактировании разделов поле "Свойства элементов". Влияет в основном на форму редактирования элемента, что бы показывались только свойства данного раздела. Но можно использовать в своих модулях/компонентах/шаблонах.
---
Редактирования списка разделов в выгрузке и их разбивка на инфоблоки делаеться в интерфейсе настройки обмена на стороне 1с, после установки модуля. Работает, как не странно, исправно. У менеджеров не было жалоб конкретно на данную фишку.
---
Решения с множеством инфоблоков я избегаю, по очевидным причинам. Но можно просто в шаблонах ссылок добавить символьный код инфоблока, и перед вызовом комплексного компонента каталога добавить несколько строк кода который будет брать символьный код и подставлять ID в параметры компонента. Хоть это заочно и навскидку, но думаю не должно быть других проблем. Я так не делаю, но должно работать.

А, по-моему, это влияет только на работу смарт-фильтра или я что-то делаю не так.
Оставил всего одно основное свойство для всего каталога здесь:/bitrix/admin/cat_catalog_edit.php?lang=ru&IBLOCK_ID=#IBLOCK_ID#
Для раздела добавил одно дополнительное свойство для отображения по адресу: /bitrix/admin/cat_section_edit.php?IBLOCK_ID=#IBLOCK_ID#&type=#IBLOCK_TYPE#&ID=#SECTION_ID#&lang=ru&from=iblock_section_admin&find_section_section=0
В итоге на странице редактирования элемента все равно вываливаются абсолютно все свойства инфоблока. (элемент привязан к единственной отредактированной секции). Ок, удалил почти все свойства из настроек формы редактирования элемента - да, они не показываются, но они все равно подгружаются, если посмотреть исходные код, в итоге страница редактирования элемента занимает около 5 мегабайт с отключенным отображением ненужных свойств как в настройках формы редактирования, так и в настройках раздела, к которому привязан товар. Что я делаю не так?

забавно что до сих пор не решена проблема с большим кол-вом свойств. накой черт тогда эт инфоблоки нужны?
храни в json поле - там и фильтровать можно и индексирование есть и гемора нет с распределением и поддержкой наборов свойств - можно хранить какие угодно наборы.

голосуйте за идею https://idea.1c-bitrix.ru/the-iblock-30-using-standart-sql-json/

или реализуйте совместимый api и продавайте в своем решении ecommerce - идея для стартапа. которая в теории должна принести кучу денег ее разработчикам.

Не то что бы я был против JSON Data Type, но у вас есть бечнмарки, сравнение, примеры существующих проектов?
Что дает в сравнении с текущей схемой таблиц инфоблоков?

Просто проблема ветки не в мускуле. Если вы напишите свой компонент каталога или свою админку на чистом мускуле, то все будет летать.
База на 100к строк товаров и 10м связанных строк других таблиц для мускула это вообще нечто, это школьный проект на планшете.

Еще раз повторюсь, проблема в медленных выборках в ядре с ненужными полями, утечках памяти в api и устаревшем UI фреймверка админки. Смена схемы базы не решит данную проблему. А так, если добавит скорости чтение/записи базы на том же обьеме данных, то я только за.

Ну может я ошибаюсь... В любом случае я нечего не решаю, и просто хочу повысить приоритет проблемы для разработчиков битрикса.

Клёвая штука, и в теории решает проблему отправки ненужных полей в форме редактирования элемента.
Но для торговых предложений оно так не работает.

Хочу сказать, что последние обновления Битрикс решили эту проблему. Теперь при вызове компонента bitrix:catalog количество читаемых свойств можно регулировать в свойстве LIST_PROPERTY_CODE