¿Es Magento la plataforma adecuada para productos 1M?

31

Necesito ver cómo Magento se desempeñará con 1M SKU; pero estoy luchando por encontrar un gran conjunto de datos de datos de muestra para descargar, o encontrar un método factible para generar el feed para la importación (y el proceso de importación en sí).

  1. ¿Alguien sabe dónde podría descargar un gran conjunto de datos ficticios para importar (o un medio sensato para generarlos e importarlos)?
  2. ¿Qué problemas prevé con un tamaño de catálogo de productos 1M +?
  3. ¿Hay alguna manera de compartir una sola base de datos de productos con múltiples tiendas independientes (diferentes compañías)?
performance import Gabriele
fuente

Respuestas:

36

tl;dr ->" Puede Magento manejar productos 1M ", la respuesta es sí , pero con algunas consideraciones. A esta escala, uno supondría que tiene volumen para respaldar una inversión decente en infraestructura y personal para comercializar un catálogo de esta proporción.

Primero:

Los datos de muestra de Magento CE, como puede haber visto, solo tienen un puñado de productos de diferentes categorías. Los datos de muestra de EE tienen más y los separan por tipo de tienda.

Puede descargar datos de muestra CE aquí . Tendrá que descargar datos de muestra de EE desde su cuenta de MagentoCommerce.com si tiene EE.

Sin embargo, descubrirá que no se trata de cientos o incluso miles de productos. Le aconsejaría que importe productos a la base de datos , un buen ejercicio para saber cómo funciona este proceso. Esto se puede hacer a través del flujo de datos de Magento o de la importación API: la información sobre cómo hacer esto a escala está disponible en Internet.

Una palabra de precaución: el flujo de datos es notoriamente lento, por lo que puede llevar bastante tiempo importar un catálogo del tamaño que solicite. Que yo sepa, no existe un catálogo de muestra en la naturaleza con cientos de miles o millones de productos que existen.

Editar 7/1/14:

@ryaan_anthony en Twitter lanzó un procedimiento almacenado MySQL que generará cientos de miles de productos https://gist.github.com/ryaan-anthony/6290973

Algunas lecturas sobre Magento API y Dataflow:

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

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

Segundo:

El producto, la reescritura de URL y la indexación de inventario son los problemas principales al ejecutar un catálogo de este tamaño . La búsqueda en el catálogo también puede ser bastante lenta, pero puede mitigarse si usa Apache Solr (integración provista nativa de EE). Hay plugins CE para Solr - Sonassi tiene uno, y otros se pueden encontrar a través de Google.

He administrado catálogos en el rango de 700k, que todavía es mucho menos de 1M, y la indexación puede llevar horas y horas . Esto se ha abordado en Enterprise 1.13 . Le recomiendo que eche un vistazo a Enterprise Edition a esta escala. ¿Es esto posible con CE? Absolutamente; pero las mejoras de indexación en EE 1.13 se adaptan específicamente a este tipo de situación.

Tercero:

La tienda múltiple es nativa de Magento; puede configurar diferentes categorías y sitios web de nivel superior. No todos tienen que compartir el mismo catálogo: puede elegir qué productos compartir en todos los sitios o decidir mantener su catálogo segregado. Más información aquí:

http://www.magentocommerce.com/knowledge-base/entry/overview-how-multiple-websites-stores-work

Cuantas más tiendas, vistas de tiendas tenga en Magento, más entradas de índice y más puede hinchar su catálogo plano hasta el punto de que el catálogo plano en realidad puede ser una pérdida de rendimiento. Nuevamente, Sonassi tiene mucha información sobre esto aquí en Magento.SE y en su sitio . Querrá buscar algunas de las respuestas de Sonassi en Magento.SE para manejar / escalar Magento cuando ingrese a este ámbito de gestión de productos.

La instalación de cada persona es diferente: debe probar, refinar e implementar ajustes constantemente para encontrar qué configuraciones funcionan mejor para su catálogo, en su situación.

philwinkle
fuente
¡Hola! Muchas gracias por toda esta información.
Gabriele
El DB está construido automáticamente por un sistema conectado a muchos editores que actualizan regularmente nuestro DB. Proporcionamos el DB final y las actualizaciones a las librerías y ahora queremos ofrecer una solución completa de comercio electrónico a nuestros clientes. Lo hice para importar todos los datos a través de Magmi. Es fantástico y perfecto para nosotros. En cuanto a la indexación, buscaré la solución Solr. No puedo usar MultiStores porque necesito proporcionar acceso de administrador completo a mis clientes. ¡Gracias de nuevo!
Gabriele
Es interesante que no haya mencionado la consideración de alojamiento, optimización de db, alternativas o mejoras para el flujo de datos, el uso de clones en lugar de la creación de instancias de fábrica para el procesamiento de datos grandes, la optimización de caché y rendimiento y otras opciones de rendimiento para optimizar magento para un catálogo de este tamaño. Esperar varias horas para que la indexación suene doloroso ... ¿por qué no ejecutar un clúster o usar el proxy mysql para procesar la indexación y dejar que una tabla DB se sincronice cuando haya terminado? Solo algunos pensamientos básicos ... también hay métodos más avanzados disponibles.
mprototype
@mprototype no dude en agregar su propia respuesta como mejor le parezca.
philwinkle
7

Use ApiImport para importar una cantidad tan grande de productos. Se basa en ImportExport y es muy rápido ... He administrado hasta 500k productos simples (indexados) por hora en una máquina virtual.

Simplemente ejecute tests / benchmark_import_api.php. Edite ese archivo para eliminar los tipos de entidad (y subtipos) que no necesita. También es posible que desee establecer USE_API en falso para obtener resultados más rápidos.

Daniel Sloof
fuente
4

Hemos utilizado http://www.icecat.biz/en/ en el pasado para extraer feeds de productos para cargar datos de muestra. También hay algunas extensiones de Magento, pero nunca funcionaron para nosotros, así que terminamos escribiendo la mayoría de nuestros scripts de importación.

Vinci Rufus
fuente
4

para obtener un millón de productos en magento. escriba un script php simple que genere un archivo csv de importación de productos compatible con magmi con diferentes tipos de productos. Luego usa el magmi para importarlos

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

sutha kathir
fuente
Magmi es un importador de CSV, ¿verdad? Entonces tengo que alimentar a Magm con archivos csv que contienen el catálogo, ¿verdad?
Gabriele
1
sí, en la wiki hay documentación, cómo debe formatear su csv para la importación del producto y luego hacer el perfil con la interfaz web y usar el comando cli para importarlo do / usr / bin / php magmi.cli.php -profile = custom_options -modo = crear -CSV: nombre de archivo = "$ {x}"; hecho
sutha kathir
CSV es una de las fuentes de datos que Magmi puede usar. Tenga en cuenta que Magmi tiene una interfaz de bomba de datos en la que puede inyectar datos, sin archivos CSV.
Axel
3

Realmente no es una respuesta completa, ya que parece que otros ya han abordado la mayoría de sus preguntas, solo algunas cosas para agregar:

1) He tenido esto por ahí: casi un millón de productos Magento aleatorios en diez CSV También puede probar http://beta.generatedata.com/ .

2) Como Philwinkle ya mencionó: la indexación, el flujo de datos y la búsqueda es el mayor obstáculo a superar con un conjunto de datos tan grande. EE1.13 hace un mejor trabajo al manejar datos tan grandes (activadores de MySQL, considerando todo el estado del producto / categoría, etc.), pero tenga en cuenta que todavía es una versión inicial (x.0.0) en este momento, tiendo a esperar algunos versiones para permitir que otros asuman la carga de encontrar errores antes de considerarlo para un entorno de producción. Infraestructura y optimización es clave. La actualización futura también es algo más a considerar, ya que ALTER TABLEno se combinan durante las actualizaciones y pueden llevar horas / días realizar la actualización en la base de datos:

Algunas lecturas adicionales sobre el tema de la indexación en una base de datos grande:

3) La forma más fácil de compartir datos entre dos tiendas Magento sería a través de una solicitud REST / SOAP a las otras compañías API de Magento. La alternativa sería simplemente volcar el catálogo de una compañía y permitir que la otra lo recoja y analice, puede ser mucho más rápido que pasar por la API con más de 1 millón de productos.

B00MER
fuente
1
1) Lo echaré un vistazo. 2) Sí, fui por Magmi en CE. Veremos cómo funcionará. 3) Sí, creo que descartar los datos e importarlos en una nueva tienda será nuestra elección, a menos que encontremos una manera de compartir una base de datos de productos común entre todas las tiendas electrónicas. Gracias lote B00mer!
Gabriele
3

Acabamos de trabajar en un proyecto con productos de 1.2m (sin atributos y especialmente solo una vista de la tienda) usando magento 1.7.xy aquí están algunas de las experiencias que tuvimos:

  1. En realidad, importar los productos está bastante bien, creo que nuestra importación inicial tomó algo así como 1.5 h

  2. Al reindexar nuestro disco io sufriría muchísimo, la solución fue obtener una buena cantidad de ram (32 gb de ram amazon ssd). Optimice la configuración de innodb donde ponemos la asignación de memoria del grupo innodb a un poco más del tamaño de la base de datos y especialmente cambiando el búfer de la tabla temporal de 16mb a 128mb por defecto, esto es realmente lo que salvó nuestro proceso de reindexación.

  3. La memoria caché, que usa solo la memoria caché de APC para la memoria caché rápida, los archivos para la memoria caché lenta, desactiva el registro innecesario y los módulos junto con la tabla plana y un par de otras optimizaciones, hace que el servidor entregue las páginas del producto html (no toda la página) en 200 ms. En nuestra lista de tareas pendientes está el caché de barniz.

  4. Estamos luchando y matando muchos problemas de punto muerto (todavía quedan algunos en administración), posiblemente una versión más nueva de Magento no dará estos problemas según los foros.

Diré que realmente hay problemas con los productos de 1.2 millones, no es algo que recomendaría hacer sin tener el equipo y los recursos adecuados, sin embargo, si tiene el tiempo, puede hacerlo funcionar.

No sé qué otra plataforma haría un mejor trabajo.

palmik
fuente
2

Siempre es bueno este, sí Magento CE & EE puede (por experiencia, no en teoría, utilizando los conjuntos de datos suministrados) aunque obviamente EE es mejor para la indexación. Magmi está bien, sin embargo, cuando vengas a reindexar la carga inicial, tendrás un problema grave. Además de eso, entonces tiene mantenimiento donde si el 3% de los productos cambian diariamente, necesita actualizar 30,000 productos con índice automático, no podrá realizar una reindexación diaria. Todo esto se reduce a dos cosas, el alojamiento en clúster y la incorporación de proveedores habilitados para delta, que son los dominios de las empresas.

La gente parece pensar que el trabajo termina cuando se cargan los productos, sin embargo, es cuando comienza el trabajo duro. Si tiene demasiadas tiendas, los niveles de precios, entonces su alojamiento debe duplicarse, por lo que para todos los efectos, el 95% no tiene posibilidades de implementarlo, el 99% no tiene posibilidades de mantenerlo. Millones de productos equivalen a empresas medianas y grandes: si sus consultores no tienen esta experiencia, espere que la infraestructura se derrumbe a mediano y largo plazo.


fuente