Elasticsearch maintenant en version 1.4

Partons à la découverte de ce moteur de recherche, et voyons comment il peut nous être utile

Elasticsearch, comme son nom pourrait l'indiquer, est un moteur d’indexation open source, et très certainement l'un des plus puissants qui existe aujourd'hui. Il y a quelques semaines, il est passé en version 1.4 et c'est l'occasion de vous présenter un peu cet outil, ses fonctionnalités, et à quel type de besoin il répond. Nous allons aussi dans cet article présenter ce qui se fait du côté de la concurrence afin d'avoir une vision plus ouverte du monde des moteurs de recherches.

Les principaux atouts

Moteur de recherche vs Moteur d'indexation

Si l'on vous demande de donner le nom de quelques moteurs de recherche, vous parlerez certainement de Google Search, Bing, DuckDuckGo, etc. Et vous aurez bien raison car un moteur de recherche est tout simplement une application (souvent web) qui permet de retrouver des liens, des images, des documents, etc. Bref, des ressources en rapport avec certains mot-clés.
Cependant, pour pouvoir donner des résultats pertinents, un moteur de recherche doit savoir à l'avance où sont les ressources qu'on pourrait lui demander. Pour le savoir, de nombreux moteurs de recherche ont des robots qui parcourent Internet à la recherche de nouvelles ressources. Ils se basent donc sur des moteurs d'indexation, dont le rôle est de collecter des ressources, et d'extraire des mot-clés les plus significatifs. Un moteur d'indexation n'est donc qu'un sous-ensemble du moteur de recherche.

Tandis que les géants du Web utilisent des moteurs d'indexation propriétaires, dans le monde de l'open source, Apache Lucene, une bibliothèque d'indexation full-text développée en Java s'est fait une grosse réputation, et est devenue aujourd'hui le standard sur lequel se basent les meilleurs moteurs d'indexation. C'est le cas d'Elasticsearch, lui aussi basé sur Apache Lucene, qui est aujourd'hui un des meilleurs moteurs d'indexation du marché.

Du côté technique

Sous le capot, Elasticsearch est développé en Java, et fonctionne donc sur toutes les plateformes qui disposent d'une JVM. Pour interagir nativement avec Elasticsearch, les interfaces disponibles sont l'API Java et le format JSON. Le moteur d'indexation a de quoi communiquer aisément avec un cluster Big Data grâce à son connecteur Hadoop disponible en téléchargement sur le site officiel. Le moteur sait aussi se connecter aux bases de données relationnelles et NoSQL.

Des fonctionnalités inédites

La réplication des données

Dans un cluster[cluster] Elasticsearch, lorsque vous avez plusieurs nœuds[noeud], les données stockées sur ces derniers sont répliquées entre eux. Ceci permet entre autres de conserver l'intégralité des données en cas de perte d'un nœud.

Un cluster Elasticsearch avec 4 nœuds, 5 shards et 2 répliquas, depuis le plugin Head

La réplication est faite de manière automatique. Rajouter un nœud ou un shard[^shard] déclenche la réplication automatique.

La recherche en temps réel et contextuelle

La recherche dans Elasticsearch est l'une des plus performantes du marché. On parle de recherche distribuée. Quand on lance une recherche sur le nœud principal, ce dernier va renvoyer la recherche sur les autres nœuds et les résultats seront renvoyés au demandeur.

L'une des particularités du moteur est qu'il regroupe les éléments indexés en rapprochant selon le contexte de la donnée. Les documents en français par exemple seront regroupés ensemble, pour faire plus vite les rapprochements.

Les facettes

Elasticsearch supporte les facettes, qui sont des regroupements de résultats de recherche. Ce qui permet aux utilisateurs d'avoir une vue agrégée de leurs données. Il existe plusieurs types de facettes disponibles dans Elasticsearch, parmi lesquelles :

  • Filter : renvoie le nombre de hits correspondant à un filtre.
  • Geo distance : regroupe les données par intervalle de distance géographique.
  • Query : renvoie le nombre de hits correspondant à une requête.
  • Terms : renvoie les termes les plus fréquents.
  • Statistical : permet de calculer les données de type somme, minimum, moyenne, maximum, variance, etc. sur des données de type numériques.

Une forte communauté

L'un des atouts majeurs du projet ElasticSearch est sa communauté. Ce qui participe à obtenir un écosystème plutôt intéressant. Bien qu'il y ait moins de 5 vrais contributeurs sur le dépôt officiel, nombreux sont ceux à proposer tout un tas de plugins différents pour connecter le moteur d'indexation avec les outils du marché et exploiter au maximum le moteur. C'est ainsi qu'on retrouve des pointures telles que :

  • Logstash : un outil qui permet de centraliser et d'analyser les logs des applications.
  • Kibana : qui vous permet de visualiser vos logs de manière user-friendly.
  • Marvel : un outil de supervision pour votre cluster.

Interface Marvel

À côté de ça, la communauté met à disposition des connecteurs qui permettent d’interagir avec de nombreuses API (Amazon, Azure, Google Twitter, RabbitMQ, MongoDB, Wikipédia, etc.) ainsi qu'avec les langages Groovy, Python, JavaScript, SQL, etc.

Pour ceux qui habitent en France, la communauté Elasticsearch organise très souvent des meetups sur Paris. C'est un des meilleurs moyens de vous tenir informé et de rencontrer les utilisateurs d'Elasticsearch.

Les apports de la version 1.4

L'équipe de développement d'Elasticsearch est très active. Les nouveautés apportées dans la version 1.4 visent essentiellement :

  • La stabilité : la découverte des machines du cluster sur le réseau en Multicast a été améliorée.
  • La consommation mémoire : l'utilisation de la mémoire a été revue et réduite au strict minimum lors d'une requête.
  • Les performances.

Des bugs ont aussi été corrigés, dont quelques bugs plutôt contraignants. On avait par exemple le bug qui empêchait de faire une sauvegarde à chaud d'un index en plein chargement.

Pour en savoir plus, je vous invite à lire la note de release.

Les reproches qui reviennent le plus

Manque de sécurité

La principale critique que l'on adresse à Elasticsearch est son manque de sécurité (on a le même reproche aussi chez la concurrence). En effet, lorsque vous installez Elasticsearch sur un réseau ouvert, si vous ne mettez pas en place un pare-feu, il sera accessible par tout le monde sur le réseau. Là où ça devient dangereux, c'est qu'étant donné qu'il est essentiellement REST, un simple appel à l'API permet de créer ou supprimer des index, sans possibilité de savoir qui a réalisé l'action, car il n'y a aucun processus d'authentification à l'API.

Un simple curl -XDELETE http://localhost:9200/monindex peut réduire à néant les travaux d'indexation de plusieurs jours.

Pour pallier ce genre de problème, certaines solutions existent mais ne sont pas toujours satisfaisantes.

  • Limiter les accès sur le port 9200 (Http) et 9300 (Transport) aux machines qui ont réellement besoin de se connecter à l'API. Ce qui limite grandement les possibilités de travail.
  • Le plugin Jetty, qui permet de limiter les accès en Http (port 9200), mais il reste possible d'attaquer votre cluster via le port 9300.

Cependant, lors de la présentation à Paris de cette dernière mouture, l'équipe Elasticsearch a annoncé travailler sur un outil dédié à la sécurité du moteur d'indexation, du nom de Shield. Il n'est pas encore disponible, mais les fonctionnalités à venir sont alléchantes.

La stabilité

La stabilité du cluster est aussi l'un des points critiqués d'Elasticsearch. Les bonnes pratiques de mise en place d'un cluster ne sont pas toujours très claires, et il n'est pas rare d'observer une séparation d'un cluster lors d'un problème réseau.

La stabilité est aussi un des points sur lesquels se sont penchés les développeurs dans la version 1.4.

Les principaux concurrents

Solr

Solr, est à quelque choses près, identique au moteur Elasticsearch. Basé lui aussi sur Lucene, Solr est également un moteur open source développé en Java. Les fonctionnalités d'Elasticsearch sont similaires à celles de Solr. Ils souffrent tous les deux du même problème de sécurité.

Depuis la levée de fonds de l'entreprise Elasticsearch, on remarque une nette augmentation des contributions au code du projet Elasticsearch, et une diminution de l'activité du côté de Solr. Elasticsearch a certainement un écosystème plus important que celui de Solr.

Quoi qu'il en soit, Solr est clairement le plus gros concurrent d'Elasticsearch aujourd'hui sur tous les terrains. Pour information, Zeste de Savoir utilise le moteur de recherche Solr.

Xapian

Xapian est un moteur de recherche open source lui aussi. Mais contrairement aux autres, il est écrit en C++. Il y a tout de même un ensemble de bindgins pour Python, Ruby, Java, PHP et Perl.

Xapian, n'est pas aussi performant et scalable que Elasticsearch ou Solr, et ne dispose pas des fonctionnalités avancées telles que la vue par facette. Il a tout de même l'avantage d'être assez flexible et il sait indexer autant du contenu Web que du contenu sur le disque dur.

Aller plus loin ?

  1. Un cluster Elasticsearch est un ensemble de nœud. ↩

  2. Un nœud au sens Elasticsearch est une instance du service. ↩

  3. Un index Elasticsearch peut stocker une grande quantité de données. Lorsque l'index est trop gros, les recherches se verront ralenties. Elasticsearch permet de diviser un index en plusieurs morceaux appelés shard. Un shard est une instance Lucene qui permet de stocker un document. Par défaut, un index Elasticsearch a cinq shard. ↩

27 commentaires

Introduction très intéressante à ce projet en utilisant le pretexte d'une nouvelle version. C'est une bonne idée et ça m'a permit de découvrir deux trois truc intéressant sur des produit que je n'utilise jamais.

Pourquoi Zeste utilise-t-il Solr et pas Elasticsearch ? Quelles sont les différences entre les deux, qui ont amené au choix de Solr ?

De mémoire c'était un choix pragmatique : celui qui est devenu notre DTC avait une expérience significatif d'installation, configuration et maintenance de Solr. Personne n'a alors proposé de solutions alternatives.

+0 -0

Pourquoi Zeste utilise-t-il Solr et pas Elasticsearch ? Quelles sont les différences entre les deux, qui ont amené au choix de Solr ?

Thunderseb

En fait, la réponse à cette question est assez simple. Le développement de ZdS a commencé il y'a plus d'un an maintenant. Il est très important de noter que Elasticsearch est passé en version stable 1.0 le 12 février 2014, c'est à dire plus de 3 mois après le premier commit sur le dépot de ZdS. Ayant suivi le projet, il a fallu attendre la version 1.2 d'Elasticsearch (sortie en Mai 2014) pour avoir un truc vraiment stable et production ready. Autant dire que c'était le moment ou ZdS se préparait à lancer une bêta privée et que Solr marchait bien.

Il faut aussi noter le fait que Elasticsearch est géré derrière par une entreprise, alors que de son coté, Solr a fusionné avec Apache Lucene. Donc, dans le doute de la vision de l'entreprise, je pense que ZdS a fait le bon choix. Ceci dit, je crois qu'avec l'arrivée de la 2.0, ça vaudra le coup de tenter une migration de Solr vers ES.

De mémoire c'est bien ça : j'avais dit que je savais utiliser Solr, Solr était déjà utilisé sur Progdupeupl (d'où vient notre code), et on a jamais cherché plus loin.

SpaceFox

En fait non, Progdupeu.pl utilise Whoosh, qui est un moteur plutôt bas de gamme dans ce monde, mais il a l'avantage d'être developpé en python et donc plus maléable en django.

+0 -0

Très bon article, merci.

Je ne peux qu'appuyer les dires de firm1 quant à la pile elasticsearch-logstash-kibana que j'utilise au quotidien.

C'est réellement très efficace pour analyser des flux requêtes, suivre un utilisateur au cours de son parcours, détecter des appels suspects, voire retracer une suite d'événements qui ont pu conduire à un bug.

+1 -0

Ceci dit, je crois qu'avec l'arrivée de la 2.0, ça vaudra le coup de tenter une migration de Solr vers ES.

Question : que nous apporterait ES maintenant qu'on a déjà Solr en place ? Tant qu'il n'y a pas d'avantages significatif à ES en comparaison à ES, et tant que Solr est maintenu, pourquoi devrions nous faire une migration qui apportera forcément son lot de bug ?

+2 -0

Un article très intéressant à lire (et à valider) :)

Edit :

Question : que nous apporterait ES maintenant qu'on a déjà Solr en place ? Tant qu'il n'y a pas d'avantages significatif à ES en comparaison à ES, et tant que Solr est maintenu, pourquoi devrions nous faire une migration qui apportera forcément son lot de bug ?

Même question pour ma part.

+1 -0

Ceci dit, je crois qu'avec l'arrivée de la 2.0, ça vaudra le coup de tenter une migration de Solr vers ES.

Question : que nous apporterait ES maintenant qu'on a déjà Solr en place ? Tant qu'il n'y a pas d'avantages significatif à ES en comparaison à ES, et tant que Solr est maintenu, pourquoi devrions nous faire une migration qui apportera forcément son lot de bug ?

Kje

Pour faire une réponse simple, je dirais que le plus gros avantage d'Elasticsearch aujourd'hui dont pourrai profiter ZdS sont :

  • Les connecteurs python pour ES
  • Les possibilités de Text Mining

Pour l'utilisateur final, ça reviendrait à avoir une barre de recherche (comme il en existe sur la home de ZdS en ce moment) avec des résultats un peu plus pertinents en auto complétion. Et une recherche avancée presqu'aussi pertinente que ce qui se fait sur Google Search.

+0 -0

Je reste peu persuadé que l'effort en vaille le coup vu qu'on utilise déjà même pas toutes les possibilités de solr, personne ne faisant l'effort de développer cette partie du code. Je ne suis pas persuadé que remplacer le moteur d'indexation changera ça et donc apportera quoique ce soit. Mais bon de toute façon je pense qu'une telle migration n'est pas prioritaire et méritera débat (tu propose de toute façon d'attendre la sortie de la version 2)

+1 -0

Ca peut paraitre un peu bête mais : Vous trouvez les résultats de Solr satisfaisant vous ? Perso, je déteste l'utiliser.

Pour l'utiliser au boulot : Solr peut sortir des résultats très pertinents, mais ça nécessite un effort de modélisation et d'ajustement que tout le monde n'est pas prêt à faire.

Cela dit, je ne vois pas trop par quel miracle Easticsearch pourrait être plus magique de ce point de vue.

+0 -0

Je reste peu persuadé que l'effort en vaille le coup vu qu'on utilise déjà même pas toutes les possibilités de solr, personne ne faisant l'effort de développer cette partie du code. Je ne suis pas persuadé que remplacer le moteur d'indexation changera ça et donc apportera quoique ce soit.

Kje

En fait pour ZdS l'effort de migration (a fonctionnalité équivalente) est presque nulle. ZdS n'attaque Solr que via une lib (HayStack) qui supporte pas mal de moteurs d'indexations. Donc pour migrer, il suffit (et théorie et en pratique) d'installer ES sur le serveur et de modifier une ligne dans nos settings de déploiements.

C'est là raison pour laquelle (comme le dis Andr0 ci-dessus), les résultats ne sont pas satisfaisant. Avec ES, on attaquerait le moteur directement pour exploiter tout son potentiel.

+0 -0

C'est là raison pour laquelle (comme le dis Andr0 ci-dessus), les résultats ne sont pas satisfaisant. Avec ES, on attaquerait le moteur directement pour exploiter tout son potentiel.

Je veux bien que tu détailles là. Haystack nous empêche de faire les réglages de pertinences, ou bien tout simplement on a jamais pris la peine de les faire ?

+1 -0

Je suis assez d'accord avec SF sur le coup. Je ne dis pas que notre moteur est satisfesant actuellement mais j'ai encore jamais vu personne tenté de les améliorer. Donc je ne suis pas convaincu que solr soit la cause.

Quelque soit la façon dont tu l'attaque, si ça reste configuré et utilisé comme actuellement, ça ne changera rien.

+0 -0

C'est là raison pour laquelle (comme le dis Andr0 ci-dessus), les résultats ne sont pas satisfaisant. Avec ES, on attaquerait le moteur directement pour exploiter tout son potentiel.

Je veux bien que tu détailles là. Haystack nous empêche de faire les réglages de pertinences, ou bien tout simplement on a jamais pris la peine de les faire ?

SpaceFox

Il nous empêche de faire des réglages de pertinence. c'est un peu une boite noire. Le jour ou l'on voudras développer cette ZEP par exemple, il va falloir faire certains appels en direct au moteur, et je pense que celui qui s'en occupera comprendra mieux de quoi il en retourne.

+0 -0

Je me pose un peu la question du moteur d'indexation en ce moment.

J'ai toujours utilisé HibernateSearch (donc en annotant directement le modèle pour dire à Lucène "ça tu me l'indexes stp". Et ça a toujours fonctionné sans aucun soucis, et sans besoin de Solr ou ElasticSearch.

Je me demandais quel était le bénéfice d'ElasticSearch ou Solr dans le cas où l'on possède un modèle qui est déjà persisté dans une base relationnelle, avec Hibernate.

J'arrive pas à trouver :\ et je pense que je rate un truc.

+0 -0

Il y a encore un truc que je ne comprend pas :

Donc pour migrer, il suffit (et théorie et en pratique) d'installer ES sur le serveur et de modifier une ligne dans nos settings de déploiements.

C'est là raison pour laquelle (comme le dis Andr0 ci-dessus), les résultats ne sont pas satisfaisant. Avec ES, on attaquerait le moteur directement pour exploiter tout son potentiel.

Dans le premier cas tu parle d'une migration transparente avec la lib qu'on utilise. Ok mais du coup on se retrouvera limité de la même façon qu'avec Solr. Dans le deuxième paragraphe tu parle d'attaquer directement ES. Déjà ça demande un developpement spécifique. Est ce qu'on ne peut pas faire le même genre de developpement, vers une autre lib, pour solr et l'attaquer directement ?

+0 -0

Il nous empêche de faire des réglages de pertinence. c'est un peu une boite noire. Le jour ou l'on voudras développer cette ZEP par exemple, il va falloir faire certains appels en direct au moteur, et je pense que celui qui s'en occupera comprendra mieux de quoi il en retourne.

firm1

Même pas sûr pour la ZEP.

Cela dit, ce qu'on est en train de dire, c'est que le problème est dans Haystack, pas dans Solr. Solr, ça comprends le REST (résultats en Json, XML, objets Java et peut-être encore autre chose), donc on pourrait tout à fait s'amuser à l'attaquer directement – même si c'est clairement plus compliqué – au besoin.

+0 -0

donc on pourrait tout à fait s'amuser à l'attaquer directement – même si c'est clairement plus compliqué – au besoin.

C'est pas ce que permet pySolr justement ? Qu'on a déjà en dépendance il me semble ?

Firm1, ou l'art de toujours présenter les infos tronqué avec des arguments de mauvaise fois quand il a décidé de pousser quelque chose… ;)

+2 -0

L'idée n'est pas de pousser telle ou telle techno sur ZdS. Si c'était le cas, j'aurai fais un topic en bonne et due forme, sur le sujet. Là la question s'est posée, j'ai juste donné mon avis (je ne pensais pas que ça bousculerait autant les foule :D ).

On peut ouvrir un topic sur le sujet pour en parler si vous le souhaitez.

+0 -1
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte