Quelle version de Magento utilisez-vous? Beaucoup de changements ont été apportés dans la v1.13 - attendez-vous donc à des différences de version avant cette version. Voici un joli billet de blog expliquant le module mView et l'indexation dans la version 1.13 de Magento: eschrade.com/page/…
Pitt
Réponses:
63
Il existe différents types d'index dans Magento.
Tous les indexeurs sont là pour accélérer les choses.
Je n'en couvrirai ici que quelques-uns.
Index plat
Il existe 2 index de ce type. Un pour les catégories et un pour les produits.
Par défaut, les entités de catégorie et de produit (ainsi que les clients et les adresses des clients, mais ils ne sont pas importants dans cette situation) sont des entités EAV . C'est très agréable pour l'extensibilité. Mais c'est un tueur de performances, car pour obtenir toutes les valeurs de tous les attributs, vous avez besoin de beaucoup de jointures ou de plusieurs requêtes.
C'est là que l'indexeur plat entre en jeu.
Il transforme la structure de l'EAV en une structure plate. Je veux dire qu'il crée une table (une pour chaque vue de magasin dans Magento) qui a une colonne correspondant à un attribut. Cela rend les sélections plus rapides. Pour les catégories, tous les attributs sont convertis en colonnes de table. Pour les produits, seuls ceux que vous marquez comme «utilisés dans la liste des produits», car vous pouvez vendre tous les types de produits avec des attributs différents et la création d'un tableau avec des colonnes de gazillions peut ne pas être possible.
De plus, certains produits peuvent être désactivés ou n'appartenir à aucun site Web et il n'est pas nécessaire de les inclure dans les entrées à rechercher. Ils sont exclus par l'indexeur.
Les tables plates générées sont utilisées pour lire les données dans le fronend. Le backend utilise toujours la structure EAV.
Index de recherche dans le catalogue
Vous pouvez rechercher des produits en fonction de nombreuses valeurs d'attribut. Certains d'entre eux peuvent ne pas être inclus dans les tables plates générées par l'indexeur plat. Cet index remplit un tableau avec les valeurs d'attribut consultables pour les produits, il est donc plus facile de les rechercher en fonction de mots clés. Le fait d'avoir toutes les informations dans une table (ou un champ) permet d'utiliser la recherche en texte intégral et d'obtenir des résultats pertinents.
Prix des produits .
Le prix d'un produit peut être affecté par de nombreuses variables. Par exemple, groupe de clients, site Web, règles de remise de catalogue.
Comme ci-dessus, obtenir les produits avec leurs prix signifiera beaucoup de jointures ou de sélections multiples. De plus, les produits groupés ont un système de tarification étrange. Cet indexeur agrège les données de certaines tables ( catalog_product_index_price_*) et facilite les sélections (tri et filtrage).
Réécriture d'URL de catalogue
Cela nettoie les règles de réécriture d'URL en définissant quelle URL correspond à quel produit ou catégorie. Il est plus facile pour le système interne de gestion des URL de décider de la page à afficher lors de l'appel d'une URL non standard. Au lieu de rechercher dans toutes les clés d'URL de produit et de catégorie, il recherche simplement dans un tableau.
Produits de catégorie
Dans Magento, vous pouvez définir un attribut de catégorie nommé «Is Anchor» sur true ou false. Si c'est vrai, cela signifie que la catégorie en question listera tous les produits de ses catégories enfants. Encore une fois, pour déterminer ce temps réel, il faudra plus de ressources que la simple lecture d'une table. Cet indexeur crée l'association entre les produits et les catégories en fonction des associations que vous définissez dans le backend et du drapeau 'Is Anchor' sur les catégories.
État des stocks
Pour les produits simples, c'est facile. Ils peuvent être en stock ou en rupture de stock, mais pour configurable, groupé et bundle n'est pas si simple. Ils peuvent être en stock ou en rupture de stock selon les produits enfants associés au produit principal. Encore une fois (je me répète juste ici), obtenir leur statut en temps réel signifierait beaucoup de requêtes.
Attributs du produit .
Celui-ci recueille tous les attributs qui peuvent être utilisés dans la navigation en couches pour la même raison. Les avoir tous au même endroit pour une lecture plus rapide.
Agrégation de balises
Je n'ai aucune idée de ce que cela fait. Je n'ai jamais utilisé de balises dans un vrai projet live.
merci marius c'est jusqu'à présent la meilleure réponse ... j'ai
sonam
Que vouliez-vous dire lorsque vous avez dit que les tables plates sont utilisées uniquement en frontend (et que le backend utilise toujours la structure EAV)? Je suis un débutant, et d'après ce que j'ai compris, lorsque nous créons / mettons à jour des entités comme des produits, il utilise toujours les tables EAV pour effectuer ces opérations et nous devons définir l'option de mettre à jour les tables plates lors de l'enregistrement ou de les mettre à jour manuellement pour ces changements doivent se refléter dans les tableaux plats. Parlez-vous de ce processus lorsque vous avez dit cela? Pourriez-vous nous en dire plus à ce sujet? Merci!
Bharadwaj Srigiriraju
1
@Marius: Pendant la réindexation, je reçois une erreur de table pleine. Veuillez aider. L'erreur que je reçois est la table 'catalog_product_index_price_bundle_sel_tmp' est pleine
Blackbeard Blackbeard
1
@Marius après 3 ans de réponse, avez-vous une idée de l'agrégation de balises, est-ce lié aux balises de produits?
Murtuza Zabuawala
1
@Noir. Vous disposez de 2 paramètres pour les index. "Mise à jour lors de l'enregistrement" et "Manuel". Pour la mise à jour sur la sauvegarde, tout devrait se produire automatiquement lorsque vous enregistrez le produit. Mais cela peut entraîner des problèmes de performances. Par exemple, si vous modifiez plusieurs produits à la fois. Pour le mode manuel, aucune réindexation n'est déclenchée immédiatement après l'enregistrement, mais vous devez reconstruire manuellement lorsque vous avez terminé.
L'indexation de Magento est similaire à l'indexation au niveau de la base de données dans l'esprit. Comme le dit Anton, c'est un processus de dénormalisation pour permettre un fonctionnement plus rapide d'un site. Permettez-moi d'essayer d'expliquer certaines des pensées derrière la structure de la base de données Magento et pourquoi elle rend l'indexation nécessaire pour fonctionner à grande vitesse.
Dans une base de données MySQL plus "typique", une table de stockage des produits de catalogue serait structurée comme suit:
PRODUCT:
product_id INT
sku VARCHAR
name VARCHAR
size VARCHAR
longdesc VARCHAR
shortdesc VARCHAR
... etc ...
C'est rapide pour la récupération, mais cela laisse un problème fondamental pour un logiciel de commerce électronique: que faites-vous lorsque vous souhaitez ajouter plus d'attributs? Et si vous vendez des jouets et plutôt qu'une colonne de taille, vous avez besoin de age_range? Eh bien, vous pouvez ajouter une autre colonne, mais il doit être clair que dans un grand magasin (pensez à Walmart, par exemple), cela entraînerait des lignes vides à 90% et tenter de maintenir de nouveaux attributs est presque impossible.
Pour lutter contre ce problème, Magento divise les tables en unités plus petites. Je ne veux pas recréer l'intégralité du système EAV dans cette réponse, veuillez donc accepter ce modèle simplifié:
PRODUCT:
product_id INT
sku VARCHAR
PRODUCT_ATTRIBUTE_VALUES
product_id INT
attribute_id INT
value MISC
PRODUCT_ATTRIBUTES
attribute_id
name
Il est maintenant possible d'ajouter des attributs à volonté en entrant de nouvelles valeurs dans product_attributes puis en plaçant les enregistrements adjacents dans product_attribute_values. C'est essentiellement ce que fait Magento (avec un peu plus de respect pour les types de données que je ne l'ai montré ici). En fait, il n'y a plus de raison pour que deux produits aient des champs identiques, nous pouvons donc créer des types de produits entiers avec différents ensembles d'attributs!
Cependant, cette flexibilité a un coût. Si je veux trouver la couleur d'une chemise dans mon système (un exemple trivial), je dois trouver:
Le product_id de l'article (dans le tableau des produits)
L'attribut_id pour la couleur (dans la table attributaire)
Enfin, la valeur réelle (dans la table attribute_values)
Magento fonctionnait comme ça, mais c'était très lent. Donc, pour permettre de meilleures performances, ils ont fait un compromis: une fois que le commerçant a défini les attributs qu'il veut, allez-y et générez la grande table depuis le début. Quand quelque chose change, nuke-le depuis l'espace et générez-le à nouveau. De cette façon, les données sont stockées principalement dans notre joli format flexible, mais interrogées à partir d'une seule table.
Ces tables de recherche résultantes sont les "index" de Magento. Lorsque vous réindexez, vous faites exploser l'ancienne table et la générez à nouveau.
Magento est un système assez puissant et complexe. Il permet de travailler avec des quantités massives de données, mais lorsque la base de données est surchargée de tonnes d'enregistrements, elle devient lourde et lente. Magento utilise des index pour résoudre ce problème. Les index sont des tables de base de données supplémentaires avec des données plates, ce qui permet d'organiser des réponses rapides à partir de la base de données.
Par défaut, le système principal met à jour les index lors de la sauvegarde de chaque élément. Mais dans certains cas, vous devez le faire manuellement, par exemple certains types d'actions de masse, etc. Vous pouvez mettre à jour les index à tout moment à partir du backend d'administration (Admin-> System-> Index Management). Mais parfois, cela pose des problèmes.
Par exemple, si vous disposez de 10 000 produits et plus et de nombreuses catégories, la reconstruction de l'index de réécriture d'URL de catalogue peut prendre des heures. Ensuite, le script php peut simplement casser en raison du dépassement de max_execution_time. Il existe un moyen de résoudre plusieurs problèmes en exécutant le processus de réindexation à partir de la ligne de commande.
Réponses:
Il existe différents types d'index dans Magento.
Tous les indexeurs sont là pour accélérer les choses.
Je n'en couvrirai ici que quelques-uns.
Index plat
Il existe 2 index de ce type. Un pour les catégories et un pour les produits.
Par défaut, les entités de catégorie et de produit (ainsi que les clients et les adresses des clients, mais ils ne sont pas importants dans cette situation) sont des entités EAV . C'est très agréable pour l'extensibilité. Mais c'est un tueur de performances, car pour obtenir toutes les valeurs de tous les attributs, vous avez besoin de beaucoup de jointures ou de plusieurs requêtes.
C'est là que l'indexeur plat entre en jeu.
Il transforme la structure de l'EAV en une structure plate. Je veux dire qu'il crée une table (une pour chaque vue de magasin dans Magento) qui a une colonne correspondant à un attribut. Cela rend les sélections plus rapides. Pour les catégories, tous les attributs sont convertis en colonnes de table. Pour les produits, seuls ceux que vous marquez comme «utilisés dans la liste des produits», car vous pouvez vendre tous les types de produits avec des attributs différents et la création d'un tableau avec des colonnes de gazillions peut ne pas être possible.
De plus, certains produits peuvent être désactivés ou n'appartenir à aucun site Web et il n'est pas nécessaire de les inclure dans les entrées à rechercher. Ils sont exclus par l'indexeur.
Les tables plates générées sont utilisées pour lire les données dans le fronend. Le backend utilise toujours la structure EAV.
Index de recherche dans le catalogue
Vous pouvez rechercher des produits en fonction de nombreuses valeurs d'attribut. Certains d'entre eux peuvent ne pas être inclus dans les tables plates générées par l'indexeur plat. Cet index remplit un tableau avec les valeurs d'attribut consultables pour les produits, il est donc plus facile de les rechercher en fonction de mots clés. Le fait d'avoir toutes les informations dans une table (ou un champ) permet d'utiliser la recherche en texte intégral et d'obtenir des résultats pertinents.
Prix des produits .
Le prix d'un produit peut être affecté par de nombreuses variables. Par exemple, groupe de clients, site Web, règles de remise de catalogue.
Comme ci-dessus, obtenir les produits avec leurs prix signifiera beaucoup de jointures ou de sélections multiples. De plus, les produits groupés ont un système de tarification étrange. Cet indexeur agrège les données de certaines tables (
catalog_product_index_price_*) et facilite les sélections (tri et filtrage).Réécriture d'URL de catalogue
Cela nettoie les règles de réécriture d'URL en définissant quelle URL correspond à quel produit ou catégorie. Il est plus facile pour le système interne de gestion des URL de décider de la page à afficher lors de l'appel d'une URL non standard. Au lieu de rechercher dans toutes les clés d'URL de produit et de catégorie, il recherche simplement dans un tableau.
Produits de catégorie
Dans Magento, vous pouvez définir un attribut de catégorie nommé «Is Anchor» sur true ou false. Si c'est vrai, cela signifie que la catégorie en question listera tous les produits de ses catégories enfants. Encore une fois, pour déterminer ce temps réel, il faudra plus de ressources que la simple lecture d'une table. Cet indexeur crée l'association entre les produits et les catégories en fonction des associations que vous définissez dans le backend et du drapeau 'Is Anchor' sur les catégories.
État des stocks
Pour les produits simples, c'est facile. Ils peuvent être en stock ou en rupture de stock, mais pour configurable, groupé et bundle n'est pas si simple. Ils peuvent être en stock ou en rupture de stock selon les produits enfants associés au produit principal. Encore une fois (je me répète juste ici), obtenir leur statut en temps réel signifierait beaucoup de requêtes.
Attributs du produit .
Celui-ci recueille tous les attributs qui peuvent être utilisés dans la navigation en couches pour la même raison. Les avoir tous au même endroit pour une lecture plus rapide.
Agrégation de balises
Je n'ai aucune idée de ce que cela fait. Je n'ai jamais utilisé de balises dans un vrai projet live.
la source
Ne peut pas prendre le crédit pour cela car il est tiré de la publication d'origine à: https://stackoverflow.com/questions/4945307/can-someone-explain-magentos-indexing-feature-in-detail
L'indexation de Magento est similaire à l'indexation au niveau de la base de données dans l'esprit. Comme le dit Anton, c'est un processus de dénormalisation pour permettre un fonctionnement plus rapide d'un site. Permettez-moi d'essayer d'expliquer certaines des pensées derrière la structure de la base de données Magento et pourquoi elle rend l'indexation nécessaire pour fonctionner à grande vitesse.
Dans une base de données MySQL plus "typique", une table de stockage des produits de catalogue serait structurée comme suit:
C'est rapide pour la récupération, mais cela laisse un problème fondamental pour un logiciel de commerce électronique: que faites-vous lorsque vous souhaitez ajouter plus d'attributs? Et si vous vendez des jouets et plutôt qu'une colonne de taille, vous avez besoin de age_range? Eh bien, vous pouvez ajouter une autre colonne, mais il doit être clair que dans un grand magasin (pensez à Walmart, par exemple), cela entraînerait des lignes vides à 90% et tenter de maintenir de nouveaux attributs est presque impossible.
Pour lutter contre ce problème, Magento divise les tables en unités plus petites. Je ne veux pas recréer l'intégralité du système EAV dans cette réponse, veuillez donc accepter ce modèle simplifié:
Il est maintenant possible d'ajouter des attributs à volonté en entrant de nouvelles valeurs dans product_attributes puis en plaçant les enregistrements adjacents dans product_attribute_values. C'est essentiellement ce que fait Magento (avec un peu plus de respect pour les types de données que je ne l'ai montré ici). En fait, il n'y a plus de raison pour que deux produits aient des champs identiques, nous pouvons donc créer des types de produits entiers avec différents ensembles d'attributs!
Cependant, cette flexibilité a un coût. Si je veux trouver la couleur d'une chemise dans mon système (un exemple trivial), je dois trouver:
Magento fonctionnait comme ça, mais c'était très lent. Donc, pour permettre de meilleures performances, ils ont fait un compromis: une fois que le commerçant a défini les attributs qu'il veut, allez-y et générez la grande table depuis le début. Quand quelque chose change, nuke-le depuis l'espace et générez-le à nouveau. De cette façon, les données sont stockées principalement dans notre joli format flexible, mais interrogées à partir d'une seule table.
Ces tables de recherche résultantes sont les "index" de Magento. Lorsque vous réindexez, vous faites exploser l'ancienne table et la générez à nouveau.
J'espère que cela clarifie un peu les choses!
la source
nuke it from space, sympa :)Magento est un système assez puissant et complexe. Il permet de travailler avec des quantités massives de données, mais lorsque la base de données est surchargée de tonnes d'enregistrements, elle devient lourde et lente. Magento utilise des index pour résoudre ce problème. Les index sont des tables de base de données supplémentaires avec des données plates, ce qui permet d'organiser des réponses rapides à partir de la base de données.
Par défaut, le système principal met à jour les index lors de la sauvegarde de chaque élément. Mais dans certains cas, vous devez le faire manuellement, par exemple certains types d'actions de masse, etc. Vous pouvez mettre à jour les index à tout moment à partir du backend d'administration (Admin-> System-> Index Management). Mais parfois, cela pose des problèmes.
Par exemple, si vous disposez de 10 000 produits et plus et de nombreuses catégories, la reconstruction de l'index de réécriture d'URL de catalogue peut prendre des heures. Ensuite, le script php peut simplement casser en raison du dépassement de max_execution_time. Il existe un moyen de résoudre plusieurs problèmes en exécutant le processus de réindexation à partir de la ligne de commande.
la source