J'ai une boutique et tout le temps TOUS les index sont invalides. J'ai remarqué, que je n'ai aucune idée, quand un index est invalidé.
Pouvez-vous me donner une liste des événements "tous", qui rendent un ou plusieurs de ces index invalides?
Faire un grep sur le répertoire de code vous obtiendra une liste de fichiers qui déclenche une invalidation.
grep -Ri '::STATUS_REQUIRE_REINDEX' .
Les fichiers de base suivants déclenchent une invalidation
./core/Mage/CatalogSearch/Model/Indexer/Fulltext.php
./core/Mage/Catalog/Model/Product/Indexer/Flat.php
./core/Mage/Catalog/Model/Product/Indexer/Price.php
./core/Mage/Catalog/Model/Category/Indexer/Flat.php
./core/Mage/Catalog/Model/Category/Indexer/Product.php
./core/Mage/Catalog/Model/System/Config/Backend/Catalog/Product/Flat.php
./core/Mage/Catalog/Model/System/Config/Backend/Catalog/Category/Flat.php
./core/Mage/Catalog/Model/Indexer/Url.php
./core/Mage/Backup/Helper/Data.php
./core/Mage/CatalogInventory/Model/Indexer/Stock.php
./core/Mage/ImportExport/Model/Import.phpLes événements de base dans le noyau Magento CE sont
Attributs du produit
attribut de sauvegarde spécifique (fait partie du produit plat), store, store_group si le produit de catalogue plat est activé
Prix des produits
vérifier les paramètres de configuration enregistrer (comme la portée des prix). ou sauvegarde de produit, création / suppression de site Web
Réécriture d'URL de catalogue
pas d'invalidation spécifique
Données plates sur le produit
Attribut de sauvegarde spécifique (fait partie du produit plat), si le produit de catalogue plat est activé, après avoir activé le produit plat
Catégorie Flat Data
Vérifier que la catégorie de catalogue à plat est activée et la catégorie de sauvegarde spécifique, après avoir activé la catégorie à plat
Catégorie Produits
la vérification est la catégorie de catalogue plate est activée et la catégorie de sauvegarde spécifique
Index de recherche de catalogue
attribut de sauvegarde spécifique (fait partie des attributs consultables), store, store_group si le produit de catalogue plat est activé
Données d'agrégation de balises
Jamais invalidé sauf conditions générales mentionnées ci-dessous
État des stocks
Système spécifique> Paramètres de configuration dans l'onglet inventaire enregistrer, afficher les produits en rupture de stock par exemple
Tous sont invalidés après une restauration de la sauvegarde System > Tools > Backupet la création, la suppression ou le déplacement de sites Web, de magasins et de vues de magasin Après l'exécution des importations de flux de données pour le produit, les éléments suivants sont invalidés: catalog_product_price, catalog_category_product, catalogsearch_fulltext, catalog_product_flat
Plusieurs indexeurs comme les données plates et l'indexeur d'URL semblent également être invalidés en enregistrant des core_config_datavaleurs.
C'est peut-être une idée de créer temporairement une réécriture pour ce site sur
Mage_Index_Model_Resource_Process
Ensuite, faites quelque chose comme:
<?php
class YourNamespace_YourModule_Model_Resource_Process
extends Mage_Index_Model_Resource_Process
{
public function updateStatus($process, $status)
{
if ($status === Mage_Index_Model_Process::STATUS_REQUIRE_REINDEX) {
Mage::log(sprintf('Indexer %s was invalidated.', $process->getIndexer()->getName()), null, 'invalid_index.log', true);
foreach (debug_backtrace() as $db) {
Mage::log(sprintf('%s::%s', $db['class'], $db['function']), null, 'invalid_index.log', true);
}
}
return parent::updateStatus($process, $status);
}
}Cela devrait facilement identifier quand un indexeur est invalidé et la trace d'appel qui en était responsable.
Puisque d'autres ont déjà répondu à vos questions spécifiques. J'ai pensé qu'il serait peut-être préférable d'expliquer pourquoi l'indexation est nécessaire et comment elle se rapporte à Magento et la relation avec les bases de données modernes .
Index: une liste alphabétique des noms, des sujets, etc., avec des références aux endroits où ils se produisent, généralement à la fin d'un livre.
Alors, qu'est-ce qu'un index en termes de bases de données ?
Un index est une structure de données qui trie un certain nombre d'enregistrements sur un ou plusieurs champs et accélère la récupération des données. Cela permet d'éviter d'analyser les blocs de disque qu'une table couvre lors de la recherche dans la base de données.
Et qu'est-ce que l'indexation en termes de Magento ? Le sous-produit de EAV (Entity Attribute Value) AKA une base de données dans une base de données. Avec plusieurs tables de recherche, regroupant tous les attributs marqués comme indexés pour être combinés en une seule table plate de toutes les tables de recherche, pour des requêtes plus rapides et moins d'E / S et de cycles CPU.
Je me souviens d'une mention selon laquelle lors du développement initial de Magento, la flexibilité figurait en haut de la liste des priorités, ce qui explique pourquoi ils ont choisi d'utiliser le modèle de données EAV. En fin de compte, cependant, le coût d'une telle flexibilité a eu un impact sur les performances et cela a tourmenté Magento depuis le début.
En général, les ingénieurs de Magento ont été chargés, avant tout, de créer le système le plus flexible et personnalisable possible, et de se soucier des performances plus tard. Pourquoi Magento est-il si lent?
L'EAV est idéal pour l'entreposage de données mais terrible pour les transactions. Alors pourquoi avons-nous besoin d'index pour commencer? Depuis que la même approche du modèle relationnel a été réimplémentée, Magento doit maintenant gérer toutes les choses que MySQL fait lui-même en interne. Certaines choses à considérer, comme les index déjà existants dans les tables MySQL. Dans cet esprit également, considérons maintenant le modèle de données EAV:
Le même doit être réimplémenté, ce qui est très "anti-modèle" OMI.
En outre, c'est la même raison pour var/lockslaquelle l' indexeur utilise pour verrouiller le processus d'indexation. Mêmes raisons pour lesquelles les bases de données ont un verrouillage de ligne / table.
Désormais, lorsqu'un enregistrement, par exemple, une valeur de produit a été modifiée, le flat tableou index(comme MySQL l'appellerait) doit être mis à jour pour être reflété afin que les requêtes sur les données nouvellement modifiées soient trouvées rapidement et efficacement sans parcourir de nombreux enregistrements. Les tables plates existent telles qu'elles sont utilisées dans la même raison que MySQL les a, sans un tel index (comme un livre), il nécessite une analyse complète de la table pour récupérer l'enregistrement. Cela signifie des quantités massives d'E / S pour le disque et la mémoire ainsi que des cycles de processeur pour localiser les données demandées, ce qui est très mauvais pour les performances.
Étant donné que Magento utilise le modèle de données EAV, il existe de nombreuses tables de recherche qui doivent être analysées pour regrouper toutes les données afin de localiser les données qui ont été demandées. C'est ce qui se produit si vous désactivez les catalogues plats. Tout comme MySQL, l'analyse de l'enregistrement par rapport à l'utilisation d'un index (table plate) à utiliser pour localiser l'enregistrement rapidement tout en préservant les précieux cycles d'E / S. Créer une table et ne pas ajouter d'index revient à ne pas utiliser les tables plates dans magento. Bien que ces deux scénarios puissent bien fonctionner dans différents scénarios, voir Ben à la très bonne réponse de Sonassi à cette question. (Indique que cela implique de comprendre la portée des données.)
Bien que ce ne soit pas une réponse directe à votre question, comprendre les parties mobiles et être mieux préparé pour elles devrait aider à atténuer certains des maux de tête qui accompagnent l'indexation. " Traitez le problème plutôt que le symptôme. "
Explorer davantage les composants internes des systèmes de bases de données modernes peut aider à mieux comprendre comment et pourquoi l'indexation est nécessaire et comment elle se rapporte (quelque peu) à l'indexation de Magento.
Pour résumer: Comprenez l'étendue de votre problème avant d'appliquer aveuglément des solutions. Comme toutes les données ne seront pas exactement les mêmes et planifier et mettre en œuvre des solutions APRÈS avoir une bonne / complète compréhension du problème. L'optimisation de la base de données peut être très enrichissante pour la gestion du changement. Telles que prévenir les redoutés DEADLOCKS.
Vous pouvez également envisager de définir tous vos indexeurs Manualet de configurer des processus alternatifs pour reconstruire l'index aux heures creuses (lorsque les administrateurs sont absents). Uniquement Product Priceset Stock Statusdoit être défini sur Update on Save.
Voyons maintenant comment fonctionne l'indexation d'un point de vue technique. Le module principal est responsable de l'indexation Mage_Index. Les modèles de base de l'indexeur: Indexer, Process, Event.
Mage_Index_Model_Indexerest l'indexeur, toutes les interactions avec d'autres modules modules Mage_Indexse produisent via ce service. Il contient les méthodes suivantes:
processEntityAction() Crée et enregistre l'événement et démarre le processus d'indexationlogEvent() Crée un événement et l'enregistre pour une indexation ultérieure;indexEvent() Exécute les événements d'indexation;getProcessesCollection()Renvoie la collection de tous les processus tels que les attributs de produit, les prix des produits, les réécritures d'URL de catalogue, etc. Habituellement après avoir changé l'essence, comme la méthode _afterSaveou _afterCommitnous effectuons une réindexation partielle.Le Mage_Index_Model_Processprocessus or est l'essence de votre indexeur qui stocke le statut, la dernière opération exécutée. Tous les processus sont stockés dans la table index_process. Le programme a une méthode getIndexer()qui retourne l'index du modèle. La plupart des tâches déléguées par le processus du modèle d'index.
Mage_Index_Model_Eventstocke des informations sur l'événement qui s'est produit. Par exemple, nous stockons le produit et après avoir enregistré, nous créons un nouvel événement et stockons des informations sur le type d'entité que nous venons de sauvegarder, quel id a l'esprit et quelle action nous avons effectuée pour cette substance.
Une liste générale des cas d'invalidation:
Tout modèle de ressource avec index enregistré dans le module config.xml, lors de l'enregistrement de la transaction. afterCommitCallback()est appelé avec un préfixe. C'est là que les événements d'index sont enregistrés, car ils se trouvent à la fin d'une transaction réussie.
... et ça me rend triste que l'EAV soit toujours là dans Magento 2. :(
Les références: