Dans la Partie 1 de cette série d'articles, nous avons présenté les champs stockés et comment modifier la configuration par défaut dans Elasticsearch. Selon notre ensemble de données, changer la configuration par défaut n'a pas amélioré les performances. Ici, nous discuterons de la fonctionnalité de surlignage d'Elasticsearch, de sa configuration et de l'amélioration potentielle des performances que nous pouvons réaliser.

Il est souvent utile de savoir quel mot ou jeton des documents a correspondu à notre requête. Dans Elasticsearch, la fonctionnalité de surlignage du jeton s'appelle, comme vous l'avez deviné, surlignage. Cette fonction peut être gourmande en CPU et chronophage dans certains cas. L'un de ces cas est le surlignage à partir d'un grand champ de texte. Nous verrons les différentes méthodes de surlignage sans entrer dans les détails techniques. Nous comparerons ensuite les performances des méthodes selon nos cas d'utilisation et notre ensemble de données.

Pour mémoire, notre ensemble de données est composé de documents JSON contenant des méta-données comme "titre" et "auteur." Un champ supplémentaire contient le texte extrait du PDF. Ce champ a une taille moyenne de 200K caractères (200 KB).

Surlignage avec Elasticsearch

Nous devons savoir si nous pouvons optimiser le processus de surlignage dans Elasticsearch sur notre ensemble de données. Selon la documentation officielle, nous pouvons paramétrer la façon dont nous voulons surligner nos résultats de recherche. Nous essayerons d'optimiser les performances de surlignage en nous basant sur deux paramètres différents :

1. Stratégie de décalage : Postings : elle ajoutera une localisation de décalage pour chaque terme dans l'index inversé. De cette manière, Elasticsearch pourra rapidement connaître la localisation d'un terme spécifique sans analyse.

Vecteur de termes avec avec_positions_offsets : une structure de données supplémentaire offrant des fonctionnalités avancées pour évaluer les résultats. Selon la documentation officielle, il est censé être le plus efficace pour un champ vaste (> 1 Mo). Il est également susceptible de consommer beaucoup plus d'espace disque.

Note : la configuration par défaut d'Elasticsearch est d'indexer les documents sans calculer de décalage.

2. Surligneur : Unified : avec l'algorithme BM25 pour évaluer le résultat. C'est le surligneur par défaut.

FVH (Surligneur de vecteurs factuels): avec l'algorithme tf-idf, il nécessite l'utilisation d'un vecteur de termes avec_positions_offsets.

Plain : il reconstruit un index en mémoire complet et minuscule au moment de la requête pour chaque document et champ.

Par défaut, Elasticsearch ne construit ni les postings ni les vecteurs de termes. Cela signifie que la fonction de surlignage utilisera le surligneur Unified sans stratégie de décalage.

En choisissant un surligneur particulier, certaines fonctionnalités ne seront plus accessibles. Nous vous recommandons de lire la documentation officielle.

Mesure des performances avec Elasticsearch

Nous avons décidé de mesurer les performances de différentes configurations de surlignage. Ces mesures visent à obtenir une estimation approximative de la meilleure configuration à choisir dans un proof of concept. Ces mesures pourraient être biaisées d'une certaine manière. En effet, notre environnement de test n'est pas sous une charge constante similaire à la production mais dédié à son seul objectif : une estimation approximative!

Notre test a utilisé la propriété résultat "took" comme montant représentatif de millisecondes nécessaire pour que la requête retourne. Nous avons effectué 100 recherches demandant une taille de 1000 documents sur trois index différents, chacun utilisant une stratégie de décalage différente.

Sans surprise, le surligneur plain sans stratégie de décalage sous-performe en raison de sa mise en œuvre technique. Selon notre ensemble de données, le surligneur unifié par défaut avec stratégie de décalage postings semble être le plus efficace. De plus, il semble mieux fonctionner sur notre ensemble de données que le FVH avec la stratégie de décalage du vecteur de termes. Nous pensons que le vecteur de termes avec FVH conviendrait mieux à des champs de texte plus grands comme mentionné dans la documentation officielle (> 1 Mo)

Le vecteur de termes consomme évidemment le plus de stockage disque en raison de sa structure de données supplémentaire. Nous pouvons voir que les postings augmentent l'utilisation du disque d'environ 20%, ce qui est, à notre avis, toujours abordable d'un point de vue commercial.

Si nous prenons en compte les performances et l'utilisation du disque, il ne fait aucun doute que les postings avec un surligneur unifié sont un bon candidat pour notre implémentation.

Recherche de données avec Kibana

Lorsqu'on essaie d'interroger les données avec Kibana, le logiciel de tableau de bord de visualisation des données d'Elasticsearch, vous verrez que c'est très lent. Le problème ne vient pas d'Elasticsearch mais en fait de l'application frontale de Kibana. En effet, Kibana essaiera de charger deux fois tous les grands champs de texte dans la page.

Tout d'abord, le grand champ de texte fait partie du champ source

. Pour accélérer Kibana, vous n'avez pas d'autre choix que d'exclure le grand champ de texte de la source. Vous pouvez le faire dans la configuration du modèle d'index sous l'onglet Filtrage des champs_ dans la version plus récente d'Elasticsearch.

Ensuite, la partie surlignée du résultat de la requête contiendra le grand champ de texte complet au lieu de fragments. Un fragment est juste une partie du texte contenant la valeur surlignée. Jetons un coup d'œil à la partie surlignée de la requête générée lors de la réalisation d'une recherche dans l'onglet découverte :

"highlight": {
   "pre_tags": [
     "@kibana-highlighted-field@"
   ],
   "post_tags": [
     "@/kibana-highlighted-field@"
   ],
   "fields": {
     "*": {}
   },
   "fragment_size": 2147483647
}

Ce qui cause le problème, c'est la taille du fragment qui est la valeur maximale d'un entier. Kibana demande le fragment de surlignage le plus grand possible, ce qui entraîne le chargement du grand champ de texte complet. Kibana le fait parce que nous croyons qu'il n'est pas encore capable de montrer plusieurs fragments de surlignage. Il n'y a pas d'autre choix pour remédier à cela que de désactiver la fonction de surlignage à partir des paramètres avancés de Kibana.

Conclusion

Nous avons découvert que Kibana ne fonctionne pas avec de grands champs de texte, en particulier pour la fonction de surlignage. Si nous voulons faire le lien avec l'article de la partie 1 précédente, il serait logique de ne pas stocker de grands textes pour économiser de l'espace disque par un facteur potentiel de 2. Nous croyons fermement qu'une application front-end dédiée est fortement requise pour implémenter le surlignage avec de grands champs de texte pour le moment dans nos cas d'utilisation particuliers.