Является ли Magento подходящей платформой для продуктов 1M?

Используйте APIIMPORT для импорта такого большого количества продуктов. Он основан на ImportExport и очень быстр... Я управлял до 500 тыс. (индексированных) простых продуктов в час на виртуальной машине.

Просто беги tests/benchmark_import_api.php . Отредактируйте этот файл, чтобы удалить типы сущностей (и подтипы), которые вам не нужны. Вы также можете установить значение USE_API равным false для более быстрых результатов.

Мы использовали http://www.icecat.biz/en / в прошлом для извлечения каналов продуктов для загрузки в образцы данных. Есть также несколько расширений Magento, но они никогда не работали на нас, поэтому мы начали писать большинство наших сценариев импорта.

Чтобы получить более миллиона продуктов в magento. напишите простой php-скрипт, который генерирует csv-файл импорта продукта, поддерживаемый magmi, с различными типами продуктов. Затем используйте magmi для их импорта

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 не объединяются во время обновлений и могут занять часы/дни для выполнения обновления на БД:

• Пакетирование изменений схемы базы данных во время обновлений

Некоторые дополнительные сведения по теме индексирования в большой базе данных:

• http://mindutopia.com/2012/04/reindexing-large-product-databases-in-magento/

3) Самый простой способ обмена данными между двумя магазинами Magento - это отправить запрос REST/SOAP другим компаниям Magento API. Альтернативой было бы просто сбросить каталог с одного компании и позволить другому подобрать и проанализировать его, это может быть намного быстрее, чем проходить через API с 1+ миллионом продуктов.

Мы только что работали над проектом с 1,2 млн (без атрибутов и особенно с одним видом магазина) продуктов с использованием magento 1.7.x, и вот некоторые из наших впечатлений:

1. На самом деле импорт продуктов довольно хорош, я думаю, что наш первоначальный импорт занял примерно 1,5 часа

2. При выполнении переиндексации наш дисковый ввод-вывод сильно пострадал бы, решение состояло в том, чтобы получить хороший объем оперативной памяти (32 гб ОЗУ, экземпляр amazon ssd). Оптимизируйте настройки innodb, в которые мы помещаем выделение памяти пула innodb немного превышает размер базы данных, и особенно изменение буфера временной таблицы с 16 Мб по умолчанию на 128 Мб, это действительно то, что спасло наш процесс переиндексации.

3. Кэш, использование только кэша APC для быстрого кэширования, файлов для медленного кэширования, отключение ненужного ведения журнала и модулей вместе с плоской таблицей и несколькими другими оптимизациями позволяет серверу доставлять html-страницы продукта (не всю страницу) за 200 мс. В нашем списке дел есть лак кэш.

4. Мы боремся и убиваем множество тупиковых проблем (некоторые из них в admin все еще остаются), возможно, более новая версия Magento не даст этих проблем в соответствии с форумами.

Я скажу, что действительно есть проблемы с 1,2 млн продуктов, это не то, что я бы рекомендовал делать, не имея надлежащей команды и ресурсов, однако, если у вас есть время, вы можете заставить это работать.

Я не знаю, какая другая платформа справилась бы лучше.

Это всегда хорошо, да, Magento CE & EE может (исходя из опыта, а не теории, используя предоставленные наборы данных), хотя, очевидно, EE лучше подходит для индексирования. Magmi в порядке, однако, когда вы перейдете к переиндексации для начальной загрузки, у вас возникнет серьезная проблема. Кроме того, у вас будет техническое обслуживание, при котором, если 3 % продуктов меняются ежедневно, вам необходимо обновить 30 000 продуктов с помощью автоматического индекса, вы не сможете выполнять ежедневную переиндексацию. Все это сводится к двум вещам: кластерному хостингу и delta включила адаптацию поставщиков, которые являются доменами корпоративных компаний.

Люди, похоже, думают, что работа заканчивается, когда продукты загружены, однако именно тогда начинается тяжелая работа. Если у вас слишком много магазинов, ценовые уровни, то ваш хостинг должен удвоиться, поэтому, по сути, у 95 % нет шансов реализовать его, у 99 % нет шансов сохранить его. Миллионы продуктов равны среднему и Крупному предприятию - если ваши консультанты не имеют такого опыта, ожидайте инфраструктура рухнет в среднесрочной и долгосрочной перспективе.

Magmi также отлично подходит для импорта большого количества продуктов. http://sourceforge.net/apps/mediawiki/magmi/index.php?title=Magmi_Wiki

В настоящее время мы работаем над разработкой для клиента, у которого 2,2 миллиона артикулов, первоначальный импорт был выполнен с использованием Magmi.