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


31

Мне нужно посмотреть, как Magento будет работать с 1М SKU; но я изо всех сил пытаюсь найти большой набор образцов данных для загрузки - или найти выполнимый способ создания канала для импорта (и сам процесс импорта).

  1. Кто-нибудь знает, где я могу скачать большой набор фиктивных данных для импорта (или разумное средство для его генерации и импорта)?
  2. Какие проблемы вы ожидаете с размером каталога более 1 млн. Товаров?
  3. Есть ли способ поделиться одной базой данных продуктов с несколькими независимыми магазинами (разными компаниями)?

Ответы:


36

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, когда вы попадете в сферу управления продуктами.

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


Привет! Большое спасибо за всю эту информацию.
Габриэле

БД создается автоматически системой, подключенной ко многим редакторам, которые регулярно обновляют нашу БД. Мы предоставляем окончательную базу данных и обновления для книжных магазинов, и теперь мы хотим предложить нашим клиентам комплексное решение для электронной коммерции. Я сделал это, чтобы импортировать все данные через Magmi. Это фантастика и идеально подходит для нас. Что касается индексации, я пойду к решению Solr. Я не могу использовать MultiStores, так как мне нужно предоставить полный доступ администратора своим клиентам. Еще раз спасибо!
Габриэле

Интересно, что вы не упомянули соображения о хостинге, оптимизации БД, альтернативах или улучшениях для потока данных, использовании клона вместо фабричной инстанции для обработки больших данных, оптимизации кэша и производительности и других опциях производительности для оптимизации magento для каталога этого размер. Ожидание индексации несколько часов звучит больно ... почему бы не запустить кластер или не использовать прокси-сервер mysql для обработки индексации и синхронизации таблицы БД после ее завершения? Просто некоторые основные мысли ... есть и более продвинутые методы.
mprototype

@mprototype не стесняйтесь добавлять свой собственный ответ, как вы считаете нужным.
Philwinkle

7

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

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


4

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


4

чтобы получить миллион + продукт в magento. написать простой PHP-скрипт, который генерирует поддерживаемый Magmi CSV-файл импорта товаров с различными типами товаров. Затем используйте Магми, чтобы импортировать их

http://sourceforge.net/apps/mediawiki/magmi/index.php?title=Magmi_Wiki


Магми импортер CSV, верно? Так что я должен кормить Магма csv файлами, связанными с каталогом, верно?
Габриэле

1
да, в вики есть документация, как отформатировать CSV для импорта продукта, а затем создать профиль с веб-интерфейсом и использовать команду cli для его импорта: do / usr / bin / php magmi.cli.php -profile = custom_options -mode = create -CSV: filename = "$ {x}"; сделано
сутха катир

CSV является одним из источников данных, которые может использовать Magmi. Помните, что у Magmi есть интерфейс для ввода данных, в который вы можете вводить данные без CSV-файлов.
Аксель

3

Не совсем полный ответ, так как кажется, что другие уже ответили на большинство ваших вопросов, просто добавим несколько вещей:

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
1) Я посмотрю на это. 2) Да, я ходил за Магми в СЕ. Посмотрим, как это будет работать. 3) Да, я думаю, что дамп данных и импорт в новый магазин будут нашим выбором, если мы не найдем способ разделить общую базу данных продуктов между всеми электронными магазинами. Большое спасибо B00mer!
Габриэле

3

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

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

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

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

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

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

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


2

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

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


Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.