Цитата | ||
---|---|---|
Алексей Огурцов написал:
Категории стале редактироваться, когда поставил параметр max_input_vars - 25000. Но производительность все равно ужасная. Куда еще копать? |
14.12.2017 18:25:07
|
|||||
|
|
20.12.2017 10:46:10
Воспользовался советом Битрикс - "При создании информационных блоков рекомендуется хранить свойства инфоблока в отдельной таблице, причем все значения свойств одного элемента хранятся в одной строке. Эта технология называется Инфоблоки 2.0 и позволяет существенно ускорить работу системы, а также снять ряд ограничений в предыдущей версии инфоблоков."
При переходе на хранение свойств инфоблока в отдельной таблице, возникли проблемы: 1. Практически все значения свойств пропали 2. Стало не возможно делать импорт через xml - выдается ошибка MySQL Query Error: UPD ATE b_iblock_element_prop_s10 SE T PROPERTY_795 = 'бытовой' WHERE IBLOCK_ELEMENT_ID=1865 [[1054] Unknown column 'PROPERTY_795' in 'field list'] |
|
|
|
20.12.2017 12:08:37
В плане количества свойств в инфоблоках 2.0 все еще хуже. Там под каждое свойство выделяеться отдельная колонка таблицы и следственно количество колонок ограничено самим mysql
К сожелению битрикс не может посчитать реальное ограничение на количество колонок(лимит количества свойств) для инфоблоков 2.0, и ошибка косвенно говорит что миграция свойств была не успешной. Думаю ваши 8000 свойств не как не влезят У вас вопрос не производительности, а архитектуры хранения данных в целом. Хранение 8000 свойств в одном инфоблоке любой версии инфоблока это ошибка. |
|
|
|
20.12.2017 15:24:02
Второй вариант - один инфоблок на одну категорию - 400 штук. Только потом это все собрать в кучу будет непростой задачей - фильтры, акции, новинки, вывод в каталоге, поиск, бренды и т.д. |
|||
|
|
21.12.2017 14:51:15
Очень странно, что вы год бьетесь над этой задачей и решить не можете. Может не в том направлении? Сразу скажу, что увеличение производительности железа слабо решает архитектурные промахи. Если у вас таблица с характеристиками в 5 миллионов строк, то она будет одинаково медленно читаться хоть на среднем хоть на самом топовом железе с 28 ядрами на процессор. Можно запиливать какой угодно кеш в MySQL, экспериментировать с настройками InnoDB, да хоть всё в оперативной памяти держать - оно всё равно будет медленное. Может быть горизонтальный шардинг помог бы, но это уже за пределами архитектуры битрикса, слишком сложный костыль. Вот мой кейс. Вводная информация. Был (и есть, но уже без меня) проект, интернет-магазин бытовой техники. Номенклатура очень широкая - 1500 категорий, 60К позиций, в спокойные времена было 30-40К позиций в наличии, а так вообще в базе ~200K товаров. При мне было около 20 поставщиков, целый зоопарк интеграций, с основными обновление цен и остатков выполнялось каждый час, с остальными раз в сутки. И всё это добро работало на трех средних серверах. Один под БД, второй под фротенд (nginx + php-fpm), третий под бэкенд (фоновые задачи, импорт, экспорт и т.д. и тесты. Общие затраты на инфраструктуру в hetzner были около 300 евро/мес. Номенклатура - в основном техника. Ну а раз техника, значит у нее есть характеристики, по которым было бы неплохо дать возможность пользователям фильтровать результаты поиска. Я с такой задачей уже не раз сталкивался, писал модули и прочие костыли, поэтому сразу предвидел, что при таком количестве товаров и характеристик всё это очень быстро нагнется. Но хотели побыстрее запустить, поэтому сначала использовали стандартное решение. При уже 300 свойствах инфоблока всё безбожно начало умирать, начало расти время генерации страниц, время обсчета фильтра, поэтому взяли паузу на заполнение характеристик, чтобы окончательно не положить всё. Писался отдельный модуль для хранения типов товаров и характеристик и отдельные компоненты для работы с этим модулем. Основной инфоблок каталога товаров содержал исключительно общие характеристики: бренд, партномер, фотки, ссылки, видео и т.д. И было кастомное свойство - тип товара. По сути это набор связанных характеристик, они подгружались через AJAX в форму редактирования товара. Только нужные, связанные с этим типом товара. И вот связанные характеристики уже хранились в отдельной таблице в БД. Я пошел дальше и развивал этот модуль, в итоге у меня были следующие сущности:
И в общем-то, это всё работало. Фильтр фильтровал всё относительно быстро (0.1-0.3 с на пересчет допустимых значений и выборку), товары выводились как обычно, в карточке товаров характеристики показывались красивой табличкой с группировкой. И самое главное - товары можно было редактировать, БД не умирала. Из глобальных минусов - сложность разработки и поддержки. У меня ушло на это всё 1 месяц активной разработки и 1 месяц на допиливание. Плюс это нестандартное решение. Вы не можете застраховаться от программиста, который придет после вас и скажет "всё сделано неправильно, давайте делать с нуля". Сейчас, если бы я повторял реализацию этого модуля, то многое сделал бы по-другому. Например, для хранения и расчета характеристик больше подходит Redis, он очень быстро умеет считать пересечения и разницу множеств. Найти допустимые ID товаров на пересечение 20 характеристик в 30 тысячах товаров - тысячные доли секунды. Вообще, использование Redis позволяет меньше использовать кеш битрикса, быстрее обновлять данные, быстрее фильтровать любые объемы данных, добавить больше персонализации для покупателей и получить значительный прирост производительности. Например, в стандартной реализации битрикса практически нереально формировать свой порядок товаров в разделе для каждого посетителя чтобы это работало быстро, потому что данные всегда выбираются из БД. А мы сможем, потому что между БД и фронтендом у нас есть Redis, в котором уже всё заготовлено в нужном виде. Если покупатель недавно смотрел товары для ребенка 10 лет, то мы можем первыми в списках показывать товары для детей 10-11 лет, например. Или если покупатель зашел на сайт по поисковому запросу, содержащий определенный бренд, то мы можем "поднять" товары этого бренда выше, чтобы они стали виднее конкретно этому посетителю. Моментальное подсказывание товаров прямо в виде карточек товаров - запросто. Ладно, это уже другая тема. И обмен с 1С мы, кстати, делали тоже свой. Выгружали из 1С только артикулы, остатки и цены в виде CSV. 1С их формирует очень быстро, минута. Они всегда свежие приходили на FTP. А на сервере уже отдельный фоновый скрипт проверяет нужный csv-файл, обновляет по нему цены по всем позициям (из 1С было 10к позиций) в течение 10 секунд. Так что обновления каждый час были не проблемой. В планах была реализация вообще в режиме реально времени. При изменении данных в 1С отправлялся на сайт REST-запрос с новой информацией о конкретном товаре, он обновлялся. |
|||
|
|
21.12.2017 16:50:49
А во втором профиле я убираю галочку с "Выгружать номенклатуру", но ставлю галочку выгружать свойства? Я правильно понял? Или нужны доработки со стороны БУС? Аналогично с картинками как быть? Заранее благодарю за ваше внимание и совет! П.С. УТ 10.3 Модуль обмена 6.5 |
|||
|
|