250000 Сгруппированных товаров в Magento

Я начал работать над новым интернет-магазином Magento, в котором около 250 000 различных товаров. Каждый товар может иметь разное состояние (новый, б/у, поврежденный и т. д., у каждого своя цена.). У Magento, похоже, нет способа реализовать это на данный момент. Из этих 250 000 товаров около 150 000 различных условий в наличии и еще 150 000 условий, которых нет в наличии, но есть цена (которую можно внести в список желаний).

Некоторые цифры: 1500 категорий, выпадающие атрибуты (страна) с > 300 вариантами, целочисленные атрибуты (год). Начиная с двух веб-сайтов по 6 языков каждый.

Я придумал два решения для решения этой проблемы:

Сгруппированная / простая структура продукта

Мы создаем сгруппированный продукт, который является контейнерным продуктом, каждое условие будет другим простым продуктом. Мы свяжем эти продукты со сгруппированным продуктом.

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

Новый тип продукта

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

Преимущество такого решения в том, что продуктов в системе будет примерно в 2-2,5 раза меньше.

Другие

Есть ли другие варианты решения этого? Может быть есть модуль, который все это делает?

В заключение: конечно, я предпочитаю первое решение, но справится ли с ним Magento? У кого-нибудь есть опыт работы с таким большим количеством сгруппированных продуктов? В системе будет около 550 000 продуктов (сгруппированных + простых). Как это повлияет на производительность? Что произойдет, когда сайт вырастет и у нас будет в два раза больше товаров?


person Paul Hachmang    schedule 04.12.2012    source источник
comment
Вы столкнетесь с узкими местами производительности с таким количеством продуктов и таким количеством отношений. Конкретику предсказать невозможно. Не продолжайте без таланта Magento, который поможет вам масштабировать это. Вы вступаете на территорию, где для этого может быть целесообразно написать специальное программное обеспечение с нуля. (Кроме того, похоже, что вы используете сгруппированные продукты в качестве настраиваемых продуктов — почему бы просто не использовать настраиваемые продукты?)   -  person Alan Storm    schedule 04.12.2012
comment
Я создал небольшой тест, чтобы увидеть, может ли Magento даже обрабатывать 250000 сгруппированных продуктов, и он, похоже, работает нормально (на моем локальном компьютере: 3 секунды без кэширования, 0,5 секунды при попадании в кеш запросов). Кажется, узким местом производительности в Magento является получение общего количества коллекции для каждой страницы. Я не тестировал под нагрузкой, но при правильном кешировании страницы каталога не сильно ударят по базе данных.   -  person Paul Hachmang    schedule 05.12.2012
comment
Не знаю о влиянии отношений. Я не настолько хороший разработчик, чтобы написать такое решение для электронной коммерции с нуля. Бизнес растет довольно существенно, поэтому спрос на масштабируемую платформу растет с каждым месяцем.   -  person Paul Hachmang    schedule 05.12.2012
comment
— мы переходим от программирования к бизнесу, но вы увидите много мелких неудач при масштабировании с таким количеством продуктов, особенно если вы будете поддерживать отношения. Нет рынка готового программного обеспечения, которое решает вашу конкретную программу. Это специальное программное обеспечение, независимо от того, разрабатываете ли вы его самостоятельно или с партнером.   -  person Alan Storm    schedule 05.12.2012
comment
Вы можете использовать newrelic.com, чтобы увидеть, где у вас есть проблемы с загрузкой или около того, и соответствующим образом масштабировать его.   -  person Mike    schedule 07.08.2013


Ответы (1)


Не зная более подробной информации, я бы склонялся к использованию нового типа продукта или просто добавлению функции независимо от типов продуктов, если вы используете настраиваемые продукты (я определенно не стал бы пытаться дублировать тип настраиваемого продукта). Я бы отключил управление запасами и использовал несколько дополнительных таблиц, в которых хранится запас отдельных предметов с условиями для каждого предмета, и таким образом поддерживается отдельный запас. Используйте события и переопределения для управления состоянием запасов CatalogInventory по мере необходимости. Постоянное создание новых продуктов, которые в значительной степени являются дубликатами, кажется проблемой, которой стоит избегать, если это долгосрочное предприятие, которое необходимо масштабировать.

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

person ColinM    schedule 04.12.2012
comment
Вы можете использовать Magmi для массовой загрузки, однако это работает намного быстрее, чем поток данных. Однако у вас должен быть очень хороший CSV-файл для импорта. - person Mike; 07.08.2013