Télécharger pour lire hors ligne
Téléchargé parCore-Techs
Les moteurs de recherche pour Drupal
Le document présente divers moteurs de recherche compatibles avec Drupal, notamment le moteur de recherche de base, Solr et Elastic, en mettant en avant leurs performances, pertinence et évolutivité. Des optimisations linguistiques et statistiques sont également discutées pour améliorer la recherche, ainsi que des options spécifiques offertes par des moteurs propriétaires pour des besoins particuliers. Enfin, il aborde les capacités de recherche géospatiale et le multilinguisme, soulignant les avantages de chaque solution.
![[ Pycon Korea 2017 ] Infrastructure as Code를위한 Ansible 활용](https://cdn.slidesharecdn.com/ss_thumbnails/pycon2017iacansible-170811160817-thumbnail.jpg?width=640&height=640&fit=bounds)
Les moteurs de recherche pour Drupal
- 1. Le meilleur moteur derecherche pour Drupal CORE-TECHSPar
- 2.
- 3.
- 4.
- 6. UN MOTEUR CAFAIT QUOI ?
- 7.
- 8. 1. Le moteurbasique de Drupal… 8/12CORE-TECHS
- 11.
- 12.
- 13.
- 14. 2. SolR :le moteur historique 14/12 CORE-TECHS
- 16.
- 17. Optimisations de pertinenceavec SOLR 17/12 CORE-TECHS Optimisations linguistiques • Racinisation • Synonymie • Stop words • Orthographe Optimisations statistiques • Scoring et pondération • Text mining • Proximité
- 18. Suggestions d’après lecorpus 18/12 CORE-TECHS
- 19.
- 20.
- 21.
- 22.
- 23. Variabilité des facettes 23/12 CORE-TECHS •Facettes de valeurs • Facettes de date • Facette par arbre / pivot • Facette par intervalle • Facette par catégorie / type
- 24.
- 25. 3. Elastic :la solution qui monte ! 25/12 CORE-TECHS
- 26. Video témoignage pourquoiElastic 26/12 CORE-TECHS
- 27.
- 28. Schéma évolutif etscalable 28/12 CORE-TECHS
- 29. Clustering natif etsimplement paramétrable 29/12 CORE-TECHS
- 30.
- 31.
- 32. Gestion plus efficacedes aggregations 32/12 CORE-TECHS • Facettes par distance géographique • Facettes métriques multiples : moyennes, maximum, sommes, … • Agrégation de filtres • Facettes de données manquantes • Facettes imbriquées • Facettes par agrégation de termes signifiants • …
- 33. Des performances assezcomparables 33/12 CORE-TECHS
- 34. Des performances assezcomparables 34/12 CORE-TECHS Temps de recherche http://www.flax.co.uk/
- 35. Des performances assezcomparables 35/12 CORE-TECHS Requêtes par seconde http://www.flax.co.uk/
- 36. Battle result 36/12 CORE-TECHS SolR • EspritOS ++ • Orienté vers la recherche texte Elastic • Simplicité, efficacité • Efficacité dans l’analyse quantitative
- 37. 4. Et lesmoteurs propriétaires ? 37/12 CORE-TECHS
- 38. Vidéo témoignage –Pourquoi un moteur propriétaire 38/12 CORE-TECHS
- 43. Des réponses fonctionnellesà des besoins particuliers 43/12 CORE-TECHS • Mises en avant, • Cross-content, • Combinaison d’expressions, • Gestion de campagnes promotionnelles, • Alertes et agents de veille • Réponses spécifiques pour des besoins d’ecommerce, (ou autre) • Outils de sauvegarde & restauration,
- 44. Des réponses auWeb sémantique 44/12 CORE-TECHS • Outils de travail pour aligner les données • Structuration RDF & URI • Sparql End Point • Intégration de thésaurus et d’ontologies • …
- 45. MERCI 45 tw itt er: @ drupagora
Notes de l'éditeur
- #3 Obésite de l’information
- #5 Hétérogénéïté technique : bases de données, fichiers, noSQL, RDF, .csv, document, …. Hétérogénéïté de structure : gabarits, documents non structurés, thésaurus, taxonomie, …
- #6 Le moteur est censé donner du sens : au contenu produit, aux dépendances entre les contenus, réduire le bruit, donner de la pertinence à une recherche, … Dans un contexte Drupal, avec des sites toujours plus complexe, complets, fragmentés, multi-sites, mulitlingues, multi-droits, … Trouver la bonne information pour chaque logique de chaque utilisateur devient une gageure
- #8 Un moteur, ça indexe : contenus web, documents, bases de données, fichiers, données structurées, non structurées. En indexant, ça traite : alignement, structuration, pondération, scoring, matching, enrichissement, …. Ca restitue : des résultats d’après des correspondances sémantiques, linguistiques, statistiques, mathématiques, ca propose des alternatives, suggestions, ca analyse une requête, … Ca expose : pour les autres, pour venir constituer le web des données,
- #10 Les éléments basiques du module cœur sont : Un bloc pour afficher le champ de recherche Une recherche avancée pour gérer les opérateurs boléen et les types de contenu sur lesquels on recherche - scoring factor basique Vous pouvez augmenter les fonctionnalités avec d’autres modules, tels que custom search, où vous pouvez : on peut faire qqles opérations de style (modifier les boutons, créer d’autres blocs de recherche, proposer des filtres sur des logiques de taxonomie, ajouter des libellés, ajouter des filtres sur les pages, afficher des métadonnées dans les résultats, ….), vous pouvez gérer les droits d’utilisation,
- #11 Vous pouvez aller plus loin avec Search API, search API Database search, Facette API, Views et Entity et gérer des facettes Types de contenu indexés, batch de cron, champs indexés, boost level, type d’inxation (string ou full text) Sauvegarde de recherches Autocomplétion Optimisation des facettes Recherches Ajax …. À compléter
- #12 Performances ! Temps de réponse et temps d’indexation. Serveur en local sur le même serveur que la DB
- #13 Pas d’indexation full text Pertinence ! Pas d’indexation plein texte, opérateurs logiques limités, pas de lemmatisation, pas d’analyse lexicale, pas d’analyse statistique
- #14 Usage transverse : cross-content, suggestions, recommandations Extensibilité ! Personnalisation
- #21 More like this See more like this (depuis la version 5 sur SolR) on donne les champs sur lesquels on veut le more like this
- #22 More like this See more like this (depuis la version 5 sur SolR) on donne les champs sur lesquels on veut le more like this
- #23 More like this See more like this
- #24 More like this See more like this
- #25 Dès qu’on veut sortir du cadre, ça commence à devenir compliqué : paramétrages XML, indexation multi-source, optimisation de la pertinence, … Il faut être un expert SolR Mais bcp de possibilités avec les modules de la communauté Interface de gestion limitée Mais depuis la version 5, SolR est encapsulé, plus besoin d’installer un tomcat
- #29 Schema évolutif et scalable (non redémarrage serveur à chaque fois). Les index sont définis à la volée
- #30 Clustering natif et simplement paramétrable Tolérance de panne de ouf : gère à chaud la répartition des shards en fonction de l’état du cluster
- #31 Courbe d’apprentissage rapide Déploiement et administration simple Fonctionnalité techniques ++ (configuration simplifiée, optimisation du boost, …) Intégration des outils Kibana et Logstash Système de plugins avancés : analyseurs de langues, rivières, Développement et intégration de plugins + simples (ex : dév d’un plugin pour récupérer en live les stats + facile sur Elastic Meilleure documentation que SolR
- #32 Scoring différent pour Elastic : algorithme de scoring personnalisable (intéressant dans un contexte e-commerce / scoring paramétrable. Par exemple : je veux d’abord remonter les articles qui ont moins de stock ou pour lesquels j’ai + de marge)
- #33 More like this See more like this
- #34 Performance-wise, they are roughly the same. I say “roughly”, because nobody has ever done comprehensive and non-biased benchmarks. For 95% of use cases either choice will be just fine in terms of performance, and the remaining 5% need to test both solutions with their particular data and their particular access patterns.
- #35 Performance-wise, they are roughly the same. I say “roughly”, because nobody has ever done comprehensive and non-biased benchmarks. For 95% of use cases either choice will be just fine in terms of performance, and the remaining 5% need to test both solutions with their particular data and their particular access patterns.
- #36 Performance-wise, they are roughly the same. I say “roughly”, because nobody has ever done comprehensive and non-biased benchmarks. For 95% of use cases either choice will be just fine in terms of performance, and the remaining 5% need to test both solutions with their particular data and their particular access patterns.
- #37 but only employees of Elasticsearch can actually make changes to Elasticsearch. In Solr world the community has a bit more say even though at the end of the day it’s one of the Solr developers who has to accept and handle the contribution
- #40 Il vous faut mettre les mains dans le cambouis Conseils et optimisation en search
- #41 Les back-office sont minimalistes Suivi statistique avancé : gestion des indexations et des agents de recherche, suivi en temps réel des requêtes Outils de sauvegarde & restauration
- #42 Les back-office sont minimalistes