Elasticsearch est un moteur de recherche et d’analyse temps-réel distribué, open-source et fait pour le Cloud. Le système, construit au dessus de la librairie de recherche Apache Lucene, propose de la recherche full text, le support de multiples langages et de la géo-localisation, ainsi que des suggestions contextualisées de type “Vouliez-vous dire…” et des snippets d’auto-complétion et de recherche.
Des API RESTful en JSON over HTTP sont proposées pour toutes les opérations sur Elasticsearch, que ce soit pour la recherche, les analytises ou le monitoring. De plus, des clients natifs pour différents langages comme Java, PHP, Perl, Python et Ruby sont disponibles. Elasticsearch est utilisable sous license Apache 2. Le premier jalon d’elasticsearch-hadoop 1.3.M1 est sorti en octobre dernier.
InfoQ s’est entretenu avec Costin Leau, membre de l’équipe Elasticsearch, à propos du moteur de recherche et d’analytise et de son intégration à Hadoop et autres technologies Big Data.
InfoQ : Bonjour Costin, pourrais-tu nous décrire Elasticsearch et nous expliquer les besoins liés à Big Data auxquels Elasticsearch aide à répondre ?
Elasticsearch est un moteur de recherche et d’analyse scalable, hautement disponible et open-source, s’appuyant sur Apache Lucene. Il vous permet de “fouiller” facilement dans vos données, à différents niveaux et en temps-réel. Chez Elasticsearch, nous avons beaucoup travaillé pour proposer un produit offrant une bonne expérience utilisateur par défaut. Nous positionnons les valeurs vous permettant de commencer facilement et, si vous en avez besoin, nous donnons un accès complet pour personnaliser à peu près tous les paramètres du moteur.
Vous pouvez utiliser Elasticsearch pour faire des recherches à l’aide de requêtes classiques du type “trouver tous les éléments X correspondant à Y”, à l'aide de filtres (ce que l’on appelle “views” dans Elasticsearch). Elasticsearch propose aussi des snippets, pour mettre en évidence les résultats de recherche dans leur contexte, de la géo-localisation ("trouver tous les éléments dans les X kilomètres"), des suggestions ("vouliez-vous dire…") et de puissantes agrégations (les "facettes"), par exemple sous forme d’histogrammes de dates ou de statistiques.
Elasticsearch s’occupe de chercher dans vos données, mais aussi de les stocker. Il propose un modèle basé sur du JSON, semi-structuré, sans schéma. Vous pouvez envoyer vos documents JSON, Elasticsearch détectera automatiquement vos types de données et indexera vos documents. Vous pouvez aussi personnaliser le schéma de mapping en fonction de vos besoins spécifiques, par exemple pour donner plus d’importance à tel ou tel champ ou à tel ou tel document, personnaliser l’analyse full text, etc.
Vous avez la possibilité de commencer avec une petite instance sur votre laptop et, sans modification ou presque, de la porter sur le Cloud avec des centaines ou des milliers d’instances. Elasticsearch passe à l’échelle automatiquement, horizontalement, et croit avec votre application.
Le système s’exécute sur la JVM et utilise du JSON à travers une interface RESTful HTTP, ce qui permet à tout client ou langage d’interagir. Il existe de nombreux clients et frameworks, dans différents langages, fournissant des APIs natives et des DSLs dédiés qui permettent de réduire “les frictions” et d’obtenir les meilleures performances.
Elasticsearch est particulièrement adapté aux problématiques Big Data car, étant scalable et distribué, il permet de rechercher et de stocker d’énormes volumes d’information, quasiment en temps-réel. Avec le projet Elasticsearch-Hadoop, nous permettons aux utilisateurs Hadoop (y compris Hive, Pig, Cascading) de compléter leur workflow avec un moteur de recherche très complet. Nous leur donnons un langage riche pour poser les questions pertinentes donnant des réponses plus claires, de façon significativement plus rapide.
InfoQ : Elasticsearch est utilisé pour des recherches “full text” temps-réel. Pourrais-tu nous décrire en quoi les recherches de ce genre diffèrent des recherches traditionnelles ?
Pour résumer simplement, la recherche traditionnelle est un sous ensemble de la recherche full text.
La plupart des bases de données implémentent la recherche en s’appuyant sur des méta-données ou sur des parts de la donnée d’origine ; pour des raisons d’efficacité, seul un sous-ensemble des données, considéré pertinent (comme les identifiants des entrées, les noms, etc.) est indexé, le reste est ignoré. Ceci résulte en un index de petite taille par rapport au volume de données, mais qui ne couvre pas la totalité des données. La recherche full text va au-delà dans l’indexation et la recherche en les appliquant à l’ensemble du corpus, aux dépens d’un besoin plus important en stockage.
La recherche traditionnelle est habituellement associée à la donnée structurée car il est plus facile pour l’utilisateur de savoir ce qui est pertinent et ce qui ne l’est pas. Cependant, lorsque l'on regarde les besoins modernes, la plupart du temps, les données sont non structurées. De nos jours, on stocke toutes les données une fois pour toutes et, lorsque c’est nécessaire, on les exploite en revenant dessus à plusieurs reprises, sous différents formats et différentes structures. Une approche full text devient ici obligatoire, étant donné que l’on ne peut pas se permettre de simplement ignorer des données.
Elasticsearch supporte aussi bien la recherche dans les données structurées que la recherche full text. De nombreuses options de recherche sont possibles, mots clés, requêtes booléennes, filtres, recherche approximative, pour en citer quelques unes. Le tout est exposé via un langage de requête riche.
Notez qu’au delà de la recherche full text, Elasticsearch propose des fonctionnalités telles que :
- La géo-localisation : pour trouver des résultats à partir de leur localisation
- L’agrégation, les facettes : pour agréger vos données au moment des requêtes. Par exemple, pour trouver de quels pays viennent les visites sur votre site, sur un article précis ou pour des tags donnés un jour specifique. Puisque les agrégations sont calculées en temps-réel, les agrégations changent en fonction des requêtes. En d’autres mots, vous avez une vision immédiate de votre jeu de données.
InfoQ : Comment aborde-t-on la conception avec Elasticsearch ?
La donnée est reine, donc il faut se focaliser sur la donnée. Pour qu’Elasticsearch fonctionne comme vous le voulez avec vos données, vous devez comprendre vos “besoins”. On peut demander à Elasticsearch de faire de son mieux pour deviner ce qu’il peut faire avec vos données. Cependant, rien ne peut remplacer la connaissance que vous avez de votre domaine pour configurer l’installation qui supportera au mieux vos besoins. Tout se résume à déterminer la granularité de la donnée et comment organiser la donnée. Pour vous donner un exemple, prenez le cas des logs, qui est assez courant. Il est préférable de découper les logs en périodes de temps, de façon à avoir un index par mois, ou par semaine, ou par jour, etc., plutôt que d’avoir un seul gros index. Cette séparation permet de mieux prendre en charge les fortes augmentations de volume ainsi que la suppression ou l’archive des données anciennes.
InfoQ : Pourrais-tu nous parler des patterns de conception et d’architecture supportés par le moteur Elasticsearch ?
Un index consiste en de multiples “shards”, chacun étant un mini moteur de recherche à part entière. Un index est en fait un espace de nommage virtuel qui pointe vers un certain nombre de shards. Avoir plusieurs shards permet de monter en charge plus facilement, juste en ajoutant des noeuds. Des replicas, c’est-à-dire des copies des shards primaires, permettent d’avoir de la haute disponibilité et un meilleur débit de lecture.
Exécuter une requête sur un index est une opération distribuée, ce qui veut dire qu'Elasticsearch doit exécuter une requête sur l'une des copies de chaque shard de l’index et ensuite assembler les résultats pour constituer un jeu de données unique en sortie. Exécuter un requête sur plusieurs index n’est qu’une extension de ce processus. Cette approche offre une grande flexibilité lorsque vous provisionnez votre entrepôt de données.
Grâce à la connaissance du domaine, il est aisé d’optimiser les requêtes pour faire en sorte qu’elles ne touchent que les shards appropriés et ainsi, supporter des charges plus importantes, avec le même matériel.
InfoQ : Comment est-ce qu'Elasticsearch se comporte vis-à-vis de la scalabilité des données ?
Elasticsearch est distribué par nature et conçu pour la haute-disponibilité et la scalabilité. Pour donner à nouveau une vue globale, Elasticsearch stocke les documents (les enregistrements de données) sous des index (ou collections). Chaque collection est morcelée en éléments appelés shards. Plus un index est gros, plus on lui alloue de shards. Il ne faut pas avoir peur d’aller en ce sens, les shards ne coûtent pas grand chose. Les shards sont répartis et distribués de façon égale à travers le cluster Elasticsearch, en fonction des paramètres et des volumes disponibles, ceci pour deux raisons :
- Pour la redondance : par défaut, Elasticsearch utilise une copie pour chaque shard. Si un shard est perdu, un autre est prêt à prendre le relai.
- Pour des raisons de performance : Chaque requête est faite sur un index et est exécutée en parallèle sur ses shards. Ceci est un mécanisme clef pour améliorer la performance : en cas de lenteur, il suffit d’ajouter des machines au cluster, Elasticsearch distribuera automatiquement les shards et leurs requêtes, sur les nouveaux noeuds.
Cette approche donne la liberté d’évoluer aussi bien verticalement (si un noeud est lent, on upgrade le matériel) qu’horizontalement (si un cluster est lent, on ajoute plus de noeuds).
InfoQ : Quelles sont les limitations ou les points d’attention, concernant cette technologie ?
Le plus gros challenge que nous constatons, c’est avec les utilisateurs qui viennent du monde SQL et qui veulent mettre en place une “recherche contextuelle”. Pour récupérer des entrées individuelles (le get classique), rien ne change : on spécifie un id et on obtient le résultat. Cependant, lorsqu’on en vient à l’exploration des données, il faut avoir recours à plusieurs constructions, en fonction du type d’analyse à réaliser, du type de recherche, du type d’algorithme à utiliser (les fuzzy queries par exemple).
InfoQ : Pourrais-tu nous parler des avantages à combiner Elasticsearch et Hadoop ?
Hadoop est by design un système distribué, orienté batch, fait pour le traitement de jeux de données volumineux. Bien que cela soit un outil très puissant, le fait qu’il fonctionne en batch implique qu’il faut du temps pour produire des résultats. De plus, l’utilisateur doit coder ses opérations, souvent de zéro. Les librairies comme Hive et Pig aident mais ne résolvent pas complètement le problème. Imaginez avoir à ré-implémenter la géo-localisation en Map/Reduce, par exemple.
Avec Elasticsearch, vous pouvez laisser les recherches au moteur de recherche et vous focaliser sur les autres parties, telles que la transformation de données. Le projet Elasticsearch-Hadoop fournit une intégration native avec Hadoop, donc il y a une continuité pour l’utilisateur. Nous fournissons des InputFormat et OutputFormat pour du Map/Reduce standard, des Taps pour lire et écrire dans Cascading et des Storages pour Pig et Hive, pour pouvoir accéder à Elasticsearch comme si la donnée était sur HDFS.
Habituellement, les magasins de données intégrés à Hadoop ont tendance à devenir des goulots d’étranglement, à cause des requêtes générées par les tâches exécutées sur le cluster pour tous les jobs. La nature distribuée du modèle Map/Reduce est particulièrement adaptée à Elasticsearch car on peut mettre en corrélation les numéros de tâches Map/Reduce et les numéros de shards pour une requête donnée. Ainsi, à chaque fois qu’une requête est exécutée, le système génère dynamiquement un nombre de parts de tâches Hadoop proportionnel au nombre de shards disponibles afin que les jobs s’exécutent en parallèle. Votre cluster Hadoop peut croitre aux côtés d’Elasticsearch, et vice-versa.
De plus, l’intégration permet de co-localiser le cluster en exposant les informations sur les shards à Hadoop. Les jobs sont exécutés sur les mêmes machines que les shards Elasticsearch, ce qui permet d’éliminer le trafic réseau et d’avoir une meilleure performance, grâce à la proximité des données. Nous recommandons d’exécuter les clusters Elasticsearch et Hadoop sur les mêmes machines spécifiquement pour ces raisons, et particulièrement parce qu’il y a complémentarité sur l’utilisation des ressources (IO vs. CPU).
Enfin, Elasticsearch fournit des temps de réponse proches du temps-réel (de l’ordre de quelques millisecondes), ce qui améliore de façon significative l’exécution des jobs Hadoop et leur coût associé, surtout lorsqu’on exécute sur des ressources que l’on a “loué”, sur Amazon EMR par exemple.
InfoQ : Existe-t-il une possibilité d’intégration entre Spring Framework et Elasticsearch ?
Absolument, vous pouvez vous référer au projet Spring Data Elasticsearch sur Github. Le projet a été initié par Biomed Central, des membres de notre communauté, et nous avons le plaisir de participer à son développement en l’utilisant et en cherchant à l’améliorer. Le projet fournit le fameux template Spring en tant qu’abstraction de haut-niveau et pour supporter un Repository au dessus de Elasticsearch avec configuration complète en XML, JavaConfig et CDI. Nous cherchons en ce moment à agréger différents modes d’intégration de la même façon, notamment spring-elasticsearch de David Pilato.
Au sujet de l’interviewé
Costin Leau travaille actuellement chez Elasticsearch, en tant qu’ingénieur, sur les technologies NoSQL et Big Data. Vétéran de l’Open Source, Costin a conduit différent projets Spring et a écrit une spécification OSGi.