tl;dr ->" Magento peut-il gérer des produits 1M ", la réponse est oui , mais avec quelques considérations. À cette échelle, on supposerait que vous avez le volume nécessaire pour soutenir un investissement décent dans l'infrastructure et le personnel pour commercialiser un catalogue de cette proportion.
Première:
Comme vous l'avez peut-être vu, les exemples de données de Magento CE ne comportent qu'une poignée de produits de différentes catégories. Les données d'échantillon EE en ont plus et les séparent par type de magasin.
Vous pouvez télécharger ici des exemples de données CE . Vous devrez télécharger des exemples de données EE depuis votre compte MagentoCommerce.com si vous avez EE.
Vous constaterez cependant qu'il ne s'agit pas de centaines, voire de milliers de produits. Je vous conseille d' importer des produits dans la base de données - un bon exercice pour comprendre comment ce processus fonctionne. Cela peut être fait via le flux de données de Magento ou via l'importation d'API - des informations sur la façon de le faire à grande échelle sont facilement disponibles sur Internet.
Un mot d'avertissement - Dataflow est notoirement lent, il peut donc prendre un certain temps pour importer un catalogue de la taille que vous demandez. À ma connaissance, il n'existe pas d' exemple de catalogue à l'état sauvage contenant des centaines de milliers ou des millions de produits.
Modifier 1/7/14:
@ryaan_anthony sur Twitter a publié une procédure stockée MySQL qui générera des centaines de milliers de produits https://gist.github.com/ryaan-anthony/6290973
Quelques lectures sur l'API Magento et Dataflow:
http://www.magentocommerce.com/knowledge-base/entry/introduction-to-magento-dataflow
http://www.magentocommerce.com/api/soap/catalog/catalog.html
Seconde:
Le produit, la réécriture d'URL et l'indexation d'inventaire sont les principaux problèmes lors de l'exécution d'un catalogue de cette taille . La recherche dans le catalogue peut également être assez lente, mais peut être atténuée si vous utilisez Apache Solr (intégration fournie native à EE). Il existe des plugins CE pour Solr - Sonassi en a un, et d' autres peuvent être trouvés via Google.
J'ai géré des catalogues dans la gamme 700k, ce qui est encore beaucoup moins que 1M, et l' indexation peut prendre des heures et des heures . Ce problème a été résolu dans Enterprise 1.13 . Je vous recommande fortement de jeter un œil attentif à Enterprise Edition à cette échelle. Est-ce possible avec CE? Absolument; mais les améliorations d'indexation dans EE 1.13 sont spécifiquement adaptées à ce type de situation.
Troisième:
Multi-store est natif de Magento; vous pouvez configurer différentes catégories et sites Web de premier niveau. Ils n'ont pas tous à partager le même catalogue - vous pouvez choisir les produits à partager entre les sites ou décider de garder votre catalogue séparé. Plus d'infos ici:
http://www.magentocommerce.com/knowledge-base/entry/overview-how-multiple-websites-stores-work
Plus vous avez de magasins et de vues de magasin dans Magento, plus il y a d'entrées d'index et plus votre catalogue plat peut gonfler au point que le catalogue plat peut en fait être un drain de performance. Encore une fois, Sonassi a une tonne d'informations à ce sujet ici sur Magento.SE et sur leur site . Vous voudrez rechercher certaines des réponses de Sonassi sur Magento.SE pour gérer / mettre à l'échelle Magento lorsque vous entrerez dans ce domaine de la gestion des produits.
L'installation de chaque personne est différente - vous devez constamment tester, affiner, implémenter des ajustements pour trouver les paramètres qui fonctionnent le mieux pour votre catalogue, dans votre situation.
Utilisez ApiImport pour importer une telle quantité de produits. Il est basé sur ImportExport et très rapide ... J'ai géré jusqu'à 500 000 produits simples (indexés) par heure sur une machine virtuelle.
Exécutez simplement tests / benchmark_import_api.php. Modifiez ce fichier pour supprimer les types d'entités (et sous-types) dont vous n'avez pas besoin. Vous pouvez également vouloir définir USE_API sur false pour des résultats plus rapides.
la source
Nous avons utilisé http://www.icecat.biz/en/ dans le passé pour extraire les flux de produits pour les charger dans des exemples de données. Il existe également quelques extensions Magento, mais elles n'ont jamais fonctionné pour nous, nous avons donc écrit la plupart de nos scripts d'importation.
la source
pour obtenir plus d'un million de produits dans magento. écrire un script php simple qui génère un fichier csv d'importation de produits pris en charge par magmi avec différents types de types de produits. Utilisez ensuite le magmi pour les importer
http://sourceforge.net/apps/mediawiki/magmi/index.php?title=Magmi_Wiki
la source
Pas vraiment une réponse complète car il semble que d'autres aient déjà répondu à la plupart de vos questions, juste quelques petites choses à ajouter:
1) J'ai eu ce problème: près d'un million de produits Magento aléatoires dans dix CSV Vous pouvez également essayer http://beta.generatedata.com/ .
2) Comme Philwinkle l'a déjà mentionné: l'indexation, le flux de données et la recherche sont le plus grand obstacle à surmonter avec un ensemble de données aussi volumineux. EE1.13 gère mieux ces données volumineuses (déclencheurs MySQL, compte tenu de tous les statuts de produit / catégorie, etc.), mais gardez à l'esprit qu'il s'agit toujours d'une version initiale (x.0.0) pour le moment, j'ai tendance à attendre quelques versions pour permettre aux autres de se charger de la recherche de bogues avant d'envisager un environnement de production. L'infrastructure et l'optimisation sont essentielles. La mise à niveau future est également quelque chose d'autre à considérer, car
ALTER TABLEils ne sont pas combinés pendant les mises à niveau et peuvent prendre des heures / jours pour effectuer la mise à niveau sur la base de données:Quelques lectures supplémentaires sur le sujet de l'indexation sur une grande base de données:
3) Le moyen le plus simple de partager des données entre deux magasins Magento serait via une demande REST / SOAP aux autres sociétés API Magento. L'alternative serait de simplement vider le catalogue d'une entreprise et de permettre à l'autre de le récupérer et de l'analyser, cela peut être beaucoup plus rapide que de passer par l'API avec plus d'un million de produits.
la source
Nous venons de travailler sur un projet avec des produits de 1,2 m (pas d'attributs et surtout une seule vue de magasin) utilisant magento 1.7.x et voici quelques expériences que nous avons eues:
En fait, l'importation des produits est très bien, je pense que notre importation initiale a pris environ 1,5 h
Lors de la réindexation, notre disque io souffrirait extrêmement, la solution consistait à obtenir une bonne quantité de RAM (32 Go de RAM amazon ssd instance). Optimiser les paramètres innodb où nous avons mis l'allocation de mémoire du pool innodb un peu plus que la taille de la base de données et surtout changer le tampon de table temporaire de 16 Mo par défaut à 128 Mo, c'est vraiment ce qui a sauvé notre processus de réindexation.
Cache, en utilisant uniquement le cache APC pour le cache rapide, les fichiers pour le cache lent, la désactivation de la journalisation inutile et des modules avec une table plate et quelques autres optimisations, le serveur fournit les pages de produits html (pas la page entière) en 200 ms. Sur notre liste de tâches se trouve le cache de vernis.
Nous avons combattu et tué beaucoup de problèmes de blocage (certains restent toujours en administration), peut-être qu'une nouvelle version de Magento ne donnera pas ces problèmes selon les forums.
Je dirai qu'il y a vraiment des problèmes avec les produits 1.2m, ce n'est pas quelque chose que je recommanderais de faire sans avoir la bonne équipe et les ressources en place, cependant si vous avez le temps, vous pouvez le faire fonctionner.
Je ne sais pas quelle autre plateforme ferait mieux.
la source
Toujours bon celui-ci, oui Magento CE & EE peut (par expérience et non la théorie en utilisant les ensembles de données fournis) bien qu'EE soit évidemment meilleur pour l'indexation. Magmi va bien cependant quand vous venez de réindexer pour la charge initiale, vous aurez un problème grave. En plus de cela, vous avez ensuite une maintenance où si 3% des produits changent quotidiennement, vous devez mettre à jour 30 000 produits avec index automatique, vous ne pourrez pas effectuer une réindexation quotidienne. Tout cela se résume à deux choses, l'hébergement en cluster et l'intégration des fournisseurs compatible delta, qui sont les domaines des entreprises.
Les gens semblent penser que le travail se termine lorsque les produits sont chargés, mais c'est là que le dur travail commence. Si vous avez trop de magasins, de niveaux de prix, votre hébergement doit doubler, donc à toutes fins utiles, 95% n'ont aucune chance de le mettre en œuvre, 99% n'ont aucune chance de le maintenir. Des millions de produits correspondent aux moyennes et grandes entreprises - si vos consultants n'ont pas cette expérience, attendez-vous à ce que l'infrastructure s'effondre à moyen ou long terme.
la source
Magmi est également idéal pour importer un grand nombre de produits. http://sourceforge.net/apps/mediawiki/magmi/index.php?title=Magmi_Wiki
Nous travaillons actuellement sur un développement pour un client qui possède 2,2 millions de SKU, l'importation initiale a été effectuée à l'aide de Magmi.
la source