Цитата |
---|
Buck написал: Очень странно что такой дорогой продукт как Битрикс не может справится из коробки с конфигурацией каталога даже для простенького интернет магазина с компьютерной комплектухой и бытовой... Мы уже почти год бъёмся над этой проблемой (много свойств и дикие тормоза) а воз и ныне там. до 30 000 товаров, всего около 4800 свойств из них в умном фильтре учавствует около 1600 (В разных каталогах от 2-3 до 6-8 свойств в умном фильтре). Карточку товара невозможно толком редактировать в админке хоть привязывай ты свойства к каталогам, хоть нет... на это давно забили - всё делаем в 1С. Выгрузка проходит очень долго, всё на выделенном сервере Ксеон v4 около 3Ггц, 32RAM SSD + Raid10 на SATA Raptor 10k, 30k товаров при полной выгрузке выгружаются почти 12 часов! При этом в каталог на диске всё выгружается минут за 40! Между 1С и Битрикс - 80-100Мбит линк! Единственное чего не пробовали, так это на каждый раздел делать отдельный инфоблок (Их у меня в верхнем уровне 14ть). Но тут наверное надо многое переделывать - и верхнее меню и корзину и агрегаторы товаров (мы используем шаблон BX-Ready) и т.д... Пилим уже год а в продакшн я такое пускать боюсь((( - мы конечники, не разработчики!
Очень нехватает толкового объяснения как вообще подходить к задачам 30k товаров, 5-10k свойств, полное еженедельное обновление и ежеждневное только изминения + каждые 2-3 часа выгружаются только наличие и цены!
И вопрос ещё возникает: чем больше делаешь узлов обмена в модуле обмена Битрикса в 1С - тем больше затрачивается время на регистрацию изминений для этих узлов обмена! Узлов обмена сейчас на один инфоблок/каталог - 5ть (с документами, с автообменом и прочее), а сколько их понадобиться для 14ти инфоблоков? У меня каждый день приходит 200-400 новых товаров, у меня только на создание номенклатуры с такими тормозами будет уходить два часа! |
Потому что битрикс изначально не был предназначен для таких тяжелых вещей, они всегда хотели делать его максимально универсальным, одна система и для сайта уровня Эльдорадо и для личного бложика в три поста. Возможно, если бы он был изначально заточен под электронную коммерцию как Magento или другие подобные системы, то в нем было бы решение таких задач. И очень жаль, что не появилось ответвления битрикса как это произошло с корпоративным порталом. Узкое специализированное решение под электронную коммерцию, глубоко переработанное и переосмысленное.
Очень странно, что вы год бьетесь над этой задачей и решить не можете. Может не в том направлении? Сразу скажу, что увеличение производительности железа слабо решает архитектурные промахи. Если у вас таблица с характеристиками в 5 миллионов строк, то она будет одинаково медленно читаться хоть на среднем хоть на самом топовом железе с 28 ядрами на процессор. Можно запиливать какой угодно кеш в MySQL, экспериментировать с настройками InnoDB, да хоть всё в оперативной памяти держать - оно всё равно будет медленное. Может быть горизонтальный шардинг помог бы, но это уже за пределами архитектуры битрикса, слишком сложный костыль.
Вот мой кейс. Вводная информация. Был (и есть, но уже без меня) проект, интернет-магазин бытовой техники. Номенклатура очень широкая - 1500 категорий, 60К позиций, в спокойные времена было 30-40К позиций в наличии, а так вообще в базе ~200K товаров. При мне было около 20 поставщиков, целый зоопарк интеграций, с основными обновление цен и остатков выполнялось каждый час, с остальными раз в сутки. И всё это добро работало на трех средних серверах. Один под БД, второй под фротенд (nginx + php-fpm), третий под бэкенд (фоновые задачи, импорт, экспорт и т.д. и тесты. Общие затраты на инфраструктуру в hetzner были около 300 евро/мес.
Номенклатура - в основном техника. Ну а раз техника, значит у нее есть характеристики, по которым было бы неплохо дать возможность пользователям фильтровать результаты поиска. Я с такой задачей уже не раз сталкивался, писал модули и прочие костыли, поэтому сразу предвидел, что при таком количестве товаров и характеристик всё это очень быстро нагнется. Но хотели побыстрее запустить, поэтому сначала использовали стандартное решение. При уже 300 свойствах инфоблока всё безбожно начало умирать, начало расти время генерации страниц, время обсчета фильтра, поэтому взяли паузу на заполнение характеристик, чтобы окончательно не положить всё.
Писался отдельный модуль для хранения типов товаров и характеристик и отдельные компоненты для работы с этим модулем. Основной инфоблок каталога товаров содержал исключительно общие характеристики: бренд, партномер, фотки, ссылки, видео и т.д. И было кастомное свойство - тип товара. По сути это набор связанных характеристик, они подгружались через AJAX в форму редактирования товара. Только нужные, связанные с этим типом товара. И вот связанные характеристики уже хранились в отдельной таблице в БД. Я пошел дальше и развивал этот модуль, в итоге у меня были следующие сущности:
- Тип товара (группа характеристик) - просто список названий
- Группы характеристик - для группировки характеристик. Например, если это характеристики ноутбука, то их можно было разделить на группы: процессор, память, экран и т.д. Визуально как на яндекс.маркете.
- Характеристика - запись имела тип данных (число, строка, список, да/нет), название, сортировку, связанную единицу измерений, допустимые значения, разрешить фильтрацию по ней, подсказка и т.д.. При этом одна и та же характеристика могла использоваться в разных типах товаров. Например, "Диагональ" могла относиться к смартфонам, мониторам, телевизорам.
- Единицы измерения - просто шаблон вида "# кг", использовались исключительно для вывода характеристик. Одну единицу измерений можно использовать для нескольких характеристик.
- Значения характеристик - одна таблица, очень похожая на b_iblock_element_property , в ней хранился ID товара, ID характеристики, значение характеристики
Сами значения для характеристик товаров забирались с яндекс.маркета - это отдельный эпичный квест. В итоге примерно у половины товаров характеристики были заполнены автоматически, для второй половины требовалось полуручное заполнение - это второй эпичный квест. Для каталога были созданы кастомные компоненты для вывода товаров и фильтра, шаблон карточки товаров был доработан, чтобы выводить характеристики из своего модуля.
И в общем-то, это всё работало. Фильтр фильтровал всё относительно быстро (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-запрос с новой информацией о конкретном товаре, он обновлялся.