Interrogez efficacement vos bases de données avec ElasticSearch

L’économie numérique actuelle est caractérisée par la donnée, et plus précisément par la connaissance. On entend souvent dire que « la connaissance, c’est le pouvoir » (Knowledge is Power). Cette affirmation n’a jamais été aussi pertinente qu’aujourd’hui. À l’heure du big data, ce qui sépare les gagnants des perdants, c’est l’accès opportun à l’information.

Malgré la démocratisation de l’information qu’a provoqué Internet, beaucoup d’individus et d’entreprises ont encore du mal à obtenir l’information dont ils ont besoin.  Par exemple, effectuer des requêtes multi-critères telles que retrouver l’hôtel de confort moyen situé le plus proche des zones de transport et pas très loin d’un aéroport, ou encore retrouver dans une base client, le nombre de clients qui habitent à Paris et qui ont acheté le dernier produit de l’entreprise… etc.  Selon une étude menée par l’IDC en 1999, les grandes entreprises perdraient 12 milliards de dollars à cause de l’incapacité de leurs employés à trouver l’information recherchée. IDC appelle cela le déficit de connaissance (knowledge deficit).

Ainsi, rendre l’information « découvrable » est l’un des grands challenges du Big Data. La recherche de contenu (de l’anglais Search ou content Search), est une problématique que vous devez surmonter si vous voulez valoriser vos données.  Actuellement, pour résoudre les challenges liés à la recherche de contenu, vous avez le choix entre deux approches : la classification en catégories hiérarchiques,  et l’indexation de contenu.

Dans la classification en catégorie hiérarchique, on  regroupe les informations de la même nature (ou informations qui traitent du même sujet) dans une catégorie, exactement de la même façon qu’on classe les livres dans une bibliothèque. Vous remarquerez d’ailleurs que c’est la classification en catégorie hiérarchique qui est utilisée pour regrouper le contenu de ce site. Malheureusement, avec le temps, la popularité et la pertinence de cette approche se  sont dégradées pour plusieurs raisons : premièrement, le processus éditorial de classement strictement manuel ne  suit pas le rythme de croissance du contenu. Lorsque le contenu ou lorsque les données deviennent trop volumineuses, il devient pénible de les classer manuellement de façon homogène ; deuxièmement, l’utilisateur ne sait pas toujours quelle catégorie rechercher les données d’un sujet particulier, spécialement si le volume de données est important.

Aujourd’hui, avec le volume important de données, l’approche la plus efficace pour la recherche d’information est l’indexation de contenu. L’indexation de contenu consiste à utiliser des mots-clés et des index pré-calculés pour retrouver algorithmiquement l’ensemble de contenus qui satisfait l’intention de requête des utilisateurs. Dans notre article « Data Mining – les principes d’interrogation d’une base de données« , nous expliquons les techniques automatisées de data science qui permettent de retrouver des contenus qui satisfont l’intention de requête des utilisateurs. Les moteurs de recherche utilisent cette approche à grande échelle pour Internet. En 2005 déjà, Google rapportait qu’il parvenait à indexer autour de 25 milliards de pages web. Dans notre livre numérique Initiation à l’écosystème Hadoop que nous offrons en téléchargement libre, nous expliquons comment Google arrive à indexer tout le web. Téléchargez l’ebook en cliquant dans la bannière suivante et lisez-le, cela enrichira votre compréhension de l’implémentation de l’indexation de contenu à large échelle.

L’indexation de contenu n’est pas indiqué uniquement pour la recherche d’information à l’échelle du web. Grâce à des moteurs spécialisés qui ont une version open source (et commerciaux) tels qu’Apache Lucene, ElasticSearch et Apache Solr, les entreprises, même de taille modeste, peuvent construire des systèmes d’indexation de contenu qui répondent à toutes les requêtes de leurs employés aussi longtemps que les données nécessaires pour satisfaire ces requêtes existent dans les systèmes sources de l’entreprise.

Dans l’artillerie technologique de l’écosystème Hadoop, les technologies spécialisées dans la recherche d’information s’appellent les moteurs d’indexation de contenu. Ces moteurs sont des types particuliers de SGBD auxquels des fonctionnalités d’indexation et de recherche de contenu ont été ajoutées.  Apache Solr et ElasticSearch sont deux de ces types de moteur. Apache Solr et ElasticSearch sont des moteurs NoSQL d’indexation de contenu scalables, qui s’appuient sur Apache Lucene, une bibliothèque de d’indexation de contenu (nous y reviendrons plus loin), pour fournir des fonctionnalités d’indexation et de recherche de contenu. Là où Apache Lucene ne gère pas le stockage des documents, ces deux moteurs fournissent le support de stockage des données de sorte que l’indexation et la recherche puisse se faire directement dans le moteur.

Malgré l’ancienneté d’Apache Solr, ElasticSearch est depuis 2010 très utilisé et sur la base de cette popularité que nous l’avons choisi pour étude dans ce tutoriel. Vous y apprendrez les concepts de base d’ElasticSearch, son fonctionnement et vous apprendrez comment l’exploiter pour répondre aux requêtes multi-critères de vos utilisateurs. 

Définition d’ElasticSearch

Depuis sa sortie en 2010, ElasticSearch est devenu extrêmement populaire. Il a été développé la même année par Shay Banon qui le commercialise via la société qu’il a crée Elastic. Malgré son aspect commercial et le fait qu’il ne fasse pas partie de la fondation Apache, ElasticSearch est open source. Formellement, ElasticSearch est un moteur distribué de stockage, de recherche et d’analyse de contenu. En tant que moteur de stockage, il stocke les données en format JSON, annulant ainsi le besoin de joindre à son application de recherche un support de stockage; en tant que moteur de recherche, Il utilise Apache Lucene pour les fonctionnalités d’indexation et de recherche de contenu sur ces documents JSON et en tant que moteur d’analyse de contenu, il s’appuie sur Logstash, un logiciel de gestion de logs et Kibana, une plateforme d’exploration et de visualisation des données, pour effectuer des analyses sur les données qu’il stocke.

Sa particularité lui vient du fait qu’il s’interroge  à partir d’une API REST, est accessible à partir du protocole HTTP et utilise le format JSON aussi bien pour le stockage des données que pour le renvoi des réponses de requêtes. Les standards HTML, REST et JSON le rendent facile à intégrer avec d’autres applications,  simple à utiliser pour les utilisateurs. De plus, le fait qu’il utilise le JSON pour le stockage des données rend l’exploitation des données possible à partir de n’importe quel langage de programmation possédant des API permettant de lire du JSON. Les aspects distribués d’ElasticSearch lui permettent d’effectuer les recherches de contenu très rapidement, dans l’ordre de la seconde (moins de 100 millisecondes en moyenne en fonction de la volumétrie des données et des caractéristiques du cluster selon les évaluations des experts). Toute interaction avec ElasticSearch se fait à travers son API REST qui vous permet d’envoyer des requêtes HTTP.

Traditionnellement, les moteurs de recherche de contenu sont déployés sur des moteurs de base de données pour fournir aux applications développées sur ces bases de données des fonctionnalités d’indexation et de recherche. Historiquement, ceci a été le cas parce que les moteurs de recherche de contenu n’offraient pas de support de stockage persistent sur lequel directement effectuer les recherches. ElasticSearch est l’un des moteurs de recherche de contenu moderne qui fournit à la fois le support de stockage NoSQL, l’indexation et la recherche de contenu, et l’Analytics. ElasticSearch est un moteur NoSQL orienté-document, au même titre que MongoDB ou RavenDB et il fournit toutes les fonctionnalités de stockage distribué que ce type de moteur offre. Cependant, vous pouvez aussi utiliser ElasticSearch avec d’autres moteurs de base de données. Si vous voulez développer une nouvelle application ou si vous voulez ajouter des fonctionnalités de recherche de contenu dans une application existante, l’API REST est l’une des fonctionnalités qui rend ElasticSearch attractif. En effet, ElasticSearch expose ses fonctionnalités à travers cette API REST, et comme nous le verrons ensemble plus bas, cela vous permet d’écrire vos requêtes en JSON, de recevoir les résultats des requêtes en JSON et d’effectuer l’ensemble de vos interactions avec ElasticSearch via ce même API. Dans la partie suivante, nous allons entrer dans l’organisation et le fonctionnement interne d’ElasticSearch.

Les concepts clés d’ElasticSearch

Pour comprendre comment l’indexation et la recherche de contenu se passent dans ElasticSearch, il faut que vous compreniez l’ensemble des concepts clés qu’il met en œuvre et la relation qui existe entre ces concepts. ElasticSearch possède 6 concepts qu’il est fondamental de comprendre pour pouvoir l’utiliser efficacement : le noeud, le cluster, l’index, le type/mapping, le document, la partition (shard) et la réplique.

• Le noeud : en ElasticSearch, un noeud fait référence à une instance d’exécution du logiciel ElasticSearch. Autrement dit, c’est un processus applicatif qui est exécuté sur une machine. Un serveur ou une machine virtuelle peut exécuter une ou plusieurs instances ou nœuds ElasticSearch en fonction de ses ressources. Les nœuds peuvent également s’exécuter sur un cluster de machines lorsqu’il y’a besoin de la haute disponibilité ;
• Le cluster : un cluster ElasticSearch est un ensemble d’un ou plusieurs nœuds. Comme nous l’avons dit précédemment, un noeud fait référence à une instance d’ElasticSearch, par conséquent un cluster entier peut tourner sur une machine virtuelle. Le cluster fournit l’indexation collective et la distribution des requêtes de recherche à travers tous les nœuds du cluster ;
• L’index : Dans la terminologie ElasticSearch, un index est un ensemble de documents JSON. Nous y reviendrons plus bas ;
• Le type : encore appelé Mapping, le type fait référence à un ensemble de documents qui partagent un ensemble de champs commun, présent dans le même index. Le Mapping est l’un des éléments qui distingue d’ailleurs ElasticSearch d’Apache Solr. Là où Solr exige que tous les documents JSON aient la même structure, ElasticSearch les stocke en l’état, mais utilise le type pour les catégoriser. C’est pourquoi on dit qu’ElasticSearch est « sans schéma » ou « n’impose pas de schéma à priori ». Ainsi, ces expressions que vous allez sans doute rencontrer ne font aucunement référence au schéma dans le sens SGBDR du terme. Nous y reviendrons plus bas ;
• L’indice: c’est le container logique des types. Le concept d’indice introduit les notions d’index ElasticSearch et index Lucene. Nous y reviendrons plus bas ;
• Le document : C’est un ensemble de champs ou propriétés définis de façon spécifique dans le format JSON. Chaque document appartient à un type et réside dans un index. A chaque document est associé un identifiant unique appelé UID ;
• La partition : de sa traduction originale Shard, une partition est une partie de l’index. Les indexes sont horizontalement partitionnés en shards, tout comme les tables dans un SGBD sont partitionnés en lignes. En d’autres termes, les documents JSON sont partitionnés par objet (par par champs) et ces partitions sont réparties dans les nœuds du cluster ElasticSearch. Chaque partition contient toutes les propriétés (champs) du document, mais moins d’objets JSON. La distribution des partitions dans le cluster fait distinguer la notion de partition primaire et partitions secondaires. Nous allons y revenir plus bas ;
• La réplique : les indexes et les partitions sont répliqués à travers les nœuds du cluster pour accroître la haute disponibilité des traitements en cas de panne. De plus, les répliques permettent de paralléliser les traitements de recherche de contenu dans le cluster, ce qui accroît la performance d’ElasticSearch ;

L’indexation de contenu dans ElasticSearch

Dans ElasticSearch, l’unité est le document. En d’autres termes, l’index dans ElasticSearch c’est l’ensemble des documents qui sont stockés dans le moteur. Les documents sont enregistrés au format JSON. La structure hiérarchique du format JSON permet à ElasticSearch d’indexer tout le contenu des documents. A titre de rappel, le contenu d’un document JSON est formellement organisé sous forme d’objets. Chaque objet est l’équivalent d’une ligne dans une table de base de données relationnelle. Les documents sont organisés en séries de propriétés, qui sont l’équivalent des colonnes dans le monde des bases de données relationnelles. La figure ci-après illustre un document JSON. Bien que basique, il est important de comprendre cette organisation, elle vous servira pour comprendre l’organisation des données dans ElasticSearch et la façon dont les requêtes de recherche y sont exécutées.

Vous pouvez voir que le document JSON mis en avant dans la figure ci-dessus possède deux objets (ou deux lignes), il possède plusieurs propriétés. Le premier objet a pour propriété  firstName  la valeur  Juvénal, tandis que le deuxième objet, pour la même propriété a pour valeur Julie. Ce document a pour caractéristique de posséder la même structure pour tous les objets (les propriétés sont les mêmes d’un objet à un autre). Cependant, dans la vraie vie, le schéma ou la structure de données des documents est rarement la même.

Dans la recherche de contenu, l’un des problèmes majeurs que l’on rencontre est la variété des formats de fichiers et des structures des données, ce qui complexifie l’indexation des données sur ces fichiers. ElasticSearch se démarque sur ce point en supportant toute forme de structure JSON. En d’autres termes, ElasticSearch indexe nativement des documents JSON dont la structure n’est pas identique d’un objet à l’autre ou d’un document à l’autre. C’est l’un des points qui le différencie de son concurrent, Apache Solr, qui exige que tous les documents JSON aient la même structure. Comment ElasticSearch réussit-il à indexer du contenu sur les documents JSON dont la structure est différente ? En introduisant la notion de type ou de type de document. Certains préfèrent parler de Mapping de document pour désigner le type.  Formellement, le typage de document consiste à regrouper les documents qui partagent les mêmes propriétés (champs) dans le même indice. ElasticSearch gère le stockage des données d’une façon logique (conceptuelle). Ainsi, l’indice est le container logique de l’ensemble des documents qui ont le même type, même si physiquement tous ces documents sont persistés au même endroit sur le disque dur. La notion d’indice permet d’introduire les concepts d’index ElasticSearch et index Lucene. Dans le point suivant, vous allez comprendre leur importance. 

L’index ElasticSearch ou index au sens ElasticSearch du terme, fait référence à l’ensemble des indices de l’index. L’index ElasticSearch est le container logique de l’ensemble des indices.  Gardez toujours à l’esprit que L’index désigne simplement l’ensemble des documents JSON stockés sur le disque. Vous pouvez imaginer l’index ElasticSearch comme une base de données relationnelle et au sein de cette base de données, il y’a plusieurs tables, chaque table regroupe l’ensemble des lignes qui possèdent les mêmes colonnes. Dans notre analogie, la base de données serait l’index ElasticSearch, tout comme une base de données n’est qu’une représentation logique du stockage des données, tel l’index ElasticSearch est un container logique des indices. Chaque table de la base de données serait un indice, et tout comme la table n’est qu’une abstraction logique de stockage, ainsi l’indice est le container logique des documents du même type. Chaque table est simplement un ensemble de lignes qui partagent les mêmes colonnes. Dans ElasticSearch, les colonnes seraient le type et chaque ligne correspondrait à un document. L’ensemble des documents qui partagent le même type.  Tout comme la base de données est stockées physiquement sur le disque dur non pas sous forme de tables mais comme des fichiers, tel est l’index. L’index est l’ensemble des fichiers JSON stockés sur le disque dur sans aucune abstraction logique. Cette distinction est très importante, car les indices sont traités indépendamment les uns des autres lors des recherches. A cause de cela, on dit d’ElasticSearch qu’il est Multi-tenant ( de Multi-tenancy, c’est une propriété qui indique qu’un système est capable de traiter plusieurs entités similaire de façon parallèle).  Le tableau suivant va vous aider à retenir l’organisation des données dans ElasticSearch.

SGBDR	ElasticSearch
Base de données	Index ElasticSearch
Table de la base de données	Indice de l’index ElasticSearch
Colonne de la table	Type de l’indice/propriétés des documents JSON
Ligne de la table	Document de l’indice

Le type est donc le moyen de séparation des documents dans l’index en groupes logiques. Attention quand même, le type sépare les documents uniquement d’un point de vue logique. Physiquement, les documents appartiennent tous au même index et sont persistés au même endroit sur le disque dur. Tout comme un SGBDR peut supporter plus d’une base de données relationnelle, vous pouvez définir plusieurs indexes ElasticSearch. Par exemple, dans une instance de SQL Server, plusieurs bases de données peuvent être installées et gérées. Il en est de même avec ElasticSearch. Toute instance d’ElasticSearch peut gérer un ou plusieurs index ElasticSearch. Laissez-nous illustrer tout cela par un exemple. Supposons que nous avons une base de clients constituée de 4 documents JSON dans ElasticSearch.  La figure suivante illustre la structure de notre index.

!!!! Attention !!!! A partir de la version 6.0 d’Elasticsearch, la notion de « type » a été supprimé. Désormais, chaque index contient des documents du même format (ou documents de la même structure). Nous en parlons encore dans ce tutoriel pour vous aider à focaliser votre attention sur les principes de base du fonctionnement d’Elasticsearch. Mais sachez que le type n’est plus d’actualité à partir de la version 6.0. Reférez-vous au lien suivant pour plus de détails sur cette mise à jour : https://www.elastic.co/fr/blog/removal-of-mapping-types-elasticsearch

Comme vous pouvez le voir dans la figure, l’index est l’ensemble des quatre documents. Il est composé des  4 documents JSON Clients1.json, Clients2.json, Clients3.json et Clients4.json.   Cependant, les documents clients3.json et clients4.json n’ont pas la même structure que les fichiers clients1.json et clients2.json. Ils possèdent la propriété address en plus qui est lui-même constitué d’un autre objet contenant 4 propriétés (rue, ville, CodePostal et Pays) que nous avons surligné dans la figure par le rectangle bleu-ciel. Pour indexer ces deux documents, l’utilisateur doit obligatoirement spécifier leur type au moment de leur ajout dans le moteur ElasticSearch. Dans la partie suivante, nous allons vous montrer comment. Pour nos besoins, nous avons choisi de nommer ce type adresse. Le type adresse contiendra dans l’avenir tous les documents qui ont la même structure que les  documents clients3.json et clients4.json. En créant ce type, ElasticSearch va indexer les 4 propriétés de la propriété adress et l’utilisateur pourra effectuer des recherches qui pointent uniquement sur ces 4 propriétés dans l’ensemble des documents du type.  Nous allons vous montrer comment dans la partie suivante. Les documents de type adresse sont placés dans l’indice 1. Les deux autres documents sont placés dans l’indice 2. En fait, tout document qui est ajouté dans ElasticSearch doit obligatoirement être placé dans un indice.  L’ensemble de ces deux indices forment un index ElasticSearch. Les indices sont ensuite indexés indépendamment les uns des autres.  Nous allons maintenant  aborder l’architecture d’ElasticSearch et comment celle-ci s’harmonise avec cette organisation de documents.

Attention !!!! Les types ne limitent pas les recherches. Une recherche globale qui ne précise pas le type sur lequel effectuer les recherches renvoie tous les documents peu importe son type. Autrement dit, les recherches ne se font pas sur les types, mais sur tous les documents de l’index. Ainsi, le typage des documents n’affecte pas négativement la précision des recherches lorsque celles-ci ne précisent pas le type sur lequel elles portent.

Architecture d’ElasticSearch

L’approche conceptuelle  utilisée par ElasticSearch pour l’indexation et la recherche de contenu conditionne son architecture tout entière.  Lorsque vous installez ElasticSearch, vous l’installez par défaut sur une machine. Une instance d’ElasticSearch est démarrée sur cette machine. Cette instance s’appelle un noeud. A l’aide des techniques de virtualisation, vous pouvez démarrer plusieurs instances d’ElasticSearch sur la même machine. Vous pouvez également installer ElasticSearch sur un ensemble de machines configurées en cluster Maître/Esclaves. Dans les deux cas de figure, le cluster ElasticSearch n’est pas égal au nombre de machines ou machines virtuelles sur lesquelles sont démarrées ElasticSearch, mais à l’ensemble des instances d’ElasticSearch en cours d’exécution. Avec un cluster de nœuds, les activités de stockage, d’indexation et de recherche des documents sont distribuées à travers les nœuds du cluster. Voyons comment cela se fait.

Tout document qui arrive dans un cluster ElasticSearch est placé dans un indice et divisé en partitions (ou shards) selon la méthode round robin (Cf. tutoriel sur le SQL dans Hadoop). Ici, la méthode round robin assure que toutes les partitions auront à peu près la même taille. Les partitions représentent les documents JSON partitionnés en objets de taille à peu près égale. Les partitions sont l’équivalent des divisions des tables relationnelles en blocs de lignes selon une méthode de partitionnement. Le processus de partitionnement affecte également à chaque partition un identifiant. Par défaut, ElasticSearch partitionne les documents en 3 partitions. Ces partitions sont ensuite répliquées entre les nœuds du cluster selon un facteur de réplication. Le facteur de réplication par défaut est de 5, en d’autres termes, chaque partition est répliquée 5 fois et ces 5 répliques sont réparties entre les nœuds du cluster. La réplication des données assure la haute disponibilité du cluster et garantit la continuité des traitements en cas de panne dans le cluster. Lors du processus de réplication, ElasticSearch désigne une réplique primaire pour chaque document.

Si nous appliquons maintenant les concepts et les principes d’organisation de contenu que nous avons vu dans les deux points précédents, alors il apparaît que les répliques sont en réalité des blocs d’index. La recherche de contenu est faite sur les répliques et comme ElasticSearch est multi-tenant, chaque réplique est considéré comme un index en soi et traité indépendamment. La figure suivante illustre l’architecture d’ElasticSearch.

La figure met en évidence le fait que l’index (l’ensemble des documents) est divisé en 3 partitions (pour chaque document de l’index) auxquelles sont affectées les ID 0, 1 et 2.  Attention, il faut comprendre que les partitions ne concernent pas un document, mais bien l’ensemble des documents JSON de l’index. La figure suivante suivante illustre  parfaitement cela. Les partitions sont ensuite répliquées dans le cluster. La couleur violette foncée dans la figure précédente illustre la réplique primaire de chaque partition. C’est sur ces répliques primaires que les opérations d’indexation et de recherche sont faites avant d’être répercutées sur les autres répliques pour la prise de relai en cas de problème avec la réplique primaire.

Comme vous pouvez le constater, chaque partition est constituée d’un bloc de chaque document de l’index  et stockée sur le disque dur de la machine dans laquelle elle a été assignée. Les partitions sont individuellement indexées, ce qui permet de paralléliser ou de traiter de façon indépendante l’exécution des requêtes de recherche sur les nœuds ElasticSearch. Les partitions représentent des indexes de plus petite échelle (taille), plus simples  à traiter, comparer à l’index original. Vous retrouvez donc là les principes de fonctionnement de Hadoop : le gros fichier est découpé en blocs de petite taille et ces blocs sont traités individuellement par les nœuds du cluster et ce de façon complètement tolérante aux pannes.

ElasticSearch applique exactement le même principe avec les partitions. Techniquement, les partitions sont des indexes Lucene. Une instance d’Apache Lucene est affectée à chaque partition et ses répliques, et lorsque les requêtes des utilisateurs arrivent dans le système, chaque instance d’Apache Lucene effectue la recherche de contenu sur la partition à laquelle il a été affecté.  Apache Lucene est un peu comme la fonction Map qui est attribuée à un bloc de fichier dans Hadoop. Apache Lucene transforme la partition en index inversé et c’est sur cet index inversé de la partition que la recherche de contenu est faite. A ce stade, vous avez compris comment l’indexation de contenu se passe dans ElasticSearch. Il est vraiment important de bien comprendre les principes que nous avons énoncés dans ces deux points si vous souhaitez maîtriser le développement d’application en ElasticSearch. Nous allons maintenant passer à l’étude de la recherche de contenu.

La recherche de contenu dans ElasticSearch

L’avantage de la structure hiérarchique du format JSON est qu’il permet d’indexer tout le contenu des documents. De plus, il facilite la recherche, car celle-ci peut se faire de façon ciblée sur des propriétés précises. Cela signifie que l’utilisateur peut faire des recherches en s’appuyant sur n’importe quelle propriété ou il peut chercher du contenu de façon générale sans indiquer les propriétés qui les contiennent. Lorsque vous effectuez des requêtes de recherche de contenu, ElasticSearch les traitent selon le principe suivant :

Lorsque la requête arrive dans le cluster ElasticSearch, elle est réceptionnée par le nœud maître du cluster, celui-ci la transfère à tous les nœuds qui possèdent une partition de l’index, que ce soit une partition primaire ou une réplique. Ensuite,  sur chacun de ces nœuds, une instance d’Apache Lucene qui y tourne effectue l’opération de recherche sur la partition (l’index inversé de la partition) et renvoie les résultats correspondants au nœud maître. Celui-ci réceptionne les résultats de chaque nœud, les agrège et les retourne à l’utilisateur.  Etant donné que les partitions ont normalement la même taille avec la méthode round robin, ce principe assure que la charge de calcul des requêtes est équitablement répartie entre les nœuds du cluster. Ce qui est également intéressant avec ElasticSearch à ce niveau est que tout ce processus est complètement transparent à l’application de recherche. L’utilisateur  exécute ses requêtes via l’API REST offerte par ElasticSearch sans s’encombrer des détails de coordination et d’exécution de celles-ci dans le cluster.

L’API REST joue un peu le même rôle que le SQL dans les SGBDR MPP (Cf. tutoriel sur le SQL dans Hadoop). C’est cette simplicité qui est l’une des raisons à l’origine du succès de l’adoption d’ElasticSearch. Dans le point qui va suivre, nous allons vous montrer comment manipuler cette API. La figure suivante illustre le processus de recherche de contenu dans ElasticSearch.

Attention !!! Il est important de noter que  la recherche se fait aussi sur toutes les répliques des partitions. Puisque les répliques contiennent les mêmes données que les partitions primaires, cela favorise la haute performance des calculs et assure la haute disponibilité du cluster en cas de panne lors des traitements.

Maintenant, tout est en place ! Nous vous proposons de faire un tour sur la vidéo suivante. Cette vidéo est l’enregistrement d’un meetup dans lequel l’entreprise Malt illustre la façon dont elle utilise ElasticSearch pour ses différents cas d’usage. C’est une vidéo que nous trouvons particulièrement parlante pour présenter de façon plus exhaustive ElasticSearch. Avant de vous rendre dans la partie suivante dans laquelle nous traitons de la recherche de contenu sur ElasticSearch via son API REST, nous vous recommandons de jeter un coup d’oeil sur cette vidéo, elle vous sera très bénéfique pour étendre votre compréhension de l’usage d’ElasticSearch.

Exploitation d’ElasticSearch

Vous avez appris tout au long des points précédents les principes de fonctionnement d’ElasticSearch. En réalité, tous ces points n’avaient qu’un seul but : vous préparer à l’utiliser efficacement. Vous avez besoin de connaître ces principes, surtout si vous souhaitez développer des applications qui utilisent ElasticSearch comme moteur d’indexation de contenu. Comme nous l’avons dit précédemment, l’interaction et la recherche de contenu dans ElasticSearch se fait à l’aide d’une API REST qu’il fournit. Que vous envisagiez d’intégrer ElasticSearch comme moteur d’indexation de contenu dans une application ou l’utiliser directement, les deux cas se font par le biais de son API REST. 

Lorsque vous développez une application de recherche de contenu qui s’appuie sur ElasticSearch, vous exploiter simplement l’API par laquelle il expose ses fonctionnalités. La ressource exposée ici c’est l’index, ElasticSearch joue le rôle du Serveur REST et vous manipulez les documents de l’index à l’aide des verbes HTTP. Le JSON est utilisé comme format d’échange de données. L’URI de l’index a la forme suivante : protocole://host [:port]/index/type/document_id 

La figure suivante illustre les différentes parties d’une URI d’index ElasticSearch.

Pour utiliser l’API REST d’ElasticSearch et lui transférer les requêtes HTTP des URI, vous pouvez utiliser des outils comme postman  (https://www.getpostman.com/) ou cURL (https://curl.haxx.se/).  Mais nous vous recommandons d’utiliser cURL car il est devenu l’outil par définition d’exploitation d’ElasticSearch. cURL est un utilitaire de ligne de commande qui permet de transférer les données à travers le protocole HTTP. Nous n’allons pas entrer sur les raisons qui font qu’il est devenu un standard dans l’utilisation d’ElasticSearch. Si vous avez installé ElasticSearch sur votre poste et que votre système d’exploitation c’est Windows, alors pour utiliser cURL, il est préférable d’installer l’outil Cygwin (https://www.cygwin.com/). C’est avec cURL démarré sur Cygwin que nous  fonctionnerons tout au long de ce point. La  figure suivante illustre la syntaxe de la ligne de commande nécessaire en cURL pour envoyer des requêtes à ElasticSearch.

L’action exprime le type d’opération qui va être réalisé. Dans le cas de figure, il s’agit d’une recherche de contenu (_search). La requête s’exprime en format JSON. Dans la figure, la requête consiste à effectuer une recherche de tous les documents de l’index Clients dont la propriété firstname est « juvenal ». 

Après avoir installé ElasticSearch sur votre ordinateur personnel, exécutez la commande suivante.

Vous devriez normalement obtenir une réponse JSON similaire  à l’objet JSON suivant :

Vous voyez dans les résultats la version de Lucene qui est intégrée à ElasticSearch (« lucene_version »: « 6.3.0 »).  Nous allons maintenant créer l’index constitué des 4 fichiers JSON de la deuxième figure du projet.  Pour ce faire, la première chose consiste à créer l’index Clients en utilisant la commande suivante :

Attention!!! L’index doit être en minuscule, sinon ElasticSearch générera une erreur.  Une fois que l’index a été créé, vous obtiendrez la réponse suivante, qui indique le succès de l’opération.

Regardons les caractéristiques par défaut de l’index que nous venons de créer. Cela se fait par la commande suivante :

La réponse à la requête montre que par défaut, l’index est partitionné en 5 et chaque partition est répliqué une fois (« number_of_shards »: « 5 », « number_of_replicas »: « 1 »).

Nous allons maintenant ajouter les fichiers clients1.json et clients2.json dans l’index dans un type que nous appellerons « simple ».

Vous pouvez vous amuser à émettre une requête GET sur ces deux documents pour voir comment ils sont enregistrés dans l’index. Nous allons maintenant ajouter les fichiers clients3.json et clients4.json dans le type « adresse ».

Attention !!! Lorsque les documents sont épaves et dispersés,  ou lorsqu’un fichier est beaucoup trop volumineux pour que vous le placez en corps de requête, un simple PUT ne suffit plus pour les placer dans ElasticSearch. Dans ce cas de figure, vous pouvez utiliser la fonctionnalité de chargement par lot _bulk introduite par ElasticSearch. Si vous n’arrivez pas toujours à charger vos données dans l’index jusque là, alors nous vous recommandons d’utiliser Logstash. Logstash est un peut comme un ETL, introduit dans la suite ELK d’Elastic, il permet de se connecter à différents sources de données, de les transformer et de les charger dans ElasticSearch.

Nous allons maintenant faire des recherches de contenu sur les quatre documents que nous avons ajouté dans l’index clients.  ElasticSearch, en dehors des fonctionnalités de recherche d’Apache Lucene, supporte plusieurs types de recherche telle que la recherche facettée, la recherche booléenne, et la recherche textuelle intégrale entre autres. Pour plus de détails sur ses capacités de recherche, rendez vous sur son site web officiel fourni dans la section « RESSOURCES » si bas. Supposons que dans notre exemple, nous voulons renvoyer tous les documents qui contiennent « Boissy Saint Léger ». Le script suivant effectue la recherche.

Cette requête fournit le résultat suivant. Les résultats d’une requête de façon générale sont stockés dans l’objet hits. Il renvoie les résultats classés par ordre d’importance.

Supposons maintenant que nous voulons récupérer tous les documents dont la ville est Paris.

Comme vous aurez pu le constater, effectuer des recherches en ElasticSearch signifie maîtriser la syntaxe de l’instruction _search et la construction du corps de la requête.

En résumé

Le Numérique est une ère résolument tournée vers la valorisation et l’exploitation de la donnée. Dans la plupart des cas, ces données sont centralisées dans des bases de données exploitées encore dans une grande majorité de cas par des systèmes de gestion de bases de données relationnelles. Les SGBDR, en s’appuyant sur le SQL, offrent des fonctionnalités de recherche de contenu qui sont très limitées. La récupération des données est malheureusement synonyme des requêtes ayant une forme similaire à celle-ci :

Hélas, comme vous pouvez le constater vous-même, le SQL n’est pas efficace lorsqu’il s’agit d’exprimer des requêtes d’une certaine complexité et dégrade même la performance du système avec l’augmentation du volume de données dans la base.  C’est pour résoudre ce problème que les moteurs d’indexation de contenu ont été créés. Apache Lucene est à la base de tous ces moteurs, il permet de développer des applications qui retrouvent efficacement l’information sur la base des critères aussi bien objectifs que subjectifs. Cependant, avec les exigences de montée en charge et de haute disponibilité requises pour gérer l’explosion du volume de données qui caractérise l’ère Numérique, Apache Lucene s’est montré insuffisant, et c’est là où vient ElasticSearch.

Ce tutoriel  a eu pour objectif de vous aider à monter en compétence sur ElasticSearch, de pouvoir y être opérationnel de suite. Il en ressort qu’ElasticSearch est un moteur d’indexation de contenu très flexible, scalable et simple à utiliser pour développer des applications de recherche de contenu de moyenne ou large échelle. Grâce à la flexibilité de son concept d’index, de son API REST, de l’utilisation du format JSON et de son intégration à Apache Lucene, ElasticSearch permet à des utilisateurs métier de facilement intégrer à des applications, de puissantes fonctionnalités de recherche de contenu. L’utilisateur n’a ni besoin d’utiliser le JAVA, ni besoin d’ajouter à son infrastructure un support pour le stockage de la base de données, il s’appuie juste sur de simples verbes du protocole HTTP pour indexer et rechercher du contenu dans ses données, et sur l’API REST pour intégrer ces fonctionnalités dans son application.

ElasticSearch évolue très vite, spécialement sur son concept d’index. La société Elastic améliore sans cesse la structure d’indexation des données dans ElasticSearch pour l’adapter à de nouvelles problématiques métier. Ainsi, ne soyez pas saisis d’étonnement que les différents schéma d’architectures mentionnés plus haut ou même les concepts d’index décrits ne soient plus correct après cet article. Les principes restent les mêmes, mais la structure évolue. Appuyez-vous sur les ressources citées ci-après pour connaitre les dernières évolutions et mises à jour d’ElasticSearch.

---

Ressources complémentaires

Pour approfondir votre apprentissage sur la recherche de contenu, ElasticSearch, le requêtage multi-critère, consultez les ressources suivantes :

• IDC (International Data Corporation) est un cabinet mondial spécialisé dans le renseignement sur les marchés des nouvelles technologies. Vous trouverez de nombreuses études et recherches sur les problématiques d’utilisation de la donnée en entreprise. https://www.idc.com/research/new
• Lisez notre article « Data Mining – extraire la connaissance d’une base de données textuelle » dans lequel nous expliquons les techniques automatisées de data science qui permettent de retrouver des contenus qui satisfont l’intention de requête des utilisateurs. Ces techniques sont la base de tout SGBD d’indexation ou de recherche de contenu
• Dans ce tutoriel, nous n’aborderons l’installation d’ElasticSearch afin d’éviter d’entrer dans les détails techniques et les configurations nécessaires liés aux différents systèmes d’exploitation. Pour plus de détails sur l’installation d’ElasticSearch, rendez vous sur  https://www.elastic.co /downloads/elasticsearch
• Pour plus de détails sur ElasticSearch et la stack ELK (ElasticSearch, Logstash Kibana) complète, cliquez ici : https://www.elastic.co/fr/
• Pour la documentation complète sur Logstash, rendez-vous sur le lien suivant : https://www.elastic.co/fr/products/logstash
• Apache Lucene est la bibliothèque de classe qui est à la base de tous les moteurs de recherche de contenu. Nous vous recommandons fortement de l’apprendre si vous souhaitez résoudre les problématiques de requêtes multi-critères de vos clients. En plus, elle est complètement open source : https://lucene.apache.org/
• Apache Solr (prononcez « solar ») est une alternative à ElasticSearch. Cliquez sur le lien suivant pour plus de détails. https://lucene.apache.org/solr/

---

Lectures recommandées

Vous pouvez aller encore plus vite et gagner énormément de temps en lisant les ouvrages suivants. Nous vous les recommandons vivement pour développer vos compétences sur la façon dont on aborde les problématiques de recherche/indexation de contenu et apprendre ElasticSearch.