Чи Magento є правильною платформою для продуктів 1М?

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

1. Хтось знає, де я можу завантажити великий набір фіктивних даних для імпорту (або розумний спосіб їх генерування та імпорту)?
2. Які проблеми ви не бачите з розміром каталогу 1М + продуктів?
3. Чи існує спосіб поділитися БД однієї продукції з декількома незалежними магазинами (різними компаніями)?

tl;dr ->" Чи може Magento обробляти продукти 1М ", відповідь " так" , але з певними міркуваннями. У такому масштабі можна припустити, що у вас є обсяг для підтримки гідних інвестицій в інфраструктуру та персоналу, щоб продати каталог цієї пропорції.

Спочатку:

Зразок даних Magento CE, як ви, можливо, бачили, містить лише кілька продуктів різних категорій. Даних вибірки EE є більше, і вони розділені за типом магазину.

Ви можете завантажити зразки даних CE тут . Вам доведеться завантажити зразки даних EE з вашого облікового запису MagentoCommerce.com, якщо у вас є EE.

Однак ви побачите, що це не сотні чи навіть тисячі продуктів. Я б радив вам імпортувати продукти в базу даних - хороша вправа, щоб зрозуміти, як працює цей процес. Це можна зробити за допомогою потоку даних Magento або через імпорт API - інформація про те, як це зробити в масштабі, легко доступна в Інтернеті.

Слово обережності - Потік даних, як відомо, повільно, тому імпортувати каталог потрібного розміру може знадобитися досить багато часу. Наскільки мені відомо, у природі не існує зразкового каталогу із сотнями тисяч чи мільйонів продуктів.

Редагувати 7.01.14:

@ryaan_anthony у Twitter випустив збережену процедуру MySQL, яка генерує сотні тисяч продуктів https://gist.github.com/ryaan-anthony/6290973

Деякі дані про API Magento та потік даних:

http://www.magentocommerce.com/knowledge-base/entry/introduction-to-magento-dataflow

http://www.magentocommerce.com/api/soap/catalog/catalog.html

Друге:

Продукт, перезапис URL-адрес та індексація рекламних запасів є головними проблемами при використанні каталогу такого розміру . Пошук у каталозі теж може бути досить повільним, але його можна пом'якшити, якщо ви використовуєте Apache Solr (інтеграція надається для EE). Є плагіни CE для Solr - Sonassi має один, а інші можна знайти через Google.

Я керував каталогами в діапазоні 700k, що все ще набагато менше, ніж 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/uk/ для вилучення каналів продуктів для завантаження зразкових даних. Також є кілька розширень Magento, але вони завжди працювали на нас, тому ми приземлилися, написавши більшість наших імпортних сценаріїв.

щоб отримати мільйон + продукт у магенто. написати простий скрипт для php, який генерує файл імпортування файлів csv, підтримуваний 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. Виконуючи реіндекс наш дисковий іо постраждав би надзвичайно, рішенням було отримати хороший об'єм оперативної пам'яті (екземпляр Amazon ssd 32 Гб). Оптимізуйте параметри innodb, де ми розмістили розподіл пам'яті пулу innodb трохи на розмір бази даних, особливо змінивши буфер тимчасової таблиці з 16 до 128 Мб, це дійсно те, що врятувало наш процес реіндексації.

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

4. У нас, де бореться і вбиває безліч тупикових проблем (деякі з адміністраторів все ще залишаються), можливо, новіша версія Magento не дасть цих проблем відповідно до форумів.

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

Я не знаю, яка інша платформа зробила б кращу роботу.

Завжди добре це, так, Magento CE & EE може (з досвіду не теорії, використовуючи надані набори даних), хоча очевидно, що EE краще для індексації. Магмі чудово, проте коли ви перейдете на індекс для початкового навантаження, у вас виникне серйозна проблема. Крім того, ви маєте технічне обслуговування, коли якщо 3% продуктів щодня змінюватись, вам потрібно буде оновлювати 30 000 продуктів з автоматичним індексом, ви не зможете виконувати щоденний перевстановлення. Все це зводиться до двох моментів, кластерного хостингу та дельта, що підтримує доставку на борту, які є сферами корпоративних компаній.

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

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

Наразі ми працюємо над розробкою для клієнта, який має 2,2 мільйона SKU, початковий імпорт був здійснений за допомогою Magmi.