Quelle est la différence entre les différents types de recherche?
- Comme
- Texte intégral
- Combiné
Je suis particulièrement intéressé par la façon dont le comportement de recherche et les performances changent pour ces paramètres.
Quelle est la différence entre les différents types de recherche?
Je suis particulièrement intéressé par la façon dont le comportement de recherche et les performances changent pour ces paramètres.
Réponses:
Tout le monde se plaint toujours de la recherche Magento, mais je pense que cela peut très bien fonctionner si vous passez du temps à la planifier et à la configurer correctement.
Méthode de recherche basée sur les mots clés, divisant votre requête en mots individuels. Voir ce qui suit de la ligne 326 en classeMage_CatalogSearch_Model_Resource_Fulltext::prepareResult()
$words = Mage::helper('core/string')->splitWords($queryText, true, $query->getMaxQueryWords());
foreach ($words as $word) {
$like[] = $helper->getCILike('s.data_index', $word, array('position' => 'any'));
}
if ($like) {
$likeCond = '(' . join(' OR ', $like) . ')';
}
Vous pouvez voir qu'il divise chaque mot de votre requête de recherche et les assemble dans des instructions LIKE - vous obtenez quelque chose comme ceci:
WHERE `attribute` LIKE 'my' OR `attribute` LIKE 'search' OR `attribute` LIKE 'query'
Cette méthode peut fonctionner pour certaines configurations de magasin où les noms de produits sont simples et les clients recherchent des articles très spécifiques, mais selon mon expérience, ce n'est pas un bon choix.
Recherche basée sur la pertinence - chaque requête de recherche est notée selon un score attribué en fonction de la requête MATCH ... AGAINST de MySQL . Vous pouvez voir ceci en action à la Mage_CatalogSearch_Model_Resource_Helper_Mysql4
ligne 44:
public function chooseFulltext($table, $alias, $select)
{
$field = new Zend_Db_Expr('MATCH ('.$alias.'.data_index) AGAINST (:query IN BOOLEAN MODE)');
$select->columns(array('relevance' => $field));
return $field;
}
La table de base de données utilisée par Magento lors de recherches en texte intégral est catalogsearch_fulltext
. Un exemple de valeur:
EmCO0014e|Emma Certified|Emma Certified Organic Herbal Tonic Mist TRIAL/TRAVEL|Australian|Certified Organic|Palm Oil Free|Nut Free|Vegan Suitable|
Ces valeurs sont directement liées aux attributs spécifiés sous "Utiliser dans la recherche rapide" sous Catalogue> Attributs> Gérer les attributs.
Assez explicite. Jetez un coup d'œil à la ligne 354 de Mage_CatalogSearch_Model_Resource_Fulltext :
if ($likeCond != '' && $searchType == Mage_CatalogSearch_Model_Fulltext::SEARCH_TYPE_COMBINE) {
$where .= ($where ? ' OR ' : '') . $likeCond;
} elseif ($likeCond != '' && $searchType == Mage_CatalogSearch_Model_Fulltext::SEARCH_TYPE_LIKE) {
$select->columns(array('relevance' => new Zend_Db_Expr(0)));
$where = $likeCond;
}
Vous pouvez voir qu'il ajoute simplement les résultats LIKE après le retour des résultats FULLTEXT.
Vous pouvez contourner les points 5 et 6 en utilisant la méthode Combiner - les résultats LIKE doivent compenser les mots ignorés par FULLTEXT.
La recherche "like" fera la correspondance habituelle, en utilisant une requête similaire "% keyword%". L'un des avantages de ce type de recherche est qu'il va correspondre aux mots partiels. Il a cependant de sérieux inconvénients:
La recherche en texte intégral fonctionnera à l'aide de la recherche en texte intégral MyISAM ( http://dev.mysql.com/doc/refman/5.0/fr/fulltext-search.html ). Vous devriez lire à ce sujet, mais en quelques mots:
L'inconvénient du texte intégral est qu'il ne peut pas effectuer de correspondances partielles, c'est-à-dire qu'une recherche sur "pho" ne trouvera pas "téléphone"
La recherche "combinée" utilisera une condition "similaire" pour faire correspondre les résultats, mais prendra également en compte le score de recherche de texte intégral pour les trier. Cela signifie que vous obtiendrez plus de résultats (tout comme la recherche effectuera également des correspondances partielles) et qu'ils seront également mieux ordonnés en raison du score en texte intégral.
Comme d'autres personnes l'ont dit, si vous êtes sérieux au sujet de la recherche, vous devriez utiliser Solr. C'est beaucoup plus rapide et beaucoup plus pertinent. Cependant, vous devrez posséder Magento EE et installer Solr vous-même.
Ce sont des références directes au type de requête que Magento utilisera. Personnellement, je pense que la recherche en texte intégral est plus puissante et que les performances sont meilleures, en particulier si LIKE est utilisé avec des caractères génériques (%). Une combinaison des deux sera probablement la plus précise, mais pourrait être exagérée. Je m'en tiendrai au texte intégral.
Mais si vous recherchez une solution de recherche performante, consultez ce projet: https://code.google.com/p/magento-solr/ . SOLR a été conçu pour la recherche de grandes collections et sa mise en œuvre devrait prendre un certain temps, mais elle en vaut la peine. Personnellement, je ne l'avais jamais utilisé auparavant dans Magento, mais dans d'autres projets PHP, il fonctionnait très bien.
La documentation en texte intégral est disponible à l' adresse suivante : http://dev.mysql.com/doc/refman/5.0/fr/fulltext-search.html La documentation LIKE est disponible à l' adresse suivante : http://dev.mysql.com/doc/refman/5.0 /fr/string-comparison-functions.html
OR
en AND
?
Le problème avec LIKE est qu'il utilise "% term%" par défaut. Je l'ai changé pour correspondre à "terme%" (notez l'espace avant le terme), afin qu'il corresponde au début des mots. J'ai également découpé le terme 's' dans un terme de recherche afin que "cars" donne les mêmes résultats que "car". De toute évidence, cela n’aide en rien les noms irréguliers comme "enfants", mais c’est quand même une grande amélioration.
Le plus grand mouvement inexplicablement absurde de Magento consiste à utiliser la recherche "OU" au lieu de "ET". Si vous recherchez "voitures rouges", vous obtiendrez tout le rouge (y compris les voitures, les chiens, les fourches, les flancs de la montagne, etc.) et tous les types de voitures (y compris les rouges, les bleues, les vertes, les jaunes, etc.). Avec "ET", vous n’obtenez que les éléments qui contiennent "rouge" ET "voiture", c’est ainsi que la recherche devrait fonctionner!
Citant la réponse de jharrison.au, changez ceci:
if ($like) {
$likeCond = '(' . join(' OR ', $like) . ')';
}
Pour ça:
if ($like) {
$likeCond = '(' . join(' AND ', $like) . ')';
}
Pour obtenir un coup de pouce immédiat et massif pour la pertinence de vos résultats de recherche.
Au pluriel, vous pouvez découper le "s" final d'un mot comme celui-ci:
$words = Mage::helper('core/string')->splitWords($queryText, true, $query->getMaxQueryWords());
$words = array_walk($words,function(&$value, &$key) {
// use substr(...) instead of rtrim($value,'s')
// because rtrim will remove multiple esses
$value = (substr($value,-1,1) === 's') ? substr($value,0,strlen($value - 1)) : $value;
});
foreach ($words as $word) {
$like[] = $helper->getCILike('s.data_index', $word, array('position' => 'start')); // note I changed this to 'start'
}
Dans app/code/local/Mage/Core/Model/Resource/Helper/Abstract.php
vous pouvez remplacer le fichier de base et changer le public function escapeLikeValue($value, $options = array())
comme un raccourci rapide, bien que la façon conseillée est de faire la même chose dans un module. Mais le voici.
Sous if (isset($options['position'])) {
il y a un interrupteur. J'ai changé les cas pour 'début' et 'fin' pour ajouter des espaces avant et après la valeur:
case 'start':
$value = '% ' . $value . '%'; // added '% ' . before
// $value = $value . '%'; // core way (bad way)
break;
case 'end':
$value = '%' . $value . ' %'; // added . ' %' after
// $value = '%' . $value; // core way (bad way)
break;
Pour que les espaces avant / après fonctionnent, vous devez probablement aussi changer la façon dont l'index de recherche est construit, comme je l'ai fait, afin qu'il s'assure qu'il y a un espace avant et après chaque mot. Le moyen par défaut de construire l’index est de séparer chaque champ par un '|' (caractère de pipe), par exemple "blue | car | une très belle voiture" pour indexer la couleur, le type de produit, la description du produit. Mais mon index a "blue | car | une très belle voiture". Vous pouvez même modifier la construction de l'index de recherche de manière à remplacer les mots composés d'un trait d'union ("voiture ultra-rapide" devenant "voiture super rapide"), etc., etc.
Emprunter un exemple dans la réponse de jharrison.au, où un champ d'index de recherche par défaut ressemblerait à ceci:
EmCO0014e|Emma Certified|Emma Certified Organic Herbal Tonic Mist TRIAL/TRAVEL|Australian|Certified Organic|Palm Oil Free|Nut Free|Vegan Suitable|
Le mien ressemblerait à ceci:
EmCO0014e | Emma Certified | Emma Certified Organic Herbal Tonic Mist TRIAL / TRAVEL | Australian | Certified Organic | Palm Oil Free | Nut Free | Vegan Suitable |
(notez les espaces avant et après chaque "|" et "/", et un espace avant le tout premier mot)
app/code/local/Mage/Core/Model/Resource/Helper/Abstract.php
. Ce fichier n'est pas utilisé ailleurs que dans la fonctionnalité de recherche?
LIKE
aux requêtes de recherche SQL, et où Magento peut-il chercher ailleurs que dans l'index de recherche de produit? J'ai apporté ce changement il y a plus de 2 ans sur un site de production et nous n'avons trouvé aucun bogue lié à cela. Tout ce que cela fait réellement, c’est que le "début du mot" doit avoir un espace devant lui et que "la fin du mot" doit avoir un espace après. Séparément, dans l'index, je m'assure que chaque mot est entouré d'espaces.
Aucune de ces solutions, utilisez le moteur de recherche intégré Zend Lucene en installant quelque chose comme Blast Lucene Search ou Extendeware Lucene Search. La pertinence dépasse toutes les offres MySQL.
Oui, j'ai parcouru toutes les versions de la réponse acceptée, mais franchement, la recherche optimisée pour Magento Stock faisait toujours cruellement défaut.
Lucene, d’autre part, fournit et est déjà inclus dans l’installation de Magento, il lui faut juste un module pour l’activer.