Utilisations d'Elasticsearch et leçons à tirer

Introduction

Dans Found, il y a beaucoup de cas d'utilisation différents d'Elasticsearch. On nous demande souvent de décrire notre client type. Or, il n'existe aucune réponse claire à cette question. Tout ce que nous pouvons dire est que notre clientèle préfère consacrer son temps au développement au lieu d'exécuter un tas de clusters. Nous constatons qu'Elasticsearch est utilisée pour un éventail de fins formidables, et dans quelques buts un peu fous aussi !

Elasticsearch est une solution relativement jeune. Notre clientèle tend à l'adopter dans le cadre d'un projet spécifique, puis à ajouter des clusters pour le logging et l'analyse.

L'évolution du développement commence souvent par la conception d'une simple recherche pour un site web ou un ensemble de documents. Ensuite, une navigation à facettes peut être ajoutée, suivie d'un correcteur orthographique ou de corrections des requêtes. Il est possible que les recherches approximatives soient garanties, de même que le remplissage automatique, voire la recherche avec saisie semi-automatique. La pertinence étant importante, des schémas de classement plus avancés sont susceptibles d'être ajoutés en fin de compte, éventuellement en fonction de l'internaute, de sa localisation et de ses relations. Bien entendu, pour savoir ce que les internautes font réellement, l'utilisation doit être enregistrée et les indicateurs doivent être stockés, afin que nous nous assurions que tout fonctionne correctement.

Vous pouvez utiliser Elasticsearch à toutes ces fins, et bien plus encore. Cependant, les différentes utilisations s'accompagnent d'un vaste éventail de niveaux d'exigences en matière de ressources et de complexité.

Qui cherche, trouve (et ce n'est que le début)

Sans surprise, Elasticsearch est souvent utilisée pour implémenter la "recherche". En règle générale, elle prend la forme d'une zone de texte dotée d'une icône en forme de loupe. La signification du mot "recherche" peut être ambiguë dans ce cas. Par conséquent, je mentionnerai différents types de recherches, par exemple "la recherche simple", "la recherche approximative" et l'agrégation. Le mot simple fait référence aux résultats pouvant être obtenus à l'aide d'une requête match ordinaire.

De nombreuses personnes trouvent surprenant que la recherche simple se classe parmi les tâches les moins gourmandes en ressources que vous pouvez exécuter à l'aide d'Elasticsearch. Si vous avez seulement besoin des dix meilleurs résultats pour une requête match régulière non approximative, vous pouvez conserver des centaines de recherches par seconde dans des ensembles de dizaines de millions de documents sur du matériel peu cher. Toutefois, quand vous ajoutez la recherche approximative ou la navigation à facettes à la liste des exigences, il faut beaucoup augmenter le processeur et la mémoire.

En règle générale, il est attendu que les interfaces de recherche modernes soient dotées d'un type de navigation à facettes, où une personne peut rapidement comprendre la distribution des résultats de recherche. Combien de livres ont été écrits par un auteur spécifique, sont vendus dans une tranche tarifaire particulière et ont un classement précis ? Ces caractéristiques sont implémentées dans Elasticsearch à l'aide des agrégations. Elles se présentent de différentes manières. Il est possible d'agréger des mots, des plages numériques ou de dates, des informations sur la distance géographique et bien d'autres données.

Il est contre-intuitif pour nombre de personnes de penser qu'examiner des millions de documents pour trouver des correspondances demande d'une certaine façon moins d'effort que comptabiliser et agréger des correspondances de différentes manières. Néanmoins, l'agrégation est chère par rapport au problème de récupération des informations consistant à identifier les dix documents correspondant à des exigences spécifiques (et étant les plus pertinents selon elles). Lors de la notation permettant d'identifier les meilleurs documents, Lucene utilisera certaines astuces, notamment la suivante : "Cet ensemble de documents ne correspond pas à tous les éléments comme d'autres documents. Il ne s'agit donc pas des meilleurs résultats possibles. Il est alors conseillé de les ignorer." Lors du filtrage, Elasticsearch utilisera beaucoup le cache du filtre. Elasticsearch et Lucene évitent de manière efficace de réaliser des opérations quand elles le peuvent. Cependant, avec les agrégations, elles doivent comptabiliser en permanence l'ensemble des correspondances.

Dans la série d'articles intitulée Elasticsearch sous toutes les coutures, nous expliquons comment l'index inversé fonctionne, mais aussi comment les listes d'affichage et de dictionnaires sont utilisées pour mener une simple recherche. Le présent article et ceux consacrés à l'analyse de textes devraient clarifier la raison pour laquelle il est très important de traiter correctement les textes lors de l'utilisation de la recherche. Les articles dédiés au dimensionnement et à la mise en production d'Elasticsearch détaillent le type d'utilisation de la mémoire auquel vous pouvez prétendre.

Analyse

Les charges de travail d'analyse tendent à compter les éléments et à synthétiser vos données. Il peut y en avoir de grandes quantités, qui peuvent même être liées au big data, si cela signifie quelque chose. Pour réaliser ces tâches, elles se fondent sur les agrégations d'Elasticsearch. Souvent, ces dernières sont générées par des outils, comme Kibana.

Nous avons déjà mentionné que ces agrégations peuvent être relativement chères, mais aussi gourmandes en processeur et en mémoire. Les exigences en matière de mémoire sont conséquentes, car Elasticsearch doit trouver rapidement une valeur à l'aide d'un document spécifique. Dans ce but, il faut charger l'ensemble des données pour tous les documents dans un "cache de champ" enregistré dans la mémoire. Cette tâche peut être allégée à l'aide des "valeurs de document", qui doivent être activées dans votre mapping avant l'indexation des documents.

En outre, les recherches analytiques exécutent souvent des données horodatées, qu'il peut être logique de répartir en index quotidiens ou mensuels, par exemple. Un index par unité de temps facilite la réduction de votre espace de recherche, mais aussi le nettoyage et l'archivage des données obsolètes.

Recherche approximative

Une recherche approximative est indulgente avec les erreurs d'orthographe. Pour donner un exemple, vous pouvez trouver Levenshtein quand vous recherchez Levenstein. Notre article sur les recherches approximatives fournit des informations supplémentaires sur leur utilisation et leur fonctionnement.

Les recherches approximatives sont simples à activer et peuvent améliorer grandement les "rappels". Cependant, elles peuvent aussi s'avérer très chères à exécuter. Par défaut, un mot de l'entrée peut être remplacé par une requête OR composée de 50 mots par champ. Associée à multi_field, cette dernière peut engendrer une explosion combinatoire de termes dans la requête écrite résultante.

Il est toujours important de tester les modifications et les améliorations apportées à vos recherches à l'aide de quantités réalistes de données avant de les envoyer en production. Cela est particulièrement vrai lors de l'ajout du paramètre fuzziness. Cette option est facile à activer, mais rendra vos recherches considérablement plus chères.

Les recherches approximatives sont gourmandes en processeur. Ajoutez-les avec précaution, et probablement pas dans chaque champ.

Remplissage automatique et recherche instantanée

La recherche avec saisie semi-automatique se présente de différentes manières. Il peut s'agir de suggestions simples, notamment de balises existantes, visant à essayer de prédire une recherche en se fondant sur l'historique ou simplement de mener une nouvelle recherche pour chaque frappe de touche (contrainte).

Pour en faciliter le développement, Elasticsearch comprend un vaste éventail de fonctionnalités différentes, notamment les requêtes prefix, match_phrase_prefix, les n-grammes d'indexation et une collection d'outils de suggestion variés.

Ce type de recherches est très sensible aux latences. En règle générale, le seuil des opérations qui ne sont plus considérées comme "instantanées" se situe à 100 millisecondes. La capacité à rechercher quasiment la moindre lettre saisie implique également un débit de recherche plus élevé. Par conséquent, il est essentiel que les recherches soient peu chères et que ces index soient mis en mémoire.

Même si elles affichent les résultats pour les recherches les plus susceptibles d'être complètes, à l'instar de Google, les recherches semi-automatiques doivent être considérées comme deux problèmes distincts. La quantité de données où il faut effectuer les recherches, alors que les précédentes recherches s'exécutent de manière semi-automatique, est probablement inférieure au contenu dans lequel des requêtes sont menées. Ainsi, il est plus pratique de la mettre en mémoire et de réaliser des recherches approximatives. Une recherche semi-automatique engendre une charge bien plus élevée que la recherche complète. Par conséquent, il convient de les distinguer afin de les scaler séparément, voire dans des clusters Elasticsearch entièrement séparés.

Lorsque Soundcloud a remanié son expérience de recherche, l'entreprise a travaillé énormément sur des suggestions. En les implémentant correctement, elle a obtenu une amélioration de la précision des recherches et une diminution non négligeable de la charge pesant sur l'infrastructure propulsant la recherche complète. Les recherches menées par les internautes suivent souvent une distribution Zipf : en règle générale, 10 % des recherches uniques représentent 90 % du volume total. Par conséquent, il est très probable que les résultats complets de la meilleure suggestion de recherche se trouvent déjà dans le cache (soit au sein de votre couche d'application) et peuvent s'afficher "instantanément".

Une grande partie du travail d'ingénierie ayant permis de concevoir l'outil de suggestion de recherche de Soundcloud a mené à la création des fonctionnalités de suggestion d'Elasticsearch. Robert Muir et Simon Willnauer ont animé une excellente présentation sur les suggestions de requête avec Lucene. Je vous conseille vivement de la regarder pour en savoir plus à ce sujet.

Architecture mutualisée

Souvent, plusieurs clients ou utilisateurs disposent de différents ensembles de documents. Une personne ne devrait jamais pouvoir mener des recherches dans des documents qui ne lui appartiennent pas. Ainsi, les systèmes sont conçus de manière à ce que chaque utilisateur dispose de son propre index.

Le plus souvent, cette solution engendre un bien trop grand nombre d'index. Dans la quasi-totalité des cas où des index par internaute sont implémentés, un plus grand index Elasticsearch conviendrait mieux. Il existe d'importants inconvénients à posséder un grand nombre de petits index :

• La surcharge de mémoire n'est pas négligeable. Des milliers de petits index consommeront beaucoup d'espace mémoire. Le nombre de descripteurs de fichier peut également exploser.
• De nombreuses duplications peuvent se produire. Étudiez le fonctionnement de l'index inversé, mais aussi les opérations d'écriture et de compression de Lucene dans les segments.
• Les snapshots et la restauration constituent actuellement un processus en série avec une surcharge par index. La réalisation de snapshots pour des milliers de petits index prend un temps bien plus long que pour quelques grands index.

Lors du dimensionnement d'Elasticsearch, plus d'informations sont disponibles à propos du partitionnement et des stratégies en la matière avec plusieurs références supplémentaires. Il peut être particulièrement difficile de réparer une application à l'aide d'un index dont la conception n'est pas optimale. Par conséquent, prendre le temps de comprendre les différentes approches en vaut vraiment la peine.

Vous devriez probablement ne pas créer un index par utilisateur pour votre application mutualisée.

Indépendance vis-à-vis des schémas/schémas définis par les utilisateurs

En parallèle d'être au service d'une clientèle variée, nous constatons un grand nombre de cas d'utilisation pour lesquels différents utilisateurs peuvent disposer de documents disparates. Par exemple, si vous fournissez des questionnaires/enquêtes auprès des utilisateurs en tant que service, il est probable que ces sondages soient dotés de champs complètement distincts.

Souvent, cette situation incite à utiliser le "mapping dynamique" d'Elasticsearch, parfois présenté comme la conception sans schéma de cette solution. Or, Elasticsearch créera un mapping pour vous en coulisses, ce qui peut se révéler problématique lorsqu'il devient bien trop grand et engendre une "explosion du mapping". Au contraire, il est important de s'assurer que les valeurs contenues dans un document sont bien des valeurs, et pas des champs distincts. Cela est expliqué plus en détail dans cet article consacré aux misères des valeurs/clés.

Elasticsearch est dotée de fonctionnalités de mapping polyvalentes, notamment des modèles d'index, des modèles dynamiques et des champs multiples. Utilisez-les !

Même lorsque vous n'utilisez pas de mapping, vous devez savoir ce que le mapping d'Elasticsearch crée pour vous.

Recherches définies par les internautes

Les schémas définis par les internautes représentent souvent la nécessité de laisser les utilisateurs finaux définir leurs propres recherches à l'aide de filtres personnalisés, de la notation et des agrégations. Une approche courante consiste à limiter la requête de recherche à certains index ou à récapituler les requêtes des internautes à l'aide de filtres.

Malgré cela, lorsque des requêtes de recherche personnalisées peuvent être définies, une personne peut causer des ravages de plusieurs manières, comme l'expression de recherches gourmandes en processeur, la monopolisation de la mémoire ou le plantage d'Elasticsearch. Ces sujets sont abordés dans cet article présentant six manières de planter Elasticsearch et dans celui-ci expliquant comment sécuriser votre cluster Elasticsearch.

Faites preuve de prudence avec les requêtes de recherches définies par les internautes.

Indexation et traitement des documents

Vous pouvez intégrer vos données dans Elasticsearch de différentes manières.

Une rivière est un concept d'Elasticsearch selon lequel la solution extrait des données d'une source, par exemple une base de données à l'aide d'un client JDBC, une file d'attente de messages, un flux Twitter ou l'indexation de sites web. Elle est relativement simple à utiliser, mais l'approche s'avère rapidement compliquée à scaler et à lancer en production. En tant que telles, les rivières sont dépréciées. Il est conseillé de résoudre ces problèmes en dehors d'Elasticsearch. Logstash continue d'être pris en charge sur davantage de systèmes et peut remplacer de nombreuses rivières. Pour les applications personnalisées, tellement de défis doivent être relevés lors de la synchronisation des données vers Elasticsearch et la préparation des documents Elasticsearch qu'une solution simple et générique comme les rivières ne devrait pas être considérée comme suffisante. Lors de l'indexation, les utilisateurs utilisent Scrapy et Nutch en parallèle d'Elasticsearch.

À cela s'ajoutent le traitement et la conversion des documents, notamment Word ou PDF, en textes bruts qu'Elasticsearch peut indexer. Il existe un plug-in "mapper-attachments" qui peut être utilisé pour réaliser cette conversion dans Elasticsearch. Or, bien que ce plug-in soit pratique à utiliser, nous vous recommandons de convertir les documents avant de les envoyer à Elasticsearch. Ainsi, vous bénéficiez d'un plus grand contrôle sur la manière dont les documents sont convertis et améliorés. Une telle conversion de document est, en règle générale, une des premières étapes du pipeline de traitement des documents/textes lors de l'ajustement du contenu. Les documents que vous envoyez à Elasticsearch doivent être le résultat de cette opération de préparation/d'ajustement du contenu, ce qui laisse à la solution la tâche finale d'indexation et de traitement des textes. La conversion de document est relativement gourmande en processeur, mais peut être facilement réalisée en parallèle. Il est préférable de laisser Elasticsearch exécuter l'indexation et la recherche, mais aussi les clients en amont convertir les documents.

Intégrez les données traitées dans Elasticsearch au lieu d'extraire les informations, puis de les traiter dans la solution.

Résumé

Il y a beaucoup à apprendre avec Elasticsearch. Parfois, il peut être difficile de définir ce que vous devez savoir faire.

Dans cet article, nous avons abordé quelques cas d'utilisation courants et éléments importants à connaître en général. J'espère que vous en avez tiré des enseignements pertinents pour vos besoins et que vous avez avancé sur le chemin menant au transfert de votre application Elasticsearch en production.