tl;dr ->« Может ли Magento работать с продуктами 1M », ответ - да , но с некоторыми соображениями. В таком масштабе можно предположить, что у вас есть объем, чтобы поддержать достойные инвестиции в инфраструктуру и персонал, чтобы составить каталог этой пропорции.
Первый:
Образцы данных Magento CE, как вы могли видеть, содержат лишь несколько продуктов из разных категорий. Пример данных EE имеет больше, и они разделены по типу магазина.
Вы можете скачать образец данных CE здесь . Вам придется загрузить пример данных EE из своей учетной записи MagentoCommerce.com, если у вас есть EE.
Однако вы обнаружите, что это не сотни или даже тысячи продуктов. Я бы посоветовал вам импортировать продукты в базу данных - хорошее упражнение, чтобы понять, как работает этот процесс. Это можно сделать через поток данных Magento или через импорт API - информация о том, как сделать это в масштабе, легко доступна в Интернете.
Предостережение: поток данных общеизвестно медленен, поэтому для импорта каталога того размера, который вы запрашиваете, может потребоваться значительное время. Насколько мне известно, в природе не существует образцового каталога с сотнями тысяч или миллионами продуктов.
Изменить 1/7/14:
@ryaan_anthony в Twitter выпустил хранимую процедуру MySQL, которая будет генерировать сотни тысяч продуктов https://gist.github.com/ryaan-anthony/6290973
Некоторое чтение по Magento API и Dataflow:
http://www.magentocommerce.com/knowledge-base/entry/introduction-to-magento-dataflow
http://www.magentocommerce.com/api/soap/catalog/catalog.html
Во-вторых:
Продукт, перезапись URL и индексирование инвентаризации являются основными проблемами при запуске каталога такого размера . Поиск по каталогу также может быть довольно медленным, но может быть смягчен, если вы используете Apache Solr (интеграция обеспечивается EE). Для Solr есть плагины CE - у Sonassi есть один, другие можно найти через Google.
Я управлял каталогами в диапазоне 700 КБ, который все еще намного меньше, чем 1 МБ, и индексация может занять часы за часами . Это было решено в Enterprise 1.13 . Я настоятельно рекомендую вам внимательно взглянуть на Enterprise Edition в этом масштабе. Это возможно с CE? Абсолютно; но улучшения индексации в EE 1.13 специально адаптированы к подобной ситуации.
В третьих:
Мульти-магазин является родным для Magento; Вы можете настроить различные категории верхнего уровня и веб-сайтов. Всем им не обязательно иметь один и тот же каталог - вы можете выбрать, какие продукты обмениваться между сайтами, или решить, чтобы ваш каталог был изолированным. Больше информации здесь:
http://www.magentocommerce.com/knowledge-base/entry/overview-how-multiple-websites-stores-work
Чем больше магазинов, просмотров магазинов у вас есть в Magento, тем больше записей индекса и тем больше ваш плоский каталог может раздуться до такой степени, что плоский каталог может фактически снизить производительность. Опять же, у Sonassi есть масса информации об этом здесь, на Magento.SE и на их сайте . Вы захотите поискать ответы на некоторые из вопросов Sonassi на Magento.SE для обработки / масштабирования Magento, когда вы попадете в сферу управления продуктами.
У каждого человека своя установка - вам нужно постоянно тестировать, дорабатывать, внедрять твики, чтобы найти, какие настройки лучше всего подходят для вашего каталога, в вашей ситуации.
Используйте ApiImport для импорта такого большого количества продуктов. Он основан на ImportExport и очень быстрый ... Я управлял до 500 тыс. (Индексированных) простых продуктов в час на виртуальной машине.
Просто запустите тесты / benchmark_import_api.php. Отредактируйте этот файл, чтобы удалить ненужные типы объектов (и подтипы). Вы также можете установить для USE_API значение false для более быстрых результатов.
источник
В прошлом мы использовали http://www.icecat.biz/en/ для извлечения каналов продукта для загрузки в данные образца. Также есть несколько расширений Magento, но они никогда не работали для нас, поэтому мы приступили к написанию большинства наших скриптов импорта.
источник
чтобы получить миллион + продукт в magento. написать простой PHP-скрипт, который генерирует поддерживаемый Magmi CSV-файл импорта товаров с различными типами товаров. Затем используйте Магми, чтобы импортировать их
http://sourceforge.net/apps/mediawiki/magmi/index.php?title=Magmi_Wiki
источник
Не совсем полный ответ, так как кажется, что другие уже ответили на большинство ваших вопросов, просто добавим несколько вещей:
1) У меня была такая тема: почти один миллион случайных продуктов Magento в десяти CSV. Вы также можете попробовать http://beta.generatedata.com/ .
2) Как уже упоминал Филвинкл: индексирование, поток данных и поиск - это самое большое препятствие, которое необходимо преодолеть при таком большом наборе данных. EE1.13 лучше справляется с обработкой таких больших данных (триггеры MySQL, учитывая состояние всех продуктов / категорий и т. Д.), Но имейте в виду, что на данный момент это все еще первоначальный выпуск (x.0.0), я склонен подождать несколько релизы, позволяющие другим взять на себя бремя поиска ошибок, прежде чем рассматривать его для производственной среды. Инфраструктура и оптимизация являются ключевыми. Дальнейшее обновление также необходимо учитывать, так как оно
ALTER TABLEне объединяется во время обновлений и может занять часы / дни для выполнения обновления БД:Некоторое дальнейшее чтение по теме индексации в большой базе данных:
3) Самый простой способ обмена данными между двумя магазинами Magento - через запрос REST / SOAP к API Magento других компаний. Альтернативой может быть просто выгрузить каталог из одной компании и позволить другой подобрать и проанализировать его, это может быть намного быстрее, чем пройти через API с более чем 1 миллионом продуктов.
источник
Мы только что работали над проектом с 1,2 млн. Продуктов (без атрибутов и особенно с одним представлением магазина), используя magento 1.7.x, и вот некоторые из наших опытов:
На самом деле импорт товаров достаточно хорош, я думаю, что наш первоначальный импорт занял примерно 1,5 часа.
При выполнении переиндексации наш диск сильно пострадает, решение заключалось в том, чтобы получить хорошее количество оперативной памяти (32 ГБ оперативной памяти, Amazon, ssd). Оптимизируйте настройки innodb, в которых мы выделяем объем памяти пула innodb немного больше размера базы данных, и особенно меняем буфер временной таблицы с 16 МБ по умолчанию до 128 МБ, это действительно то, что спасло наш процесс переиндексации.
Кэширование, использующее только кэш APC для быстрого кеширования, файлы для медленного кеширования, отключение ненужных журналов и модулей вместе с плоской таблицей и пару других оптимизаций, заставляет сервер предоставлять html страниц продукта (не всю страницу) за 200 мс. В нашем списке задач есть кеш лака.
Мы боремся и убиваем множество тупиковых ситуаций (некоторые в админке до сих пор остаются), возможно, более новая версия Magento не даст этих проблем по форумам.
Я скажу, что на самом деле есть проблемы с 1,2-метровыми продуктами, я бы не рекомендовал делать это без наличия надлежащей команды и ресурсов, однако, если у вас есть время, вы можете заставить его работать.
Я не знаю, какая другая платформа будет работать лучше.
источник
Всегда хорошо, да, Magento CE & EE может (из опыта, а не теории с использованием предоставленных наборов данных), хотя, очевидно, EE лучше для индексации. С Magmi все в порядке, но когда вы начнете переиндексировать начальную загрузку, у вас возникнут серьезные проблемы. Кроме того, у вас есть обслуживание, при котором, если 3% продуктов меняются ежедневно, вам необходимо обновить 30 000 продуктов с автоматическим индексом, вы не сможете выполнять ежедневное повторное индексирование. Все это сводится к двум вещам: кластерному хостингу и включению дельта-поддержки поставщиков, которые являются доменами корпоративных компаний.
Люди, кажется, думают, что работа заканчивается, когда продукты загружены, однако именно тогда начинается тяжелая работа. Если у вас слишком много магазинов, ценовые уровни, то ваш хостинг должен удвоиться, поэтому 95% не имеют шансов реализовать его, и 99% не имеют возможности его поддерживать. Миллионы продуктов равны средним и крупным предприятиям - если ваши консультанты не имеют такого опыта, ожидайте, что инфраструктура рухнет в среднесрочной и долгосрочной перспективе.
источник
Magmi отлично подходит для импорта большого количества продуктов. http://sourceforge.net/apps/mediawiki/magmi/index.php?title=Magmi_Wiki
В настоящее время мы работаем над разработкой для клиента, у которого 2,2 млн. SKU, первоначальный импорт был выполнен с использованием Magmi.
источник