Shay Banon (@kimchy) a accepté de répondre à quelques questions sur ElasticSearch, l’un des sujets qu’il présente à la conférence « What’s Next » fin mai. Shay est l’ancien CTO de GigaSpace, qu’il a quitté pour fonder ElasticSearch en février 2010. C’est un passionné et l’auteur d’un blog très pointu sur la recherche et l’indexation de données dans le cloud.
Nicolas: Merci Shay d’avoir pris le temps de répondre à mes questions. Pour commencer, un petit défi. Comment expliqueriez-vous, comment décrire ElasticSearch et votre travail actuel à quelqu’un qui n’est pas un Geek ? Imaginons que vous deviez expliquer votre travail à votre meilleur ami ou à votre voisin de palier…
Shay: ElasticSearch vise à offrir des fonctionnalités avancées de recherche à n’importe quelle application ou site web, le tout très facilement, avec la possibilité de monter en charge sur de gros volumes de données. Lorsque tu construis une application web, ou n’importe quelle application importante, la connaissance de ce sur quoi tu peux chercher, de l’importance relative de tes résultats et son intégration dans ton application est très spécifique. L’idée d’ElasticSearch est d’offrir une solution de recherche à usage général, qui peut évoluer d’une seule machine à plusieurs centaines. Pour cela, il s’agit de créer des méta-données au format JSON, qui sont ensuite stockées et indexées dans le cloud ElasticSearch.
N: Sur la partie requêtage des données, quel système d’aide à la recherche offre ElasticSearch ? Par exemple, est-ce que je peux lancer une recherche sur un livre de Science-Fiction publié en 2010 ?
S: Oui, la recherche de base effectue une recherche sur le texte; le résultat est ensuite classé et pondéré, afin d’afficher en premier les résultats les plus pertinents. En fait, en s’appuyant sur la puissance de Lucene, qui est le moteur interne d’ElasticSearch, il est possible de trier et filtrer très facilement les résultats. Encore mieux, on peut utiliser facilement des requêtes type ‘fuzzy search’ (recherche par approximation) ou ‘more like this’ afin d’affiner sa recherche.
N: Concernant l’indexation des données voyons si j’ai bien compris. J’indexe mes données en créant des structures JSON, que je POST ensuite vers mon nuage de serveur ElasticSearch, le tout via une API REST. Mais comment dans ce cas effectuer la maintenance et la mise à jour de mon index de données ?
S: En général la mise à jour de l’index est très simple. ElasticSearch a une API simple à utiliser. Tout ce que vous devez faire est en effet de représenter les données que vous souhaitez indexer au format JSON, puis à les envoyer vers ElasticSearch. C’est très facile du point de vue client. JSON est une API orientée WEB très populaire, quelque soit le langage. Il est en général assez facile de convertir les objets de son domaine vers une structure au format JSON.
Il y a un effort pour essayer de simplifier ce processus, en utilisant ce que l’on appelle les « Rivers » dans ElasticSearch. L’idée de ces rivières est qu’il s’agit d’entités qui fonctionnent dans le cluster ElasticSearch. Elles sont responsables de la réception des changements. Par exemple, la river CouchDB peut se brancher sur les changements dans un domaine CouchDB pour ensuite automatiquement effectuer la mise à jour des indexes. N’importe quel changement dans CouchDB est alors mirroré quelques instants plus tard.
N: Sur le site d’ElasticSearch, l’une des fonctions qui m’a interpellé s’appelle TimeMachine. A quoi cela sert-il ? Peux-tu m’en dire plus ?
S: Oui. Lorsque l’on travaille sur des systèmes de données distribuées, l’une des plus grandes questions est comment peut-on stocker les données de persistance à long terme, afin de survivre à un crash d’un noeud ou à l’arrêt du cluster. Par défaut, ElasticSearch est en mesure de recréer l’ensemble de l’état du cluster ainsi que l’ensemble des indexes de chaque noeud (dans le cluster) grâce à un état local stocké sur le système de fichier.
Une autre option consiste à stocker les données dans un stockage partagé. ElasticSearch peut persister l’état du cluster dans un espace partagé comme Amazon S3, et peut donc récupérer ceci en cas de besoin. Ce processus est hautement optimisé et ne persiste que les modifications effectuées sur l’index. De plus, tout ceci est fait de façon asynchrone afin de ne pas interférer avec les opérations d’indexation classiques.
N: Est-il possible de naviguer dans l’historique ?
S: Non, c’est un système de journalisation qui permet de garantir que les données sont « reliables ».
N: Peux-tu en dire un peu plus concernant la partie serveur et réseau ? Quelle stack réseau utilises-tu ?
S: Oui bien sûr. Nous utilisons JBoss Netty comme librairie réseau. C’est un moteur complétement construit et pensé autour de la gestion d’entrées/sorties non bloquantes. Cela signifie par exemple, que lorsque tu fais une recherche distribuée sur plusieurs noeuds, il n’y a pas de Threads bloquées en attente de réponse.
(Note de Nicolas : Play! Framework utilise aussi JBoss Netty depuis la version 1.1)
N: est-ce qu’ElasticSearch supporte aussi d’un point de vue client, des requêtes du type long-polling ou des clients WebSockets ?
S: Non, car les requêtes de recherche par nature dans ElasticSearch sont très courtes. Lorsque tu exécutes une requête, tu obtiens immédiatement un résultat. De même, lorsque tu demandes une indexation pour une donnée, la réponse est immédiate.
Là où cependant cela aurait une utilité, c’est lorsque tu dois naviguer dans des pages de résultat. Pour répondre à ce besoin, ElasticSearch offre une API qui permet de scroller littéralement dans les pages de résultat, et de conserver une requête (scrollID) pour permettre à l’utilisateur de fouiller dans son résultat.
En fait un autre endroit où le long polling, ou le ‘pinging back’ pourrait avoir un sens c’est le support du Percolator. Dans ElasticSearch, Percolator est un système qui permet d’enregistrer des requêtes pré-determinées afin de déclencher des événements lorsque par exemple un nouveau document arrive dans l’index, ou non. Pour l’instant, on le reçoit comme une réponse à une demande d’indexation. Mais imagine qu’en plus, comme faisant partie de l’enregistrement, tu puisses dire : notifie-moi lorsqu’un document matche ma requête…
N: Qu’est-ce que la notion de ‘Facet’ dans Elastic Search ?
S: J’adore les Facets. Une Facet permet d’agréger des données sur un résultat de recherche, qui sont en rapport avec des documents qui correspondent à une requête de recherche (et juste ces documents). Les Facets sont calculées en temps réel. On peut par exemple retrouver les catégories les plus populaires qui correspond à une requête.
ElasticSearch offre différents types de Facets. Ma favorite est de loin celle qui se base sur un histogramme. Imagine que tu indexes des documents relatifs à une date de publication, et que tu récupères, en plus de ton résultat de recherche, une information sur le nombre de hits par document, chaque mois. Cela te permet même d’aller plus loin et de récupérer des informations historiques mensuelles (par exemple avec un champ date que tu mets dans ton bucket JSON ou un autre champ).
N: J’ai lancé un job board il y a quelques mois. Disons qu’en tant que candidat, je cherche les offres d’emploi situées autour de Paris. Est-ce qu’il est possible de faire des requêtes géolocalisées ?
S: Oui, notre logiciel a en effet des possibilités de recherche géolocalisée. Cela inclut surtout la possibilité de définir des filtres basés sur un emplacement, afin par exemple, de n’afficher que les offres situées dans un rectangle de 50 km autour de Paris. Une autre option intéressant est que nous pouvons trier les résultats de recherche par distance. Ainsi une offre située plus proche de toi apparaîtra en premier, qu’une autre offre similaire située plus loin. Et enfin, concernant les Facets, il y a une Facet qui permet de dire automatiquement le nombre d’offres à 10km, 30km puis au delà. Comme un filtre de recherche automatique.
N: Dernière question : comme tu le sais, la conférence « What’s Next » demande à chaque speaker de présenter un sujet original et de faire une présentation qui n’a jamais été donnée. Peux-tu en quelques mots nous dire de quoi tu vas parler fin mai ?
Shay: Oui, les sujets que je souhaite vous présenter seront tout d’abord de faire une introduction rapide à ElasticSearch, puis ensuite de parler un peu de son architecture, sa nature distribuée, et comment nous avons rendu Lucene distribué, dans le cloud. Je parlerai aussi de l’intégration avec les moteurs NoSQL, avec par exemple une présentation de la faciliter à indexer des données venant de CouchDB vers ElasticSearch.
N: Merci beaucoup d’avoir répondu à mes questions et rendez-vous à Paris !
S: Avec plaisir, à bientôt !
Merci à Pierre Queinnec, CTO de Zenika, pour m’avoir mis en contact avec Shay.
Cette interview a été traduite de l’anglais, retrouvez aussi l’interview sur le blog de Zenika
Joli interview, et surtout très interessant sur la description d’ElasticSearch. J’apprécie sutout la notion de facets qui me donne des idées sur un truc.
Sinon ElasticSearch est une version plus distribuée et cloud de SOLR. Mais avec des features comme l’api rest (plus lisible et clean) et surtout le côté multi-tenant. Interesting.
Une référence compulsionnelle à un framework java s’est cachée dans cette article, sauras-tu la retrouver?
Un indice pour te guider : Amuses-toi!
:)))
Interessant de voir que la notoriété de ce nouveau moteur gagne du terrain. Il vient manger sur une partie du périmetre de Solr en proposant une approche fraiche, et moins inerte de ce fait.
A suivre
ElasticSearch, ca ressemble à du Lucene motorisé par une data grid.
Ce qui ne serait d’ailleurs pas étonnant sachant que GigaSpaces, c’est du data grid…
Si je compare ElasticSearch avec Oracle Coherence (la datagrid que je connais le mieux):
– ElasticSearch, une solution de recherche, qui peut évoluer d’une seule machine à plusieurs centaines => idem l’élasticité des datagrids
– survivre au crash d’un noeud => idem le mode backup dans Coherence : par défaut, toutes les données sont stockées dans un noeud primaire et dans un noeud secondaire, de sorte que le crash d’un noeud n’a aucun impact (perte de données) pour la datagrid
– Percolator : idem les Continuous Query de Coherence
– les Facets (qui permettent d’agréger des données sur un résultat de recherche) : ca ressemble à du map/reduce, non ?