Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×

Les moteurs de recherche pour Drupal

Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Nächste SlideShare
Présentation de Drupal
Présentation de Drupal
Wird geladen in …3
×

Hier ansehen

1 von 45 Anzeige

Les moteurs de recherche pour Drupal

Herunterladen, um offline zu lesen

Découvrez comment les moteurs Open Source (et autres) peuvent apporter des réponses efficaces dans des contextes de Big Data, de données non structurées et de besoins sémantiques.

Découvrez comment les moteurs Open Source (et autres) peuvent apporter des réponses efficaces dans des contextes de Big Data, de données non structurées et de besoins sémantiques.

Anzeige
Anzeige

Weitere Verwandte Inhalte

Diashows für Sie (20)

Andere mochten auch (20)

Anzeige

Ähnlich wie Les moteurs de recherche pour Drupal (20)

Weitere von Core-Techs (20)

Anzeige

Aktuellste (20)

Les moteurs de recherche pour Drupal

  1. 1. Le meilleur moteur de recherche pour Drupal CORE-TECHSPar
  2. 2. OBESITE DE L’INFORMATION
  3. 3. Visuel Big Data BIG DATA
  4. 4. HETEROGENEÏTE DES SOLUTIONS
  5. 5. UN MOTEUR CA FAIT QUOI ?
  6. 6. Indexe Restitue Expose
  7. 7. 1. Le moteur basique de Drupal… 8/12CORE-TECHS
  8. 8. PERFORMANCES !
  9. 9. PERTINENCE !
  10. 10. EVOLUTIVITE !
  11. 11. 2. SolR : le moteur historique 14/12 CORE-TECHS
  12. 12. 16/12 CORE-TECHS Vidéo Témoignage pourquoi SolR
  13. 13. Optimisations de pertinence avec SOLR 17/12 CORE-TECHS Optimisations linguistiques • Racinisation • Synonymie • Stop words • Orthographe Optimisations statistiques • Scoring et pondération • Text mining • Proximité
  14. 14. Suggestions d’après le corpus 18/12 CORE-TECHS
  15. 15. Highlight des résultats 19/12 CORE-TECHS
  16. 16. Moteur de recommandation 20/12 CORE-TECHS
  17. 17. Recherche géospatiale 21/12 CORE-TECHS
  18. 18. Multisite 22/12 CORE-TECHS
  19. 19. 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
  20. 20. Multilinguisme 24/12 CORE-TECHS
  21. 21. 3. Elastic : la solution qui monte ! 25/12 CORE-TECHS
  22. 22. Video témoignage pourquoi Elastic 26/12 CORE-TECHS
  23. 23. Drupal avec Elastic 27/12 CORE-TECHS
  24. 24. Schéma évolutif et scalable 28/12 CORE-TECHS
  25. 25. Clustering natif et simplement paramétrable 29/12 CORE-TECHS
  26. 26. Implémentation simplifiée 30/12 CORE-TECHS
  27. 27. Paramétrage du scoring 31/12 CORE-TECHS
  28. 28. Gestion plus efficace des 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 • …
  29. 29. Des performances assez comparables 33/12 CORE-TECHS
  30. 30. Des performances assez comparables 34/12 CORE-TECHS Temps de recherche http://www.flax.co.uk/
  31. 31. Des performances assez comparables 35/12 CORE-TECHS Requêtes par seconde http://www.flax.co.uk/
  32. 32. Battle result 36/12 CORE-TECHS SolR • Esprit OS ++ • Orienté vers la recherche texte Elastic • Simplicité, efficacité • Efficacité dans l’analyse quantitative
  33. 33. 4. Et les moteurs propriétaires ? 37/12 CORE-TECHS
  34. 34. Vidéo témoignage – Pourquoi un moteur propriétaire 38/12 CORE-TECHS
  35. 35. 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,
  36. 36. Des réponses au Web 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 • …
  37. 37. MERCI 45 tw itt er : @ drupagora

Hinweis der Redaktion

  • Obésite de l’information
  • 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, …
  • 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
  • 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,
  • 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,
  • 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
  • Performances ! Temps de réponse et temps d’indexation. Serveur en local sur le même serveur que la DB
  • 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
  • Usage transverse : cross-content, suggestions, recommandations
    Extensibilité !
    Personnalisation
  • 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
  • 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
  • More like this
    See more like this
  • More like this
    See more like this
  • 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
  • Schema évolutif et scalable (non redémarrage serveur à chaque fois). Les index sont définis à la volée
  • 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
  • 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

  • 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)
  • More like this
    See more like this
  • 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.
  • 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.
  • 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.
  •  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
  • Il vous faut mettre les mains dans le cambouis
    Conseils et optimisation en search
  • 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


  • Les back-office sont minimalistes

×