Вот что Битрикс ответил после недельной переписки: - проблема не распространенная и вообще не типовой случай...
"Обычно такая задача решается разделением на инфоблоки (по разделам или по типам). Каких-то штатных средств нет для ускорения продукта при таком количестве свойств."
"Прочитайте статью наших специалистов по производительности:
Особенное внимание уделите пункту "Неправильная структурная организация инфоблоков". Я думаю, что часть вопросов пропадёт.
Если у вас есть предложения по развитию продукта, пишите на наш сайт идей: Если доработка понравится другим пользователям и разработчикам, то она будет включена в план на реализацию."
В самой статье ничего нового, а по этой теме привожу отрывок -
"Неправильная структурная организация инфоблоков
Пожалуй, это наиболее распространенная проблема — встречается в 90% проектах (а Битрикс сказал, что не типичная проблема). Когда все товары «складывают» в один инфоблок. У такого инфоблока накапливается большое количество свойств всех товаров, это чревато большими выборками и медленным импортом. Рассмотрим на примере абстрактного спортивного магазина, у которого в ассортименте одежда, лыжи, велосипеды (и у каждого вида товаров свои свойства). Свойства товаров попадают в один инфоблок, велосипеды получают свойства лыж и одежды (и, соответственно, наоборот — данные виды товаров получают свойства велосипедов). Представьте, сколько «избыточных» свойств накапливается, если категорий товаров у магазина много.
При этом однажды мы столкнулись с противоположной проблемой: у проекта была правильная структура инфоблоков, но также было много агрегирующих выборок (новинки, акции, хиты). Получилось, что вместо одного запроса в «долгий» инфоблок для генерации выборки отправлялось по запросу в 50+ быстрых инфоблоков и затем ещё происходило их совмещение в коде. Из-за этого компонент в целом стал работать медленнее. Так что если проекту необходима такая функциональность, то надо разрабатывать запасной план — создавать отдельную таблицу в базе данных (делать «денормализацию» структуры инфоблоков), либо через внешнюю агрегацию, либо что-то ещё."
Buck написал: О_о! Не ожидал такой реакции так быстро! Да, курим долго проект потому что меняли партнёра-разработчика, сейчас сам себя уже считаю продвинутым пользоватлем битрикс (сам я разработчик 1С). Пытаюсь во всём разобраться сам, кое в чём уже успел разобраться! Да, наша выгрузка 30k - это только наличие, всего номенклатура более 200k и это после перехода на новую свеженькую 1С-базу, скоро её станет ещё больше, в справочнике значений свойств сейчас хранится уже 6 млн. записей (из них непосредственно на сайт выгружаются менее 500k) и ежедневно добавляется по паре сотен... Буду курить ваши замечания и предложения вместе со своими разработчиками на Битриксе. Спасибо! Дай бог денег всё это запустить... )
П.С. И да, картинок очень много, примерно в 10 раз больше номенклатуры. Подозреваю что огромное кол-во времени тратится на её ресайзинг, наверно на этом тоже можно много сэкономить, если делать его заблоговременно, а саму фичу по ресайзингу в Битриксе вообще не использовать...
Ну да, ресайз картинок заранее на бэкенде - отличное решение. Тоже им занимаюсь, но еще в купе с использованием CDN для хранения всякой статики и бэкапов.
Ребята, я обещал вам написать как это решать, но нет времени. Необходимо переписать несколько файлов. Сейчас работает при свойствах >4500 в одном инфоблоке + 10 параллельных обменов инкрементальных (они конечно иногда выстреливают в дедлоки, но задачу они свою решают).
Повторюсь, магазин >60к товаров
Проблема в нескольких местах. Смотря что вы используете.
1. построение arResult для секции в плане выбора и выброса всех свойств (они не нужны) 2. обновление и выбор свойств из базы 3. механизм скидок по правилам, которые как текст записаны в базу ну и т.д.
будет время напишу.
да, и про админ панель с модификацией свойств забудьте битрикс делается универсальным для не программистов, поэтому отход в сторону админ чтобы там все, конечно ущербный если объемы большие приходится прибегать к базе руками
Ну это конечно трэш, угар и содомия. Вместо того, что бы разбить каталог на раздельные инфоблоки Вы решили переписать двиг. Вам понадобиться свои компоненты каталога, своя админка и свой обмен. Это жесть. И самое простое это обмен. При таком обьеме правок возможно Вам не следовало покупать битрикс. Если прям Вам так надо, что бы все было в одном инфоблоке, то просто вынесите свойства в свои таблицы. 60к товаров это небольшое количество, тут у Вас не будет проблем. Вы слишком усложняете элементарные вещи.
Dios написал: Вы пробывали хранить часть свойств(не фильтруемых) одной строкой как текстовое описание ? У меня экономия на этом до 10к(95%) свойств.
Тут свои геморрои. В зависимости от типа хранения возникает некоторые проблемы. Например, если данные хранятся как сериализованный массив, а потом возникает задача изменить какую-то характеристику - руками обычного менеджера это уже не сделать. Если хранить как кусок html-кода в виде таблицы или еще как-то подобно, то получается избыточное хранение html-тегов и жесткая привязка к существующему дизайну. Ну и характеристики зачастую для того и существуют, чтобы их фильтровать, если они числовые или списочные. Иначе просто можно было бы вставлять табличку характеристик в описание товара и не знать никаких проблем.
никто не предлагает переписывал основы предлагается исправить бестолковый полный выбор ненужных свойств и изменить назначение свойств и их выбор. далее по вкусу. и нет необходимости делать свои компоненты, за исключением каталог.секции кстати делать свои компоненты это вообще хороший тон,
не драматизируйте
а вот плодить бесконечное неконтролируемое количество инфоблоков это глупость. вы же не знаете заранее какие свойства появятся у вновь прибывших товарах в новых направлениях. ну создайте 100 или 200 инфоблоков и тратте время только на контроль куда какое свойство должно попасть и отображаться. если вам так нам нравится. нам нет.
100-200 инфоблоков тоже перебор, я скорей говорил о 10, ну максимум 20. 100+ инфоблоков тоже ошибка.
Оптимизация выборки в catalog.section это мелочь, еще нужно страницу товар переделать, плюс фильтра, плюс сравнение. Плюс админка, редактирование товара на 8к свойств тоже надо переделывать, плюс редактирование в таблице. Производительность публички хорошо, но об админке то не надо забывать. Плюс обмен с 1с. Плюс возможные экспорты во внешнии базы, маркет и мерчант например.
Делать свои компоненты это точно не хороший тон, тупо делать ради того что бы было "свое" бессмысленно. После здачи проекта код не обновляеться и менее надежен чем типовой обновляймый и проверенный тестерами команды битрикса. Максимум что вы можете получить так это только придельную оптимизацию для узко-специализированного решения. На типовых компонентах для разделов новости/статьи/каталог/контакты/справка/тд заметного прироста не будет. А код может сдохнуть после обновления ядра или хостинга. Свой компонент и/или свой модуль нужен на не типовых задачах, типа генерации медиа файлов (jpg, pdf, mp3, тд), выборки не типовых сущностей, формы и виджеты, различные конструкторы/интерактивы и тд. А новости и каталог это самое типовое решение, практически все можно дописать в шаблоне.
Да, битрикс не расчитан на такие цифры в таких сценариях. Да, это можно исправить поправив ядро. Можете предложить свои правки разрабам. Но уверен, что они сами прекрасно все знают. Пока что имеем, то что имеем, и 8к свойств в одном инфоблоке это не решение. Когда то может доработают ядро и можно будет смело столько забивать, но не сейчас.
Модерацию перечня свойств контенщик полюбому делает как минимум для умного фильтра. Для сценария с одним инфоблоком, я завожу белый список свойств, с интерфейсом в админке. В нем указываються перечень свойств для фильтрации и редактирования, только они и импортируються в инфоблок. все остальное у меня храниться в отдельной таблице и подгружаеться в шаблоне. За одно тут же расширенный функционал по валидации/нормализации/обьединения/подмены/парсинга/тд значений свойств. Если нужно редактируемое свойство, то оно вноситься контенщиком в белый список и следующей синхронизацией автоматом создаеться и заполняеться с сответсвующих баз(1с, яндекс маркет, прайсы, апи дестрибьютеров).
Ну не нужны 8к свойств в инфоблоке. Минимум 90% таких свойств, просто справка и дубликаты с путаницей написания, и их можно хранить более дешевыми методами.
Так выходит минимальное количество правок, максимальная производительность публички и админки, масштабируемость базы, целое ядро.
