Nantes JUG – 11/2016 – Démystifier ElasticSearch

Afficher l'image d'origine

Le 30 novembre 2016 s’est tenu le Nantes JUG à l’Epitech.

Le thème de cette édition était le moteur de recherche ElasticSearch, présenté par Maxime Odye, développeur back chez Zenika à Rennes. Cette présentation a été très intéressante et alternait discours et démonstrations.

Ce sujet m’intéressait particulièrement étant donné que j’ai eu l’occasion d’utiliser Apache Lucene, bibliothèque open-source JAVA sur laquelle se base ElasticSearch.

C’est d’ailleurs avec cette bibliothèque que Maxime a introduit sa présentation en posant les trois questions suivantes :

  • Qui connait Apache Lucene ?

  • Qui a déjà utilisé Apache Lucene ?

  • Qui a galéré en utilisant Apache Lucene ?

Il est vrai que Lucene est beaucoup critiqué comme étant assez complexe, chose que je peux confirmer de par mon expérience et ElasticSearch va justement masquer cette complexité à l’aide de services standards (HTTP, RESTful, JSON) tout en gardant la puissance de Lucene, sa capacité de traitements et  ses temps de réponse plus qu'acceptables.

ElasticSearch, Kezako ?

La présentation s’est donc poursuivit sur les premières choses à savoir sur ElasticSearch. Il s'agit d'un moteur de recherche composé d’un moteur d’indexation de documents et d’un moteur de recherche sur les index. Ce dernier est donc beaucoup plus performant qu’une base de données pour faire des recherches, et heureusement vu que c’est son rôle principal.

Il présente de nombreux avantages à la recherche SQL :

  • Une requête SQL va parcourir toutes les lignes jusqu’à avoir la réponse à la requête. (le like% a des performances très mauvaises comparé à une recherche par index).

  • Aucune tolérance aux fautes de frappe dans une requête SQL.

  • Recherche par mot-clefs et recherche fulltext très compliquée à mettre en place.

  • Avoir un résultat pertinent et positionner ce résultat selon sa pertinence est plus simple à réaliser avec un moteur de recherche.

ElasticSearch utilise une base de données NoSQL, codée au format JSON, les données sont donc rangées sous forme de documents de la même manière que MongoDB, il faut donc oublier le SGBDR.

Afficher l'image d'origine

Le moteur d’indexation

Maxime a donc poursuivi en nous présentant l’indexation, la classification des données. ElasticSearch propose pleins de moyens rapides et dynamiques permettant de rechercher des informations grâce à son moteur d’indexation.

Ce dernier va indexer automatiquement les données qu’on lui injecte et va les traiter en une seule fois en leur donnant de multiples liens et des catégories. Cela va permettre d’accélérer la recherche en évitant de parcourir l’ensemble des documents lors d’une recherche spécifique sur un terme.

Lorsqu’un document est injecté dans ElasticSearch, ce dernier sera analysé par un "analyzer". Maxime nous a donc présenté comment fonctionnait ce composant. Il comporte deux éléments : un tokenizer et un filter. Le tokenizer lui va découper l’élément du document en tokens, selon le type de tokenizer choisit par l’utilisateur. ElasticSearch propose une multitude de tokenizer différents dont la plupart étant issus d’Apache Lucene. Les deux plus basiques sont les suivants :

Whitespace tokenizer : il sépare les tokens à chaque espace rencontré.

Ce dernier n’est pas très pertinent lorsque l'on souhaite réaliser une recherche par mot-clefs étant donné qu’il indexe tous les mots d’une phrase dont les pronoms et adjectifs Pour éviter cela il existe d’autres tokenizer tels que :

Standard tokenizer : Ne prend pas en compte les éléments indésirables (pronoms, ponctuation) et mets l’ensemble des tokens en minuscules.

En plus des tokenizers, ElasticSearch propose également des filtres qui eux vont se charger de supprimer ou de transformer les tokens. On va donc les cumuler avec les tokenizers selon le besoin de l’utilisateur afin d’avoir une gestion des données optimale et adaptée aux besoins de son application.

Il existe également une multitude de filtres que propose ElasticSearch. La transformation des tokens en ascii, en termes phonétiques, ou bien des stemmers (ne garde que la racine du token. Exemple : "jumped" est filtré en "jump"). Bien sûr, pour ce genre de filtres il en faudra un qui soit associé à la bonne langue, il est possible d’avoir plusieurs stemmers qui racinisent chacun dans une langue précise.

L’analyse de données

En plus de l’indexation de données, Maxime nous a également présenté l’analyse des données par les agrégations. Ces dernières vont fournir des résultats sur la recherche effectuée sous forme de métriques (hits, score, …), que le développeur pourra traiter pour affiner sa recherche. Cela va donc pouvoir servir par exemple pour remplir des graphiques ou alimenter des modules de reporting, ce qui nous amène à la dernière chose qui nous a été présentée, Kibana. Cet outil est l’interface officielle d’ElasticSearch et est donc également open-source. Il permet de visualiser et de rechercher parmi les messages de logs et autres événements systèmes mais n’est pas du tout limité à ça. Il permet également de requêter et de visualiser n’importe quelle donnée contenue dans ElasticSearch. Kibana se présente sous l’interface suivante et propose également pleins de Dashboard différents.

Kibana

Sur cette image, on peut voir typiquement le genre de requête qui peut être envoyée au moteur de recherche ElasticSearch. GET pour effectuer une recherche ou POST pour injecter un document.

En conclusion

ElasticSearch représente une solution très efficace pour tout ce qui est recherche fulltext et indexation de par ses fonctionnalités d’agrégation et d’analyse. Cet outil se veut très user-friendly et s’adapte à tout type de projet quelle que soit la technologie utilisée.

Je n’ai pas vraiment pu effectuer de comparatif car je n’ai jamais utilisé d’autres outils identiques tels que SolR et donc impossible pour moi de dire s’il est plus performant qu’un autre.

Maxime a pu présenter pendant cette séance des résultats de performances avec l’outil gatling et ceux-ci sont très révélateurs et parfois plus ou moins bons selon les méthodes d’indexation utilisées et le type d’analyse réalisée sur les données. Il faut donc bien penser à utiliser les méthodes les plus pertinentes et les mieux adaptées au besoin de l'application et au type de recherche que l’on souhaite effectuer.

 

Enregistrer

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.