¿Qué versión de Magento estás usando? Se han realizado muchos cambios en v1.13, por lo tanto, espere diferencias en la versión anterior a esa versión. Aquí hay una buena publicación de blog que explica el módulo mView y la indexación en la versión 1.13 de Magento: eschrade.com/page/…
Pitt
Respuestas:
63
Hay diferentes tipos de índices en Magento.
Todos los indexadores están ahí para hacer que las cosas funcionen más rápido.
Cubriré aquí solo algunos de ellos.
Índice plano
Hay 2 de esos índices. Uno para categorías y otro para productos.
Por defecto, las entidades de categoría y producto (y clientes y direcciones de clientes, pero no son importantes en esta situación) son entidades EAV . Esto es muy bueno para la extensibilidad. Pero es un asesino de rendimiento porque para obtener todos los valores de todos los atributos necesita muchas uniones o consultas múltiples.
Aquí es donde entra en juego el indexador plano.
Transforma la estructura EAV en una estructura plana. Quiero decir que crea una tabla (una para cada vista de tienda en Magento) que tiene una columna correspondiente a un atributo. Esto hace que las selecciones sean más rápidas. Para las categorías, todos los atributos se convierten en columnas de tabla. Para los productos, solo los que marca como 'Usados en la lista de productos' porque puede vender todo tipo de productos con diferentes atributos y puede que no sea posible crear una tabla con millones de columnas.
Además, algunos productos pueden deshabilitarse o no pertenecer a un determinado sitio web y no es necesario incluirlos en las entradas para buscar. Están excluidos por el indexador.
Las tablas planas generadas se utilizan para leer datos en el viernes. El backend todavía usa la estructura EAV.
Índice de búsqueda en el catálogo
Puede buscar productos por muchos valores de atributo. Algunos de ellos pueden no estar incluidos en las tablas planas generadas por el indexador plano. Este índice completa una tabla con los valores de atributo que se pueden buscar para los productos, por lo que es más fácil buscarlos en función de las palabras clave. Tener toda la información en una tabla (o un campo) permite utilizar la búsqueda de texto completo y obtener resultados relevantes.
Precios de productos .
El precio de un producto puede verse afectado por muchas variables. Por ejemplo, grupo de clientes, sitio web, reglas de descuento de catálogo.
Igual que el anterior, obtener los productos con sus precios significará muchas combinaciones o selecciones múltiples. Además, los productos combinados tienen un extraño sistema de precios. Este indexador agrega los datos en algunas tablas ( catalog_product_index_price_*) y hace que las selecciones (clasificación y filtrado) sean mucho más fáciles.
Reescrituras de URL de catálogo
Esto limpia las reglas de reescritura de url al establecer qué url corresponde a qué producto o categoría. De esta manera, es más fácil para el sistema interno de administración de URL decidir qué página debe ver al llamar a una URL no estándar. En lugar de buscar en todas las claves de URL de productos y categorías, solo busca en una tabla.
Productos de categoría
En Magento puede establecer un atributo de categoría llamado 'Es ancla' en verdadero o falso. Si es cierto, significa que la categoría en cuestión enumerará todos los productos de sus categorías secundarias. Nuevamente, determinar este tiempo real requerirá más recursos que solo leer una tabla. Este indexador crea la asociación entre productos y categorías en función de las asociaciones que establezca en el backend y el indicador 'Es ancla' en las categorías.
Estado del stock
Para productos simples es fácil. Pueden estar en stock o fuera de stock, pero para configurables, agrupados y agrupados no es tan fácil. Pueden estar en stock o fuera de stock dependiendo de los productos secundarios asociados al producto principal. De nuevo (solo estoy repitiendo aquí), obtener su estado en tiempo real significaría muchas consultas.
Atributos del producto .
Este recopila todos los atributos que se pueden utilizar en la navegación por capas por el mismo motivo. Tenerlos todos en un solo lugar para una lectura más rápida.
Agregación de etiquetas
No tengo idea de lo que hace. Nunca he usado etiquetas en un proyecto real en vivo.
gracias Marius esto es como mucho, la mejor respuesta ... Tengo
Sonam
¿Qué quiso decir cuando dijo que las tablas planas se usan solo en la interfaz (y el backend todavía usa la estructura EAV)? Soy un novato, y por lo que entendí, cuando creamos / actualizamos entidades como productos, todavía utiliza las tablas EAV para realizar estas operaciones y tenemos que configurar la opción de actualizar las tablas planas al guardarlas o actualizarlas manualmente para estos cambios se reflejarán en tablas planas. ¿Te refieres a este proceso cuando dijiste eso? ¿Podría dar más detalles sobre esto, por favor? ¡Gracias!
Bharadwaj Srigiriraju
1
@ Mario: Durante la reindexación, recibo un error de tabla completa. Por favor ayuda. El error que obtengo
zed Blackbeard el
1
@Marius después de 3 años de esta respuesta, ¿tiene alguna idea sobre la agregación de etiquetas, está relacionada con las etiquetas de los productos?
Murtuza Zabuawala
1
@Negro. Tiene 2 configuraciones para los índices. "Actualización al guardar" y "Manual". Para la actualización de guardar todo debería ocurrir automáticamente cuando guarde el producto. Pero esto puede causar problemas de rendimiento. Por ejemplo, si cambia varios productos a la vez. Para el modo manual, no se activa la reindexación inmediatamente después de guardar, pero debe reconstruir manualmente cuando haya terminado.
La indexación de Magento solo es similar a la indexación a nivel de base de datos en espíritu. Como afirma Anton, es un proceso de desnormalización para permitir una operación más rápida de un sitio. Permítanme tratar de explicar algunos de los pensamientos detrás de la estructura de la base de datos de Magento y por qué hace necesaria la indexación para operar a gran velocidad.
En una base de datos MySQL más "típica", una tabla para almacenar productos de catálogo se estructuraría de la siguiente manera:
PRODUCT:
product_id INT
sku VARCHAR
name VARCHAR
size VARCHAR
longdesc VARCHAR
shortdesc VARCHAR
... etc ...
Esto es rápido para la recuperación, pero deja un problema fundamental para una pieza de software de comercio electrónico: ¿qué haces cuando quieres agregar más atributos? ¿Qué sucede si vende juguetes y, en lugar de una columna de tamaño, necesita age_range? Bueno, podría agregar otra columna, pero debe quedar claro que en una tienda grande (piense en Walmart, por ejemplo), esto daría como resultado filas que están 90% vacías e intentar mantener nuevos atributos es casi imposible.
Para combatir este problema, Magento divide las tablas en unidades más pequeñas. No quiero recrear todo el sistema EAV en esta respuesta, así que acepte este modelo simplificado:
PRODUCT:
product_id INT
sku VARCHAR
PRODUCT_ATTRIBUTE_VALUES
product_id INT
attribute_id INT
value MISC
PRODUCT_ATTRIBUTES
attribute_id
name
Ahora es posible agregar atributos a voluntad ingresando nuevos valores en product_attributes y luego colocando registros adyacentes en product_attribute_values. Esto es básicamente lo que hace Magento (con un poco más de respeto por los tipos de datos que los que he mostrado aquí). De hecho, ahora no hay ninguna razón para que dos productos tengan campos idénticos, por lo que podemos crear tipos de productos completos con diferentes conjuntos de atributos.
Sin embargo, esta flexibilidad tiene un costo. Si quiero encontrar el color de una camisa en mi sistema (un ejemplo trivial), necesito encontrar:
El product_id del artículo (en la tabla de productos)
El atributo_id para color (en la tabla de atributos)
Finalmente, el valor real (en la tabla attribute_values)
Magento solía trabajar así, pero era muy lento. Entonces, para permitir un mejor rendimiento, hicieron un compromiso: una vez que el dueño de la tienda ha definido los atributos que desea, continúe y genere la gran tabla desde el principio. Cuando algo cambie, destrúyalo desde el espacio y vuelva a generarlo. De esa manera, los datos se almacenan principalmente en nuestro formato flexible y agradable, pero se consultan desde una sola tabla.
Estas tablas de búsqueda resultantes son los "índices" de Magento. Cuando vuelve a indexar, está inflando la tabla anterior y volviéndola a generar.
Magento es un sistema bastante poderoso y complejo. Permite trabajar con grandes cantidades de datos, pero cuando la base de datos se sobrecarga con toneladas de registros, se vuelve pesada y lenta. Magento usa índices para resolver este problema. Los índices son tablas de base de datos adicionales con algunos datos planos, lo que permite organizar respuestas rápidas de la base de datos.
Por defecto, el sistema central actualiza los índices en cada elemento guardado. Pero en algunos casos debe hacerlo manualmente, por ejemplo, algunos tipos de acciones masivas, etc. Puede actualizar los índices en cualquier momento desde el backend de administración (Admin-> Sistema-> Gestión de índices). Pero a veces causa problemas.
Por ejemplo, si tiene más de 10k productos y muchas categorías, la reconstrucción del índice de 'reescritura de URL de catálogo' puede llevar horas. Luego, el script php puede simplemente romperse debido a que max_execution_time excede. Hay una manera de resolver varios problemas ejecutando el proceso reindexar desde la línea de comandos.
Respuestas:
Hay diferentes tipos de índices en Magento.
Todos los indexadores están ahí para hacer que las cosas funcionen más rápido.
Cubriré aquí solo algunos de ellos.
Índice plano
Hay 2 de esos índices. Uno para categorías y otro para productos.
Por defecto, las entidades de categoría y producto (y clientes y direcciones de clientes, pero no son importantes en esta situación) son entidades EAV . Esto es muy bueno para la extensibilidad. Pero es un asesino de rendimiento porque para obtener todos los valores de todos los atributos necesita muchas uniones o consultas múltiples.
Aquí es donde entra en juego el indexador plano.
Transforma la estructura EAV en una estructura plana. Quiero decir que crea una tabla (una para cada vista de tienda en Magento) que tiene una columna correspondiente a un atributo. Esto hace que las selecciones sean más rápidas. Para las categorías, todos los atributos se convierten en columnas de tabla. Para los productos, solo los que marca como 'Usados en la lista de productos' porque puede vender todo tipo de productos con diferentes atributos y puede que no sea posible crear una tabla con millones de columnas.
Además, algunos productos pueden deshabilitarse o no pertenecer a un determinado sitio web y no es necesario incluirlos en las entradas para buscar. Están excluidos por el indexador.
Las tablas planas generadas se utilizan para leer datos en el viernes. El backend todavía usa la estructura EAV.
Índice de búsqueda en el catálogo
Puede buscar productos por muchos valores de atributo. Algunos de ellos pueden no estar incluidos en las tablas planas generadas por el indexador plano. Este índice completa una tabla con los valores de atributo que se pueden buscar para los productos, por lo que es más fácil buscarlos en función de las palabras clave. Tener toda la información en una tabla (o un campo) permite utilizar la búsqueda de texto completo y obtener resultados relevantes.
Precios de productos .
El precio de un producto puede verse afectado por muchas variables. Por ejemplo, grupo de clientes, sitio web, reglas de descuento de catálogo.
Igual que el anterior, obtener los productos con sus precios significará muchas combinaciones o selecciones múltiples. Además, los productos combinados tienen un extraño sistema de precios. Este indexador agrega los datos en algunas tablas (
catalog_product_index_price_*) y hace que las selecciones (clasificación y filtrado) sean mucho más fáciles.Reescrituras de URL de catálogo
Esto limpia las reglas de reescritura de url al establecer qué url corresponde a qué producto o categoría. De esta manera, es más fácil para el sistema interno de administración de URL decidir qué página debe ver al llamar a una URL no estándar. En lugar de buscar en todas las claves de URL de productos y categorías, solo busca en una tabla.
Productos de categoría
En Magento puede establecer un atributo de categoría llamado 'Es ancla' en verdadero o falso. Si es cierto, significa que la categoría en cuestión enumerará todos los productos de sus categorías secundarias. Nuevamente, determinar este tiempo real requerirá más recursos que solo leer una tabla. Este indexador crea la asociación entre productos y categorías en función de las asociaciones que establezca en el backend y el indicador 'Es ancla' en las categorías.
Estado del stock
Para productos simples es fácil. Pueden estar en stock o fuera de stock, pero para configurables, agrupados y agrupados no es tan fácil. Pueden estar en stock o fuera de stock dependiendo de los productos secundarios asociados al producto principal. De nuevo (solo estoy repitiendo aquí), obtener su estado en tiempo real significaría muchas consultas.
Atributos del producto .
Este recopila todos los atributos que se pueden utilizar en la navegación por capas por el mismo motivo. Tenerlos todos en un solo lugar para una lectura más rápida.
Agregación de etiquetas
No tengo idea de lo que hace. Nunca he usado etiquetas en un proyecto real en vivo.
fuente
No puedo dar crédito por esto, ya que está tomado de la publicación original en: https://stackoverflow.com/questions/4945307/can-someone-explain-magentos-indexing-feature-in-detail
La indexación de Magento solo es similar a la indexación a nivel de base de datos en espíritu. Como afirma Anton, es un proceso de desnormalización para permitir una operación más rápida de un sitio. Permítanme tratar de explicar algunos de los pensamientos detrás de la estructura de la base de datos de Magento y por qué hace necesaria la indexación para operar a gran velocidad.
En una base de datos MySQL más "típica", una tabla para almacenar productos de catálogo se estructuraría de la siguiente manera:
Esto es rápido para la recuperación, pero deja un problema fundamental para una pieza de software de comercio electrónico: ¿qué haces cuando quieres agregar más atributos? ¿Qué sucede si vende juguetes y, en lugar de una columna de tamaño, necesita age_range? Bueno, podría agregar otra columna, pero debe quedar claro que en una tienda grande (piense en Walmart, por ejemplo), esto daría como resultado filas que están 90% vacías e intentar mantener nuevos atributos es casi imposible.
Para combatir este problema, Magento divide las tablas en unidades más pequeñas. No quiero recrear todo el sistema EAV en esta respuesta, así que acepte este modelo simplificado:
Ahora es posible agregar atributos a voluntad ingresando nuevos valores en product_attributes y luego colocando registros adyacentes en product_attribute_values. Esto es básicamente lo que hace Magento (con un poco más de respeto por los tipos de datos que los que he mostrado aquí). De hecho, ahora no hay ninguna razón para que dos productos tengan campos idénticos, por lo que podemos crear tipos de productos completos con diferentes conjuntos de atributos.
Sin embargo, esta flexibilidad tiene un costo. Si quiero encontrar el color de una camisa en mi sistema (un ejemplo trivial), necesito encontrar:
Magento solía trabajar así, pero era muy lento. Entonces, para permitir un mejor rendimiento, hicieron un compromiso: una vez que el dueño de la tienda ha definido los atributos que desea, continúe y genere la gran tabla desde el principio. Cuando algo cambie, destrúyalo desde el espacio y vuelva a generarlo. De esa manera, los datos se almacenan principalmente en nuestro formato flexible y agradable, pero se consultan desde una sola tabla.
Estas tablas de búsqueda resultantes son los "índices" de Magento. Cuando vuelve a indexar, está inflando la tabla anterior y volviéndola a generar.
¡Espero que eso aclare un poco las cosas!
fuente
nuke it from space, agradable :)Magento es un sistema bastante poderoso y complejo. Permite trabajar con grandes cantidades de datos, pero cuando la base de datos se sobrecarga con toneladas de registros, se vuelve pesada y lenta. Magento usa índices para resolver este problema. Los índices son tablas de base de datos adicionales con algunos datos planos, lo que permite organizar respuestas rápidas de la base de datos.
Por defecto, el sistema central actualiza los índices en cada elemento guardado. Pero en algunos casos debe hacerlo manualmente, por ejemplo, algunos tipos de acciones masivas, etc. Puede actualizar los índices en cualquier momento desde el backend de administración (Admin-> Sistema-> Gestión de índices). Pero a veces causa problemas.
Por ejemplo, si tiene más de 10k productos y muchas categorías, la reconstrucción del índice de 'reescritura de URL de catálogo' puede llevar horas. Luego, el script php puede simplemente romperse debido a que max_execution_time excede. Hay una manera de resolver varios problemas ejecutando el proceso reindexar desde la línea de comandos.
fuente